Faster BTS 3.19

[Sephi]

This mod is just a few speedtweaks to make the game run faster. No gamechanges. I did a testgame in BTS 3.19 huge map and the turn time decreased by 7%. The mod should be save game compatible.

How to install:
copy the DLL into the Assets folder. make a backup of the
CIV4GamecoreDLL.dll file first! If you play multiplayer make sure everyone uses the same dll.

I am using these tweaks for month now in my own mod and Kael merged them into FFH a while ago so they are already playtested a lot and should be 100% bugfree

 

[Ninja2]

Could you maybe explain a bit what you've done, and provide sources for us mergers?

 

[Sephi]

source is in the download. Code changes are documented (just search for Sephi)

 

[keldath]

sweet sephi,


you should recommend this to jdog5000 to include this in his betterai.

 

[makke]

Could this and CAR mod be merged?

 

[os79]

Could this and CAR mod be merged?

Additional question:
How is this mod different from CAR? Did you change different codes from CAR or had you done this mod without knowledge of CAR beforehand?

 

[Sephi]

It's completly unrelated to CAR and merging would be easy. Reason I uploaded it for BTS is save game compatibility which CAR doesn't have IIRC. If I ever play BTS again I probably would take the time to merge it with CAR before.

 

[Voltage]

This thread and car mod turn me on lol. Speed is everything! Thankyou for your work!

I tried to merge this with RevDCM but the source codes clash.

 

[Yakk]

Please try to format the code the same.

The original code uses tabs to indent. You used 4 spaces for each tab they use.

Most of the optimisations limit searching for units to group with (etc) to a radius of iMaxPath*4. Does this take into account railroads?

Actually, that is all of the optimisations. Hmm. It would be better suited by teaching the A* algorithm to stop searching after it hits a passed in max path value? Actually, another efficiency is noting that the set of plots reachable within MaxPath won't change from one iteration of the loop to another: so somehow getting that collection of plots and checking against it would massively (I mean massively) speed up these loops.

But those are harder solutions.

 

[Sephi]

Actually, another efficiency is noting that the set of plots reachable within MaxPath won't change from one iteration of the loop to another: so somehow getting that collection of plots and checking against it would massively (I mean massively) speed up these loops.

Most of the loops do a generatepath call on every plot only once at max anyway. I don't see how caching is going to help you at all here.

 

[Agent327]

Hadn't noticed this before: nice one, Sephi!