This is a merge of the Unit Statistics mod and FFH. I personally enjoy tracking the history of my units and heroes, especially in FfH, where unit development plays such an important role. For the merge, I need access to the SDK, which means that the mod will not always be available for the newest version.

Check the main thread (http://forums.civfanatics.com/showthread.php?t=162977) for screenshots and more info on the mod.

Download

Unitstats for FFH 2 0.33e (http://forums.civfanatics.com/downloads.php?do=file&id=8266)

What's new

Compatibility with FFH 2 0.33e


Known issues

Some FfH-specific features can confound the statistics. Elemental weaknesses and resistances modify the damage after it is reported to UnitStats, for example.

Installation Instruction

Copy the contents of the archive you downloaded into the FfH main folder.
Some files will be overwritten, which is ok. If you want to play without the mod later on, you can just disable it in the PythonCallbackDefines.xml. If you need to remove it entirely (for example for multiplayer matches), the original files can be restored by (re-)installing the latest patch.

Screenshots
http://forums.civfanatics.com/downloads//civ4screenshot0027_XjJ_thumb.jpg (http://forums.civfanatics.com/downloads//civ4screenshot0027_XjJ.jpg)

Another stat man, like myself. Very cool. Thanks.

That's freakin Awesome :) Can't wait for some screenshots from this program for brag rights :)

Any unique trophies for FfH? ie. Most Equipment Carried, Most Spells Cast...

And are there any chances for an Icon Overhaul to make the icons match a bit better with FfH's standard icons (pretty pictures in full color)?

I originally wanted to include some FFH-specific information (I'm especially interested in spell damage), but this would require some changes to the python files that I'd have to rewrite every time a new version is released. Hence I decided not to do that.

And I'm not much of a graphics guy, that's why I 'stole' the icons (well, they were freely available), and also why they are mostly arbitrary. It would be great if someone made icons that match the FFH style and/or have more to do with the actual category they stand for.

I could check into what I can make for you. Just made a couple for my PDF last night, and overall it isn't too hard if you have Photoshop, they included the template that was used to make their buttons so that you can easily match the size/border design.

There is a Template.dds in the art folder that I used to modify some of the buttons and that could be used as starting point. I know how to do it, but I don't have the patience to make 30 new buttons and I don't think the result would be any good... :)

Ok, going to look around for some button ideas, but some quick questions first:

Why multiple sizes? I would have to do quite a bit more work to make smaller options for the buttons, but I don't think that the smaller ones look that good on the Living Units & Hall of Fame screens. I prefer how they look on the Top 10 (full size) screen. So, will cutting you down to large size only be a problem? --- EDIT --- Nevermind, my DDS program automatically creates these smaller size images for me :) Still prefer full size for all screens though...

Can you tell me if you use the following buttons? Didn't see entries for them in the Hall of Fame: Air Strike Inflicted/Suffered (obviously not using I assume), 4, 1, 0, Commando, Cargo Counter, Move Counter, Max Turns Fortified, TotalTurnsFortified, Warp, UnitAge, Unitstatsbutton, Unitstatsbutton2, Unitstatsbutton3.

Also, could really see the use for a Total Movement in the High Scores, looks like there used to be a ranking for that, or I just missed finding where it was. Would it be hard to add a "Number of Spells Cast" high score? Seems it'd be a fairly simple one that isn't too invasive into python, but not sure. One final area that may be fitting to add is a Hero's Slain field, if not specific trophies for specific heroes.

Attached a .zip file with new icons for the highscores sheet. I only put in the ones that I saw actually used, tested them out and they do work. Haven't played with them long enough to decide how well I like them. Somewhat hard to see what they are while fogged out because I have no high scores as yet.

Wow, that was fast!

Air Strike Inflicted/Suffered are used in the vanilla game, but not in FFH

4, 1, 0 are not used at all. They're just there in case I want to create a new category.

Cargo Counter (number of tiles moved with cargo on board, the high score for transport units :p), Move Counter (number of tiles moved regularly) and Warp (total distance moved, including 'warp' effects (for example expulsions) are disabled by default. Depending on the size of the game and the number of units, they might slow down AI turns. They can be enabled in the UnitStatisticsDefines.py

Max Turns Fortified, TotalTurnsFortified and Commando (turns in enemy territory) dito. The value to enable this is g_bTrackTurnInformation

UnitAge. Hm, it should be there - perhaps a bug because FFH doesn't start 6000 BC. I'll have a look later :)

UnitStatsButton 1-3 are for the top right button on the main screen that you use to open the stats. Only one of them (UnitStatsButton) is actually used.

Numbers of spells cast is possible with hooks in CvSpellInterface.py. The system has been reworked for BTS and I'm not sure how it works. If the 'cast'-function catches all spells, then it would be feasible. If not, one would have to add a hook to every spell, and this would be too much work if it had to be redone for every version.

I'll now go play a round of FFH and have a look at the new buttons :)

FfH doesn't use Year at all, only turn timer. So that'll change everything about your Unit Age if you had based it off of the year entry.

Had figured that the UnitStatsButton entries were so you could get to the screen without the keyboard, but only looked in the bottom section of the HUD for them. Personally I think it would be better located on the right side of the END TURN button, but I am not sure how that will look in the city screen. As it is the button is BARELY noticeable under the Brotherhood of Wardens Icon.

Not entirely sure I can manage the black border jsut the right way to get the transparency to work properly or I would play with changing out that key as well :)

