Why aserai recrut have very slow lvling proces?. As imperials can lvl very fast for example.
-
If you are reporting a bug, please head over to our Technical Support section for Bannerlord.
Aserai recrut lvl speed very low
- Thread starter Lastbrabve1983
- Start date
Users who are viewing this thread
How does that work? Are xp points shared with in that group (leve) of soldiers?
Lets say out of 20 recruits, 10 are ready to level up, but i don't level them up. Then in the next battle 10 get killed. How is it determined whether the 'ready' troops got killed or the ons that werent ready to level up?
Exp is indeed shared in a way. So when you have 20 recruits, and 10 of them are already ready to level up, their kills will still contribute to leveling up the other 10 the same way it would themselves.
Dunno about the death thing. But I assume it's as if those that didnt have exp get killed and you are left with 10/10 ready to level up.
You keep all the XP in case the ten get killed.
Kut
Sergeant at Arms
Imho leveling up troops at times seems a bit too fast to me. At first when you have to be cautious it might take a bit longer, but once you get a good core of T2-3 troops it goes fast. I feel like leveling up in WB was much slower unless you had a bunch of heroes with several points in trainer then leveling flew by.
yes, experience is shared between all troops of the same type. even to the ones injured. so if i have 7+1w troops and i deploy the 7 on the next battle and they kill a bunch of enemies, i could potentially level up all 8 of them, bulk leveling is the best way to train troops.
and to the original question. yes aserai recruits are worse, that's because of their starting weapon. sturgians have the "best" recruits in terms of level speed. and sadly the aserai also have the worst tier 2 troops but starting at t3 they are all good except for the infantry.
Is it verified in the code that troops in a stack share XP like they used to in Warband or is it just an assumption because that's how it's always been? I ask because there are lots of times when I check the after-battle report and it shows a group having earned, say, 3 upgrades, but some of them were killed. Then after the battle there's only 2 can upgrade, which suggests to me that one of the the soldiers who was ready to upgrade got killed and took his xp with him instead of passing it on to the rest of the group. Maybe I'm just looking at it wrong, but it seems a little different than it was in Warband.
Littlepage
Recruit
Look at it this way, if troops of the same type didn't share XP, then the only alternative is to have every troop have its own xp pool, which means that the computational power needed for XP is at least 10 to 30 times what you were using before. It would be utterly stupid not to do it that way, especially when you need all the computational power you can get for battle physics.
The XP stuff is done at the end of the battle, or whenever someone is levelled up. Simple C language calculations like that can be done extremely quickly, you would have to have tens of thousands of soldiers for the xp calculations to make any impact on modern hardware.
There are mods for warband where xp isn't shared and troops are all individuals. They could do this in bannerlord if they wanted, but most people are unlikely to care about the discrepancy mentioned by OP
That does seem like the smartest way to do it. I'm still not sure what would explain the behavior though. Maybe when a group gets enough XP during a battle it sets a level-up flag on one of the individual soldiers, and if that guy dies before the battle's over, you lose the level-up.
NLCRich
Squire
This bit of code is called when on hit to apply XP.
Later,
The below bit of code is called which includes removing the xp when upgrading.
NLCRich
Squire
I am not an expert but it looks to me like the XP is applied to the stack and not the individual troop. Now, I could be wrong because I found this code rather confusing, particularly the more digging that I did. One thing that really made me think this is the stack is in the second block where int num is the upgradexp cost * the total number. Then it sets the elelementXP to subtract that num, which would be the total xp not just for an individual troop. Also, the nomenclature being a FlattenedTroopRosterElement in the first block.
Here's my interpretation of the scoreboard/XP code. XP is applied to individual troops during combat, but those XP gains are not fully committed until after the combat ends. If a troop dies or routs, then the XP that they earned during the battle is lost. However, any upgrades that are earned during the course of combat remain on the scoreboard.
During combat, anytime a troop scores a hit with their weapon, they will earn a chunk of XP (which varies based on certain factors). This earned XP is tracked by each individual troop while the battle is ongoing (each individual troop has a unique identifier). That's what's happening in NLCRich's first screenshot above: the FlattenedTroopRosterElement is a structure for an individual troop, and the troopSeed is the unique identifier for that specific troop.
This XP is also added to a temporary pool of XP for a whole troop stack for the purpose of upgrading the scoreboard. However, the troop upgrade column on the scoreboard can only increase, so even if a troop dies and their earned XP is lost, the scoreboard will not subtract the upgrade. You can see this in the conditional statement of the CheckUpgrade method:
The variable num will be either +1 or -1 to represent troop upgrades gained or lost, but the scoreboard is only updated when num > 0. Here's the TroopNumberChanged method that it calls, which is in the SPScoreboardVM class.
After the battle is over, all of the XP that was earned by each individual troop of a particular troop type is added up and applied to the total XP pool for that stack of troops (e.g. Aserai Recruits or Imperial Archers). So as a simple example, if Aserai Recruit #3 earns 40 XP, Aserai Recruit #7 earns 25 XP, and Aserai Recruit #9 earns 70 XP, then once the battle ends 135 XP is added to the collective XP pool of the stack of Aserai Recruits.
5% of the XP earned by each individual troop is also split between ALL of the troop stacks in the party. Here's the CommitXpGain method:
The second screenshot in NLCRich's post shows the method that handles the player upgrading troops via the Party Menu.
During combat, anytime a troop scores a hit with their weapon, they will earn a chunk of XP (which varies based on certain factors). This earned XP is tracked by each individual troop while the battle is ongoing (each individual troop has a unique identifier). That's what's happening in NLCRich's first screenshot above: the FlattenedTroopRosterElement is a structure for an individual troop, and the troopSeed is the unique identifier for that specific troop.
This XP is also added to a temporary pool of XP for a whole troop stack for the purpose of upgrading the scoreboard. However, the troop upgrade column on the scoreboard can only increase, so even if a troop dies and their earned XP is lost, the scoreboard will not subtract the upgrade. You can see this in the conditional statement of the CheckUpgrade method:
The variable num will be either +1 or -1 to represent troop upgrades gained or lost, but the scoreboard is only updated when num > 0. Here's the TroopNumberChanged method that it calls, which is in the SPScoreboardVM class.
After the battle is over, all of the XP that was earned by each individual troop of a particular troop type is added up and applied to the total XP pool for that stack of troops (e.g. Aserai Recruits or Imperial Archers). So as a simple example, if Aserai Recruit #3 earns 40 XP, Aserai Recruit #7 earns 25 XP, and Aserai Recruit #9 earns 70 XP, then once the battle ends 135 XP is added to the collective XP pool of the stack of Aserai Recruits.
5% of the XP earned by each individual troop is also split between ALL of the troop stacks in the party. Here's the CommitXpGain method:
The second screenshot in NLCRich's post shows the method that handles the player upgrading troops via the Party Menu.
NLCRich
Squire
Thanks for clarifying. I spent a long time looking at this and did have some trouble figuring it out. I saw the commitxpgain method as well and understood most of it but I couldn't tell that the FlattenedTroopRosterElement was actually an individual troop. I did second guess myself on that part a couple times. What I didn't find was the CheckUpgrade method. I was looking for that... I knew the latter bit I posted was when the upgrade was commited. I was looking at how the backend dealt with the xp which did sort of lead me in the right direction there. However, after your response, it all makes sense. I feel like I just gained some XP lol.. That is why you are the C# Sleuth...Here's my interpretation of the scoreboard/XP code. XP is applied to individual troops during combat, but those XP gains are not fully committed until after the combat ends. If a troop dies or routs, then the XP that they earned during the battle is lost. However, any upgrades that are earned during the course of combat remain on the scoreboard.
During combat, anytime a troop scores a hit with their weapon, they will earn a chunk of XP (which varies based on certain factors). This earned XP is tracked by each individual troop while the battle is ongoing (each individual troop has a unique identifier). That's what's happening in NLCRich's first screenshot above: the FlattenedTroopRosterElement is a structure for an individual troop, and the troopSeed is the unique identifier for that specific troop.
This XP is also added to a temporary pool of XP for a whole troop stack for the purpose of upgrading the scoreboard. However, the troop upgrade column on the scoreboard can only increase, so even if a troop dies and their earned XP is lost, the scoreboard will not subtract the upgrade. You can see this in the conditional statement of the CheckUpgrade method:
The variable num will be either +1 or -1 to represent troop upgrades gained or lost, but the scoreboard is only updated when num > 0. Here's the TroopNumberChanged method that it calls, which is in the SPScoreboardVM class.
After the battle is over, all of the XP that was earned by each individual troop of a particular troop type is added up and applied to the total XP pool for that stack of troops (e.g. Aserai Recruits or Imperial Archers). So as a simple example, if Aserai Recruit #3 earns 40 XP, Aserai Recruit #7 earns 25 XP, and Aserai Recruit #9 earns 70 XP, then once the battle ends 135 XP is added to the collective XP pool of the stack of Aserai Recruits.
5% of the XP earned by each individual troop is also split between ALL of the troop stacks in the party. Here's the CommitXpGain method:
The second screenshot in NLCRich's post shows the method that handles the player upgrading troops via the Party Menu.
So, individual troop in battle and applied to the stack after battle. Makes sense. Pretty much along the same lines most people were thinking.
Thanks for the great explanation. So in the end, they do pool their xp after all, so holding off on upgrading units until the whole stack is ready to upgrade is still the fastest way to level them. I'm glad its still like that.Here's my interpretation of the scoreboard/XP code. XP is applied to individual troops during combat, but those XP gains are not fully committed until after the combat ends. If a troop dies or routs, then the XP that they earned during the battle is lost. However, any upgrades that are earned during the course of combat remain on the scoreboard.
During combat, anytime a troop scores a hit with their weapon, they will earn a chunk of XP (which varies based on certain factors). This earned XP is tracked by each individual troop while the battle is ongoing (each individual troop has a unique identifier). That's what's happening in NLCRich's first screenshot above: the FlattenedTroopRosterElement is a structure for an individual troop, and the troopSeed is the unique identifier for that specific troop.
This XP is also added to a temporary pool of XP for a whole troop stack for the purpose of upgrading the scoreboard. However, the troop upgrade column on the scoreboard can only increase, so even if a troop dies and their earned XP is lost, the scoreboard will not subtract the upgrade. You can see this in the conditional statement of the CheckUpgrade method:
The variable num will be either +1 or -1 to represent troop upgrades gained or lost, but the scoreboard is only updated when num > 0. Here's the TroopNumberChanged method that it calls, which is in the SPScoreboardVM class.
After the battle is over, all of the XP that was earned by each individual troop of a particular troop type is added up and applied to the total XP pool for that stack of troops (e.g. Aserai Recruits or Imperial Archers). So as a simple example, if Aserai Recruit #3 earns 40 XP, Aserai Recruit #7 earns 25 XP, and Aserai Recruit #9 earns 70 XP, then once the battle ends 135 XP is added to the collective XP pool of the stack of Aserai Recruits.
5% of the XP earned by each individual troop is also split between ALL of the troop stacks in the party. Here's the CommitXpGain method:
The second screenshot in NLCRich's post shows the method that handles the player upgrading troops via the Party Menu.
