World History Mod Conversation

[Nightinggale]

Really, would it be possible to start the XML development already? This is huge and big project but it might grow to really interesting mod.

That post made me think on how to rush a start. I have come to the conclusion that we can split development into a few steps:

1. CivEffects is finished. XML modding can begin and graphics can be added.
2. More CivEffects (like traits) are added to XML and can be changed by a mod.
3. DLL gets a savegame upgrade, which breaks old savegames.
4. M:C is tested, bugfixed and released.

Originally I planned for other mods to start at step 4. However strictly speaking mod development could start when 1 is done, which is why I will aim at 1 right now.

At some point pedia text should be fixed as well. Currently it's blank meaning you can't actually check what you entered in XML. It would be a good thing to have, but not strictly needed to include from the start of the mod. In other words it can be added while the XML editing starts.

 

[Lib.Spi't]

I thought one of the bigger issues was how yields are handled/work, as they are a part of the .dll?

That was one of the reasons I pushed pause(not much of a reason, as I had plenty of other things to turn my attention to anyway.)

I am guessing this would be XML Dll stuff rather than Core Dll stuff?

At the moment we have the beginnings of a list of Core Dll (mod breaker changes) list in your civeffect thread Night.

Would that perhaps be a good topic to create a new thread for so we could highlight the thinking of 'What is left for a Core Dll?' This would then answer the question (or at least begin to) of 'How long until we can start work on Mod X(ml)'

I think I will do that now, in the M:C thread (they are all interrelated when it comes to Dll anyway) it could even be the beginning of correlation of information for the UMS Mod (Anyone remember that gem of an acronym? (I hope I actually remember it right! )

I think it might have been UCS... doesn't matter!

Link to new thread:
Core DLL and XML DLL

 

[Nightinggale]

I thought one of the bigger issues was how yields are handled/work, as they are a part of the .dll?

Currently mod specific data like yields are set in 3 header files. Those 3 files are part of the mod and not part of the DLL source code. It expect the files to be at ..\..\sourceMOD if I remember correctly. This mean that XML modders have write access to those files even if they do not have access to the DLL source.

One long term plan is to simplify the mod specific setup and (if possible) make one DLL file, which fits all. Currently we have to compile one DLL for each mod. Regardless of how much this can be improved, the current setup is good enough and not a reason to not make an XML based mod.

 

[Lib.Spi't]

I remember a time when the goal was to get the yields into xml, rather than being hardcoded into the .dll.

I guess it would become an XML DLL component eventually, right now it is something of a third category which requires a specific .dll to be made for each mod.

I would guess other things that would currently be an issue moving forward, are M:C content that is Hardcoded, and needs to become XML Core, that could still break things for other mods?

 

[Nightinggale]

I remember a time when the goal was to get the yields into xml, rather than being hardcoded into the .dll.

It is a goal to place all yield stuff in XML. However there are performance issues and a stupid AI and it is rather time consuming not to break either. This mean we are stuck with mod specific DLLs for quite a while.

I still wonder if it is a good idea to have one DLL file for each mod or if it makes sense to hardcode mod specific data for performance reasons. The more I think about it, the less I like the idea of not being able to hardcode anything.

Even if we stick to the hardcoded yields path, it should be simplified. Currently adding a yield means adding it to 3 header files and 3 XML files (yield, unit and unit class). I would like to reduce this to ideally 1 enum and the yield XML and then autogenerate the rest based on this. However I will not do that right now as it can't be done in a single day.

I would guess other things that would currently be an issue moving forward, are M:C content that is Hardcoded, and needs to become XML Core, that could still break things for other mods?

There is a compile flag called MEDIEVAL_CONQUEST. M:C defines this in the yield header (since it's mod specific, not that it's a logical location). This flag enables compilation of additional DLL features, such as feast, which has hardcoded costs (using M:C yields). Any mod not defining this flag can work without M:C yields, but at the same time feasts will not be available.

I think this flag should take care of all issues. It's not pretty code, but it saved many hours of code fixing to just disable code this way. Nothing important is disabled.


One thing I have been wondering about (which kills the one DLL for all idea) is to make a bunch of flags modders can turn on and off.
Say for instance col2071 needs a space domain. The mod specific header can then contain

#define USE_DOMAIN_SPACE

Unit movement and pathfinding (some of the slowest code in the game) will then be hardcoded to figure out how to handle space and can be optimized to handle it as fast as possible. Mods not using a space domain will simply not define the flag and then the compiler will not compile code to support this domain, which will be even faster at runtime. Regardless of the mod using space or not, all mods will slow down by checking domain stuff from XML.

The DLL file, which should fit all mods would have to be completely clean of mod specific code. If we hardcode unit movement (which we likely should), then it makes little sense to try to completely avoid hardcoding yields. Instead it would make sense to split the defined flags into specific features to allow mods to turn features on individually without actually touching the shared code, like using a flag called USE_COMMAND_FEAST without getting the entire MEDIEVAL_CONQUEST package.

I'm still not sure what to do and until I have figured it out, I'm not working towards either direction.

 

[Lib.Spi't]

These are the sorts of things I mean, because otherwise we may well end up with the same thing happening over and over just like we have now, where M:C and 2071 just 'break' and we don't know how to fix it, or what the confilct is/was.

Couldn't the domain type stuff be done by it having all of the AI thinking about each domain in the .dll for all, but then in path finding instances etc. only run the path finding code when a unit has that domain specified?

So in M:C it would never run the space domain stuff because no unit uses space, but 2071 would.

Surely there has to be a definition in the xml that says which units belong to which domain, and so do something along the lines of a jump to specific domain code, because even in M:C there are 2 domains, does it always run all code for both domains regardless of the domain type of a unit?

 

[Nightinggale]

These are the sorts of things I mean, because otherwise we may well end up with the same thing happening over and over just like we have now, where M:C and 2071 just 'break' and we don't know how to fix it, or what the confilct is/was.

The problem with a mod breaking where we don't know why is due to XML schema changes. I added all the XML schema files to the source repository meaning we can get git to tell what has changed since last release. That way we will hopefully avoid this issue.

If it breaks in the DLL, then the debugger can tell what went wrong.

Couldn't the domain type stuff be done by it having all of the AI thinking about each domain in the .dll for all, but then in path finding instances etc. only run the path finding code when a unit has that domain specified?

Both pathfinding and AI could be made to work just fine relying on XML domains alone and for the most part they already work fine. Hardcoding with flags and pure XML setup will provide the same result.

XML only: no need to recompile to change stuff and you can just copy the DLL from another mod instead of compiling one yourself.
Hardcoding: faster to run and code, but requires compiling a unique DLL for each mod and recompile each time the hardcoded data is changed.

We can get the game to do as we like using both systems. Regarding bugs I would say that it's likely around the same, but the flags will cause failure to compile bugs while the XML setup will compile fine, but fail to do what we want ingame.

Surely there has to be a definition in the xml that says which units belong to which domain, and so do something along the lines of a jump to specific domain code, because even in M:C there are 2 domains, does it always run all code for both domains regardless of the domain type of a unit?

It's set in CIV4DomainInfos.xml, but they are also hardcoded in the DLL for performance reasons. I added a crude piece of code to assert that the DLL and xml stays in sync. In fact I think I added code to ensure that all hardcoded XML files stay in sync, but I did so more than a year ago and can't remember the details.

Actually I don't think this is the right thread to debate how to set up the DLL

 

[Lib.Spi't]

Actually I don't think this is the right thread to debate how to set up the DLL

I know, but until last night you kept talking here and refusing to use my fancy new link