Cargo Counter would probably go to a Recon every game for his Hawk, so not sure that it will work well with FfH. I suppose if the Move Trackers will slow down time between turns even more that it is a good thing that you have them off by default, enough people have long turns already ;) But if you like this set of icons I can look into making some new ones for the rest of the set. I already have a couple in mind for movement, but Cargo will probably be a bit hard to come up with. I know that I will wind up using the cover from Terry Pratchet's "Last Hero" picture book version for Age if I do anything for it. Cohan the Barbarian DEFINES oldest Hero ;)

It's a bit too late to look into the bug(s) today, but if I have time tomorrow, I'll try to fix them.

About your buttons: something is wrong with the borders; they are not transparent, but blue-ish. I uploaded the .png version of my templates, perhaps it's easier to achieve transparency with them.

I like the icons that have a clear subject and a simple, contrasting background (for example BattleCount or BestOdds), because those are recognizable despite their small size. If there is too much detail (for example averageOdds), I find it hard to make anything out.

If you can make buttons for all high scores, I'm thinking about adding them in as an additional option. One could then either choose which one to use in the config file (UnitStatisticsDefines), and I could make yours to be used by default in FFH mode, the others in vanilla mode.

I had the same feel just now when I loaded up the game to play for a while. The buttons I made are just too... busy.

I had made them with the borders which are standard in most of the FfH sets (silver), but I think that I understand now that a black border shows up as transparent in the game, so I can probably make some that have some transparent borders.

EDIT: Yeah, I was way off. It isn't that the border is black, it is that .dds actually saves Alpha Channel data, and I wasn't setting mine to do so. I got it fixed now, so I just have to decide on some better pictures for everything.

Very nice! I really like unit statistics, so I'll try this. Hopefully we do eventually get it integrated again in the basic FfH.

I'll try it now, and if I like it I may use it as the base for my modmod instead of normal FfH.

Here is a new set. Let me know if you want a larger transparency outline on them, I understand what I am doing quite well now :)

Towards the end I began to get comfortable with cleaning up images to make them less "busy," so if some of these are still a bit much I can actually do something about it now :)


Hadn't tracked precisely where I got each icon from, many are pictures that have been on my harddrive for ages, some are from Deviant Art. I tried to stick to the artists already used in FfH though.

Anyhow, let me know your thoughts on them, I might redo some tomorrow if you think they need it. I loaded a game to decide on them, but I've been so immersed in it I can't judge anything just yet ;)

Oh yeah, included the template that I wound up using for the setup of each icon, it is in PSD though, so I think you'd need photoshop. I shoulda probably saved a blank in DSS as well...

Me likey! :)

