Project integration Idea, Suggestion & Discussion

I think that we will need some guide line or discussion on how to integrate multiple source code into single set of files. Let's discuss that before it become too big and too late.
This thead will not discuss topic of specific individual mod, but general and overall topic that will affect all SDK mod's.

My Suggestion:
1) Minimize impact on original source file?
We should make least modification to existing source file and least unit of code block. This will make it easy to integrate multiple SDK MOD's and easy to upgrade our project to next Civ4 patch version or next expansion (with next version of SDK release). I think that using separate source file for SDK mod ( or multiple mod) will minimize impact on existing source code. ( except few lines for hooking from existing code/source file.)

2) Use conditional #ifdef as much as possible.
Whenever we add or modify original source code, we should use #ifdef to conditionally include the modification. If we undefine all #ifdef condition, then the compiled DLL should work as equivalent as possible to original unmodded DLL. This may not practical on some times or even impossible, but we should try to do it. This condition can be little relaxed on mod that does not change behavior of existing code. The added part will be just sitting there as dead/unused code in that case.
Or we may include runtime flag that will direct wherther the mod will be activated or not. If the flag is deactivated, then the modded part will behave just same way as original DLL behavior.

Add your idea and suggetion in this thread...

And this is my other sugegstion:
How about to have our own CyGlobalContext equivalent for all user-developed (including this project) SDK mod?
current CyGlobalContext is too big and crowded.
Due to structure of Boost.python code, every class exposed to python mod will need more-or-less addition to CyGlolbalContext (gc) code. I suggest that we agree to use separete common CyGlobalContext equivalent other than original CyGlobalContext. If it we agree to use common gc, it will reduce source code impact to already-bloted CyGlobalContext and make the integration much easier and with less clutter for Python modder.
This also make it clear which is custom-made API or in-stock original API for Global context.

SimCutie said:

And this is my other sugegstion:
How about to have our own CyGlobalContext equivalent for all user-developed (including this project) SDK mod?
current CyGlobalContext is too big and crowded.
Due to structure of Boost.python code, every class exposed to python mod will need more-or-less addition to CyGlolbalContext (gc) code. I suggest that we agree to use separete common CyGlobalContext equivalent other than original CyGlobalContext. If it we agree to use common gc, it will reduce source code impact to already-bloted CyGlobalContext and make the integration much easier and with less clutter for Python modder.
This also make it clear which is custom-made API or in-stock original API for Global context.

Click to expand...

I think this is a good suggestion as far as we talking about added general Python Functions. But what about object specific function?

Example :
We add a function "xy" which do something specific with a unit. To have a simple use in the python mods this function should belong to the CyUnit class, so that you can call like "pUnit.xy()". If it belongs to the our own global context, it is not possible to have it objects specific. Then a call would look like OwnGlobalContext.xy(pUnit).

I'm not sure if this would be accepted.

I agree with 12 on that example, object specific stuff should follow the pre-established python calling that Civ4 uses. A new global context should be restricted to truely global stuff like a function that returns a list of all the modifications in our dll and its version number (SimCutie sugjested this earlier). Options and activation/deactivation of new content could also use the new context.

Every mod will need an initialization, reset and uninitialization more ore less.
But if mods are working inter-dependantly, the init/uninit of each mod should be concerted in consistent manner to avoid race condition..

The Civ4 has many stage and steps of initalization. I will list major one of our intertest.
1. static/global class construction time - good time to allocate/init constant items.
2. Event manger "OnInit" time.
3. Main menu time (Application finished init. all resource initialized, python mod loaded and readay to accept user menu input)
4. starting new game ("GmeStart" time - init/reset mod data.)
5. loading saved game ("OnLoad" time - another reset time.
Acually this is 2 step process - uninit data inited on step 4(game start time ) and re-init it )
6. Quit game - Time for uninit...

When do you init/reset/uninit your mod? and how?
I am getting help from CvGame class init and Python Eventmanager. But it seems not so satisfactory.

I would also suggest that if you are changing the way a whole function works, that to keep compatibility and to make code reading/implementation easier that you put it into a new function.

EG:
CvUnit::updateCombat(..) is the original combat function
CvUnit::updateStackCombat(..) is my new combat function using the original as a template.

It is assumed that the replacement function is called from the function it replaced with old functionality commented out.
updateCombat(...)
{
}


Is this correct?

I would imagine so.

Unfortunately I couldn't do that as I had to parse extra variables through to updateStackCombat. Thus I have to call it direct from groupAttack(..).