trying to understand retraining/recruitment mechanics

[wipo]

Hello,

I've got two questions regarding retraining/recruitment pools


first, do they work the same?


let's take this line for example :

recruit_pool "AS Rocket Launcher" 1 0.5 3 0 requires factions { mongols, }

so, unless I misunderstood things, it's gonna work this way :

(start) 1 point - 1 rocket launcher available for recruitment
(+1 turn) +0.5 pt = 1.5 pts
(+1 turn) +0.5 pt= 2 pts - 1 rocket launcher available for recruitment
(+1 turn) +0.5 pt = 2.5 pts
(+1 turn) +0.5 pt = 3 pts - 1 rocket launcher available for recruitment

is the rule the same when retraining this unit?


my second question, can you use two different lines for the same unit (in the same building)?

one for 'slow' recruitment, one for 'fast' retraining

like this for example :

c_cannon_foundry castle requires factions { northern_european, middle_eastern, eastern_european, southern_european, } and event_counter not_pagan_lithuania 1 and event_counter gunpowder_discovered 1
{
convert_to 5
capability
{
recruit_pool "AS Rocket Launcher" 1 0.5 3 0 requires factions { mongols, } recruitment
recruit_pool "AS Rocket Launcher" 0 0.99 0.999 0 requires factions { mongols, } retraining


thanks!

[Taiji]

First question. Yes that is how it works.

Second question. Yes that will work.

[wipo]

ok, good!

thanks for your help

[Augustus Lucifer]

Second question. Yes that will work.

How specifically will it work? It won't CTD, that's true. But there's no condition that can be applied to check when a unit is being retrained vs. when it's being recruited. It can work if you set event counters for 'unique units' which toggle off the former pool, but otherwise I don't know of a way to do it like he suggests.

My tests of it show that the game will read the last pool of a given unit in a given building when more than one are applicable and ignore the rest. If others have different results please share because it's an important relationship.

[Taiji]

OK, I tested and I was wrong.

Where there are duplicate units set up for training and recruitment, the game uses the pool with the whole number.

With duplicate units that both have pool a no smaller than 1, both entries are displayed in game with 2 options for recruiting.

[Augustus Lucifer]

I think we need to start a research project with the goal of determining the exact parameters of recruitment pools. I tried getting my team to test some things for me in that department many moons ago but the results I received were still not well planned enough to provide a conclusive behavior. My inconclusive findings were described in brief as:

After reviewing the test results and making a few edits and testing it more myself(mainly by making sure that the sum of A and B doesn't equal B), I've concluded that when two pools of the same unit in the same building are active at the same time, the game will read the latter pool and ignore the former.

I've also concluded that the game either stocks the pools before running the FactionTurnEnd event(possibly at the SettlementTurnEnd event), or that somehow the counter isn't read by the EDB as being active until after the pools are stocked. This is instanced by the fact that the second pool should activate on the first end turn(and it is active the next turn as shown by the experience), but you only gain 1 unit, which is the replenish rate of the former pool.

What we really need is to design some numbers and develop counter-proofs, then get multiple people to test it to rule out everything but one behavior for the various stats like replenish rate, max, and experience, as well as when newly toggled pools go into effect.

[Taiji]

Well that makes sense. I mean STE, and not CTE or FTE, for unit building activity.

I just found that recharge rates combine when one pool is less than 1. This seems very interesting to me. It means we can have events changing recharge rates. Not seen that before.

I'm thinking of adding this mechanic into an existing feature we have in DLV called the 'war draft'. Currently it raises a faction's military limit (another cool script) when war is declared, if the player chooses to, and at some expense. So I can add this new feature of it boosting the recharge rates for units also.



edit:

More testing and perhaps this is even cooler: A duplicate entry with '0 0 0 2' will give all new units 2 experience and allow older units to train up.

So for example:

recruit_pool "Italian Militia" 0 0.28 4 0 requires factions { milan, venice, papal_states, sicily, }
recruit_pool "Italian Militia" 0 0 0 1 requires factions { milan, venice, papal_states, sicily, } and event_counter 1
recruit_pool "Italian Militia" 0 0 0 2 requires factions { milan, venice, papal_states, sicily, } and event_counter 2
recruit_pool "Italian Militia" 0 0 0 3 requires factions { milan, venice, papal_states, sicily, } and event_counter 3

1, 2 and 3 events could be time spent at war/since war. Very nice and simple application.

They could be part of a system of investment in military/trade/agriculture/government etc. Where investing in training provides experience for all troops produced. Plenty of potential applications for these duplicates, it seems.

[Augustus Lucifer]

Indeed, I'd implemented something similar in AUH to correspond with a few of our systems, but there's still question marks about the behavior of certain pool functions that will require further acutely defined testing setups.

[Taiji]

Like what? Where are you putting these question marks? The stuff I did just there took minutes to test. What exactly is going to take longer?

[Augustus Lucifer]

Like what? Where are you putting these question marks? The stuff I did just there took minutes to test. What exactly is going to take longer?

It's possible my previous tests were simply poorly conducted. I'm not suggesting things will take longer or shorter to test, just that we have definitely correct definitions for a few properties of inter-operating pool behavior. Let's see if I'm understanding what you concluded right:

• A pool base value is only added when the building is initially built and not when a pool is initialized. Correct?
• A pool which displays a unit for recruitment is defined by having a max greater than 1. Correct?
• If two pools of the same unit with a max greater than 1 and some replenish rate are active at the same time in the same settlement (in the same building?), there will be two pools for that unit. (Same if the pools are in two separate buildings?)
• If one pool is active with a max greater than 1, and another pool is active with a max lower than 1, within the same building within the same settlement, the pool with the max lower than 1 will compound with the pool greater than 1. This process continues indefinitely where the same conditions are true. Correct?
• The compounding process occurs for both replenish rate and experience. (Or does experience use the highest given value of a given set of pools?)
• All active pools prior to... (SettlementTurnEnd? FactionTurnEnd? PreFactionTurnStart? FactionTurnStart? SettlementTurnStart?) are added to the pool in a given subsequent turn, observed by trackable replenish rates.
• If a unit is recruited over multiple turns and a pool is deactivated during its recruit time, does it receive the experience value the pool had when it was queued or when it was 'built'?

So essentially the above needs to be defined/corroborated. If you have the answer to all of those then let me know and I will engineer tests to corroborate your findings or counterproof them; if not then I'll try and help find the answer to whichever we don't have one on(there may still be other scenarios I missed that are important for scripting use cases, such as settlements changing hands, buildings being upgraded, a second building with a same unit pool and a base # attribute as well being built, or what happens when a base pool is deactivated). These are all important considerations when fine tuning pool relationships.

[Gigantus]

My experience:

the same recruit_pool in two buildings in one settlement will combine, eg if the max units figure is 3 each, then the pool (only one recruitment pic) will go up to 6. Haven't checked if the replenishment rate gets halved or not, but my guess is yes.

[Taiji]

OK AL, here goes

1 Depends what you mean by initialised. If you mean 'does it only work at construction and campaign start?' then I think the answer is yes.

2 Yes that is correct.

3 Yes, as 2. To me this seems to be the same question.

4 I don't know. I haven't tested the combining of sub 1 pools. I doubt they combine given that whole number pools do not.

5 Yes. But how many can combine is unknown. I've tested with 2s, when I tested with 3 for experience it ignored one of them. My current assumption is 'max 2 entries combined' for experience.

6 Yes to the first, unknown to the second, possibly a yes. Simple to test.

7 Don't know. Pools probably should be processed at STS. Set a required event to fire at FTS to test.

8 I would say when it finally is produced. The game doesn't record the situation and then apply those factors, it will check upon completion.

Gigantus, your experience runs counter to mine. I would like to know how you got it to combine pools.

[Augustus Lucifer]

Okay, I'll create tests to verify your findings as soon as I can get around to it. Bookmarked this thread in case I forget. Thanks Euthyphro... now could you explain what piety is?

[Taiji]

Sure I can do that. It's the level to which your behaviour is in line with your beliefs. Usually reserved for religious matters because typically knowledge is used to guide behaviour elsewhere. If you never share your beliefs then noone will ever be able to measure your piety by observing your behaviour.

Before I wrote that 'stab in the dark' answer I checked the thread to see if Euthyphro had posted... Confused for a moment there...

edit:

Just checked him out on Wiki. Socrates needs a different answer. He is dealing with charges from a gnostic religious authority. Best bet is to plead 'insanity', they should at least be able to relate to that. I doubt you'll be able to plead insanity to AUH though