I checked why the unit age high score doesn't work: since it is checked every turn, it's disabled by default, together with the commando and fortify information.

I switched OtherDamageInflicted with OtherDamageSuffered: both are not used ATM, but could be used if I add spell damage tracking. I guess I'll play with the code for the next few days and then release a new version.

Those two were actually the first ones I grabbed this time through, so I was looking for "Clean" more than "Appropriate" :) But in general trying to find something where the fellow looks HURT means you need more detail than fits on an Icon :( (Hence the most damage suffered image just being a fellow with no armor. He does have blood all over him, but I am not sure if you can easily tell)

I'm glad they work decently well this time :)

Alright, I added two new high scores (most heroes killed and most spells cast), fixed one (most summoned units survived --> fireballs etc. will now longer count as killed units), and made it possible to switch between different sets of buttons.

xienwolf, could I ask you to make two new buttons for the new high scores? I'll then repackage everything and upload it.

New Icons are titled SpellsCast & HeroSlayer. I also made a new icon for opening the screen, see if you like it (2 versions)

EDIT: Added the other button

I like the new UnitStats button. Can't find HeroSlayer though.

Fixed it, should both be in there now. I hope you can actually tell what the Hero Slayer picture is (at least the important bit), I was just looking at it and it is pretty clear to me, but I saw the full size version...

Thanks a lot. A new version is up.

Got a wierd Python exception that I figured I would post in case you can tell what it is. First popped up after my hunter, hired from an event, captured an animal, and then popped up again anytime I tried to settle an animal.

There were some problems with captured units, but I *think* I fixed them in version (c). Which one are you playing with?

Good question. I'm not sure I ever updated since I already had the pretty icons and all that. I'll re-install it and see if I can break it again next game :)

This MOD is awesome!!!

thx a lot for this!

I will definitely be using this minimod from now on, those extra stats are priceless! Forgive the obvious question, does this work with the new patch J?

If you install patch j, the unit statistics mod will be disabled. If you then install the unit statistics mod again, you can re-enable it. However, while some changes of the patch will be retained (for example the events and models), others will be lost (mainly the CtD and OOS fixes).

I recommend to either continue with patch h or do without the unit statistics mod until the source code for the current patch is released.

