Author Topic: exp calculation (Read 220 times)

Dolfo

I have simplified the exp calculation on my local server.

Edit:
Changed the calc for a linear +/-1% each level difference.
Edit:
Changed it to a mirrored sqare root curve. See the ranges in coments below.

Code: [Select]

// who is exp source(monster), op is exp target(player)
// we need to return a float, where 1 is 100%
float calc_level_difference(int who_lvl, int op_lvl)
{
 /* some sanity checks */
 if (who_lvl<0 || who_lvl>200 || op_lvl<0 || op_lvl>200)
 {
  LOG(llevBug, "Calc_level:: Level out of range! (%d - %d)\n", who_lvl, op_lvl);
  return 0.0f;
 }

 // float factor=1.0f-((float)(who_lvl-op_lvl))/10; // this is loosing/gaining 10% for each level, not the best formula
 // float factor=1.0f-((float)(who_lvl-op_lvl))/100; // this is loosing/gaining 1% for each level, better, but perhaps boring?

 // calculate abs and sign
 int lvl_relativ = who_lvl-op_lvl;
 int lvl_absolut = abs(lvl_relativ);
 int lvl_sign = (lvl_relativ > 0) - (lvl_relativ < 0);
 // float factor=1.0f-(float)(lvl_sign*lvl_absolut)/100; // test if sign and abs is correct
		
 // log(1)=0 where log(0) is not not defined (unlimited), so we adjust +1
 // float lvl_abs_log = log(1+lvl_absolut); // so we have on level difference 0 log(1)=0
 // logarithms is not a nice curve, lets try square root curve
		
 int percent = sqrt(lvl_absolut) * 10; // this could be adjusted, currently this means
 // level difference leads to +/-x%
 // 0 = 0%
 // 1 = 10%
 // 4 = 20%
 // 9 = 30%
 // 16 = 40%
 // 25 = 50%
 // 36 = 60%
 // 49 = 70%
 // 64 = 80%
 // 81 = 90%
 // 100 = 100% (this is means exp when player is +100 level over mob)
 // 121 = 110% (where minus exp don't go under 0, when we check for it in return line)
		
 float factor=1.0f-lvl_sign*((float)percent)/100.0f;
 return (tmp >= 0) ? tmp : 0.00f;
}

The old color logic is not really nice, because:

1. we can exactly calculate a factor, when we know level of player and monster
2. there is no need to adjust this by a colored foldersystem
for example

Killing an ant soldier level 1 with a level 3 char we gain 44 exp, killing a black widow level 2 with a level 3 char we gain 63 exp.
Doing same with a level 4 char we gain 37 exp for the ant soldier and 26 exp for the black widow.
This is because the color logic has put the widow in same color folder like the ant now, but widow is 1 level higher than ant. Of course this example is also twisted because map exp definitions from ant is higher than the widow. But this example is enough to show the problem with this color folders.

3. The code for the color adjustment is unessary logic and brain weight to coders to read this.

4. The color logic is nice for visual effects, helping players to get a fast information of the dangerous of a monster. We should keep it there, but not for exp calculation.

We can only win, when we remove this exp mess, we have also changed this for grey mobs and removed the grey = 0 exp cap in here for season. Why not remove this complete and build one nice formula for this?

Dolfo

I go deeper here. This i such a mess, everywhere the exp is changed. Why we need special handling of exp for players in range up to level 7? And all players above 7 gain only 85% exp? That's unbelievable. I removed this shit. If we want calculate, we should do this with one nice formula, but not with 100 code lines spreaded all over the server. Pain.

calc_skill_exp- outcommented max_mul factor

Code: [Select]

/*if (who_lvl < 2)
   max_mul = 1.15f;
  else if (who_lvl < 3)
   max_mul = 1.10f;
  else if (who_lvl < 4)
   max_mul = 1.05f;
  else if (who_lvl < 5)
   max_mul = 1.0f;
  else if (who_lvl < 7)
   max_mul = 0.95f;
  else if (who_lvl < 8)
   max_mul = 0.9f;
  else
   max_mul = 0.85f;*/
...
 tmp = ((float) (exp_threshold[who_lvl + 1] - exp_threshold[who_lvl])); // * 0.1f * max_mul;

Dolfo

Wow that's great, looking the function parameter of

