C2C SVN Changelog

[Thunderbrd]

Update

Updated all Hydro and DH UnitSchemas so that those which needed to utilize the PromotionLineInfos could do so without error.

 

[Thunderbrd]

Just pushed to SVN (3752):

• Fixed AI odds miscalculation when attacking with large stacks
• Fixed bug in game object expression textualization that could result in crashes (happened to me entering world-builder)
• Fixed promotions handed out by buildings

The first of the above was behind the AI's tendency to make suicide (or at least bad) attacks from large stacks.

Note - I have also found that the combat mod has thrown off the AI's assessment of odds (the multi-round nature of combat with strengths being recalculated each round means that the AI assessment routine mis-predicts quite badly). This will need to be fixed, and I'll try to sort it out tomorrow.

Edit - also pushed merge of Damgo's fix for the main screen Python (rev 3753)

I didn't think it would change things too greatly... just makes imbalances in the ratio a bit more prominent I'd think. But the StrAdjperRnd values would certainly be a factor that has not been considered by the odds calculations so if you're taking a look at how to get the odds to calculate more effectively in light of simple recalculations, please see if you can figure out a method to include StrAdjperRnd modifiers while you're at it. I did not feel, however, that if those modifiers should ever be used very liberally so should not have had such an overwhelming effect to miscalculate that it would be necessary to go back to college to learn the math needed to fix it up. But if you've got that knowledge, please... help!

btw... what odds calculations are you adjusting? All of them? Or just the AI one?

 

[Koshling]

I didn't think it would change things too greatly... just makes imbalances in the ratio a bit more prominent I'd think. But the StrAdjperRnd values would certainly be a factor that has not been considered by the odds calculations so if you're taking a look at how to get the odds to calculate more effectively in light of simple recalculations, please see if you can figure out a method to include StrAdjperRnd modifiers while you're at it. I did not feel, however, that if those modifiers should ever be used very liberally so should not have had such an overwhelming effect to miscalculate that it would be necessary to go back to college to learn the math needed to fix it up. But if you've got that knowledge, please... help!

btw... what odds calculations are you adjusting? All of them? Or just the AI one?

Just the AI result-prediction one - the actual combat resolution seems fine. Problem is that the AI mis-predicts it now and tends to suicide as a result. First strikes have a much bigger effect now, because while one side is first-striking they are reducing the damage that the other side will be able to do once the first strikes are exhausted. The inter-round recalculation also exaggerates the advantage of the side that is on top at the start more than before (because they do more damage faster which reduce the opponents damage in later rounds, and this is slightly non-linear).

The prediction routine is VERY performance sensitive (the AI evaluates 10000s of attacks per turn but only maybe 1 in 1000 are actually executed), so I can't actually go through the rounds in 'simulation mode'. I think I can tweak it to give a decent approximation though, which is all that is needed.

 

[Thunderbrd]

Just the AI result-prediction one - the actual combat resolution seems fine. Problem is that the AI mis-predicts it now and tends to suicide as a result. First strikes have a much bigger effect now, because while one side is first-striking they are reducing the damage that the other side will be able to do once the first strikes are exhausted. The inter-round recalculation also exaggerates the advantage of the side that is on top at the start more than before (because they do more damage faster which reduce the opponents damage in later rounds, and this is slightly non-linear).

The prediction routine is VERY performance sensitive (the AI evaluates 10000s of attacks per turn but only maybe 1 in 1000 are actually executed), so I can't actually go through the rounds in 'simulation mode'. I think I can tweak it to give a decent approximation though, which is all that is needed.

Sure... sounds right to me. If the AI evaluation is more accurate than the actual odds evaluation, it actually makes sense. The core odds is also going to form the power ratio and have an influence in the actual battle, so in a sense it really shouldn't be messed with. And players should be challenged to look past the odds for themselves at anything that influences things beyond the first round I think, learning to take the odds as the base assessment of comparable current strengths but not as the end all be all actual chance of victory or defeat.

As a side note... I always felt that first strike was a bit lacking in effectiveness as an ability and when I realized, during development of the combat mod, what you said about its newly enhanced effect thanks to the recalculations between rounds, I was extremely pleased about that! It should be highly coveted now by the player who understands this effect, and quite capable of being a superior choice over a straight combat % gain.

 

[AIAndy]

Update
Rewrote the property solver to use multi threading. It is activated by USE_MULTIPLE_THREADS_PROPERTY_SOLVER and on by default. 4 threads are currently used. The behavior is a bit different which can have an effect on the result and all players in a multiplayer game should have the same setting.

 

