Technical documentation

Hi, how do you make those spreadsheets of settlermaps/citynames/etc? I'd really like one so I could make my modmod with totally new map easier.
 
Hi, how do you make those spreadsheets of settlermaps/citynames/etc? I'd really like one so I could make my modmod with totally new map easier.

There are many ways. If you already have your new map, I attached a simple script you can use to print the map to the python log. Make sure logging is enabled. Once in game, open the python console (~) and type:
from printmap import *
printmap()


It prints the map data to PythonDbg.log, in csv format, with following settings:
0 = water
1 = land
2 = peak

If you don't want mountains marked, use printmap(False) instead.

Select the output in Notepad++ or similar, remove the blank lines (TextFX Edit -> Remove blank lines in Npp) and copy it to LibreOffice/OpenOffice/MSO, choosing semicolon as a separator. Add some colors and you have a base for all of your spreadsheets.
 

Attachments

  • printmap.zip
    398 bytes · Views: 104
I checked your modifications in the SVN version.

What motivated you to move all this stuff from Rhyes.h to Enums.h? It makes sense, just curious.

Are you still going to try and move a lot of stuff from the dll to python? Would it be worth it to wait for you to do that before really modding?
 
I checked your modifications in the SVN version.

What motivated you to move all this stuff from Rhyes.h to Enums.h? It makes sense, just curious.

Leoreth suggested it and it's neater in that it doesn't require type casting in the code, though ideally it should be removed altogether.

Are you still going to try and move a lot of stuff from the dll to python? Would it be worth it to wait for you to do that before really modding?

I tried and it didn't work out. I can say that I'm going to try again, but if it's not done by the end of the year then it's ulikely it'll be done in any reasonable timeframe.
 
Any plans to include some stuff from K-mod? I probably will eventually.

Any particular things you think should be included? I'm not very familiar with K-mod, but I know that most AI improvements meant for epic game do not apply in RFC context (for example, large parts of BBAI are about AI using strategy to achieve victory, or settler AI etc. so including whole BBAI in RFC would make the AI actually worse).
 
Embryodead, would you mind sharing the makefile you use for your project? I seem to have some compiling problems and I could use it to track down the issue.
 
Sure, but this is an unmodified, universal makefile from DannyDaemonic. Only the paths are changed to my CIV4 location.
 

Attachments

  • Makefile.zip
    2.2 KB · Views: 101
Thanks! Well, I think my issue has to do with my setup, libs and all. Still want to try with yours though :)
 
Part of the promised code overhaul is on SVN.

- All basic arrays from CvRhyes.cpp are now stored in CvPlayer objects and initialized from Python
- CATAPULT_X & CATAPULT_Y are now stored in CvGame and initialized from Python
- MAX_COM_SHRINE is set in GlobalDefinesAlt.xml

There's a new Python module called DataLoader.py. It has one method "setup" called by CvRFCEventHandler on game start. DataLoader initializes the DLL data that was previously found in CvRhyes.cpp by filling it with variables from Consts.py.

That means much more stuff is editable in Python rather than being in hardcoded in the DLL. Moreover, all this stuff is saved and can be updated in-game. I used this to update the inflation rate and other balance modifiers for respawned civs such as Cilicia and Uzbeks (DynamicCivs.py).

TO-DO:
1. move the remaining 2d arrays to CvPlayer
2. move the maps to CvPlot
3. convert Rhye's X/Y loops to plotIndex loops (pt. 2 + 3 means that you can change the map dimensions without recompiling the DLL or immediately updating map arrays)
4. deal with other hardcoded stuff that's not in CvRhyes.cpp
 
Oh, and also, if you're one of the people using SoI as base, you've have seen the latest changes and think it's pointless, let me know. It all seems beneficial, but at this stage - I'm not sure.
 
I really didn't have a problem modding the SoI DLL files. It was just a question of the map arrays and a lot of commenting out, a huge improvement over Rhye's, which I tried repeatedly to adapt and always ended up with a problem I couldn't find or understand. That being said, I think if you can set it up so you can say "make your own regional/theme mod, NO dll required", it might prompt beginners (like me) to more readily try it out. I was also thinking it would be helpful to make a "blank" dll with all mod-specific parts removed and civs and other things numbered rather than named.
edit: or perhaps the "blank dll" thing is actually what you're aiming for, in which case yeah that would be awesome.
 
