[MODCOMP] Unit Statistics

Normally, everything works fine, but =DOCTOR= uses the mod in his CustomAssets directory while CvPath.py is only intended to work in the mods directory.
 
Hi TheLopez, presumably for those, like myself, who might just incorporate it into the normal Custom Assets folder rather than the Mod folder?

Has no one else experienced the massive late game lag when all options for recording are selected?
 
=DOCTOR= said:
Has no one else experienced the massive late game lag when all options for recording are selected?

It's probably the movement stats that slow your system down late in the game.

I'm at war most of the time and finished my test games way before the modern age and even before I got railroads. Thus, I didn't experience any lag (except for the first implementation of the high scores, which were way too slow).

If you like to amass great armies and move large stacks of unit by train, you will notice a significant slow-down. This is because every one-tile-movement triggers two events (onUnitMove and onUnitSetXY). Thus, moving 40 units 10 tiles will trigger 800 events. Going through them admittedly takes a while with the unit statistics and you might want to turn it off.
 
YEs, you're right. It was about the railroad time and when my unit stacks were getting larger that I began noticing the huge slow downs. Removing the 2 movement records and possible time in service would be definitely advisable.
 
Time in service takes almost no resources since it's not updated every turn. Rather, the year of creation is stored and the output is simply "current year - start year". And as I said, you can still disable movement logging at the top of CvUnitStatisticsEventManager.py, even if the config doesn't work in CustomAssets. There's no need to remove it entirely.
 
Ok, I seem to have managed to disable the movement things in UnitStatisticsUtils (I couldn't find any in CvUnitStatisticsEventManager) and this has stopped them from showing when I press "u"; however, the massive delay when moving stacks was very much still present. :confused:

I presume that the game must still be making the calculations, just not showing them? Any ideas? I really like the combat details (i.e. units killed and things on whether the unit's the luckiest, deadliest, etc), but something in this mod is making late game unplayable due to excessive computations.

Anyway, I've uploaded my current save game below in case you're interested to test and see how the lag compares at your end for this stage in a game. Saved game should be me as the Spanish and I have a massive fleet bordering the Chinese which when moved are resulting in 10 or more seconds delay. If it's not then it's the wrong file :o

Regards
 
Ok, I seem to have managed to disable the movement things in UnitStatisticsUtils (I couldn't find any in CvUnitStatisticsEventManager) and this has stopped them from showing when I press "u"; however, the massive delay when moving stacks was very much still present.

You just disabled g_bShowDistanceMoved, g_bShowDistanceTransported and g_bShowTotalDistanceTravelled. What you have to disable in order to save performance is g_bLogUnitMovement in CvUnitStatisticsEventManager.
 
Ah, I was using an older version of that file and that line wasn't included. I've updated to the newer version and disabled that option and now the game now runs super smooth again.

Thanks for your help.

DrJ
 
after playing on a higher difficulty and losing some games, I found that unit statistics are no fun when I have no units that survive... :) Thus, I now included player statistics (can be opened by pressing 'X') that tell you some nice and useless things such as the total damage your units have done, the total battles you have fought, won, and lost and so on.

also, a 'hall of fame' has been implemented. For now, it is at the bottom of the player statistics popup and lists all high score values. I intend to link it to the units that have the high scores, so that you can actively look for your best units instead of wildly clicking around and hoping to find one.
 
OzzyKP said:
Will that hall of fame retain info for dead units?

Yep, the output looks like this:

Most kills: 27 (living units: 7)

the first number includes dead units, the second doesn't.

A sidenote: I don't know if all the statistics are self-explanatory, so if something isn't, please tell me so :)
 
Hurray, I solved all performance issues!

By using SdToolKit, all the stats were written in the same file (CyGameInstance.setScriptData()), which was painfully slow when you had many units.

Now, the stats are stored separately for each unit in CyUnit.setScriptData(). Unit Statistics now has become so fast that you won't even notice that it's running (which was my personal goal #1). I use to create 250 units in worldbuilder and move 40 of them 10 tiles (railroad). This took up to 120 seconds with the unoptimized code, now it only takes 2 (it also takes 2 seconds when UnitStatistics is off ;)):D

personal goal #2, making unique names obsolete, probably won't be possible until the SDK comes out.
 
Teg_Navanis said:
Hurray, I solved all performance issues!

By using SdToolKit, all the stats were written in the same file (CyGameInstance.setScriptData()), which was painfully slow when you had many units.

Now, the stats are stored separately for each unit in CyUnit.setScriptData(). Unit Statistics now has become so fast that you won't even notice that it's running (which was my personal goal #1). I use to create 250 units in worldbuilder and move 40 of them 10 tiles (railroad). This took up to 120 seconds with the unoptimized code, now it only takes 2 (it also takes 2 seconds when UnitStatistics is off ;)):D

personal goal #2, making unique names obsolete, probably won't be possible until the SDK comes out.
Goodjob :goodjob:

Note to self: always use unique names with the SD-Toolkit.
 
Note to self: always use unique names with the SD-Toolkit.

Nope, that's what didn't work smoothly. The unique name only tells the SD-function which part of the scriptdata to change (or where to look for the Var), but still, the whole scriptdata is loaded/stored very time you use sdGetVal or sdSetVal.

I had to rewrite the SD-Toolkit for my purpose (check the file UnitSdToolkit.py).
 
Aaah, I get it. I'd never really looked into the code - I just trusted it. This looks to be a great improvement.

Hmmm - this means I no longer have to worry about silly unique naming and suchlike. It seems most obejects have a scriptdata function.
 
The Great Apple said:
Hmmm - this means I no longer have to worry about silly unique naming and suchlike. It seems most obejects have a scriptdata function.

Well, not all objects have a script function only:
- CyCity
- CyGame
- CyPlayer
- CyPlot
- CyUnit
- CyGameInstance
- PyCity

But I think Teg brings up a great point, maybe the right thing to do is generalize Tegs code and merge it into SD-Toolkit. This way if the object passed in has the get/setScriptData methods then those are used otherwise the more generic way CyGameInstance is used instead. What do you guys think?
 
But I think Teg brings up a great point, maybe the right thing to do is generalize Tegs code and merge it into SD-Toolkit. This way if the object passed in has the get/setScriptData methods then those are used otherwise the more generic way CyGameInstance is used instead. What do you guys think?

Hehe, I'm already working on it ;)
 
But are you just merging the unit code from your UnitSdToolkit.py file or are you making a generic solution?
 
But are you just merging the unit code from your UnitSdToolkit.py file or are you making a generic solution?

It will be a generic solution that works for all objects.
 
So when do you think it will be done? Do you need some help testing it?
 
Back
Top Bottom