DLL Code Repository

[EmperorFool]

This thread is for modders wanting to modify the BULL code. Here I will describe how the Subversion (SVN) code repository will be laid out. I hope to be committing the code this weekend in preparation for a release.

Repository Structure

As per SVN standards, main development will continue in a root "trunk" folder. Under that I will have an Assets folder to hold Art and XML (translated interface text strings).

trunk/
  Assets/
    Art/
      ACO/ (advanced combat odds images)
    XML/
      GlobalAltDefines.xml (for using BULL without BUG)
      Text/
        ACO_CIV4GameText.xml
        BULL_CIV4GameText.xml

Next to that will be the SDK folder to hold the source files for the DLL itself, the makefile, and hopefully the requires libs:

  SDK/
    makefile
    CvGame.h
    CvGame.cpp
    ...
    libs/
      msvcrt.lib
      ...

I will check in three sets of all of the cpp/h files, one after the other, to support easy tracking of changes:

1. All original BTS files
2. UP versions
3. BULL versions

Does anyone see any problems with this or have any suggestions?

 

[EmperorFool]

I have committed the code and the current build of the DLL to the repository in the "trunk" folder. The DLL itself is in the "Assets" folder.

I will next work on building an installer for BULL. For now, copy everything in the Assets folder into BUG's Assets folder. If you installed BUG using single-player, copy everything into the CustomAssets folder and move the DLL to BTS's Assets folder, renaming the one that is already there first for backup.

 

[phungus420]

For mergers, Better AI or otherwise, will the python from 3.6 work, or have there been significant changes?

 

[EmperorFool]

The DLL will work without BUG or with any BUG version, merged or not. However, you will have to change DLL options using the GlobalDefinesAlt.xml file. The trunk version of BUG has the code necessary to place the DLL options onto the BUG Options Screen, so it enhances usuability of BULL.

As well, there are a few BULL features that only work if you are using the very latest (trunk) version of BUG, specifically a few new hovers on the BUG Finance Advisor, Exotic Foreign Advisor, and the Scoreboard. You won't see them if you're not running the latest BUG, but they won't cause any problems.

BTW, you could use Subversion to make updating your merge to the latest BUG much easier. Once you put your merged mod's code into a Subversion repository (e.g. at SourceForge.net for free), you can apply the changes between two versions of BUG to your code using TortoiseSVN's merging facility. It allows you to diff two revisions in BUG's repository and apply those same changes to your code.

Some files will certainly have conflicts, most likely init.xml and CvMainInterface.py. Really, any file that you and BUG both changed during changes will probably get conflicts, but you can then fix them (search for <<<< to find the markers or use WinMerge).

 

[AlpsStranger]

I have committed the code and the current build of the DLL to the repository in the "trunk" folder. The DLL itself is in the "Assets" folder.

I will next work on building an installer for BULL. For now, copy everything in the Assets folder into BUG's Assets folder. If you installed BUG using single-player, copy everything into the CustomAssets folder and move the DLL to BTS's Assets folder, renaming the one that is already there first for backup.

Awesome! Thanks for all the hard work EmperorFool

 

[PieceOfMind]

I'm wondering...

At this point in time, what exactly do I need to do to use BULL+BUG with Better AI? I prefer to do it as a mod - not custom assets.

From what I understand, BULL, Better AI and ACO (included in BULL) all make DLL changes so I would first need a merged version of BULL+BAI, then put it in a basic BUG installation. Is this right?

If so, has anyone merged BULL with BAI yet? If not, is there an easy way to do it?

 

[EmperorFool]

I think BetterAI is going to be the most often merged mod with BULL, and I'm very tempted to create the merge myself with #ifdef preprocessor tests for a BETTERAI #define.

#ifdef BETTERAI
    // Better AI version of code
#else
    // normal version of code
#endif

Would you or anyone be interested in helping out with this? WinMerge could help a lot, but it will definitely require actual C++ knowledge to make sure the merge is done correctly.

 

[PieceOfMind]

I think BetterAI is going to be the most often merged mod with BULL, and I'm very tempted to create the merge myself with #ifdef preprocessor tests for a BETTERAI #define.