Code: [Select]

  int calc_skill_exp(object_t *who, object_t *op, float mod, int level, int *real)

where mod is a direct modificator and real can overwrite the exp calc.

checking all calling functions
[/code]
D:\_daimonin\season\server\src\server\aggro.c (8 hits)
Line 387: calc_skill_exp(hitter, victim, 1.0f, aggro->level, &exp);
Line 397: e1 = calc_skill_exp(hitter, victim, 1.0f, pl->skill_ptr[s1]->level, &exp);
Line 406: e1 = calc_skill_exp(hitter, victim, 0.65f, pl->skill_ptr[s1]->level, &exp);
Line 408: e2 = calc_skill_exp(hitter, victim, 0.35f, pl->skill_ptr[s2]->level, &exp);
Line 422: e1 = calc_skill_exp(hitter, victim, 0.55f, pl->skill_ptr[s1]->level, &exp);
Line 424: e2 = calc_skill_exp(hitter, victim, 0.30f, pl->skill_ptr[s2]->level, &exp);
Line 426: e3 = calc_skill_exp(hitter, victim, 0.30f, pl->skill_ptr[s3]->level, &exp);
Line 569: calc_skill_exp(high, victim, 1.0f, high->level + high_drain_level, &exp);
in relation to this overwrite logic

Code: [Select]

 if(real != NULL)
 {
  if(*real > 0)
   op_exp = (int)((float)(*real)*mod);
  else if(*real == 0)
   *real = op_exp;
  }

we have 3 situations
- without real pointer(=null) we keep our calculation modified by mod
- with real pointer>0 we overwrite our full calculation, we had done before and return real*mod
-> this check should be put at the beginning of the logic, no need to calculate something, when we don't use it
- we have real pointer=0, this is same then real pointer null, where we only addional update the value of this pointer.

So a lot of strange behavior, this means group exp is calculated somewhere outside exp.c. I try to look deeper there. Group exp is also bad player feeling. It's mostly impossilbe to train skills in group. We should really rebuild group logic to make it fun for players. Give a kind of community bonus, when players group together.

Dolfo

This was pain. Our object structures and my missing pointer experiences gave me some hard challenges.

I changed aggro_exp_single function in aggro.c. I have seen that we have a full history on skills players used on monsters. Why we limit this to 3 skills only exp gain? And why we use this strange 3 steps calculation, when we have full informations in this history?

So i changed this. If you hit a 5hp ant with 1 damage skill1 and 4 damage skill2, skill1 get 20% and skill2 gets 80%. This also make the logic more readable and shorter, except my comments. ;-)

Of course players can't no more hit an icegolem with icebolt for 0 damage, kill with other non ma skill and get exp for ma. Now it's a clean definition.

"You get what you hit."

I must spend a lot more time to test this and also continue to make this for multiplayer game nice. Dunno how this looks there. I know there are coming a lot more problems. But single player looks fine so far. Here is code.

Edit: I have removed code here. You can find it on github.
https://github.com/Kamor/Dolfo/blob/main/code/aggro_exp_single

Shroud

I don't know if it affects anything but there is also an XP cap per level. This means that for example if a lvl 1 kill a lvl 110 mob they'd get the same as if they had killed a much lower lvl mob. This is also applied before guild XP modifiers.

Dolfo

Yeah exp cap is max 1/4 level, so you must at least kill 4 mobs for a level. Hm ok, exp cap should be last in exp_adjust, we should change this by time. But currently i stuck on all this exp code everywhere and try to understand the logics.

For the moment i have updated the lowest end of this exp chain/train. Colors are gone totaly from exp calculation, instead i use currently a simply linear formula where 1 level difference means +/- 1% exp.

So a level 11 killing a level 1 gains 90% where a level 100 killing a level 1 gains 1% and up this is goes to 0 exp. I tried also a kind of logarithm curve, but failed for the moment. I don't want waste more time here, when i need to look at ALL other places for exp calculations to clean this mess.

But so far single player can use all skills. Would be funny to see the client messages, when a player hit a monster with all 5 ph mellee skills, all 4 ag ranged skills, 2 ma skills and 1 wi skill. I will try this by time.

I have updated the logic in first post.

Dolfo

Ok i told nonsense above. Found the guildbonus in basebonus logic. This is calculated before the cap. So this is good.

