Skill rate slow doan near max skill

[Shendare]

Nice! There's hardly anything you can't do with scripting these days!

[Kingly_Krab]

Exactly, haha, all it takes is some TLC and you can do whatever you want.

[AdrianD]

I'm trying to find where in the code the different skills have different values for `chancemodi` (or is it `mod_increase_skill_chance`?).

I've searched the code and can't indentify where the different skill up mod rates are located.

Please point me in the right direction.

Snippet I'm referring to, client.cpp (~2292):

	if (skillval < maxskill)
	{
		// the higher your current skill level, the harder it is
		int32 Chance = 10 + chancemodi + ((252 - skillval) / 20);

		Chance = (Chance * RuleI(Character, SkillUpModifier) / 100);

		Chance = mod_increase_skill_chance(Chance, against_who);

		if(Chance < 1)
			Chance = 1; // Make it always possible

		if(zone->random.Real(0, 99) < Chance)

The categories are somewhat apparent even without logging features enabled.

Initial observations - very low skill levels
	- logs shows mod default level of 22% at low skill levels
	- initial observations show defense/offense/weapon skills set to a default 22% - 15
	- certain skills appear to be set at a default level (22%) - 10 (dodge12)		
	- certain skills appear to be set at a default level (22%) + 15 (tracking53)
	- certain skills appear to be set at a default level (22%) + 10 (taunt73)
	- certain skills appear to be set at a default level (22%) + 5 (sneak42, bind wound9, forage27)
	- certain skills appear to be set at a default level (22%) + 0 (casting skills)
	- certain skills appear to be set at a default level (22%) - 17 (swimming50) although I'm guessing this is set differently - false

EDIT: I searched `CheckIncreaseSkill` and I think I found what I was looking for.

[AdrianD]

I went ahead and graphed the current skill up rates I am aware of. I graphed a few more equations I may add to the code

I was working within the confines of the graphing program so, the equations would normally be a little cleaner. (plus I haven't had to work with quadratics for 20+ years)

- http://prntscr.com/8klhn0 = current skill rates

- http://prntscr.com/8klhv3 = possible skill rates

* If you look at the graphs, x-axis is skill level and y-axis is % chance

My question is, do you foresee issues when x = 0 or, in this case the skill is 0.

EDIT: with the equation being <-sqrt((x^2)/2x) + 10> or <-sqrt(x/2) +10>

Thanks

EDIT: I tried a different equation which does a better job, imo.
Not as concerned about the equation unless someone can recommend a better one. (just tinkering with it)

<-root(3, 3.75x) +10> negative cube root of 3.75x + 10
* this may also solve any issues with skill = 0 since it intersects exactly at + 10

- http://prntscr.com/8km9zo = possible skill rates2

- http://prntscr.com/8km8lg = apples to apples
EDIT: above is something I would consider

[Shendare]

I had totally forgotten about this... but I remember SOE explaining years ago -exactly- how skill ups work in EQ Live. I think it was a dev explaining it during an SOE Fanfaire or something.

Every skill in the game has a difficulty number associated with it. They start at 1 for combat skills, and climb up to (IIRC) 15 for things like Beg that are designed to skill up very slowly.

Every skill may or may not have an alternate stat associated with it in addition to the regular INT/WIS for skillup frequency. Archery and backstab had DEX as an alternate stat, for example. Defensive skills often had AGI. Begging I think had CHA. If it doesn't have an alternate stat, it's categorized as just a general skill and is slightly harder to skill up, being given a stat mod of -15.

Most skills also have a situation where the skill check either succeeds or fails. I can't think of how Swimming, for example, would have a succeed/fail check, though.

The factors above work together to end up with the following skillup logic:

StatEffect = AlternateStat ? Max(INT, WIS, ALT) : (Max(INT, WIS) - 15)
SucceedFail = SkillCheckSucceeded ? 1 : 2

Chance1 = StatEffect / Difficulty / SucceedFail

If Roll(100) < Chance1, there's then a second check to make skill increase faster at lower values (100% at 0 skill if you pass Roll 1) and slow down to a minimum of 5% chance as your skill increases up to 190, after which it's just the Skill Difficulty and your Stats that affect skillup rate.

Chance2 = 100 - Min(95, CurrentSkill / 2)

[AdrianD]

Thanks for further explaining how it works, appreciate it.

I'm not sure what the rates are on live, now. What I have observed on the emu doesn't make a lot of sense to me, though.

If these are current live rates, from what I have observed, what I tested briefly with logsys, what my follow-up searches found and what the graphs verified, it's something I am definitely changing. Absurd to think some skills will never have a skill-up rate below 20%.

I have wanted to do this for quite a while. It's one of the first things I noticed when in game. It seems <client.cpp (~2292)> governs the rate in many circumstances. I will no doubt look into those areas you mentioned Shendare.

[starblight]

So from what I can tell by the graphs weapon skills start at 10% chance decreasing to 1% chance at skill level 200. Then to get from skill level 200 to 295 you are looking at a 1% chance?

[AdrianD]

I haven't parsed it and I haven't looked at the other influences that Shendare linked (which probably alter the slope and theoretical x/y intercepts) but, from observations (noticing more or less skillups) and confirming with logging features, what you state is true.

Using the rule_values mod for skilluprate won't have any effect on skills after they reach the x-axis, with the current equation (or any equation, might I add). This varies substantially, as you can see in the graph. Swimming, for example, will never be easy (as it should be?) without scrapping it's coeffcient. Other skills on the higher end will skill up 50+ X faster (with rules set for higher skillups). Doesn't make sense to me.

[Rakkoraz05]

Originally Posted by Kingly_Krab

As for Shendare's resolution, you can also do that in Perl (this would go in your global_player.pl):

sub EVENT_LEVEL_UP {
    foreach my $skill (0..55, 62, 66, 67, 70..74) {
        if($client->CanHaveSkill($skill) && $client->MaxSkill($skill, $client->GetClass(), $ulevel) > $client->GetRawSkill($skill)) {
            $client->SetSkill($skill, $client->MaxSkill($skill, $client->GetClass(), $ulevel));
        }
    }
}

So i added the above to the global_player.pl and it doesn't seem to be working for me. Are there syntax that need to be updated?

[Andvari]

Originally Posted by Rakkoraz05

So i added the above to the global_player.pl and it doesn't seem to be working for me. Are there syntax that need to be updated?

Unless I'm mistaken (I'm new here), EQEmu now prioritizes .lua files over .pl files. So if there is a .lua file of the same name, the .pl file will be ignored.

That being said, here's some lua for you! This is the first piece of lua I've ever written, so it could probably be optimized by somebody that knows what they're doing. But this works to, on each level up 1) maximize [I]all[I] skills, including tradeskills and lockpicking etc., 2) scribe all spells up to current level, and 3) train all disciplines up to current level.

This goes in your server/quests/global/global_player.lua file.

View it on GitHub for some syntax highlighting

function event_level_up(e)

	-- All skills except caster specializations
	local skills = { 0,  1,  2,  3,  4,  5,  6,  7,  8,  9,
			10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
			20, 21, 22, 23, 24, 25, 26, 27, 28, 29,
			30, 31, 32, 33, 34, 35, 36, 37, 38, 39,
			40, 41, 42,                     48, 49,
			50, 51, 52, 53, 54, 55, 56, 57, 58, 59,
			60, 61, 62, 63, 64, 65, 66, 67, 68, 69,
			70, 71, 72, 73, 74, 75, 76 };

	-- Determine max possible skill and assign it at each level up
	for k,v in ipairs(skills) do
		local max_skill = e.self:MaxSkill(v);
		local raw_skill = e.self:GetRawSkill(v);
		local can_have = e.self:CanHaveSkill(v);
		if ( max_skill > 0 and raw_skill < max_skill and can_have ) then 
			e.self:SetSkill(v, max_skill);
		end
	end

	-- Determine if client is a caster and can specialize
	if ( e.self:CanHaveSkill(43) ) then

		-- Specialization skills
		local special = { 43, 44, 45, 46, 47 };
		-- Create tables of raw skills and max skills
		local raw_skills = {};
		local max_skills = {};
		for k,v in ipairs(special) do
			raw_skills[k] = e.self:GetRawSkill(v);
			max_skills[k] = e.self:MaxSkill(v);
		end

		-- Check each specialization and determine what to do
		for k,v in ipairs(special) do
			if ( raw_skills[k] == 50 ) then
				-- do nothing
			elseif ( raw_skills[k] > 50 and raw_skills[k] < max_skills[k] ) then
				e.self:SetSkill(v, max_skills[k]);
			elseif ( raw_skills[k] < 50 and raw_skills[k] < max_skills[k] ) then
				if ( max_skills[k] <= 50 ) then
					e.self:SetSkill(v, max_skills[k]);
				else
					e.self:SetSkill(v, 50);
				end
			end
		end
	end

	-- Scribe all spells up to current level
	eq.scribe_spells(e.self:GetLevel());

	-- Train all disciplines up to current level
	eq.train_discs(e.self:GetLevel());
end

The conditional checks for caster specialization skills seem to be necessary. At least on the RoF2 client, if you have multiple specializations above 50, all specializations then get reset to 1 as soon as you cast a spell that would trigger a specialization skill-up. Not sure if other clients behave the same way.

The basic idea for the specialization conditionals came from this post. Sadly, I know even less about perl than lua. I did my best to translate c0ncrete's idea.

[Uleat]

Originally Posted by Andvari

EQEmu [sic] now prioritizes .lua files over .pl files.

That is correct.