I really didn't have a problem modding the SoI DLL files. It was just a question of the map arrays and a lot of commenting out, a huge improvement over Rhye's, which I tried repeatedly to adapt and always ended up with a problem I couldn't find or understand. That being said, I think if you can set it up so you can say "make your own regional/theme mod, NO dll required", it might prompt beginners (like me) to more readily try it out. I was also thinking it would be helpful to make a "blank" dll with all mod-specific parts removed and civs and other things numbered rather than named.
edit: or perhaps the "blank dll" thing is actually what you're aiming for, in which case yeah that would be awesome.

It's difficult to make it completely independent of DLL, unless it's really blank DLL i.e. no Unique Powers, special behaviors for specific civs or religions etc. But all the basic RFC stuff like settler maps, war maps, RFC balance etc. would be there, managed from Python.
 
Maybe your changes will make SoI more accessible though. Personally I didn't mind to have to change the dll, fairly used to it. Although it has the added benefit to not require recompiling to change a lot of stuff.

If I got it right, DataLoader happens at the loading of the game, right? Not at the loading of the scenario?

I also like the fact that your relic work is quite independent from the rest so I could avoid merging it, since I won't need it ;)
 
Maybe your changes will make SoI more accessible though. Personally I didn't mind to have to change the dll, fairly used to it. Although it has the added benefit to not require recompiling to change a lot of stuff.

There's no need to restart the game even, if you call DataLoader again from python console.

If I got it right, DataLoader happens at the loading of the game, right? Not at the loading of the scenario?

It happens exactly once, when a new game starts. After that, the data is stored in the savegame (1-2 kilobytes, so doesn't count towards MAFs).
 
Some cool stuff in the SVN. CvRhyes is almost gone, and should be all gone within a week :) Moved all strings to Consts.py and maps to Maps.py. This means that:
- provinces, city art styles and settler maps can be changed without altering the DLL
- they can be changed even without restarting the game, allowing mods to change map data with events, respawns etc.
- actual maps can be resized without altering the DLL (the mod will load even if the map's size doesn't match the arrays in Maps.py)
- the mod can use multiple maps of different sizes with the same DLL (with some extra Python work you can have a single, multi-map mod)
- settler found values can be easily randomized in Python (see DataLoader.py)

SorenRand.py - replacement for Python random module based on Civ4's synchronous RNG; has useful functions like shuffle (shuffle a list), choice (select random list element), sample (select x random elements) or dice (roll 1-100).

Not on SVN yet - XML-to-variable converter; an easy way to handle XML data in Python, makes a large part of Consts.py obsolete. Once you import it, you no longer need to use getInfoTypeForString("...") or maintain long lists of variables that have match XML data. Instead you just do an import and you can use variables like UNIT_SPEARMAN or BONUS_IRON that always correspond to XML indices. The module loads all XML types found in the files, including future ones. The question is, again, whether modders' want it. After all it involves changing all the variables in all Python files. IMHO it's not that much work with Find&Replace, and the benefits are nice for future work, which always involves adding/removing a lot of units/buildings/bonuses etc.
 
That sounds good. Even for people who have no problem modifying the DLL it's probably easier to quickly balance things this way without having to quit the game and recompile every time.
 
This all sounds very handy, embryodead, the XML thing too, since listing all these stuff in Consts is a bit annoying.

Are you gonna use the modification of maps for SoI?
 
This all sounds very handy, embryodead, the XML thing too, since listing all these stuff in Consts is a bit annoying.

I may have to back from this one since apparently with some modules, it requires a lot of changes. Since Python is initialized before XML is loaded, no variable should use XML on module level - they always have to be initialized within a class. This is why all original Python code of Civ4 does this, and it's the correct way to program in Python, but redoing it right now, and going further away from the established RFC structure, I don't know.

Even if it's not that much work, it means moving some of the XML-dependant stuff out of Consts.py back to their respective classes in different modules, for instance I'd have to move back mercenary list to mercenaries module, and religion-related lists & tuples to Religions.py. Consts would be used only for stuff shared by multiple modules and not dependant on any XML data (e.g. provinces, modifiers, capitals). I'm kind of lost on what is right and convenient really... I mean it's nice having it all in one place, but then again, if this data is used ONLY by Religions.py, then it shouldn't really be in Consts.py... and there's a lot of mod-specific code in the a module such as Religions.py anyway. :hammer2:

Are you gonna use the modification of maps for SoI?

No, I'm not planning to at least.
 
Top Bottom