I cleaned more of the code. Looks so far ok. Need some more cleaning and i must try to understand one more logic from old code and if this was bugged there before or i made a bug on my reinterpretation of this logic. I updated above code so far.

But to make it easier i uploaded my changed functions here.

https://github.com/Kamor/Dolfo/tree/main/code

I changed the old color logics to a mirrored sqare root formula. Currently its adjusted this way:
// level difference leads to +/-x%
// 0 = 0%
// 1 = 10%
// 4 = 20%
// 9 = 30%
// 16 = 40%
// 25 = 50%
// 36 = 60%
// 49 = 70%
// 64 = 80%
// 81 = 90%
// 100 = 100%
// 121 = 110%
for minus exp, exp is adjusted to 0, so a level 101 player gets 0 exp killing a level 1 ant

Guildbonus (Basebonus) also works now, if found also definitions (bonuses) for non guild players, which looking strange to me, because non guild players should be the default exp, what all the exp calculations work out. Adjusting this in bonus(base) definitions in unclean logic and more a hack to balance player exp. But this is more complain at a high level.

These are the bonuses i found
// *** guildbonus ***

guildless
// base_skill_group[0] bonus ph = 25
// base_skill_group[1] bonus ag = 15

// mercenary guild
// base_skill_group[0] bonus ph = 55
// base_skill_group[1] bonus ag = 45

Dolfo

I made a screenshot, so you can see my solution for single player exp.

For single player this means, you get what you hit.
So for example you hit a monster with 51% to get the aggro and lure this to a npc guard or another player finish the kill, your exp is also only 51% from this monster.

Now you can use throwing weapons to lure a distance monster without getting punished in your main skill. In example above i lured the enemy with one throwing weapon and finished with close fight.

I inflicted 37 damage with melee pierce and 1 damage with throwing dagger. So the exp from monster is splitted in relation to this. Also the level difference between used skill and enemy is in here.

I my rewrite i made the mistake to grant +% exp for killing higher monster, instead of capping this like the current exp system does. Currently i like it. This means, if a player manages to kill higher monsters, why we should cap him for? We have always in last instance the 1/4 level cap, what is good. In past this high level monster cap led to strange player feelings, where they don't understand why they get more exp, when killing lower monsters. But i can easy change this back, it's only a sign i must remove from calculation.

Now start to thinking for group players, i think i wanna try an equivalent logic, with mostly one difference. All monster exp is given to the players in relation to their damage. So players will not be punished in groups, when they try to train low skills.

In past this always led to something like, "your skill is to low to get exp". Also our current system, where one player can run behind the other player doing nothing, getting exp equivalent to his guild, is not the best logic. I will also try here, what you hit is what you get.

Think of 4 players joining team, one is normaly to weak to fight, where the team goes, but he can inflict some few damage. Perhaps he manged to inflict 5% of the total team damage. And then this monster is some levels above him, so he get also some bonus here. And finally this monster has a nice ground exp value. So this is also a win for this lower player in a higher group.

Don't speak about the other members allow him to loot all the coppers.

So yeah, exp group bonus can be fast done, when groups fighting higher mobs and have higher kill speed.

But using such a logic, we need to think also about healing priests behind the lines. How we can reward them? We can't say give all non hitting players a guild exp bonus, because there is a different between a hard working (healing) priest in background and a passiv sightseeing only chasers char. So we need to find an interesting way to help our priests here. More they heal, more they gain exp?

Dolfo

I am one step closer. Implemented the logic to groups.
Player 1

Player 2

This idea of "you get what you hit" also means, you don't need to check, if players are close to you. So this is the next function i don't need to call, when using this system.

Also i have done this in above example.

Player 1 inflicted 2 damage points, leaved the map.
Player 2 inflicted 3 damage points, killing enemy
Both players get their exp equivalent to their inflicted damage, so player 1 40% and player 2 60%

I don't know what old logic had done in this situation? Grant exp to both or only the one player on map?

Dolfo

I included a logic for passiv but close players for quest kill rewards.

In this example it worked fine. I invited another player, he killed ant boss, i was passiv but close to ant boss and got my quest reward. This must be tested more, but i think my logic is very close to a safe logic. I also cloned the old tripple distance to a double distance check. No need to check if a passiv player is close to kill target and to player in group with most agro. That's unnecessary in my opion. Also used a cleaner logic to target quest check for passiv players, than the old logic, i hope. Distance check is also only nessessary on passiv players.