#ifdef BETTERAI
    // Better AI version of code
#else
    // normal version of code
#endif

Would you or anyone be interested in helping out with this? WinMerge could help a lot, but it will definitely require actual C++ knowledge to make sure the merge is done correctly.

EF,

Regrettably I'm at the limit of my abilities at this point. To be honest, getting the latest version of ACO out was getting pretty difficult. I'm not all that good with the code-related stuff - it is really only maths and straight-forward algorithms I'm competent with (the only things that ACO really needed) - keep in mind I used DanF's code to get me started.

Anyway, I'm guessing that cooperation with jdog would help a lot. I guess that either the developers of BULL or BAI are going to have to keep an eye on updates from the other. Perhaps the one with less frequent updates would be best to be the one that is added second each time.

Is it likely that there will be updates to BULL very often? If not, we could maybe get jdog to maintain both a BULL and normal version of BAI, and extra stuff added to BULL every now and then could be relayed to him and put in the next release of BAI.

 

[phungus420]

Anyway, I'm guessing that cooperation with jdog would help a lot. I guess that either the developers of BULL or BAI are going to have to keep an eye on updates from the other. Perhaps the one with less frequent updates would be best to be the one that is added second each time.

You know, it would make the most sense to just have BBAI incorporate BULL as default. Also since jdog works on RevDCM which includes BUG and will include BULL once an official release is out, having default BBAI include BULL would save him work in the longrun. You should ask him if he's willing.

Also why would you need good working knowledge of code to merge BULL and BBAI? Just use BBAI as a base and merge in the BULL comments, they should be pretty disconected, as BBAI doesn't really touch the interface.

I was going to volunteer to do this until you said you needed a good working knowledge of C++, which I definatly don't have... Still though I could give it a shot once I'm done with my current project, which will take a few days.

 

[EmperorFool]

What I'd like to produce is a BAI + BULL codebase where you can turn off BAI with a compilation switch. This tells the C++ compiler to ignore certain parts of code. That takes more than just WinMerging in the differences. You need to preserve the original code and integrate the new code. It's not rocket science, but it's more difficult than just clicking a "Copy changes" button.

For example, say that the original code has this:

    if (GET_PLAYER(ePlayer).getStateReligion() == eReligion)
    {
        ...

Let's say BAI adds a check to see if the player ID is even (totally arbitrary):

// BetterAI - start
    if (GET_PLAYER(ePlayer).getStateReligion() == eReligion [B]&& ePlayer % 2 == 0[/B])
// BetterAI - end
    {
        ...

The merged code would look like this:

// BetterAI - start
#ifdef BETTERAI
    if (GET_PLAYER(ePlayer).getStateReligion() == eReligion && ePlayer % 2 == 0)
#else
    if (GET_PLAYER(ePlayer).getStateReligion() == eReligion)
#endif
// BetterAI - end
    {
        ...

#ifdef works much like if() tests, but they are evaluated before compilation rather than while the program is running. If the preprocessor variable BETTERAI is defined, the first if() line is used and the compiler doesn't even see the second one. If it isn't, the other happens. This is done by the C++ preprocessor, the same thing that handles stripping out ASSERT checks for Final_Release builds.

The reason I'd like to do this is I imagine that both BAI and BULL will continue to add new features. The above would make doing merges easier since you'd just need to integrate the new BAI stuff once each time they release rather than doing everything each time either one has a release.

As you said, probably most of the changes in the projects are disjoint file-wise. This would make doing merges easier. However, BULL does have a few changes in CvSelectionGroup, CvCity, and CvUnit, files heavily modified by BAI.

 

[phungus420]

OK, that makes sense. BTW, ACO wouldn't merge in earlier releases of RevDCM with winmerge, had to be done manually.... So do you define this in the configuration manager then, like differentiating a debug and final release build?

Like I said I'm a bit hung up with a current issue in Legends. But once that's done I'll see about working on a merge of BAI and BULL. Probably the best bet though would just be to convince jdog to build BAI with BULL

 

[Cybah]

BAI+BULL would be great.