[Koshling]

Update
Rewrote the property solver to use multi threading. It is activated by USE_MULTIPLE_THREADS_PROPERTY_SOLVER and on by default. 4 threads are currently used. The behavior is a bit different which can have an effect on the result and all players in a multiplayer game should have the same setting.

Does the solver allocate memory? If so have you added locks to the allocators (since hey use the engine's malloc which is the single thread library version)?

Edit - good place to start with multi-threading though, and it's time we got going with that effort

 

[Thunderbrd]

Update
Rewrote the property solver to use multi threading. It is activated by USE_MULTIPLE_THREADS_PROPERTY_SOLVER and on by default. 4 threads are currently used. The behavior is a bit different which can have an effect on the result and all players in a multiplayer game should have the same setting.

Wow... our first step into multi-threading huh? Wicked

I do have to ask though, do you think it would be preferable to let a single thread boosted chip operate on the single thread or to utilize this feature?

 

[Koshling]

Wow... our first step into multi-threading huh? Wicked

I do have to ask though, do you think it would be preferable to let a single thread boosted chip operate on the single thread or to utilize this feature?

If you have more than about 1.3 cores its better to be multi-threaded if you can allocate parallel work reasonably effectively.

 

[AIAndy]

Does the solver allocate memory? If so have you added locks to the allocators (since hey use the engine's malloc which is the single thread library version)?

It does allocate memory by using some STL data structures.
Are you sure there is a single thread malloc in use given that the engine does use multiple threads, just not for the game core?

 

[Koshling]

It does allocate memory by using some STL data structures.
Are you sure there is a single thread malloc in use given that the engine does use multiple threads, just not for the game core?

Not 100% sure no.

 

[Koshling]

Just pushed to SVN (3763):

• Compiled TB's code that fixes some promotion cases
• Reworked AI combat results prediction code to better match the combat mod changes

Also (rev 3765):

• Another combat mod fix to free promotion handling that meant they were not saving correctly, and were than being lost on reload (my screw-up in the memory optimization work - oops)
• Merged the fix from God-Emperor to unit hover help for large stacks

 

[ls612]

Update:

-Added damgo's fix for Culture Distance calculations.

 

[makotech222]

Getting a consistent crash on new games after a few turns (3-6)

On the latest svn as of this post.

 

[JosEPh_II]

Getting a consistent crash on new games after a few turns (3-6)

On the latest svn as of this post.

Please post in Bug thread. Upload Savegame and Minidump. BBAI log too if set up from BUG Option screen.

This thread is for SVN Updates from Modders. Thnx.

JosEPh

 

[Hydromancerx]

Updates
- Tweaked Bamboo Armourer.

 

[AIAndy]

Update
Deactivated multi threaded property solver until it is rewritten with a threadsafe memory allocator.

 

[Koshling]

Update
Deactivated multi threaded property solver until it is rewritten with a threadsafe memory allocator.

If it is this then a mutex in the allocator/deallocator routines in CvGameCoreDLL.cpp (which just delegates to the EXEs allocator) should suffice.

 

[Desolator]

Update
Deactivated multi threaded property solver until it is rewritten with a threadsafe memory allocator.

What about

<Define>
		<DefineName>USE_MULTIPLE_THREADS_SPAWNING</DefineName>
		<bDefineBoolVal>0</bDefineBoolVal>
	</Define>

(It is right before the USE_MULTIPLE_THREADS_PROPERTY_SOLVER in the A_New_Dawn_GlobalDefines.xml)

Is that safe to turn on?

 

[AIAndy]

What about

<Define>
		<DefineName>USE_MULTIPLE_THREADS_SPAWNING</DefineName>
		<bDefineBoolVal>0</bDefineBoolVal>
	</Define>

(It is right before the USE_MULTIPLE_THREADS_PROPERTY_SOLVER in the A_New_Dawn_GlobalDefines.xml)

Is that safe to turn on?

If the memory allocation is an issue, then this one will have the same problems. I remember that we had some spurious crashes back then when I first added it and we decided to leave it off by default.
Besides, it is not such a performance sensitive part to give you much of a gain. And being an early test, it is not well written either and starts too many threads.
If we get the multi-threaded property solver working correctly, then I will go back to this one and improve it.

Feel free though to do some testing with either option activated to see if it crashes any more than with it deactivated.

 

[Koshling]

Just pushed to SVN (3768):

• Rewrote the large stack display code that allocated ridiculous amounts of memory

This should save you about 150M if you ever mouse over a stack of more than 15 units!