We-the-People-civ4col-mod / Mod

This is the repository where the mod resides.
89 stars 37 forks source link

Allow other mods to use the codebase #94

Open Nightinggale opened 5 years ago

Nightinggale commented 5 years ago

In order to make the best use of the human resources available to the Colonization modding community, it would be ideal if development could focus on just one codebase. At the same time we should not discontinue all other mods. In other words we need a plan, which allows other mods to use the DLL code with as little impact as possible for RaRE development.

This should have only minor or beneficial impact on RaRE. Other mods can then add one or more cpp files with replacement for the disabled functions (telling AI how to treat other yields etc). This would be enough for Colonization 2071 and possibly also Medieval Conquest while they keep their uniqueness.

There is one big issue though. This will need Civics and Techs. Adding the xml files is not a big issue. The effect of those should rely on CivEffects, which is how they hook into the code elsewhere, meaning this part is not an issue either. Civic upkeep will likely be in a yield(mod) specific function anyway.

What's left is mostly the GUI and AI for Civics and Techs. I don't have a clear idea of how to implement those in a clean way right now, but it seems to be the last issue regarding transferring other mods to the RaRE codebase.

I have spent a while thinking about this as well as talking with other people about the differences between M:C and RaRE. It has essentially been evaluating every single feature difference for what can be changed into providing sort of the same result with xml changes only, what can be dropped without major losses and what really needs to be done to RaRE to get this working.

If/when we manage to be able to move mods over to our codebase, I can discontinue all work on other mods and devote myself 100% to RaRE. It's not only the most efficient for RaRE development, it's also what I would prefer doing, but at the same time I don't want to abandon existing mods with active xml development, which relies on my DLL coding.

ShadesOT commented 5 years ago

Something that itches me is what you wrote in another issue:

That if other mods add their mod-specific code with #ifdefs the code might become unreadable at some point. Rules would have to made (eg. diverging code only in the form of complete member functions or in form of inheriting classes). Someone would have to make sure other modders adhere to the rules. But still #ifdefs would be all over the code.

Imagine that for 100 mods or even just 5. IMO it does not scale very well.

ShadesOT commented 5 years ago

Also this is an issue: https://github.com/Religion-And-Revolution-Extended/Mod/issues/97#issuecomment-423152624

devolution79 commented 5 years ago

This is a fairly comprehensive proposal but I definitely agree that we eventually should have a single DLL to work with ALL mods. I suppose to that end, that the RARE DLL would be the successor to the M:C DLL ?

Nightinggale commented 5 years ago

I agree it's not a minor change, but the alternatives are working on multiple DLL files in parallel (which is even worse) or killing off all other mods (not good either).

I agree that adding some if else if chain of mods would be horrible and it was never on my mind. Instead I'm thinking of something where another mod can use the RARE repository in read only access. It should likely work something like this:

Another mod starts out as a fork of RARE. There is a don't care about the source code. Instead it's all about anything inside Assets. For getting the DLL, it compiles in a RARE repository. However it needs some mod specific data. To do this, we can add a plain text file to the project file directory telling where to find the xml files. At compiletime, the header generator script can use that path instead of a hardcoded one. It can also use that path to locate a source directory and copy all .cpp and .h files into DLLSources. Once done, it compiles normally and post compilation can then copy the resulting DLL back using the path.

The result is that it will overwrite one header file, which sets some defines (#define MAIN_RARE or whatever) and the cpp files are extra files, which will be compiled because the makefile compiles *.cpp, not a list.

The result will be that RARE development can basically ignore other mods. If a function becomes problematic, we just make it RARE specific by encasing it with ifdefs without any else case. Other mods will then fail to compile, but tell of the missing function, which in turn can make them copy paste the function into their cpp file(s) and edit it to match the mod in question. The goal is to not sacrifice coding freedom for working on RARE.

Documenting the xml files for each mod #97 isn't an issue. Since the xml interface isn't mod specific, all the mods will use the same documentation.

I suppose to that end, that the RARE DLL would be the successor to the M:C DLL ?

I certainly hope so. Ideally speaking nobody will ever commit to the M:C C++ code anymore. Using more than one C++ source code is a lot of work, particularly since if you say optimize one, you realize it would work in the other mod too and then you have to port the optimization and test it there too. It's so much extra work working on multiple DLL source codes in parallel and the extra work is close to being the most boring kind of programming.