I did get a Python exception when unloading a unit from a Galley into my town last night, but otherwise seems to work fine on J (I don't think I ever actually opened the window to view the stats though...)

Even though this hasn't been updated ot the latest patch, I decided to go ahead and use it with the latest version. So far, I haven't had a problem.

Well, that is to say, the UnitStats mod seems to be working fine. I decided to make some other changes to CvUnit.cpp (letting HN unit capture units, not automatically granting weapons promotions, letting all units conduct spy missions (eventually I'll limit this to Esus units)), but none of those work. I don't get it, if it is reading your portions of the code enough to let the unitstats mod work, why is it ignoring all my changes?

Did you actually compile the changes and put the new CvGameCoreDLL in the right place? The .cpp files are not directly loaded by the game, they are just part of the source code that has to be re-compiled every time you make a change.

Oh, for some reason I was under the impression that it would read them first if they were in the SDKfiles folder, but I guess that is not the case. I had tried to compile it a while back, but was getting lots of errors because the .rc file was included (this isn't mentioned in the main post of the "Installing and using the SDK" thread, but I found it several pages in). I fixed that, but am now getting errors that seem to be related specifically to your changes:

Project : CvGameCoreDLL
Compiler : Microsoft Visual C++ Toolkit 2003 (called directly)
Directory : C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\Mods\CvGameCoreDLL030h\CvGameCoreDLL030h\
--------------------------------------------------------------------------------
Switching to target: Final Release
Linking dynamic library: ..\Beyond the Sword\Assets\CvGameCoreDLL.dll
Creating library ..\Beyond the Sword\Assets\CvGameCoreDLL.lib and object ..\Beyond the Sword\Assets\CvGameCoreDLL.exp
CvUnit.obj : error LNK2019: unresolved external symbol "public: int __thiscall CvGlobals::getUSE_UNIT_STATISTICS_CALLBACK(void)" (?getUSE_UNIT_STATISTICS_CALLBACK@CvGlobals@@QAEHX Z) referenced in function "protected: void __thiscall CvUnit::collateralCombat(class CvPlot const *,class CvUnit *)" (?collateralCombat@CvUnit@@IAEXPBVCvPlot@@PAV1@@Z)
..\Beyond the Sword\Assets\CvGameCoreDLL.dll : fatal error LNK1120: 1 unresolved externals
Process terminated with status 1 (0 minutes, 6 seconds)
2 errors, 0 warnings

Hum, I haven't seen that error message before. Have you added all four modified files (CvGlobals.cpp, CvGlobals.h, CvUnit.cpp and CvUnit.h) to the source code folder? There will be problems if you only added CvUnit.cpp and CvUnit.h, but left out the other two.

I'm pretty sure I copied all the files. I also added a slightly edited CvCity.cpp and commented out some lines in your CvUnit.cpp (to allow HN units to capture units but not cities, and to make all Esus units able to conduct spy missions) but I don't think that should matter. I do see defines in CvGlobals.cpp that clearly come from your modmod.

Edit: I thought that I'd forgotten CvzGlobals.h, but I was searching from your define going down from near the bottom of the file.


The error makes it look like it is searching for the define in the default BtS dll instead of your files. Why is that?


Edit2: Ok, it seems to be working now. "Build" does not work, but "Rebuild" does.

A version compatible with FFH 2 0.31 is up.

NICE!!! You rock :)
I'm testing it right away (haven't had the chance yet, since I'd already upgraded past patch .h when I found out about this).

Bumping the thread to say that a version compatible with patch d is up (the one for patch c was largely ignored).

Give us something and we'll ask for more! Any way to name units? i.e. Axeman of Siege Tentationis or Phalanx of the Fire Axe

Coincidentally, a unit naming system was included in earlier versions of the mod, but was removed for the current release. It was bloated with too many options and no longer worked the way it should. While it will not be re-implemented in the unit statistics mod, I could make a stand alone system that can be fed with a list of unit names (or a system to automatically generated them), if there is enough interest.

Hmm...how did I overlook that you already posted a 0.32 version?

I may have to start the SDK portion of my modmod soon, to include UnitStats, xienwolf's xml modcomp, and Broader Alignments (probably from Fall Further, since it is more updated and has a few other things I'll probably borrow, like allowing paradropping when not in a city). I'm including Marnok's Explorable Lairs modmod and FFHBUG too, but I don't think they use the SDK.

(I don't suppose someone would like to do the merge for me? I've compiled DLLs before, but not one with this many changes.)


Oh, one more thing. Does anyone know know why the Abandon City/Raze Building Python-only modcomp work with normal FfH, but not with UnitStats? I haven't tried in 0.32 yet, but in .31 it always worked so long as UnitStats was not included.

Abandon City/Raze Building mod modifies the same file as the unit statistics mod does, CvCustomEventManager.py. This means that only the mod you install last will work properly.

If I remember correctly, I noticed that and so merged the two python files together, but still only UnitStats worked. Maybe I just didn't merge them very well.

After most modmods had trouble with patch d, a new version for patch e is up and running smoothly.

Is this going to be updated for patch i anytime soon?

It already is - look at the first post.

Oh...never mind then. Thanks for updating. I would go ahead and download, but it seems like Vehem is going to include all the schema changes my modmod needs (including this mod), so I might as well wait for that.

UnitStats for FFH2 0.32j is up (people seem not to notice when I update it quietly).

Update for version l is up. I hope I don't have to repeat this every two days...

lol, thx :goodjob:

Just merged this into FF and all seems to work very nicely, with the sole exception of the "Top 10" option.

The exception isn't one that I'm familiar with - any ideas?

At first glance it sounded like something may have changed in 3.17 - though I'm not sure having looked at it.

Yep, that error pops up when the program is expecting a list/dictionary object, but the object is actually an integer or string.

This usually happens when sdObjectGetVal (line 200, two lines before the line that returns an error) fails (it will then return 0). It will also print the error message "initialize object first!" to the file PythonDbg.log. You can go check if this is indeed the case, which would mean that my diagnosis is correct.

My guess would then be that the 'template' in which the actual values are later filled in (called UnitStatsData in UnitStatisticsDefines.py) is not created for new units, which in turn is most likely caused (assuming that you didn't fiddle with the python files themselves) by a wrong entry in PythonCallbackDefines.xml. USE_ON_UNIT_CREATED_CALLBACK and USE_ON_UNIT_LOST_CALLBACK have to be set to 1 for it to work correctly (and you need to add USE_UNIT_STATISTICS_CALLBACK).

Would it be somehow possible that you merge this with the FfH BUG mod? Maybe you and its developer could work together and combine the mods "for good", since I'd guess that nobody would not want one or the other...?

Yep, that error pops up when the program is expecting a list/dictionary object, but the object is actually an integer or string.

This usually happens when sdObjectGetVal (line 200, two lines before the line that returns an error) fails (it will then return 0). It will also print the error message "initialize object first!" to the file PythonDbg.log. You can go check if this is indeed the case, which would mean that my diagnosis is correct.

My guess would then be that the 'template' in which the actual values are later filled in (called UnitStatsData in UnitStatisticsDefines.py) is not created for new units, which in turn is most likely caused (assuming that you didn't fiddle with the python files themselves) by a wrong entry in PythonCallbackDefines.xml. USE_ON_UNIT_CREATED_CALLBACK and USE_ON_UNIT_LOST_CALLBACK have to be set to 1 for it to work correctly (and you need to add USE_UNIT_STATISTICS_CALLBACK).

Thanks for the quick reply - the error string is present in PythonDbg.log, but so are the call backs...

<Define>
<DefineName>USE_ON_UNIT_CREATED_CALLBACK</DefineName>
<iDefineIntVal>1</iDefineIntVal>
</Define>
<Define>
<DefineName>USE_ON_UNIT_LOST_CALLBACK</DefineName>
<iDefineIntVal>1</iDefineIntVal>
</Define>
<Define>
<DefineName>USE_UNIT_STATISTICS_CALLBACK</DefineName>
<iDefineIntVal>1</iDefineIntVal>
</Define>
</Civ4Defines>

Most of the Python files were included untouched - with the exception of the MainInterface.py, though as I understood the code placed there it shouldn't be related to that.

Having looked a little more carefully at things though - I've realised that the details of individual combats (%chance, damage inflicted etc) aren't being stored either. I'm going to take a look at the DLL files again to make sure I haven't missed something there, before going to the Python to find the actual called back functions.

Teg, I was wondering about a few lines in UnitStatisticsTools. Lines 87-103:
else:

for i in range(14):
if (htype == DAMAGETYPE[i]):
for objUnit in unitList:
damagestats = sdObjectGetVal("UnitStats", objUnit, DAMAGESTATS)
if (not i / 7):
data = damagestats[INFLICTED][i % 7]
else:
data = damagestats[SUFFERED][i % 7]
datalist.append(data)
break

else:

for objUnit in unitList:
datalist.append(sdObjectGetVal("UnitStats", objUnit, htype))


Line 100 has an ELSE statement which lines up with a FOR statement. Never seen that before and wonder if it is intentional/actually works. And as for the FOR Statement, range 14, and checks for Damagetypes? There are only 7 Damgetypes in FfH, unless that is not meant to be Fire/Ice/Death/Holy/Unholy, but some other Statistics defined Damagetype... A quick search of that file showed that it most likely is some internally defined tracking system.

The iTypeofAttack value is passed from the SDK hook to the function onCombatHit:

# iTypeofAttack
# 0: (empty, reserved for total damage)
# 1: Attacker is hit
# 2: Defender is hit
# 3: Collateral damage (defender is hit)
# 4: Flanking strike (defender is hit)
# 5: Air Strike (defender is hit)
# 6: Other (FfH magic?) (defender is hit)

#6 is not used yet. For the high scores, there are 14 damage types (for each of the seven, maximum amount of damage inflicted and suffered). This approach might be a little less transparent at first, but it makes the code more maintainable - there is now a single function that handles damage tracking instead of one for each of these types (as was the case in earlier versions).

About the for statement at the end of a for-loop: Yep, that's intentional (http://docs.python.org/tut/node6.html#SECTION006400000000000000000)

FYI: I added a python callback on combat result in 0.33. It will probably break Unit Stats, but its not a huge deal to enable. Its set in the PythonCallbackDefines.xml file.

Thanks for the info. A 0.33 version of the mod is now up.

Did you include the new sourcecode? Looks like you left the old stuff in there.

Whoops, looks like I've copied the new source files to the wrong location. I've attached them to this message.

Thanks a ton :) When I updated FF for 033 I hadn't the time to figure out precisely where to move your functions. I imagine Kael's change to Immortal rebirth caused a bit of a shuffle to be required. :)

Actually, I just left those functions out. I didn't take the time to check how exactly Kael changed the immortal rebirth code, since I first wanted to make sure the other hooks work before adding any new.

From what I can see now, the new immortal rebirth code is in the kill function. This means that the defeat of an immortal unit will no longer be counted as a withdrawal, but be treated like the defeat of an ordinary unit at fist, incrementing the 'units lost' count of the unit/owner, the kill count of the winner and so on. That's not too bad a thing. It might actually be funny to track how often people manage to kill off their Immortals... :) Anyway, the only problem I see is that the survival odds ('this is your luckiest unit') will be screwed up by this, but that's just a minor glitch.

Sorry if this has been answered but does this mod slow than the game at all? Does it need to record extra information (compared to vanilla games) or would there only be a lag if you tried to look at individual units and it would have to bring up the relevant information?

Yes, the mod does slow the game a bit because extra information has to be processed/stored. The speed loss is barely noticeable though, and one is most likely to see a difference if there are hundreds of simultaneous operations that are tracked by the mod. In consequence, some statistics are disabled by default, especially those that would have to be updated all the time (every turn and/or whenever a unit moves). Most of the statistics that are enabled by default deal with the tracking of combat results, and there usually aren't hundreds of combats at once.

Since the mod is easy to switch on and off, I might try to get some benchmark results on my machine to see whether the AI turns take any longer with Unit Statistics turned on.

Since the mod is easy to switch on and off, I might try to get some benchmark results on my machine to see whether the AI turns take any longer with Unit Statistics turned on.

that would be nice to know. please share your experience after you try :)

OK, I worked with two late-game save games from my last game (standard map size). My machine has these specs:

Intel dual-core 1.7 Ghz,
2GB Ram,
ATI Radeon 1400XT

I measured the time of the AI turns with my wristwatch, so the numbers are not too reliable (+/- 2s).

When at war, you can expect the AI turn to take significantly longer. I measured these times:

Unit Statistics on, tracking everything: 33s/34s
Unit Statistics on, default settings: 32s/31s
Unit Statistics off: 30s/31s

At peace, the AI doesn't take that long:

Unit Statistics on, tracking everything: 19s/20s
Unit Statistics on, default settings: 16s/17s
Unit Statistics off: 18s/17s

As you can see, I would need a more reliable measuring method to see how big the impact of the mod really is. But actually, knowing that the performance loss is so small that it's hard to measure is good enough for me. It does seem that the features that are disabled by default do affect the turn times a bit, so they probably won't be turned on again in future versions.

I also tested how much space the mod data takes up in a savegame, and it's about 10% (395kb vs. 430kb and 431kb vs. 472kb). That's pretty much for such a small mod (gameplay-wise), but since all the mod does is track and store additional information, this was to be expected. I could probably half this number if I really wanted to, just by using shorter variable names, but this involves some work and could introduce new bugs, so I don't think it's worth it.

thanx for the feedback. a couple seconds longer is no problem at all, at least for me. my specs are really similar to yours btw, core 2 duo @ 1.66 with 3 gigs of ram. probably a tad bit faster than yours thanx to the ram, but shouldn't vary much. on large/huge maps it could make more of a difference though. if you could try those out too, that would be awesome. but don't feel obliged to do so, of course :)