So group members can now be activ, make some damage and leave the map and get the quest reward or be passiv, than they need to be close to the kill target to get the reward.

The thing with guards stealing 49% exp, when they inflict 49% damage, currently not work. I am lucky to made the code working to browse the aggro history for players and group members. I will look there later. But for the moment, i think this logic is ready for tests and for discussing.

I summarize the above.

1. Logic didn't use anymore the special exp tuning for level 1-7.
2. Logic didn't use anymore the color logic for level differences.
-> For the moment it uses a mirrored square root logic
3. Logic grants bonus exp, using lower skills on higher monsters, instead of caping exp here.
-> I need really feedback here, what is better?
4. Single player didn't split used skills anymore to a fixed logic, where we get (100%) (65%/35%) or (55% 30% 15%(30% bugged)
-> instead it uses the above square root curve
5. Group player exp is not more adjusted to highest player, to punish all other players
6. Group player currenty i removed the +10% bonus in there for each extra player
7. Group player didn't devide the exp anymore by player count
-> instead each player "get what he hits"
8. Group player also didn't use anymore the skill tripple logic leading to a group play, where low skill training is impossible.
-> So currently group logic gives no group exp bonus, but also no punish here.
9. I temporary removed the guild exp bonus for passiv players, but its only one outcommented line to activate this logic again.

We need really to decide, if we want players running behind other players doing nothing, getting exp, or focus on activ players rewarding them? We want a nice skill training experience in group or a free exp on running behind other players?

As is said above i allowed passiv players to get kill quest trigger, when they are close to the kill target. I think forcing players to make at least one damage, to get this trigger is not really funny for groups.

Dolfo

example /setglobalexp and /exp

example kill mob

This is so far, how it looks. I am close to finish the exp chain.

server exp should be a kind of adjustment by code only, like season server, fastexp server, hard grind server, classic server. In above example this is not included in calculation.

global exp should be a kind of global adjustment for bonus/malus. This can be used for special exp hours, like happy hours, double exp hours, tripple exp hours up to exp^10, but can also be used to reduce exp, like half exp or till down to 0 exp, for pre events for special events like world bosses or townraids. This is also showed in (bonus) when players getting exp by killing mobs.

Base skill groups players can see their guildbonus.

I found now the missing piece for my logic. The current "high" dynamic is targeting a table, where it gets its factor in relation to monster level. You can see this in exp for this skill, where skill difference and this monster level goes in.

I want to change this and putting this monster level factor * exp in monster generation process. So we have a clean split.
Generating monster exp, by map exp, arch exp (or by default server value), adjust by server exp, adjust by level, by masks, ...
and
Killing monster
Split exp to group members in relation to there inflicted damage. Adjust exp in relation to used skills. Adjust base(guild) skill bonus, adjust personal bonus and global_exp_bonus.

Dolfo

So far i started the split. Exp level adjust and server adjust is before skill adjust.

But i am doing this still on "skill adjust" when killing a mob. I have seen that fix_monster is overwriting op->stats.exp and op->level. So i need to read there deeper first.

In relation to level drain, we have also a logical bug, because draining mechanics changes op->level and if we drain monster levels with drain attack items, we are loosing exp. And not only once, we loose exp in the exp level calculation AND in the skill against monster level calculation.

But back to topic. In above example i killed a level 1 ant, with server 200% exp. This is a little more than the manuel adjusted ant maps had before, but also adjust the other maps. I remind, on public trunk all maps get their exp from arches except the ant maps, what leads to bad exp on all maps except the ant maps.

With cleaning the ants from manuel exp and adjusting the serverexp, i fixed this inbalance on public trunk maps. Dunno how the common mapper behavior is on non public maps. Do they have used a lot of this adjusting exp in maps?

Author Topic: exp calculation (Read 220 times)

Dolfo

exp calculation

Dolfo

Re: exp calculation

Dolfo

Re: exp calculation

Dolfo

Re: exp calculation

Shroud

Re: exp calculation

Dolfo

Re: exp calculation

Dolfo

Re: exp calculation

Dolfo

Re: exp calculation

Dolfo

Re: exp calculation

Dolfo

Re: exp calculation

Dolfo

Re: exp calculation

Dolfo

Re: exp calculation

Related Topics