This thread is for the first release, a download for which should be available sometime soon. If you come up against any problems with it, please post them here, and we'll see about fixing them.

Changelog for v1.61.0001a:

NOTE: This is getting out of date. Please check release thread for actual changelog. It is similar to this, but all of SimCutie's changes are yet to be included.

For details of the following, please look at the changelog included with the file.

All options labled '(configurable)' will be have no effect on the default game unless enabled in the options menu.

1) AI:
Nothing

2) UI:
- Civ 4 CCP custom options screen added. Here you can cofigure which options you want enabled/disabled. (SimCutie)
- (configurable) Names of units can now be changed to display the unit type before the name instead of after the name. (SimCutie)
- (configurable) Added Great People Type and Civs name in Great People born announcement. (SimCutie)
- (configurable) Added Unit Type name in press-AltKey Combat Odd display. (SimCutie)
- Button states (show tiles/resources etc.) are now saved as user info, and will always be restored to their previous position on starting a game. (SimCutie)

3) Performance:
Nothing

4) Modding:
Note: None of these will have any impact on the normal game experience, however hopefully they will aid modders in improving the game.

a) Bugs:
- Fixed a crash when an incorrect model path was specified. (SimCutie)
- Fixed a bug where increasing the number of commerce type would cause bad things to happen. (Impaler[WrG])
- CvUnit::getNameKey() now correctly returns TXT_KEY_ entries for great people (SimCutie)

b) Changes/additions:
- New generic event manager interface to handle new events. Locates any function which returns a dictionary of events, and proccess them. Very pluggable. (SimCutie)
- All units have a unique unitID which is static throughout the unit's life. It will stay constant during upgrades/gifts. CvUnit::getUID() (c++), or CyUnit.getUID() (python) to get the unique ID. (SimCutie)
- Added CvUnit::getOldX() and CvUnit::getOldY() (c++), and CyUnit.getOldX() and CvUnit.getOldY() (python), to find the plot the unit was on before the current plot. (SimCutie)
- City name colour text can now be changed in CIV4ColorVals.xml (SimCutie)
- Scriptdata is now preserved across upgrades/gifts (SimCutie)
- Various initialization routines added (SimCutie) extern void CvExt_preinit();
void CyExtGC::onInit(python::object args);
extern void CvExt_postinit();
void CvExt_GameBegin()
void CyExtGC::onLoad(python::object args);
void CyExtGC::onGameStart(python::object args);
void CvExt_GameEnd();
void CyExtGC::onUnInit(python::object args);
- Fiddled with the save/load framework including backward compatibility.(SimCutie) Use following for global save data read/write:

extern void CvExt_read(FDataStreamBase* pStream);
extern void CvExt_write(FDataStreamBase* pStream);
- Enhanced game utils. The following checks have been incorperated into python to better control the game (12monkeys):

1.a.) called from CvCity.cpp
----------------------------
canCityWorkOnPlot -> if you want to prevent a certain plot to be workable
canCityHurry -> to prevent hurry production in a city
canCityConscript() -> to prevent conscripting in a city
calculateCityDistanceMaintenance() -> to change the distance maintenance for a certain city. Eg. by a special building.
calculateCityNumCitiesMaintenance() -> to change the num cities maintenance for a certain city. Eg. by a special building.
spreadReligionToCity -> to take action if a new religion is spread to y city


1.b.) called from CvUnit.cpp
----------------------------
doUnitCommand() -> be informed about all unit commands and take action if necessary
canUnitMoveInto() -> do restrict/allow a plot for unit movement
canUnitFortify -> Eg. for fantasy mods a "restless" cast
canUnitHeal -> to prevent a unit from healing (eg. for fantasy mods)
canUnitNukeAt -> to allow to nuke a friend or yourself (return TRUE to be able to nuke yourself!)
canUnitSpread() -> eg. to decide if a missionary can spread a religion
unitUpgradePrice -> to change upgrade price for certain units (due to a special building in a city?)
isUnitInvisible -> changes a units invisiblity (maybe for TheLopez' sniper mod)
canUnitJoinGroup -> to define if a unit can join a group. Eg. for limited group sizes.


1.c.) called from CvPlayer.cpp
----------------------------
canPlayerContact -> influence diplomatic abilities of a civ
canPlayerTradeItem -> influence in what players can trade.
canPlayerTradeNetworkWith -> to temporarily interrupt trade networks
canPlayerRazeCity -> have influence if a city can be razed or not
razeCity -> be informed/take action when a city is razed
canPlayerFoundCity -> influence where a city can be found
canPlayerConvert -> have influence on the religion conversion of a certain player
playerFoundReligion -> to prevent a religion being founded


1.c.) called from CvSelectionGroup.cpp
----------------------------
canGroupStartMission -> decide what group mission is allowed or not
groupStartMission -> be infromed when a group starts a mission
- New XML tags. Won't cause errors if not included. Full interface & 'pedia support (Impaler[WRG])

Civ4TraitInfos.xml
----------------------------
<iHappiness> - Adds set happiness in all cites. Negative values supported.
<iDiplomacy> - Any leader with Diplomacy altering traits experiences a bonus/penalty to all Diplomatic relations
<iSpecialists> - Any leader with the trait will get the perscribed number of free specialists in all cities
<iVoteModifier> - The number of Votes a player recives in the UN is multiplied by the modifer. No 'pedia support

Civ4BuildingInfo.xml
----------------------------
No AI support on these
<LocalSpecialistYieldChange> - Increases the yield of the set specialist for this city only
<LocalSpecialistCommerceChange> - As above but for commerce

Python Exports:
int CyCity::getExtraSpecialistCommerceOfType(int Commerce, int Specialist)
void CyCity::changeExtraSpecialistCommerceOfType(int Commerce, int Specialist, int Change)
void CyCity::changeExtraSpecialistYieldOfType(int Yield, int Specialist, int Change)

Pyton Alterations:
behavior of CyCity::getExtraSpecilistYieldOfType(int Yield, int Specialist)
changed to reflect local bonuses rather then just piping up to the player, and getting an all cities
modifier, to get a Bonus attactched to the player as the result of a wonder or Tech use the
new CyPlayer::getSpecilistExtraYield call described below


Civ4TechInfos.xml
----------------------------
No AI support on these
<SpecialistYieldChange> - Allows specialists of a certain type to increase their yield by the set amount on discovering the tech
<SpecialistCommerceChange> - As above but for commerce

Python Exports:
int CvTechInfo::getSpecialistYieldChange(int specialist, int yield)
int CvTechInfo::getSpecialistCommerceChange(int specialist, int Commerce)
int CvPlayer::getSpecialistTypeExtraYield(int specialist, int yield)
int CvPlayer::getSpecialistTypeExtraCommerce(int specialist, int Commerce)
void CvPlayer::changeSpecialistExtraYield(int specialist, int yield)
void CvPlayer::changeSpecialistExtraCommerce(int Specialist, int Commerce)
- 3 new forms of commerce added. Happiness, health, and experience (Impaler[WRG])

The mod will have no effect unless a modified Civ4CommerceInfos.xml is included and Civ4TechInfos is altered to give one or more Techs the <CommerceFlexable> ability to allow the user to direct funds towards the new Commerce types. Alternativly any thing in the game that adds commerce with tripple <iCommerce> tags can create the new Commerce types.
- Two new python methods: bool CyPlot.isOcean(), and bool CyCity.isConnectedToOcean() (12monkeys)
- (configurable) "combatLogCalc" event replaced with "combatBegin" event triggered at the beginning of every battle. Contains both unit pointers, and the combat odds. (SimCutie) pAttackerUnit Attacking unit
pDefenderUnit Defending unit
combat_odd (probability of attacker win in per thousand (0-1000))

- "combatHit" event added. Called before the damage is done in a combat phase. (SimCutie) pUnitInflictor damage-inflicting unit
pUnitSufferer damage-suffering unit
bIsAttacking inflictor is attacking(true) or defending(false)
iDamage damage percent (int)
fDamageEffective actual damage value (float)- "initEnd" event added - it is triggered when Civ4 application/Python initilization is finished, loading XML data before main menu is finished, font symbol is inited, and just before displaying first main game menu. (SimCutie)
- New CvCity method. CvCity::getNameLong() (SimCutie)
const CvWString CVCity::getNameLong();
Returns City name followed by Civ. name. ex) "Paris, France"
- C++ : const CvWString CvCity::getNameLong();
- Python : string CyCity.getNameLong()
- CV***Info search routines: CyExtGC::findInfoTypeForString(LPCTSTR infoKey ) - similar to GC.getInfoTypeForString(LPCTSTR infoKey ) but it will not cause Assert failure when info does not exist. See readme for details (SimCutie)
- Action routine - Executes a widget action as if the widget is clicked by mouse. See readme for details (SimCutie)
- Misc. routine - Adds text entry to Game text manager. See readme for details (SimCutie)
- 1.13 Something to do with logging - I have to go now, will update this later. Can you give me a brief description to put here SimCutie?
- Custom widget action facility. This is used to attach any python function to your widget. See readme for details (SimCutie)
- Action Button facility. This is an application of the Custom Widget Action facility described above allowing addition of action buttons. See readme for details (SimCutie)
- Debug function added for SDK. Check out mod readme for details (12monkeys)

5) Bug fixes:
- Fixed a bug where units being transported by units which get upgraded, and lose transport capacity because of being upgraded (caravels --> frigates), were still transported. Now transported units will jump to the nearest valid plot, like when you are pushed by culture. (12monkeys)
- Fixed relocation due to culture/end war for ships. They will no longer get stuck in lakes when they were originally on the ocean. (12monkeys)
- Fixed an issue where production queues could be loaded in new games allowing construction of other Civ's UUs. Production queues can still be loaded, but you can no longer build other Civ's UUs. (12monkeys)

6) Optional Gameplay Tweaks:
- (configurable) GreatPeoplePointPooling by Impaler[WRG]. Re-directs all GreatPeople Points generated in an Empire to a central Pool attached to the player.
- (configurable) RogerBacons Flying mod, AirCombat, and Defensive zoom
- (configurable) Chalids Slow Cultural Borders
NOTE: Should get some links for the above, rather busy doing other things right now

I am OK to release on May 17 though it has not much thing to show...
We should have time to integrate and adjust conflict /duplication /inconsistancy among our own codes.. So I had released a preliminary version few days ago, but I did not get much feedback regarding such confict with modder's own work.
No one except me has released or commited code in CVS, it seems.
Am I missing something or drumming wrong drum?

Integrating codes of multiple author ( especially who never met in persopn or worked togather) would be not so easy and potentially troublesome process. It will take quite a time and many discussion. I suggest you all to commit your code into CVS as soon as possible and begin to look into each others codes closely to see if any problem may arise.

Well, my code is more or less ready as well. I don't expect much problems with it, because the changes I did are very less and very simple. I would have done more, but due to this unlucky CVS issues I spent most of my time with CVS than coding :( . [BTW : I can't reach the CVS this evening, it seems to be down, so I can't upload anything.]
As TGA already said, we should have at least one ore two bugfixes in, which may increase the acceptance of the project. I will try to take care of some the next days, but I can't promise.
Maybe we have to postpone the release for a week or two, to solve the remaining CVS issues and to gain some time for testing.
Also : I'm not sure who of the enroled team members is doing actively what for the project? There are only 5 members registered at SF for this project (TGA, SimCutie, SpoiledFruit, Impaler and me). So the chance to get something from the others is quite less. TGA, maybe you should contact them directly by PM to get a status. Infos we need are what has been changed and when it is ready.
Another topic is documentation. The changes must have a documentation and (in some cases) examples how to use it.
Still a lot to do and to organize.

For the version number, we probably could use v 1.61.0001 to show that it is compatable with the 1.61 patch and is version 0001 of our revision. I used four digits but we probably could just use three.

For alpha builds we can use the letter a (v1.61.0001a)
For betas we can use the letter b (v1.61.0001b)
And final builds have no letter (v1.61.0001)

This is the convention I use at work when I am updating only DLLs of existing programs.

I have some minor changes but until now was not able to debug with that CodeBlocks. I'll try to look again into it this weekend so we'll see.

I am OK to release on May 17 though it has not much thing to show...
We should have time to integrate and adjust conflict /duplication /inconsistancy among our own codes.. So I had released a preliminary version few days ago, but I did not get much feedback regarding such confict with modder's own work.
No one except me has released or commited code in CVS, it seems.
Am I missing something or drumming wrong drum?The SDK is rather large, and it'll probably be a while before we get any really big conflicts. From what I can tell the only thing in your changes that may cause conflict is the unitID switch - but I don't it's likely to. From what I can tell everybody is working in slightly different areas. This is, in part, why I made the "mods in progress" thread - so that we can avoid two people doing the same thing in different/conflicting ways.

I think we should try to upload to the CVS whenever we feel we have a stable version of our current changes, so that any edits can be based on them, or at least the ideas behind them.

Well, my code is more or less ready as well. I don't expect much problems with it, because the changes I did are very less and very simple. I would have done more, but due to this unlucky CVS issues I spent most of my time with CVS than coding . [BTW : I can't reach the CVS this evening, it seems to be down, so I can't upload anything.]
As TGA already said, we should have at least one ore two bugfixes in, which may increase the acceptance of the project. I will try to take care of some the next days, but I can't promise.
Maybe we have to postpone the release for a week or two, to solve the remaining CVS issues and to gain some time for testing. Sounds like we might have to. Maybe shift the provisional date back to Monday 22nd so that we have the weekend for testing? We'll see how it goes.


Also : I'm not sure who of the enroled team members is doing actively what for the project? There are only 5 members registered at SF for this project (TGA, SimCutie, SpoiledFruit, Impaler and me). So the chance to get something from the others is quite less. TGA, maybe you should contact them directly by PM to get a status. Infos we need are what has been changed and when it is ready.So far we have 15 people, however, it would seem that alot of people are lurking behind the scenes. I'll probably do as you suggest and send out a bulk PM tomorrow sometime.


Another topic is documentation. The changes must have a documentation and (in some cases) examples how to use it.
Still a lot to do and to organize.For most people it would be simply "install into mod directory". Other changes I would expect to be documented within the code, and if we include files changed in the changelog then people shouldn't have too much difficulty in finding it.

For the version number, we probably could use v 1.61.0001 to show that it is compatable with the 1.61 patch and is version 0001 of our revision. I used four digits but we probably could just use three.Good idea. Maybe we should include something to show which game it is compatable with - a .dll file for Warlords may not be compatable with one for regular Civ. Maybe:

c 1.61.001a (Civ, patch 1.61, 1st version, alpha)
w 1.00.162b (warlords, patch 1.00, 162nd version, beta)
e 1.32.125 (expansion 3 patch 1.32, 125th version, stable)

Although this could have troubles if they call the 2nd expansion pack something beginning with 'c' or 'w'...

On a different note - have you managed to get the options screen working yet? Not that crucial for this release as we don't have much in here - just curious


I have some minor changes but until now was not able to debug with that CodeBlocks. I'll try to look again into it this weekend so we'll see. Okies, looks like you will need a few more days as well.


If you missed the date I had hidden in there, I am suggesting we move the date back to Monday 22nd so that we can sort out CVS/server issues, as well as give a tiny bit more time for people to finish things off.

EDIT: Also, is what we are doing a mod component or a mod pack. I'm thinking component, though it has some aspects of a pack. Hmmm.

EDIT: Also, is what we are doing a mod component or a mod pack. I'm thinking component, though it has some aspects of a pack. Hmmm.

IMO its clearly a mod component. Most of the changes are for modders only. If you just install it, the effects on the game are very low.

On a different note - have you managed to get the options screen working yet? Not that crucial for this release as we don't have much in here - just curious.
I finished custom option screen for SDK DLL runtime confiuration. Complete with Option Screen, Python API, SDK API, Ini file Config read/write, in-SDK user configuration access. I will update it in next CVS upload.

I finished custom option screen for SDK DLL runtime confiuration. Complete with Option Screen, Python API, SDK API, Ini file Config read/write, in-SDK user configuration access. I will update it in next CVS upload.


Hey! That sounds really good :D. I'm curious to see it. But CVS is still down :(.

I am eager to see it as well, I want to use it for controling by GreatPeoplePointPooling mod (pools all GPP from across your empire rather then in each city individualy), I have it all set up too switch between original behavior and my new behavior with a boolean call. Most of my other mods are run off XML flags and will be silent without the required flags thus they dont require any run time configuring.

SimCutie could you zip and upload the files so we can start plugging in our mods, and thus get things ready asap.

I have been busy at work lately but I will try to get the CVS server fully accessable today or tommorow. I will not have password protection on the FTP server right now b/c I haven't had a chance to send out all the User IDs and Passwords and the forum is still private.

The FTP server link is here (Link Removed) if you want to get to it. If it doesn't work, its b/c the server isn't up yet. Read and write access is enabled at this point for existing files only. This is just a temporary IP, the permanent one I will PM everyone allong with there user ID and passwords.

Also I saw SimCutie was already ahead of me on the options menu so I let Sim handel it. I will add extra options as needed though (if thats alright with you Sim).

On the prefix for game versions (original, Warlords, Etc.) I thing we can just separate them into there own groups instead of worrying about prefixes

I need some help..
I need unmodified Firaxis version of \Assets\XML\Interface\CIV4ColorVals.xml of update 1.61.
I inadvertantly overwritten a XML file in my Game installation directory instead of CustomAssets. :sad:
I have some backup but it was that of update 1.52, not 1.61.
Please, upload the file CIV4ColorVals.xml in ZIP as a attachment for me.... :p

I don't have a copy of the 1.61 file here, only the 1.52. I didn't know that this file was changed in the update.


On the prefix for game versions (original, Warlords, Etc.) I thing we can just separate them into there own groups instead of worrying about prefixes
You're probably right.

EDIT: Oh, and I'll send out a bulk PM to anybody not already posted on this thread to check status when the server is up.

I need some help..
I need unmodified Firaxis version of \Assets\XML\Interface\CIV4ColorVals.xml of update 1.61.
I inadvertantly overwritten a XML file in my Game installation directory instead of CustomAssets. :sad:
I have some backup but it was that of update 1.52, not 1.61.
Please, upload the file CIV4ColorVals.xml in ZIP as a attachment for me.... :p

Here's what you need.

Is anyone able to access the CVS, I was initialy able to access it make checkouts and perform commits but havent been able to get anything the last 2 days. Is SF locking us out or doing some kind of repair? 12monkeys says he's having problems as well so I dont think its me. Also has anyone yet commited a mod to the CVS, SimCutie sounds ready to do so are you able too? I continue to work on new Mods as I wait but I need to get a hold of that Options menu to plug in to it. And we need a solution to savegame compatability (see new thread) have we desided if backward compatability is a must for first release or is it a goal for next release?

']Is anyone able to access the CVS, I was initialy able to access it make checkouts and perform commits but havent been able to get anything the last 2 days. Is SF locking us out or doing some kind of repair? 12monkeys says he's having problems as well so I dont think its me. Also has anyone yet commited a mod to the CVS, SimCutie sounds ready to do so are you able too? I continue to work on new Mods as I wait but I need to get a hold of that Options menu to plug in to it. And we need a solution to savegame compatability (see new thread) have we desided if backward compatability is a must for first release or is it a goal for next release?

CVS ist down since the last 3 days. Nobody can connect to it, though you can ping the server. It seems to be global SF problem, because a LOT of projects have such problems. If you look into the SF Support Requests there are tons of requests reporting CVS connect problems since days.
Right now, I haven't found any info from SF what happens there and what they are plan to do. Its simply frustrating, that they are not able to inform the users about the source of the problems.

How about to have some chatting on our project before we release first result?
I suggest it to be May 13, 23:00 GMT (Saturday, Today) at #civfanatics channel of IRC chatting.. It will be 19:00 in USA, NewYork Time (EDT)

How about to have some chatting on our project before we release first result?
I suggest it to be May 13, 23:00 GMT (Saturday, Today) at #civfanatics channel of IRC chatting.. It will be 19:00 in USA, NewYork Time (EDT)Sounds like a good idea but...

I can't access the chat from the computers here. Always says "unable to connect to server" . I might try again later. I can't change any of the settings as they aren't my computers...

How about to have some chatting on our project before we release first result?
I suggest it to be May 13, 23:00 GMT (Saturday, Today) at #civfanatics channel of IRC chatting.. It will be 19:00 in USA, NewYork Time (EDT)

Mmmhh. This is 01:00 MES. I will try...

Mmmhh. This is 01:00 MES. I will try...Eh? I thought Germany was GMT+1?

Eh? I thought Germany was GMT+1?

Yes when talking about CET (Central European Time). But right now we have daylight saving time in Germany, which is CES or CEST (Central European Summer Time). SimCutie said 23:00 GMT. GMT aka UTC is, by definition, no daylight saving time. SimCutie mentioned EDT which should be Eastern Daylightsaving Time (which came from EST : Eastern Standard Time). EST is GMT-5, so EDT is GMT-4. This matches with his other statement about EDT 19:00 and GMT 23:00 (-> difference of 4 hours).

Conclusion : EDT 19:00 = CEST 01:00 = BST 00:00 = GMT 23:00.

TGA : you should dial in at 00:00 and not at 23:00 if you're still in Cambridge ;)

12m

I stand corrected, even though I'm still slightly confused.

Java chat still isn't working.

Do we have enough time to get the sourceforge CVS up before Friday? If not, there may have to be another delay.

I have my server up and online however it seems to me that people from the outside cannot get in to the FTP server. I am trying but it might be because I am testing access within my network, trying to go out and come back in again.

If someone could test this link (Link Removed) and tell me what they get I would appreciate it.

Now with the server up and fully functioning (except the connection part) and I am starting to get the hang of the CSV program I instaled, we might get the release without SourceForge.

Like I said the server is ready, I just cant get it to connect via my external IP. I have port 20 and 21 forwarded to my server.

Following Error message after a brief wait

530 Not Logged in. Username or Password Incorrect or user logged in too many times.

Am I supposed to have a password, I dont, if I was supposed to enter it someware I saw noware to do so.

I hope we can make the First Version by the End of the Month, CVS has been such a hastle to get up and running and the directory still needs to be cleaned out of various garbage files accumulated when we were unable to use webview and inadvertantly created gobs of directories.

I am wondering if we want to start a Thread advertising the First Release, kind of a Preview as many mods have. We could include a list of expected changes, ask for sugjestions, invite more moders into the project or ask others who have been doing SDK mods if they are interested in donating their code.

I got a window asking for my username and password - seems to be working.

As for potential chagelists - I need people to post up individual change logs as I asked in the first post of this thread... otherwise we don't have much to put in there!

Alright I forgot to set access to Annonymous. I will send out PM's to everyone shortly with their user name and password as well as the server IP link. I am going to dissable the links in the forum after everyone gets their PM.

As before, just PM me a new password if you want to change it. The password IS case sensitive as well. If you have any problems just PM me or post it here.

Also I will create folders with your individual names for posting update files and change logs not yet in the regular builds. Think of it like your scratchpad.

Right, looks like we're going to have to push it back again.

How about -

Release date: Thursday May 25th

Changes Locked: Monday May 22nd

This gives us the weekend to merge the code, and get everything working together. That should be plenty of time, assuming that the server is up and running by tomorrow.

OK, I'm back on track now. My changes are finished and tested and ready to be merged to whereever we have something. I'm fine with the date.

12m

I think we should use my FTP server until SourceForge is up to merge the source. Try and put your new files in your own personal folders and I will merge them together and compile an alpha binary.

Right... looks like we are heading for another delay. I was hoping that the either one of the servers would be working fine by the weekend, but it doesn't seem to be the case.

I think I'll hold off putting out new provisional dates which won't be met unit one or other of them are working.

I give up on CVS..
It seems that it will not fixed any soon...
Spoiled Fruists's server is not working properly..
Now we have only one choice..
Lets use ZIP attach file...
We should finish first release without using CVS..
All moder here, How about post your code as attachement in this thread.?
Here is mine.. ( not yet cleaned up fully but all features are included)
jobs to do now: clean up codes, tide up few XML text entries, documentations..

I give up on CVS..
It seems that it will not fixed any soon...
Spoiled Fruists's server is not working properly..
Now we have only one choice..
Lets use ZIP attach file...
We should finish first release without using CVS..
All moder here, How about post your code as attachement in this thread.?
Here is mine.. ( not yet cleaned up fully but all features are included)
jobs to do now: clean up codes, tide up few XML text entries, documentations..

I think its currently best solution. If we do so, we should synchronize the merging via this thread here.

Everybody who is merging something should announce the start and end of this work here. Otherwise we have have overlappings which results in duble work.

I will try to start merging my changes into SimCuties attachment this evening [about GMT 20:00]. Before I start I will check here in the forum and post the status. If somebody else is faster I will wait of course.

12m

Yes it seems this will be the only way for now, I sugjest we take turns each of us merging in out content testing and then uploading for the next person to use, As each person merges we can consider the code under lockdown so as in essense to do our own CVS'ing. If the file sizes exceed the upload limits of CivFanatics (very likly if we include XML and Python) we can resort to E-mail (Just think of it as a PBEM but with Code). I'm still polishing off a mod I realy would like to see included so I recomend someone else who is fully ready do the first merger with SimCuties code and upload their results. I will be pounding away at the code Sunday but then work Monday & Tuesday (and I work 12 hour shifts) so thouse days are no good for anything but the following 2 (Wed, Thursday) I have off and will definatly be ready (and if I am not I'll just skip that mod till next cycle).

We almost certainly won't hit max file size. You can upload up to 5 megs using the "Upload File" link at the bottom of each page.

Is there anybody else with files to include at this stage? If so, I'd suggest either starting your changes before GMT 20:00 (and telling 12m), or doing them after 12m has finished.

If this all goes to plan we should be able to do final testing on Friday, and release on Saturday - we should have to do so much testing as testing happens while we merge files. This is just in time for the pledge in my sig.

Also, once you've merged your files could you please post a change log here. I'm just going to update the first post with the changelog hidden away in SimCuties file.

I don't really have time right now to pour through the code finding answers to these, so I thought I'd ask.

1.6 Added Great People Type and Civs name in Great person born announcement.
Old: "Albert Einstain has born in Frankfrut"
New: "Albert Einstain (Great Scientiest) has born in Frankfrut, Germany"
Is this configurable?




2.1 "unitCreated"/"unitLost" :
"unitCreated"/"unitLost" event will not triggered on unit upgrade/ unit gift.
Replaced with "unitReborn/EVENT_UNITREBORN" on such case.

...

2.3 "combatLogCalc" : Removed. Replaced by "combatBegin"

...

Change 2.1, 2.3 can be turned on/off by run-time config (LEGACY_EVENT).
Turning it on will restore old behavior.Surely this should not be runtime config? Event behaviour should be consistant throughout an individual mod, and should be controlled by the modder and not the player.

OK, then lets do it this way. I will start merging my changes into SiMCuties' this evening. I also will add a text file with a change log. Also, I will post as soon as I start and I will post when I'm finished.

BTW : TGA, your sig tells something about "SDK Community Civ 4 Enhancement Project". But isn't the name of this project "Civilization 4 Community Core Project" as it is announced in SF? In any case we should have a common name and maybe a common sig pointing at it.

BTW : TGA, your sig tells something about "SDK Community Civ 4 Enhancement Project". But isn't the name of this project "Civilization 4 Community Core Project" as it is announced in SF? In any case we should have a common name and maybe a common sig pointing at it.It does? :mischief:

Forgot to update that bit - been there since the thread started.

I have to say SimCutie - that's ALOT of stuff in there. I'm quite impressed!

Documentation may be a bit lacking - I'd quite like to see examples of how to incorperate a new event manager, as well as define new options for the options screen. It would seem that you have to define them in an .ini file, and then in CvCustomOption.py, right?

You also seem to have alot of redundant files. From what I can tell the main interface changes aren't in effect, nor the civilopedia changes. We should really get rid of the files which don't actually do anything before the release.

OOPS! My CHANGELOG is not ready to be released.. It is full of error and under extensive editing.. Don't trust it. *blush*


Surely this should not be runtime config? Event behaviour should be consistant throughout an individual mod, and should be controlled by the modder and not the player.
I see, So it has no custom option screen check box to be changed by player.
But I will consider to modify it to be configured only on boot time. (Python Mod should set it on 'OnInit' event time.)


... Documentation may be a bit lacking - I'd quite like to see examples of how to incorperate a new event manager,
Yes, lack of docs. I am working on it. But too short time until first release time. So I will do major work to supplement lacking docs after first release.
I am not English-native so it may be slow process, please be patient.

as well as define new options for the options screen. It would seem that you have to define them in an .ini file, and then in CvCustomOption.py, right?
.
No. Only places you should edit are your "EventHandlerRegister()" and handler code in *your* MOD. No editing of .ini file or CvCustomOption.py.
This is driving design objective of this implementation.

For example in *YOUR* MOD file...


import CvUtilCustom

def EventHandlerRegister( evt_mgr, unused = None ):

import CvCustomEvent
return { CvCustomEvent.EVENT_OPTIONBEGIN : onDrawOption, }


def onDrawOption(argsList):
optscr, canvas, Unused = argsList[:3]

CvUtilCustom.useSection("MY_SECTION")
# Show Checkbox on Option Screen

optscr.addGenericCheckbox( canvas, "MYOption1Checkbox",
"TXT_KEY_OPTIONS_MYOPTION1_LABEL", "MY_SECTION", "my_option1", False )

# show Drop down box...
aszDropdownElements = (
"TXT_KEY_OPTIONS_MY_OPT2_DD0",
"TXT_KEY_OPTIONS_MY_OPT2_DD1",
"TXT_KEY_OPTIONS_MY_OPT2_DD2",
"TXT_KEY_OPTIONS_MY_OPT2_DD3" )

optscr.addGenericDropdown( canvas, "MYOPT2Dropdown",
"TXT_KEY_OPTIONS_MYOPT2_LABEL", aszDropdownElements, "MY_SECTION",
"my_option2", 0 )


def Your_MOD_function():
.........
if CvUtilCustom.getCutomOption("MY_SECTION","my_option1", False) == True :
do do something acction to user choice....

optVal = CvUtilCustom.getCutomOption("MY_SECTION","my_option2", 0)
if optVal == 0 :
.............
elif optVal == 1 or optVal == 2 :
............
elif optVal == 3:




That is all... And add appropiate TXT_KEY_'s like "TXT_KEY_OPTIONS_MYOPTION1_LABEL"
and "TXT_KEY_OPTIONS_MYOPTION1_LABEL_TT" (for tool tip), "TXT_KEY_OPTIONS_MYOPT2_LABEL",
"TXT_KEY_OPTIONS_MYOPT2_LABEL_TT", "TXT_KEY_OPTIONS_MY_OPT2_DD1" ,
.... "TXT_KEY_OPTIONS_MY_OPT2_DD4" in text XML file.
NO editing of .ini file or CvCustomOption.py. is required.


You also seem to have alot of redundant files. From what I can tell the main interface changes aren't in effect, nor the civilopedia changes. We should really get rid of the files which don't actually do anything before the release.
Yeah, some Python files and XML files are included in ZIP file unintentionally. Ignore them ..
Civilopedia is not required to work properly. It is mistake. :blush:
But Main interface is included to demonstrate Action button faciliy. It should work to see action button. and Show grid/Show resource fix.

The FTP server is back up and should work now. Let me know if you have problems in the server helpdesk thread. If you need a login name and password as well as the IP address, just PM me

Oh and TGA, could you get Thunder to Stickey the Helpdesk thread?

OOPS! My CHANGELOG is not ready to be released.. It is full of error and under extensive editing.. Don't trust it. *blush*Ooops. Sorry ;)

Yes, lack of docs. I am working on it. But too short time until first release time. So I will do major work to supplement lacking docs after first release.
I am not English-native so it may be slow process, please be patient.
No problem - take your time.


No. Only places you should edit are your "EventHandlerRegister()" and handler code in *your* MOD. No editing of .ini file or CvCustomOption.py.
This is driving design objective of this implementation.

For example in *YOUR* MOD file...

<snip>

That is all... And add appropiate TXT_KEY_'s like "TXT_KEY_OPTIONS_MYOPTION1_LABEL"
and "TXT_KEY_OPTIONS_MYOPTION1_LABEL_TT" (for tool tip), "TXT_KEY_OPTIONS_MYOPT2_LABEL",
"TXT_KEY_OPTIONS_MYOPT2_LABEL_TT", "TXT_KEY_OPTIONS_MY_OPT2_DD1" ,
.... "TXT_KEY_OPTIONS_MY_OPT2_DD4" in text XML file.
NO editing of .ini file or CvCustomOption.py. is required.Aaaah, I get it! That's actually really neat!

Yeah, some Python files and XML files are included in ZIP file unintentionally. Ignore them .. Ok, will ignore. I had assumed some of them were junk anyway.

The FTP server is back up and should work now. Let me know if you have problems in the server helpdesk thread. If you need a login name and password as well as the IP address, just PM me

Oh and TGA, could you get Thunder to Stickey the Helpdesk thread?
Works great! I shall PM Thunderfall.

Ok guys - scrap the plan with the uploading to CFC, let's get FTPing.

@ SimCutie
I had a look on your files and its a impressive mass of changes which you implemented. But there are several points which makes me think that we should not use them that way for the release.

a.) I did check nearly each non SDK file for its contents and I found a lot of files with questionable contents, sense or format. Its hard to determine which file is an example, which file is used and which has been added accidently.
b.) There is general lack of comments and documentation. The comments which are found does not match our specifiation.
c.) The changed SDK files (cpp and h) still contains #ifdefs, allthough we decided not to use them. BTW : I was not able to compile the project. It may be because I didn't used your project file and simply copied the cpp an h files into my version. I got fatal errors while linking. Did you maybe forgot an h file? Anyway that makes it impossible for me to test anything from your package.
d.) The single changes and files in the non SDK part, can't be assigned to the modification they belong to. As a modder, I would like to know what the code is doing and for what changes the modifcations are.
e.)The list of modifcations you implemented is impressive, but, to be honest, I would prefer a third of them if they are completed, documented and tested. The current situation is, that they are not documented and badly commented.
f.) you seems to removed several events. If so, this is not a good strategy. this may make existingmods incompatible. Better would be to add events and than to remove or replace them.

SimCutie, please don't take this personal, but you need to do your modifications more carefully. I don't talk about the quality of your change, in fact I think you're a brilliant developer. Only looking on the Action Button changes and the Event Handler, tells me that you a way better developer than me. Its even hard for me to understand what and way you are doing things the way you did. But exactly that may become a problem for the project. The project has the target, to deliver a common core (you may also tell it a framework) for the complete community. But this presupposes that the people need to UNDERSTAND the framework. If nobody understand how the changes works, or at least how to USE it, they won't use the framework.
I think I'm a average programmer with average skills. But I'm working in the software developement (actually as project manager, former as developer) for nearly 18 years now and I saw a lot of people, problems and projects come and go. Out of my expereince, there is not much more important than to keep code simple. I agree that sometimes code must be complex out of the problem. But if you need to make it complex you have to balance this with a good documentation and/or sample implementations. You may did so, but I can't identify them as this, because you send us a bunch of bad documented files.
Please let me make a suggestion: looking at your list of changes, we should reduce the list of implemented features to a smaller amount. Than you can concentrate on those features to implement them consequently, to document them and maybe to create sample implementations (eg. for the action buttons and/or event handler).

Especially for the first release, the parole shold be "quality is better than quantity".

Attached you will find a ist with comments to your non SDK files and the list of the errors form the linker.

12m


PS : I haven't merged my changs because it makes no sense without being able to compile it.

@ SimCutie
I had a look on your files and its a impressive mass of changes which you implemented. But there are several points which makes me think that we should not use them that way for the release.
.......[snip]
Especially for the first release, the parole shold be "quality is better than quantity".

Attached you will find a ist with comments to your non SDK files and the list of the errors form the linker.

12m


PS : I haven't merged my changs because it makes no sense without being able to compile it.

Oh! Thank you very much for kind comment and criticism... This comments would be invaluable advice for my work..

Some XML files are errornously included in ZIP file.. Please ignore them...I am sorry for confusing you.

There is genuine lack of documentation indeed but this is just alpha or beta stage of the project and just 1.0 at best. It is changing and evolving so fast; moving target is hard to document.
You are too much to expect complete document for 1.0 of this kind of hobby project of just little over a month. You must be very demending boss or manager, I guess :)
I need some more time to build up docs. I am not English-native and not even belong to Latin-languge group. Pardon me for a while for lack of documents.
Example usages in working souce code is currently best document.
But think of how much of docs/comments the Firaxis code has?
I boast much higher density of comment and docs compared with Firaxis code or other averge Modders in Civfanatics commiunity. :)

#ifdef thing is currently under use for regression/component testing.
I will remove it if it is considered as stable and semi-permanent part of the SDK.
It is too early to commit them as permanent part.

Use "CvGamCoreDLL.vcproj" file in ZIP to include addtional files to your project. All linkage error are reference to the added new files.

On event removal: There is only one event removed. And it is actually replaced with similar event. Because old one is considered to be a BUG. Wrong event in wrong time and with wrong argument. So it is hardly utilized productively by any current MODS.

On understanding frame work:
No I don't think so. The usage of this framework is rediculously easy and simple.
Just one example explains it all. See first few part (line 55-110, 157-161) of "SimCutieMainInterface.py".
It has examples for Event handler, screen handler, action button and Custom option screen, custom option access, abd DLL access .. nealy all in just 50 lines.

I can not imagine the same work can be expressed or implemented in simpler way than this.
Take little time to understand it.

The attched ZIP above is not intended as final submission, so don't use it as base for merge as final release. I haven't seen any of other modder's code and didn't check for any possible conflict or inconsistency. I just posted the ZIP to promote others to post current source which is being worked on.
Has anyone posted some code except me? I wanna see yours all... please post....

Well now with my FTP server up (and actually WORKING!!!!) I think we should show and merge filse via the personal folders and implement beta changes in the civ4 folder where the main source code is. I would also like people to use the included project or solution file (i have a free software addin that does python in VS.net I will put in my folder should make combining code much easier) That way we dont have to search posts to find files.

Oh! Thank you very much for kind comment and criticism... This comments would be invaluable advice for my work..

Ok, first of all, sorry for the harsh words (if so). I really don't want to offend you.


Some XML files are errornously included in ZIP file.. Please ignore them...I am sorry for confusing you.

There is genuine lack of documentation indeed but this is just alpha or beta stage of the project and just 1.0 at best. It is changing and evolving so fast; moving target is hard to document.
If this is alpha or beta state, than you shold to mark them as this. I thought you posted it to start the "merging cycle".
My usual way of working is that I only have one topic in work and I do implementing, testing and documenting it completly, before I start another one. Looking at yours it seems to me that you started 8 points without finalizing one completly. Please keep in mind, that have to work in a team and that the changes needs to be understood by the others. You put yourself under pressure if you start to much at one time (at least this is my opinion).


You are too much to expect complete document for 1.0 of this kind of hobby project of just little over a month. You must be very demending boss or manager, I guess :)
I need some more time to build up docs. I am not English-native and not even belong to Latin-languge group. Pardon me for a while for lack of documents.
Example usages in working souce code is currently best document.
But think of how much of docs/comments the Firaxis code has?
I boast much higher density of comment and docs compared with Firaxis code or other averge Modders in Civfanatics commiunity. :)
Again, I don't think so. If we want the modders use our work, they have to understand it. We have a different position to firaxis, because they built the game everbody wants. There is a large community analyzing the SDK and API and creating documents and guidelines to use. We are only a few people offering something which MAY help them. Don't expect that anybody will spend much time to anlyze and dcoument what WE are doing. If the modders have the feeling, that it is to complex or that the don't understand how to use it, than they won't use and we failed.
Regarding examples : there may be example, but they can hardly be indentified as such. Examples must be marked as examples. Mybe you put those files into a seperate subdirectory.


#ifdef thing is currently under use for regression/component testing.
I will remove it if it is considered as stable and semi-permanent part of the SDK.
It is too early to commit them as permanent part.
If they are tested they will be permanant part. To have a config option to switch them on/off whould be enough.


Use "CvGamCoreDLL.vcproj" file in ZIP to include addtional files to your project. All linkage error are reference to the added new files.
I copied all your files into my solution. Anyway, I'll test it again this evening.


On event removal: There is only one event removed. And it is actually replaced with similar event. Because old one is considered to be a BUG. Wrong event in wrong time and with wrong argument. So it is hardly utilized productively by any current MODS.
Still not sure if wouldn't be better to add a new one, instead of removing an old one. But OK.


On understanding frame work:
No I don't think so. The usage of this framework is rediculously easy and simple.
Just one example explains it all. See first few part (line 55-110, 157-161) of "SimCutieMainInterface.py".
It has examples for Event handler, screen handler, action button and Custom option screen, custom option access, abd DLL access .. nealy all in just 50 lines.

I can not imagine the same work can be expressed or implemented in simpler way than this.
Take little time to understand it.
Again, examples hould be marked as examples.


The attched ZIP above is not intended as final submission, so don't use it as base for merge as final release. I haven't seen any of other modder's code and didn't check for any possible conflict or inconsistency. I just posted the ZIP to promote others to post current source which is being worked on.
Has anyone posted some code except me? I wanna see yours all... please post....
If this is the intention of your ZIP than its OK, but you posted that we should try to start merging via forum. So I took the ZIP as your release version.

But before you upload some files next time, have them more clean and ready, please.

Above you said that, I may be a demanding boss. I'm working in the computer aided quality control business and have some years of experience as developer and project manager. As a project mangaer I'm the one who have to go to the customer to specify the changes and to anylze customer demands. And I'm the one who is repsonsible to make the customer satified.
Maybe thats the reason why I have a different look on those things, because usually the customer beats me when something does not work or is not what they expected.
I'm just glad that nobody has to spend money for it ;)

I think, we just starting with something which is a bit new in the community. To gain acceptance, we have sell ourself a bit especially in the first release. Thats why I said: quality is more important than quantity.


12m

To be honest the simplest event manager is the Firaxis standard one - you just put your things where the events are. What could be easier to understand? The way you've implemented it, while neater, and even simpler, is less easy to understand in the first place.

12m makes some very valid points. If we release a version that people don't understand, then make it simpler in later versions, people won't use the first versions because they don't understand them, and then may not try later versions becasue they thing they won't understand them. We have to remember that alot of people may not have written a line of code before they bought Civ 4, and so while we can hide complicated stuff away where they don't have to worry about it, the actual bits they do have to worry about (event manager, and so forth) should be very simple to understand.

As for the lack of time - it can't be. We need to release something soon, before it becomes too late and people don't use it because it conflicts with another SDK mod. The later we leave it, the less willing individual modders will be to merge their work with ours.

I think, we just starting with something which is a bit new in the community. To gain acceptance, we have sell ourself a bit especially in the first release. Thats why I said: quality is more important than quantity.I have to agree with this. Also:
4) Moddability - make sure that the added modding feature is easy to understand, as well as potentially useful. Too many added features will slow the game, as well as make existing features more complicated to use. These features should have no effect unless activated by a modder.

Relating to the FTP. If you can upload you're working projects along with any working release versions in the folders, then people can easily browse through and comment on your working code, and whenever we decide to do a release we can combine together all the files in the "release" folder, test, and then release it.

To be honest the simplest event manager is the Firaxis standard one - you just put your things where the events are. What could be easier to understand? The way you've implemented it, while neater, and even simpler, is less easy to understand in the first place.

12m makes some very valid points. If we release a version that people don't understand, then make it simpler in later versions, people won't use the first versions because they don't understand them, and then may not try later versions becasue they thing they won't understand them. We have to remember that alot of people may not have written a line of code before they bought Civ 4, and so while we can hide complicated stuff away where they don't have to worry about it, the actual bits they do have to worry about (event manager, and so forth) should be very simple to understand.

As for the lack of time - it can't be. We need to release something soon, before it becomes too late and people don't use it because it conflicts with another SDK mod. The later we leave it, the less willing individual modders will be to merge their work with ours.

I have to agree with this. Also:


Relating to the FTP. If you can upload you're working projects along with any working release versions in the folders, then people can easily browse through and comment on your working code, and whenever we decide to do a release we can combine together all the files in the "release" folder, test, and then release it.

My rationale on the event manager code is "complex in implementation, simple in usage".
Indeed, Mine is much complex than Firaxis or any other custom event managers.
Because it does an acrobatic feat any other event manager didn't and can't, to make it easy and simple for modder to use event manager and multiple mod by the general players.
I don't think that python modder in general who uses this event manager should understand the event manager code. It is not what I intended. It is enough just understand *interface* only.
The interface of this event manager is the simplest form ever invented. Just return one python dict data with event name - handler value pairs. The event manager will do it all automagically for you. Could you ever imagine any simpler way to express them? Much more simpler than even the Firaxis one.
This event manager code should be treated like a blackbox which you should communicated only through interface. The internals of the event manager code is not for faint-of-heart or children or pregnant women. :)

Actually it is too simple to use that no documentation is needed to use the event manager. Then, it accomplishes a feat that no event manager ever did. No need to add or edit event manager code to use it. Not a single line. not a single character. This makes it tremendusly easier to use or merge or manage multiple mod by the player without any modding skill.
So modder don't have to look into it, no need to unserstand it. Say, the manager code can be compiled into binary form ( *.pyc form) or obfuscated beyond recognition and distributed and used without problem.

The interface is simplest form ever invented. Just one python dict data with event name - handler value pairs does it all. Could you ever imagine any simpler way to express them?
I could argue here that I know of quite a few people who mod in python who don't know what a dictionary is.

I understand what you are saying though.

I think most people could manage if an example file was made to trigger at some default events, and do some action. Something like printing a message when you move a unit, or at the start of every turn. This way people could see quickly how it tied into whatever they currently have.

From a brief glance this would work, right? (assuming standard imports)
def EventHandlerRegister( evt_mgr, unused = None ):

return {
'BeginPlayerTurn' : beginGameTurn,
'unitMove' : unitMove
}

def unitMove(argsList):
CyInterface().addImmediateMessage("You have just moved a unit","")

def beginGameTurn(argsList):
CyInterface().addImmediateMessage("You have just begun a turn","")
Hmmm. Might it not be a good idea to have the default set up to return blanks for all the events except the ones the modder defines to be different, just so all the handlers are there for everybody to see?

Hmmm. I have to go know. I might post more random thoughts later.

I could argue here that I know of quite a few people who mod in python who don't know what a dictionary is.

I understand what you are saying though.

I think most people could manage if an example file was made to trigger at some default events, and do some action. Something like printing a message when you move a unit, or at the start of every turn. This way people could see quickly how it tied into whatever they currently have.
.. [snip....]
[code]
Hmmm. Might it not be a good idea to have the default set up to return blanks for all the events except the ones the modder defines to be different, just so all the handlers are there for everybody to see?

Hmmm. I have to go know. I might post more random thoughts later.
Code above is correct except that handlers need same argument just like Firaxis event handlers.
Default action of event that does not have custom handler is not doing nothing.
Event manager calls default Firaxis handler code in original Firaxis "CvEventManager".
Even event *with* custom handler will execute default Firaxis handler unless it explicitly prohibit it by rerturning True as return value of custom handler.
Hmm.. Providing default handler for event with empty handler would be good idea.
Currently { 'event': None } dict will print one error message log and be ignored.
Printing on screen event notification may be better than ignoring it.
Currently, all outstanding *custom* event handlers are printed in "PythonDbg.log" file like this:

Custom event handlers
'UnInit+' =: [<Boost.Python.function object at 0x18488C10>]
'buttonShow' =: [<function onShowButtons at 0x189A3D30>, <function
onShowButton at 0x18719B30>, <function onShowButton at 0x18781C30>]
'UnInit-' =: [<bound method CvSimCutieMainInterface.onUnInit of
<CvSimCutieMainInterface.CvSimCutieMainInterface instance at 0x18997030>>]
'UnInit' =: [<function onUnInit at 0x18647BF0>]
'Init+' =: [<Boost.Python.function object at 0x18488BE0>]
'buttonAction' =: [<function onActionButtons at 0x187811B0>, <function
onButtonAction at 0x1864AAB0>, <function onActionButton at 0x18781830>]
'Init' =: [<function onDLLOptionUpdate at 0x18647C70>]
'optionEnd' =: [<function onDLLOptionUpdate at 0x18647C70>, <bound method
CvSimCutieMainInterface.onCloseOption of
<CvSimCutieMainInterface.CvSimCutieMainInterface instance at 0x18997030>>]
'OnSave-' =: [<function onSaveUtil at 0x18916270>]
'OnLoad+' =: [<Boost.Python.function object at 0x18488C50>, <function
onLoadUtil at 0x18916870>]
'GameStart+' =: [<Boost.Python.function object at 0x18488C90>]
'InitEnd+' =: [<function InitUtilCustom at 0x18916830>]
'optionBegin' =: [<function onDrawOption at 0x18781070>, <function
onDLLOptionDraw at 0x18647C30>, <function onDrawOption at 0x1864AF70>, <function
onDrawOption at 0x187818B0>]

Code above is correct except that handlers need same argument just like Firaxis event handlers.Oh yes, forgot that bit. I was in a hurry. I have corrected it.

About the other stuff - what I meant is that we'd distribute an event handler template so that all the events are listed for easy use. For example this code would be in the file we send out as a template event manager file:

def EventHandlerRegister( evt_mgr, unused = None ):
# Format: { 'eventname 1' : <function to run 1>, ..., 'eventname n' : <function to run n> }
EventHandlerMap = {
'mouseEvent' : None,
'kbdEvent' : None,
'Init' : None,
'Update' : None,
'UnInit' : None,
'OnSave' : None,
'OnPreSave' : None,
'OnLoad' : None,
'GameStart' : None,
'GameEnd' : None,
'plotRevealed' : None,
'BeginGameTurn' : None,
'EndGameTurn' : None,
'BeginPlayerTurn' : None,
'EndPlayerTurn' : None,
'endTurnReady' : None,
'combatResult' : None,
'combatLogCalc' : None,
'combatLogHit' : None,
'improvementBuilt' : None,
'routeBuilt' : None,
'firstContact' : None,
'cityBuilt' : None,
'cityRazed' : None,
'cityAcquired' : None,
'cityLost' : None,
'cultureExpansion' : None,
'cityGrowth' : None,
'cityDoTurn' : None,
'cityBuildingUnit' : None,
'cityBuildingBuilding' : None,
'cityRename' : None,
'unitMove' : None,
'unitSetXY' : None,
'unitCreated' : None,
'unitBuilt' : None,
'unitKilled' : None,
'unitLost' : None,
'unitPromoted' : None,
'unitSelected' : None,
'UnitRename' : None,
'goodyReceived' : None,
'greatPersonBorn' : None,
'buildingBuilt' : None,
'projectBuilt' : None,
'techAcquired' : None,
'techSelected' : None,
'religionFounded' : None,
'religionSpread' : None,
'goldenAge' : None,
'endGoldenAge' : None,
'chat' : None,
'victory' : None,
'changeWar' : None,
'setPlayerAlive' : None,
'windowActivation' : None,
'gameUpdate' : None,
<Insert custom stuff here>
}
return EventHandlerMap

Then the user just puts the function they want to run into the map. If the map returns None then nothing at all happens. This will document all the events possible, as well as any custom events we happen to have. Maybe an example of how to trigger an event from the map would be good.

I suggest this method because it puts all the possible event names in front of the modder's face - they don't have to go around searching for whatever the name of the event they want is - it's right there for them.

Each mod could have a unique version of this template, and all would be good.

OK, my files are uploaded on the FTP server. They are in my user directory, for further checks and comments. They are final and ready for final testing through the team.

12m

I like what you've done to CvGameUtils. Some great additions there. I know for certain I'll use the canConvert function myself. I can see lots of people having fun with the other functions as well.

OK, my files are uploaded on the FTP server. They are in my user directory, for further checks and comments. They are final and ready for final testing through the team.

12m
On style of canXXXX() hooking..
When you hook some existing canXXX predicates (like CvUnit::canMoveInto())
You use two separate Python entrypoint..( eg. "canMoveInto", "canMoveInto2")
It will confuse modder and has two times of overhead of calling python.
Python call is very expensive call (big overhead) so it should be avoided when Python "canMoveInto" is not used.
It can be improved for better way.

See this code.

.................
bool CvUnit::canMoveInto(const CvPlot* pPlot, bool bAttack, bool bDeclareWar, bool bIgnoreLoad) const
{
// ------ BEGIN BY SIMCUTIE (2006-05-16) ---------------------------------
#ifdef SIMCUTIE_UNITEXT
bool bcanMoveIntoResult = canMoveInto_Orig(pPlot, bAttack, bDeclareWar, bIgnoreLoad);

return canMoveInto_Python(pPlot, bAttack, bDeclareWar, bIgnoreLoad, bcanMoveIntoResult);
}

bool CvUnit::canMoveInto_Orig(const CvPlot* pPlot, bool bAttack, bool bDeclareWar, bool bIgnoreLoad) const
#endif // SIMCUTIE_UNITEXT
{
// ------ END BY SIMCUTIE ------------------------------------------------
TeamTypes ePlotTeam;

FAssertMsg(pPlot != NULL, "Plot is not assigned a valid value");

.......................... (original canMoveInto() codes)

extern bool callPythonEntryPoint( LPCSTR szPyFunc, CyArgsList &pyArgs, long &lResult );

// called by CvUnit::canMoveInto() to check if the Unit can move into the plot.
// This calls "CvGameInterface.py/canUnitMoveInto()" Python entry point
// extra invocation argument : bCanMoveInto - boolean result from original canMoveInto()
//
bool CvUnit::canMoveInto_Python( const CvPlot* pPlot, bool bAttack,
bool bDeclareWar, bool bIgnoreLoad, bool bcanMoveIntoResult ) const
{
if ( !cm_hasCanUnitMoveInto )
return bcanMoveIntoResult;
long lResult = bcanMoveIntoResult; // default on call failure.
const CyUnit* pyUnit = new CyUnit(const_cast<CvUnit*>(this));
const CyPlot* pyPlot = new CyPlot(const_cast<CvPlot*>(pPlot));

CyArgsList pyArgs;
pyArgs.add(gDLL->getPythonIFace()->makePythonObject(pyUnit));
pyArgs.add(gDLL->getPythonIFace()->makePythonObject(pyPlot));
pyArgs.add(bAttack);
pyArgs.add(bDeclareWar);
pyArgs.add(bIgnoreLoad);
pyArgs.add(bcanMoveIntoResult);

(void) callPythonEntryPoint( PYFUNC_CANUNITMOVEINTO, pyArgs, lResult );
delete pyUnit; delete pyPlot;
return ( lResult );
}



cm_hasCanUnitMoveInto is class static member(== global) boolean variable.

and in global initalization code

//! \brief Check existence of Python attribute value..
bool hasPythonAttr(LPCSTR module_name, LPCSTR attr_name )
{
FCheckString(module_name); FCheckString(attr_name);
if ( isStrOK(module_name) && isStrOK(attr_name))
{
PyObject *py_mod = PyImport_ImportModule (const_cast<char*>(module_name));
return ( py_mod && PyObject_HasAttrString( py_mod, (char*) attr_name);
}
return false;
}

// Common init for GameStart or OnLoad case.
static void CvExt_GameBegin()
{
FAssertMsgExt( getInitStage() == ESTAGE_READY , "Init stage error" );
setInitStage( ESTAGE_PLAY );
report_stage(true);
// init code here...
CvUnit::cm_hasCanUnitMoveInto = hasPythonAttr(PYMODULE_ENTRYPOINT, PYFUNC_CANUNITMOVEINTO);
report_stage(false);
}


This will remove overhead of calling python entrypoint when no CvGameInterface.py/canUnitMoveInto() is defiend.
And it will reduce two python invocation call into just one call.
Yet, the Python "canUnitMoveInto" entry point can check original canMoveInto result at hand, so modder can decide to honour the result or to ignore the result at modder's will, so you need just one call to Python.

PS. You don't have to edit and pre-define "canUnitMoveInto()" in "CvGameInterface.py"
It can be dynamically added in Run-time to "CvGameInterface.py" by python mod when the mod has need to hook "canMoveInto".

def setPythonEntryPoint( funcName, funcDef):
""" Add Python Entry poin function to CvGameInterface module.
Added function can be called from SDK/"CvExtension.cpp/setPythonEntryPoint() """
import CvGameInterface
assert funcName and isString(funcName) and callable(funcDef)
setattr(CvGameInterface, funcName, funcDef )

...............
def My_canUnitMoveInto(argsList):
pyUnit, pyPlot, bAttack, bDecalreWar, bInoreLoad, bcanMoveIntoResult = argsList[:6]
.........
return my_result;

On OnInit() event:

setPythonEntryPoint( "canUnitMoveInto", My_canUnitMoveInto)

PS2: I used "canUnitMoveInto" instead of "canMoveInfto" because CvSelectionGroup has same canMoveInto().
I recommend change other Entry point names more descriptively. (ex: "canWork" -> "canWorkOnPlot" )
You should not expect general Python modder will read SDK code. So no need to match both name sacrificing readability/undertandability of Python code.

PS3: Some Python entrypoint predicate canXXX like canStartMission()/canTradeWith()/canFound()/canConvert() returns TRUE, FALSE, or -1. -1 for obeying original code result. It is confusing.
Python canXXX() should return always boolean value. not -1.
No other Firaxis canXXX() Python entry point uses such questionable practice.
You can use same scheme described above to make them return only boolean value.

Oh yes, forgot that bit. I was in a hurry. I have corrected it.

About the other stuff - what I meant is that we'd distribute an event handler template so that all the events are listed for easy use. For example this code would be in the file we send out as a template event manager file:

<.............>

Then the user just puts the function they want to run into the map. If the map returns None then nothing at all happens. This will document all the events possible, as well as any custom events we happen to have. Maybe an example of how to trigger an event from the map would be good.

I suggest this method because it puts all the possible event names in front of the modder's face - they don't have to go around searching for whatever the name of the event they want is - it's right there for them.

Each mod could have a unique version of this template, and all would be good.
I guess it is not good way when integrating multiple mod which uses "EventhandlerRegister()" for its own mod.
This is scheme is designed to make mutiple mods working in harmony without stepping on other mod's toe working togather. It should install event handler for only events that the mod has need to handle. Leave alone for event that the mod doesn't care. The list itself is readily available in any modder's and player's installation folder.

OK. I sensed some feeling of reluctance among members here all to accept radical approach of my eventmanager ( using dict data to install handler)

So I added somewhat more conventional way to do same work.
You all may be accustomed to old addhandler() method thing.
So I added similar interface to the my event manager.

Here is example usage:

More conventional way:
def EventHandlerRegister(evt_mgr, unused):
evt_mgr.addEventHandler('Init', onInit)
evt_mgr.addEventHandler('UnInit', onUnInit, evt_mgr.PRIORITY_HIGH)

Radical way:
def EventHandlerRegister(evt_mgr, unused):
return { 'Init' : onInit , 'UnInit+': onUnInit }


Both way works in exactly same way.
Are you satisfied?

On date format:
Some members here uses date format like 23-05-2006 ( day-month-year).
It is questionable convention and discouraged in source code commenting for clarity . Because someone uses 05-23-2006 for same date (month-day-year) even in same western civilization.
date like 05-10-2006 can be interpreted as May 10th or October 5th.
If the year is abbreviated in two digits (frequent practice) it is total chaos.
Can you tell what date it is 07-05-06?
So I recommend to use ISO international standard date format like 2006-05-23. (year-month-day)
Or at least, Use month name like 23-May-2006 or May-23-2006

Ok, first of all, sorry for the harsh words (if so). I really don't want to offend you.

No problem, constructive criticism is the way we are getting better than before. And I always appreciates frank word than sweet lie. Your advice is really good medecine for my code.


Above you said that, I may be a demanding boss. I'm working in the computer aided quality control business and have some years of experience as developer and project manager. As a project mangaer I'm the one who have to go to the customer to specify the changes and to anylze customer demands. And I'm the one who is repsonsible to make the customer satified.
Maybe thats the reason why I have a different look on those things, because usually the customer beats me when something does not work or is not what they expected.
I'm just glad that nobody has to spend money for it ;)
I think, we just starting with something which is a bit new in the community. To gain acceptance, we have sell ourself a bit especially in the first release. Thats why I said: quality is more important than quantity

Oh I understand... Sticking to quality is good point that I should learn from professionals like you. I am just a hobbist in modding. I should have much thing to learn from you.
But our project is not commercial product. So I think that applying or demending strictly same practice and standard of quality like commercail product to our project is too much or just overkill and counter-productive. More over Civ4 is just a game, not mission-critical or life-supporting software of spaceship. ;)
To accomplish such degree of quality of code and documentation, we would hardly make out any notable thing before next expansion come out! and the next expanison is following us, not far from our back.

More conventional way:
def EventHandlerRegister(evt_mgr, unused):
evt_mgr.addEventHandler('Init', onInit)
evt_mgr.addEventHandler('UnInit', onUnInit, evt_mgr.PRIORITY_HIGH)

Radical way:
def EventHandlerRegister(evt_mgr, unused):
return { 'Init' : onInit , 'UnInit+': onUnInit }

Actually I prefer the radical way.

I'm getting slightly confused here. Does this method actively search for mods with events, or do you have to define them in one specific file? The note at the top of CvSimCutieEventManager.py seemed to imply that it would search for any event manager in the mod file, and use these.

It should install event handler for only events that the mod has need to handle. Leave alone for event that the mod doesn't care. The list itself is readily available in any modder's and player's installation folder.
I disagree. While what you are saying is true, that doesn't mean it's the right thing to do. There are many advantages of having all your events and functions listed out - you can see at a glance what all the events available to you are, and what functions each event calls. If there is a none result, then nothing gets handled, and there is no problem. It's clear, easy to understand, and easy to alter. It may be less clever, or neat, but I think it's better.

It would perhaps be even better if they could attach multiple functions in a list inside the dictionary, so that it's even clearer. For example:

def EventHandlerRegister( evt_mgr, unused = None ):
EventHandlerMap = {
...
'EndGameTurn' : handleEndGameTurn,
'BeginPlayerTurn' : (handleBeginPlayerTurn1, handleBeginPlayerTurn 2),
'EndPlayerTurn' : None,
...
}

return EventHandlerMap
This would just be a case of plugging the functions that you want to use on an event into the template. You would never have to change the names of the events, or alter the order, unless you added one yourself. Very easy IMO.

As mentioned above, I think we should make it as clear as we can to the user how to use the mod. This is the clearest method I can think of - it has the names of the events, and the names of the functions so it you can see at a glance what happens when. It has the names of the events you can use, so you add new functions at a glance.

Have updated my above post, emphasising some points. We need to get this cleared up to everybodies satisfaction rather soon I think.


On date format:
Yes, I agree dd/mm/yy and mm/dd/yy are very easy to get confused. I will update the commenting guidelines.

Actually I prefer the radical way.

I'm getting slightly confused here. Does this method actively search for mods with events, or do you have to define them in one specific file? The note at the top of CvSimCutieEventManager.py seemed to imply that it would search for any event manager in the mod file, and use these.

Yes, It actively searches for specific directory like {Custom, MODS/<active-mod-name>/}Assets/Python/Screens and its sub-directories recursively for all python file that has EventHandlerRegister fucntion defined..
Each mod should have its own EventHandlerRegister(). EventManger will call each of the EventHandlerRegister() function in each python files. (It is possible that single mod has multiple EventHandlerRegister in different python files). Each EventHandlerRegister() needs to register only handlers that the specific mod wish to handle.


I disagree. While what you are saying is true, that doesn't mean it's the right thing to do. There are many advantages of having all your events and functions listed out - you can see at a glance what all the events available to you are, and what functions each event calls. If there is a none result, then nothing gets handled, and there is no problem. It's clear, easy to understand, and easy to alter. It may be less clever, or neat, but I think it's better.
...<snip>
As mentioned above, I think we should make it as clear as we can to the user how to use the mod. This is the clearest method I can think of - it has the names of the events, and the names of the functions so it you can see at a glance what happens when. It has the names of the events you can use, so you add new functions at a glance.
It is so if there is only one EventHanderRegister and only one place to add new event handler throughout entire collection of MOD's.
The design of this scheme is exactly opposite.
In old CustomEventManager, there is central pace to add new mod with event handing code. So such centralized list makes sense.
This event manager is just opposite. it has completely de-centralized structure. Every mod that need event handling should have its own EventHandlerregister() in its own mod python file, not in single, big, comprehensive list of mod or event handlers. There is no such central list of all mod or event handlers list in source level. Complete list of event and custom event handlers are available only in run-time and is printed in "PythonDbg.log".
So each EventHandlerMap in specific mod will have only few (2-4) non-empty handlers out of 60+ events in the Map. It is just waste of space.
Most complex mod of mine had only 5 custom event handlers.
Empty entry in the EventHandlerMap serves no purpose at all.

PS) Registering multiple handlers for a same event in single mod is possible and will cause no conflict at all. All handlers are treated equal except for its priority. There is no diffrence between handlers from same mod or from other mod. In fact, there is no way to tell to what mod a specific python file with EventHandlerregister belongs among multiple mod's in action.

Yes, It actively searches for specific directory like {Custom, MODS/<active-mod-name>/}Assets/Python/Screens and its sub-directories recursively for all python file that has EventHandlerRegister fucntion defined..
Each mod should have its own EventHandlerRegister(). EventManger will call each of the EventHandlerRegister() function in each python files. (It is possible that single mod has multiple EventHandlerRegister in different python files). Each EventHandlerRegister() needs to register only handlers that the specific mod wish to handle.
Right I thought so. This is good :)

I'm still slightly concerned about the ease of finding the right string to use to catch each event, though I may be slightly underestimating modder's ability to catch onto these things.

I have a plan - when we finish this build and send it out to some third-party testers we should flag this up as a potential issue. If they understand it then that's great, otherwise we may have to tweak it.

Right I thought so. This is good :)

I'm still slightly concerned about the ease of finding the right string to use to catch each event, though I may be slightly underestimating modder's ability to catch onto these things.

I have a plan - when we finish this build and send it out to some third-party testers we should flag this up as a potential issue. If they understand it then that's great, otherwise we may have to tweak it.
Don't worry. If event manager gets wrong event name or invalis handler, then error log is printed in "PythonDbg.log". And complete list of active custom event handlers are printed in the log file.

On style of canXXXX() hooking..
When you hook some existing canXXX predicates (like CvUnit::canMoveInto())
You use two separate Python entrypoint..( eg. "canMoveInto", "canMoveInto2")
It will confuse modder and has two times of overhead of calling python.
Python call is very expensive call (big overhead) so it should be avoided when Python "canMoveInto" is not used.
It can be improved for better way.
...
...
cm_hasCanUnitMoveInto is class static member(== global) boolean variable.


I really like your idea with this wrapper function. I will review my changes and will rework them regarding this point.

You're using some methods and constants I can't find somewhere else. Where did you take them from? Could it be, that you heavily using code from your own changes?
I have to admit that I understand the concept of your code (will say : what you intend to do), but I don't understand what you'e doing in detail without analysing your changes. It seems to me, that you implemented a very generic approach of those python loopback calls.
I think I'll wait for your final code and rethink your generic approach again then. In between I will use the static calls which requires the functions in the CyGameUtils as it is now.



PS2: I used "canUnitMoveInto" instead of "canMoveInfto" because CvSelectionGroup has same canMoveInto().
I recommend change other Entry point names more descriptively. (ex: "canWork" -> "canWorkOnPlot" )
You should not expect general Python modder will read SDK code. So no need to match both name sacrificing readability/undertandability of Python code.

I had the same doubts at the beginning, but the CySelectionGroup::canMoveInto is just calling the CyUnit::canMoveInto function in loop for all members of the group. This is similar for some other functions. So I choosed the naming conventions of Firaxis and added the source of the call in the comments of the python functions. But I'm still not sure if this is the best solution. Maybe some other opinions to this point?



PS3: Some Python entrypoint predicate canXXX like canStartMission()/canTradeWith()/canFound()/canConvert() returns TRUE, FALSE, or -1. -1 for obeying original code result. It is confusing.
Python canXXX() should return always boolean value. not -1.
No other Firaxis canXXX() Python entry point uses such questionable practice.
You can use same scheme described above to make them return only boolean value.
Yepp! Thats surely a dirty solution. but it was the simplest way to have a tri-state return. But you're right, I can replace it by passing the SDK decision to Python so that the user can return it if he don't wants to change something. This is surly better. Good call!

12m

@SimCutie :
BTW : where is the difference between


const CyUnit* pyUnit = new CyUnit(const_cast<CvUnit*>(this));


and


const CyUnit* pyUnit = new CyUnit((CvUnit*) this);


As I understand there is no difference, but I'mnot sure.

12m

... I am just a hobbist in modding. ....
What do you think we are? Professional modders :D?
TBH : When I look for the code you writing and the concepts you're implementing you should look for a job as professional programmer. And I mean this seriously.

... I should have much thing to learn from you.
Don't overestimate me.

... But our project is not commercial product. So I think that applying or demending strictly same practice and standard of quality like commercail product to our project is too much or just overkill and counter-productive. More over Civ4 is just a game, not mission-critical or life-supporting software of spaceship. ;)
To accomplish such degree of quality of code and documentation, we would hardly make out any notable thing before next expansion come out! and the next expanison is following us, not far from our back.
Yea, thats true. We're not an commercial project and thats good for sure. Otherwise it woudn't make so much fun.
I also don't expect that everything is error free or perfect. I don't even expect that form our programmers at work. But nevertheless this project has targets and one target is that other people should use what we are doing. If they don't use it, we've failed. Thats my only concern.

@SimCutie :
BTW : where is the difference between


const CyUnit* pyUnit = new CyUnit(const_cast<CvUnit*>(this));


and


const CyUnit* pyUnit = new CyUnit((CvUnit*) this);


As I understand there is no difference, but I'mnot sure.

12m
It is just purely of cosmetic difference.
Former one is ANSI C++-98's way of casting const to non-const. quite selectively.
Latter is old C's way of casting anything to another thing.
I used former just to have false feeling of comformance to latest standard of C++ , a kind of fanfaronade or techno-snobism :lol:.
In fact, Old C's way is as good as that of C++.

I really like your idea with this wrapper function. I will review my changes and will rework them regarding this point.

You're using some methods and constants I can't find somewhere else. Where did you take them from? Could it be, that you heavily using code from your own changes?
I have to admit that I understand the concept of your code (will say : what you intend to do), but I don't understand what you'e doing in detail without analysing your changes. It seems to me, that you implemented a very generic approach of those python loopback calls.
I think I'll wait for your final code and rethink your generic approach again then. In between I will use the static calls which requires the functions in the CyGameUtils as it is now.

Yes, I have a library for general use in Civ4 SDK modding. (CvExtension.cpp) Until recently better part of my time was spent on building the library / infrastructures rather than actual modding. I like this approach. With good and stable building blocks, future job will be much easier.
Geneic call is not much thing. It is just couple of funtions. It is used to save typing of C++ code ( I am slow and error-prone typist) and reduce number of code lines inserted between Firaxis code. With less impact on original source code, it will be easier to migrate our code to next Expansion("Warlord") version of SDK. I recomand you not to scatter your changes all over the source codes. I ususally concentrate them in end of existing source file.
The library is quite new and evolving rapidlly so I think that it is not time for other modder to depend on it. You can wait until it is cooked well.

I had the same doubts at the beginning, but the CySelectionGroup::canMoveInto is just calling the CyUnit::canMoveInto function in loop for all members of the group. This is similar for some other functions. So I choosed the naming conventions of Firaxis and added the source of the call in the comments of the python functions. But I'm still not sure if this is the best solution. Maybe some other opinions to this point?

Please comapre your names with other function names in GameIntarface.py. Firaxis function names are generally longer and descruptive. Follow naming conventions used by Firaxis one.
The names are very important because it is part of Python mod API which should not be changed later once it is decided now for backward compatibility with Python mod which depens on it.

Basically, Python modder should be able to figure out what the function does from its name in the GameInterface/GameUtils functions without reading long document or SDK code. This is why the Firaxis functions have somewhat longer and descriptive names. I like name form like <verb>+ <objective> style. ie. canWorkOnPlot() instead of canWork().

Right.

It would seem that we've just about got everything sorted. Does anybody have an objection to seeing if we can get the first version testing tomorrow?

For this we will need people to upload onto the server everything they currently have which is working & complete, and which they want included. I also need a change log from everybody uploading stuff.

A quick reminder - remember that the default config should leave the game the user sees exactly as it was before the user installed the mod, except the new options menu.

I never managed to connect to Spoiled Fruits Server, with the CVS finaly cleared out I thought we would be using that instead. I will upload my Code to the forum here and hope Spoiled can put it in my Folder (I will get in their someday I hope).

']I never managed to connect to Spoiled Fruits Server, with the CVS finaly cleared out I thought we would be using that instead. I will upload my Code to the forum here and hope Spoiled can put it in my Folder (I will get in their someday I hope).Did you try the new IP he posted here (http://forums.civfanatics.com/showpost.php?p=4086348&postcount=23)? The old one went down due to a power failure.

Did you try the new IP he posted here (http://forums.civfanatics.com/showpost.php?p=4086348&postcount=23)? The old one went down due to a power failure.

This new one is down as well, so I'll UL my version here. Its finished so far.

The difference to the first one are :
- date format in the comments is changed to format dd-MMM-yyyy
- implemented some wrappers as SimCutie proposed
- renamed the python functions in game utils to more clear names

Its tested so far and can be implemented as soon as there is something to merge.

12m

Right, anybody else?

EDIT: In other words, if you have finished could you upload your code, otherwise could you post an ETA of when you will be finished?

Sorry but I had to reset the entire local domain here. It works with the new IP now (Also for some weard reason the HD with the FTP data didn't get detected by the right after the power outage. It works fine now).

Here is my version.
Ready to intergrate into project.

Here is my code ready to merge, if any of the documentation is unclear please ask and I can in more detail describe the changes. As most effects require XML to activate and test I will prepare some content files that you can slip in Custom Assets, make shure your using the main assets pack here as your explicitly loaded mod as it contains the nessary Schemas to alow thouse content files to be read.

Okies - I think these are the only three ones we're going to get for this release.

@ SimCutie
Browsing through your changelong I am a bit concerned by the following:


1.4 When Unit name was set by player, the unique(custom) name returned by
CvUnit::getName() will be "Unit Type, custom name"
This is run-time config (UNITNAME_TYPEFIRST) and turned on/off in custom Option Screen.
NOTE: I tried to put it as PlayerOption but PlayerOption is not working properly as of 1.61
It will be changed to PlayerOption if this is fixed in later Civ4 version.
Old : "My best defender (Archer)"
New : "Archer, My best defender"
Behavior on unit without unique / custom name is not changed.

1.6 Added Great People Type and Civs name in Great People born announcement.
Old: "Albert Einstein has born in Frankfurt"
New: "Albert Einstein (Great Scientist) has born in Frankfurt, Germany"

1.7 Added Unit Type name in press-AltKey Combat Odd display
Old: "4.3 vs. 6.1"
New: "4.3 (Axeman) vs. 6.1 (LongbowMan)"
Firstly, 1.4 isn't a problem, except from what I can tell it is enabled by default. Which it should not be.

1.6 and 1.7 should also be configurable, and disabled by default. Maybe make one flag - something like "Enhanced text info", and have it trigger all three?

Also - what does CvUnit Script data / experience is preserved across unit upgrade/ unit gift. mean? On the same entry - I think it may have been originally intended for foritifcation to be broken when updrading. I'm not sure we should change this.

We have to be careful not to change the game in any way the user might not like without the user's permission.

Okies - I think these are the only three ones we're going to get for this release.
.............
EDIT: Am also updating the changelog. Will change this bit when I'm done.
OK. All will be done soon. And You are right, not experice, but fortification.. it is documentation error. Experience is preserved even in original version.

Actually, by defailt experience is reduced to a maximum of 10 experience points when you upgrade. This is what I thought you may have changed.

Have finished updating the changelog, and have to go now. I've highlighted some bits in bold. I didn't have time to work out how to summerise the logging routines that you've added SimCutie, so I've left a placeholder there.

Could everybody please check I've got all the changes you've made in there.

']Here is my code ready to merge, if any of the documentation is unclear please ask and I can in more detail describe the changes. As most effects require XML to activate and test I will prepare some content files that you can slip in Custom Assets, make shure your using the main assets pack here as your explicitly loaded mod as it contains the nessary Schemas to alow thouse content files to be read.
@'Impaler:
Have you checkcked compatibility with old savefile?
If you change NUM_PLAYER_OPTION_TYPES, It may or may not read old original save file. Please check out it. And it will make compatibility problem in future with more player options unless this is attacked and handled explicitely.

As far as I am aware we're waiting on SC's little update so that the interface changes are configurable, and Impaler to look at NUM_PLAYER_OPTION_TYPES right?

This is updated files as TGA said. (Chnaged file only)

I put it under NUM_GAME_OPTIONS not PLAYER_OPTIONS. I dont see why we would be conserned about NUM_GAME_OPTIONS when I already made a bunch of other changes that break savegame compatability (new data members in CvCity and CvPlayer). I though we had desided it was ok to do this? Though the user cant currently use the custom game options screen to set the mod they can use the XML file to set it or they can use a python call at startup. It seems like the best place to put the controls as its incorporated in the game perminently, eventualy we can get that UI problem corrected and then it will be perfect.

']I put it under NUM_GAME_OPTIONS not PLAYER_OPTIONS. I dont see why we would be conserned about NUM_GAME_OPTIONS when I already made a bunch of other changes that break savegame compatability (new data members in CvCity and CvPlayer). I though we had desided it was ok to do this? Though the user cant currently use the custom game options screen to set the mod they can use the XML file to set it or they can use a python call at startup. It seems like the best place to put the controls as its incorporated in the game perminently, eventualy we can get that UI problem corrected and then it will be perfect.
In that it may have backward compatiblility hazard, NUM_GAME_OPTIONS or PLAYER_OPTIONS are not much diffrent. Adding new data members in CvCity and CvPlayer is OK. Game saved in new format is sure to break the compatibility. it is inevitable.
But it should be able to *read* original old save file. This is backward compatibility I am talking about. But your current implementaion breaks this compatibility.
You should check the save file version and if it is save file of original unmodded game, skip reading additional variables from file and fill the new variables with default (reasonable) values.

Given that this bit doesn't do anything anyway (right?) it wouldn't do any harm to remove it.

Does somebody want to do the final merge and compile? If you are going to do it post here so nobody else does it at the same time.

Oh - and SimCutie; could you please right a brief explaination about that logging function for me?

Already started merging them. I'll post the finished dll on my FTP server when Its done.

Great - ta!

can't wait to get my hands on it!

In that it may have backward compatiblility hazard, NUM_GAME_OPTIONS or PLAYER_OPTIONS are not much diffrent. Adding new data members in CvCity and CvPlayer is OK. Game saved in new format is sure to break the compatibility. it is inevitable.
But it should be able to *read* original old save file. This is backward compatibility I am talking about. But your current implementaion breaks this compatibility.
You should check the save file version and if it is save file of original unmodded game, skip reading additional variables from file and fill the new variables with default (reasonable) values.

Again I though we had desided this type of backward save game compatability was not nessary. End users routinly start new games when a new mods are released its not an issue for them. To impelement what your sugjesting every single read/write would need to have an if statment checking for the savegames DLL version and I dont know of any check we can make which will tell us that.

Given that this bit doesn't do anything anyway (right?) it wouldn't do any harm to remove it.

It is fully functional and can be activated by setting the Default flag to true under the Gameinfos.xml Any game the player starts with that tag set will contain the changed behavior perminently even if they subsequently change the tag, close and reload the program and reload the game (just like other game options). Theirs no reason to leave out a good working feature just to try to save backward compatability.

SpoiledFruit: I have some last minute bug fixes to include, also I put Chalids Slow Cultural Border Expantion in as another option and am working on merging in RogerBacons changes to City Work Radius, Cultural Borders on Ocean and the Flying Mod. The Work radius I am changing slightly to make in an Option rather then a hardcoded part of DLL. I can merge all these in if you put the source up at a place I can access it (I still can not access your server at the old or the new IP). I can also just post the altered files here for you to use if you like.

']
It is fully functional and can be activated by setting the Default flag to true under the Gameinfos.xml Any game the player starts with that tag set will contain the changed behavior perminently even if they subsequently change the tag, close and reload the program and reload the game (just like other game options). Theirs no reason to leave out a good working feature just to try to save backward compatability.
Okies - I see what you mean. I thought it was just redundant.

The end result of the backward compatabilty discussion seemed to be that we should have most releases not breaking backward compatablilty, but there should be an amount that did.

When are we going to get this release?

When are we going to get this release?
Already started merging them. I'll post the finished dll on my FTP server when Its done.
When it's done ;)

Should be ready somtime today or tommorow

Well, I'll do as much work/moding as I can now, so I'll be able to play this later. I'm really looking forward to having all of my GPP pooled together.

']Again I though we had desided this type of backward save game compatability was not nessary. End users routinly start new games when a new mods are released its not an issue for them. To impelement what your sugjesting every single read/write would need to have an if statment checking for the savegames DLL version and I dont know of any check we can make which will tell us that.


It is fully functional and can be activated by setting the Default flag to true under the Gameinfos.xml Any game the player starts with that tag set will contain the changed behavior perminently even if they subsequently change the tag, close and reload the program and reload the game (just like other game options). Theirs no reason to leave out a good working feature just to try to save backward compatability.

SpoiledFruit: I have some last minute bug fixes to include, also I put Chalids Slow Cultural Border Expantion in as another option and am working on merging in RogerBacons changes to City Work Radius, Cultural Borders on Ocean and the Flying Mod. The Work radius I am changing slightly to make in an Option rather then a hardcoded part of DLL. I can merge all these in if you put the source up at a place I can access it (I still can not access your server at the old or the new IP). I can also just post the altered files here for you to use if you like.

I don't think so. When Piraxis issues new patch they maintains backward read compatibility with old savefile. Acutally they do check the savefile version everytime they read save file. They do great care to maintain read compatibility with old save file. Why can't we?
I am not argueing that the features should be removed or left out. It is OK to add new varibale or the features. But it should also be implemented in the way as it can read old save file.
Having new feature AND being able to read old save file too, is techincally feasible and strongly desirble.
I object to releasing any new version that will crashes on old original save file.
It will ruin credibility of our project.
At least, it should be able to read old original savefile when the feature is not selected by run-time cobnfigure or the new XML tags are not used.

True, however seeing as the CCP will often be bundled with a new version of a mod, the mod is likely to break backward compatabilty as well.

Sometimes it won't be, and that is why I suggest we try to make as many releases as possible be backward compatable, but if we're not careful the whole code becomes a bundle of different version checks.

I don't think so. When Piraxis issues new patch they maintains backward read compatibility with old savefile. Acutally they do check the savefile version everytime they read save file. Why can't we?
I am not argueing that the features should be removed or left out. It is OK to add new varibale or the features. But it should also be implemented in the way as it can read old save file.
Having new feature AND being able to read old save file too, is techincally feasible and desirble.
I strongly object to releasing any new version that will crashes on old original save file.
It will ruin credibility of our project.

I agree. We shoud be able to read old save games without crashing the game. I'm sure there are people who want to load their current game and to proceeed with the new features.
Also, a lot of modders (me as well) have created their test scenarios to check certains aspects of the game with their mods. It will raise acceptance if they still can use them with our DLL/API.
After the game is save once, we may loose compatiblity, as long as we communicate it. Everybody who has a problem with this, can make a backup of the savegames.


12m

Read my post at the bottom of this thread for my arguments against backward compatability. If people had made their feelings know back then we could have possibly developed this feature but its definatly too late for the first release unless someone wants to A- drop nearly all the content I made or B- has the code for this ready right now.

http://forums.civfanatics.com/showthread.php?t=170670

Well A isn't really an option.

Could B be implemented on the files after SF has merged them, and then recompiled?

Well A isn't really an option.

Could B be implemented on the files after SF has merged them, and then recompiled?
OK. In versionI posted, it DO has backward compatibility facility.
In CvExtension module, ExtLoadAction has value indicating current save file version, which is one of four possible values.
EXTLOAD_NONE - original firaxis save,
EXTLOAD_OK - current modded savefile,
EXTLOAD_OLD - modded davedfile of previous version.
EXTLOAD_ERROR - error, should generate FAssert failure.
Check this value and do appropiate action when reading save file.
If ExtLoadAction is EXTLOAD_NONE, read only original firaxis data, nothing more.
Include file for this is "CvExtGlobal.h"
See CvExtension.cpp/CvExt_read() and PlayerOptionReadAdjust() (Commented out)
potion on how to use it right.

I will be out of town for remainder of the week and then busy till atleast Wednsday, Fruit has not yet (to my knowlage) finished merging so I figured I would do as much as I could and provide it too yall to use when I am away.

I have created a new branch on the CVS "impaler" (sugjest other folks start making their own branches as well). And have uploaded by most resent materials (more up to date and debugged then my forum upload). I merged 12Monkeys content with my own and it compiles/runs fine, a few small popular mods off the forum were included as well, see the Mod list for information. I could not get SimCuties changes to compile, I get an "int should be proceeded by ';' " and "unexpected end of file marker" in C:\Program Files\Microsoft Visual C++ Toolkit 2003\include\excpt.h both line 36. I checked this file and it looks fine. It seems he did something with the CodeBlocks project as that file has incressed substantialy in size, could it have anything to do with the new header files?

Okies.

SC - have you any idea about the compiler errors?
SF - any ETA on completed merging?

Should be done today, was a bit busier at work than expected yesterday.

Good to hear.

SimCutie - can you suggest something to fix those compiler errors, just in case SpoiledFruit runs in to them as well?

Merging complete but I'm having trouble compiling. Impaler, I am getting your GAMEOPTION_GREAT_PEOPLE_POINT_POOLING as undefined. Where was this definition added? If you forgot, do you want me to add it?

Also, SimCutie, I see a lot of ifdef statements with your code, I don't know if it will work with them or do you want me to comment them out?

Also some of yours and 12Monkey's code clashed and seeing no clear definition on your code or how it interacts between the two functions I commented it out so both of you need to take a look at that, especially in the CvUnit.cpp and CvUnit.h files. The big one was the canMoveInto_Python function. That was a big conflict (that I can see after looking at it only 5 minutes).

-------------------------------------------------

Update:

OK, I was able to compile a dll without any compiler or linker errors. I loaded to the main screen jsut fine, however, when I try to start a new game the game crashes. You 3 really will need to take a look at that commented out code. (all of Impalers additions in the CvCity.cpp and Sim and 12Monkeys in the CvUnit files)

I am uploading it onto my FTP server and it is now on sourceforge as well.

One of the troubles may be that some people have conducted partial merges by themselves. Impaler's changes uploaded to Sourceforge also include changes by 12monkeys, I think - and he also mentioned that the ones on SF had no bugs.

I think where 12M and SimCutie's changes bump into each other you should use SimCutie's code instead, but put it in the same place as 12M has put his - I think what he did in his set of updated files is take 12M's changes, and add a few things to make them run better.

I would try merging SimCutie's changes with the changes on SourceForge submitted by Impaler, given they seem to be the latest versions.

I also can't see your upload on SourceForge, and I'm having trouble connecting to the FTP server again... but that's another issue.




A more general comment now.

Could we please try to keep our coding looking like Firaxis code, rather than coding in our own styles? I have noticed, for example, that SimCutie tends to put the includes just before they are used, rather than at the top of the file with the rest of them. Firaxis has put them at the top, so we should too. It just makes life alot easier. We have to remember that these files may go through lots of revisions, and there is no reason to leave them any messier than we found them.

There's also the whole commenting style thing, which I hate to drag out again, but I'm going to anyway. Of the three people who have submitted changes, only one is using the commenting style set out in the guidelines. While this may be fine now, where everything is still quite simple, things are going to get more problematic, we are going to get overlapping comments, and to save confusion we should all use the same commenting style.

Also, while there are only 3 or 4 people actively changing the code at the moment, there may be many more at a later date.

I say that we should sticky a thread with the commenting style. This is what I use, but will change if it is not good:

...
//Lord Olleus / [Mod Name] / 3rd June 06
...
...
//Lord Olleus / End

The mod contributions guide thread already has this. I think that mabey TGA might want to rename that thread.

TGA you should be able to connect to the FTP server now, I forgot to update my port forwarding on the gateway, sorry.

I just saw this line in Civ4.ini



; Game Options
GameOptions = 0000000000000000



Could this have anything to do with the new game options not working?

Also, SimCutie, I see a lot of ifdef statements with your code, I don't know if it will work with them or do you want me to comment them out?
.......
OK, I was able to compile a dll without any compiler or linker errors. I loaded to the main screen jsut fine, however, when I try to start a new game the game crashes. You 3 really will need to take a look at that commented out code. (all of Impalers additions in the CvCity.cpp and Sim and 12Monkeys in the CvUnit files)

This is why I put #ifdef SIMCUTIE_XXX thing. Just undefine all SIMCUTIE_XXX in CvExtGlobal.h, then all my codes become commented out by #ifdef and it will work same as oriiginal code. So you can test the crash is caused by my code or not. Or you can disable my code selectively, feature by feature.

I recommend that all developer should provide modder means to selectively disable specific features: For example, 12Monkey's Python hook incurs quite big overhead in runtime even if modder/player does not use the feature. So other SDK modder should be able to completely disable this feature with no or minimal overhead.
I expected he will modify his code to use #define or at leat run-time configure switch to remove the overhead, but he didn't do it so far.

I think that we should NOT try to our code looks like Firaxis's.
We are not maintaining Firaxis's code. We are patching on it. Our source code it self will never make into Firaxis's code archive. So our code shouled be distinctive from Friraxis and we should always be prepared to move our code to SDK sorce of next expansion.
That is why I put horizontal ruler (-------) to distinguish my potion and original potion. I use #ifdef to minimize impact on original source code.
I put #include where before code that uses it in same reason.
I generally put my code to end of source file and put #include in start of my potions. It is better than scattering our changes all over the source code.

On Impaler's comment style:
He comment outs original line with precedding // in same line with original code line.
It is not so visually distinctive to code reader. Please make it more visually distinctive for easier identification.
It does not looks good when I compare his code with orihginal source with diff tool like WinMege or Windiff. Such diff tools does not understands C++ syntax and confused by line preceeded by //. Please leave original line as it was, line by line. You may put /* */ comment line before and after original code or use #ifdef.

I just saw this line in Civ4.ini



; Game Options
GameOptions = 0000000000000000



Could this have anything to do with the new game options not working?
This is overwritten each time we start/exit Civ4.exe, So if we adjust NUM_GAME_OPTION_TYPES, it should also extend and contract (padded with zero), if it was done right.

@SpoiledFruit - are you having another attempt at merging the files together given what I suggested, or do you want it cleaned up first?

@SimCutie - I quite like Firaxis' style as it allows other users to dive in and quickly and easily see what is going on. It is designed how it is for a reason, be it so that the Firaxis coders could see what was going on, or so that people who downloaded the SDK could see what was going on. Either way, it is what, in their opinion, is clear to read.

@Everybody - Any other opinions on this? It's definatly not to late to change over to a more distinctive style like SimCutie suggests, and he certainly makes some good points. Good that we have these discussions earlier rather than later. We really need to all be doing the same thing.

I don't seem to be able to recompile it. I coppied the standard project, removed all of the .cpp and .h files, added all of your files, made them part of the project and then tried to compile. This is what my log said:

Switching to target: Final Release
Civ4ccp_Tools.cpp
CvArea.cpp
CvArtFileMgr.cpp
CvCity.cpp
CvCityAI.cpp
CvDLLButtonPopup.cpp
CvDLLEntity.cpp
CvDLLPython.cpp
CvDLLWidgetData.cpp
CvDeal.cpp
CvDiploParameters.cpp
CvExtension.cpp
C:\Program Files\Microsoft Visual C++ Toolkit 2003\include\excpt.h(36) : error C2144: syntax error : 'int' should be preceded by ';'
C:\Program Files\Microsoft Visual C++ Toolkit 2003\include\excpt.h(36) : fatal error C1004: unexpected end of file found
Process terminated with status 1 (0 minutes, 58 seconds)

I am going to try and remerg the files tonight, hopefully it works. I placed a link to the files in the CCP Download thread. They should also be available in the Files tab of our project site on SourceForge.

I am going to try and get the debug code I see within the source working again so we can see what is going wrong and where. This should help for future debugging.

I like the way Firaxis wrote there code because it is the correct way to write code as well as it is readable. We should keep there coding style because it will allow people to understand better what is going on and the interaction between the new and old code.

I think that you can put in the new python calls inside the original functions just at the end before the return without needing to add 2 new functions (this is part of where the problem is).

I asked someone who does a lot of C++ what they thought and was wrong and they told me that it is probably a problem with a macro which is defined for you not for anyone else.

I have no idea what that means.

I believe it has something to do with SimCutie's ifdef statements.

any sucsess?

working on it, but going through 10,000 lines of code doesn't happen very fast.

I downloaded alpha version from sourceforge. 1-61-0001aSC.zip
and compiled it.
Thing to fix:
the ZIP file is missing two files: FVariableSystem.inl, CvGameCoreDLL.vcproj
So I added it and compile in Release configuration.
It compiled without problem. Run it. Selected Single Player/Play Now! (newgame). It showed Dawn of Man screen. But it freeze or in endless loop I can hear music/narration of Dawn of Man. But the screen freezed at 1/5 of(" Initilizing...) progress bar.
When loading old saved game, It immedately exited to desktop without any warning or messsage.

Part of "PythonDebug.log"


load_module Oasis

load_module Ring

load_module Shuffle

load_module Team_Battleground

load_module Terra

load_module Tilted_Axis

load_module Wheel

PY:Player 0's alive status set to: 1
PY:Player 1's alive status set to: 1
PY:Player 2's alive status set to: 1
PY:Player 18's alive status set to: 1
shifting hints by

0

0

load_module CvGameInterface

player

0

pass

0

failed

player

0

pass

1

failed

player

0

pass

2

failed

player

0

pass
..............

This "player /failed / pass" thing loops infinitely.

What I think we are going to have to do is have each new mod added one at a time untill we find out which one is faulty. Unfortunately this could take a while. This is why we really need to have the CSV in use right away so code can be added and tested as it is created and not 2000 lines at once.

My guess on this matter:
- This code that prints this infinite loop is neither in our code, nor SDK code.
It is in Civ4.exe, I guess. This is caused by "load_module CvGameInterface" or some code that requires "CvGameInterface".
Which comes much earlier than normal timing of appearance of this message in "PythonDebug.log"

Normal loading time should be like this.:

PY:Player 1's alive status set to: 1
PY:Player 2's alive status set to: 1
PY:Player 18's alive status set to: 1
shifting hints by

0

0

99 SCREEN TURNED ON

SCREEN OFF

load_module encodings.latin_1

8500 - gold

8501 - research
.............
8538 - taoism

3 SCREEN TURNED ON

load_module CvGameInterface

99 SCREEN TURNED ON

PyCivSim: Init Done.
load_module CvWBInterface

load_module CvWBDesc
....


PS) I build SDK with my code removed from source. ( by effectively undefine all SIMCUTIE_XXX ).
But the sympthom seems just as same as before with my code compiled in.
But there is a possiblity that I may have forget to enclose my code with #ifdef ( I found one or two while reviewing in new SF's merged code ), and that part may cause the fault.

Here I attached source with all my code disabled. (Only updated part)

@Everybody - Any other opinions on this [commenting style]? It's definatly not to late to change over to a more distinctive style like SimCutie suggests, and he certainly makes some good points. Good that we have these discussions earlier rather than later. We really need to all be doing the same thing.Any more thoughts?

Any more thoughts?


I think we should do it the Firaxis way, because its the way the poeple know and which they expect. If they look for an include then they will look at the top of the file and not somewhere else. Also the additional work we had with this style when merging our changes into another update, can be ignored compared to the overall work.

Also, I think its much more important to prevent #ifdefs to only where it is absolutly necessary, because there is a big disadvantage. If the #ifdef section of a certain mod, starts to overlap with the #ifdef of another mod, its getting extremly complitcated to make the code work for both comibnations. The resulting code may be hard to read and hard to test.

12m

I'm a bit confused where I can find what version.

The version on SourceForge does not seem to contain any changes (at least not mine). Also the changed Python Files are missing. But some version numbers are changed to 1.3?

The CvGameCoreDLL_v161 Version on the FTP Server can not be downloaded (for whatever reason)

What is the actual version, what should I DL for testing? Anything I missed?

12m

I think we should do it the Firaxis way, because its the way the poeple know and which they expect. If they look for an include then they will look at the top of the file and not somewhere else. Also the additional work we had with this style when merging our changes into another update, can be ignored compared to the overall work.

Also, I think its much more important to prevent #ifdefs to only where it is absolutly necessary, because there is a big disadvantage. If the #ifdef section of a certain mod, starts to overlap with the #ifdef of another mod, its getting extremly complitcated to make the code work for both comibnations. The resulting code may be hard to read and hard to test.

12m
OK. I will change #inclide position to Top of the file as Firaxis's way.
Instead, I suggest use of # ifdef for all our code be adpoted as general guide line.
Resolving overlapping #ifdef is exactly the work we should have to do.
The #ifdef section is not random peice of code. It is logical unit of change for a feature. So if same potion of code should be changed diffrently by combination of feature, it should be logically resolved depending on combination of feature. Not using #ifdef is hiding problem under carpet, not solving it. That is not right thing to do.
Current problem of merged version (by SF) is also same problem. Each piece of code worked without problem before merging. But when they are combined, it caused problem. So it is our task to solve it logically. This is what "integration" is for. if all code used #ifdef for each individual feature, the integration test will be much eaiser, not harder.
Most major open-source software developed by multiple developer adopts such convention (i.e. compile time feature selection by #ifdef adopted by apache web server)
Some uses automatic compile timme configuration generation with autoconf.
Why shouldn't we?
I'm a bit confused where I can find what version.

The version on SourceForge does not seem to contain any changes (at least not mine). Also the changed Python Files are missing. But some version numbers are changed to 1.3?

The CvGameCoreDLL_v161 Version on the FTP Server can not be downloaded (for whatever reason)

What is the actual version, what should I DL for testing? Anything I missed?

12m
See post of mine ( http://forums.civfanatics.com/showpost.php?p=4121760&postcount=29). Use "dev" branch to get latest version in CVS.

Any more thoughts?
As minimum, original line should be remained intact line by line. Commenting out original line by preceeding // will hinder comparison of source file with diff tools.
And please, don't use comment at end of line to notify start of change.
It is visually hard to find.

Bad example:
...
// Original a = 1;
a = 2; // start of change for foo.
....
Good example:
....
/* Original
a = 1;
*/
// start of change for foo
a = 2;


On commnet style on individual function.
How about to use Firaxis function commneting style, then.

From original Firaxis function. CvUnit.cpp

//------------------------------------------------------------------------------------------------
// FUNCTION: CvUnit::computeWaveSize
//! \brief Computes the wave size for the round.
//! \param bRangedRound true if the round is a ranged round
//! \param iAttackerMax The maximum number of attackers that can participate in a wave (alive)
//! \param iDefenderMax The maximum number of Defenders that can participate in a wave (alive)
//! \retval The desired wave size for the given parameters
//------------------------------------------------------------------------------------------------
int CvUnit::computeWaveSize( bool bRangedRound, int iAttackerMax, int iDefenderMax ) const
{

I'm back from my trip though I will be working for a few days before I can get some major code crunching time.

Lord Olleus is getting the same compile error I was having (so its not realy a corrupted file or anything like that). We need to solve this problem not simply so Spoiled Fruit can do a merger, rather we need to make sure the code remains compilable for EVERYONE. It seems the source of this error is in SimCuties code as I dont experience it when compiling myown code or 12monkeys. I am afraid I can't be of much help in debugging it.

GREAT_POPLE_POINT_POOLING should apear on the Enum.h right above NUM_GAME_OPTIONS, I must have removed it misspelled it someware as I did a few other Enums for commerce that you dont seem to have any trouble with these. It can easily be added in, if you dont mind.

On comenting styles, generaly when I change a function and the change involves a simple if statment changing the return value I use.

funtion()
{
//Start Change Mod Name Impaler[WrG]
if (myModisEnabled)
{
return newreturn
}
else
{
//Original Behavior
return original return
}
//End Change
}

I like the way that WinMerge will see this as two seperate blocks of change wrapped around the original code, its shows quite literaly that the original has been wrapped and not itself altered. When I do a single line change I do it like such

//Start Change Mod Name Impaler[WrG]
//ORIGINAL CODE original-line-of-code
my-new-line-of-code
//End Change

I cant see how any diff tool or person would fail to see that as a change.

I think we should try to stick with Firxais style, I have been trying to replicate their style both in the mechanicaly and stylisticly (ofcorse it helps that 90% of my changes are pastes from some other portions of the SDK). I see no real reason to go out of our way to keep changes spacialy confined, I do obvious stuff like putting two function that refference each other right next to each other but nothing besides that, you have to jump all over to understand Firaxis code anyway.

As I've said before I am against Ifdef, I see no value for the end users. The whole point of this project is that the end user is NOT competed at C++ and can not even understand let alone compile the code. The only arguable advatage for us is in debugging which I also find to be slim. Ifdef presents more wrinkles into the equation, makes the code harder to read and in my opionion is a way to excuse sloppy codeing, if its not working dont use it, if its is working it dosn't need an ifdef.

']I'm back from my trip though I will be working for a few days before I can get some major code crunching time.

Lord Olleus is getting the same compile error I was having (so its not realy a corrupted file or anything like that). We need to solve this problem not simply so Spoiled Fruit can do a merger, rather we need to make sure the code remains compilable for EVERYONE. It seems the source of this error is in SimCuties code as I dont experience it when compiling myown code or 12monkeys. I am afraid I can't be of much help in debugging it.

Resolved in latest update. See code attached above.
']

On comenting styles, generaly when I change a function and the change involves a simple if statment changing the return value I use.

funtion()
{
//Start Change Mod Name Impaler[WrG]
if (myModisEnabled)
{
return newreturn
}
else
{
//Original Behavior
return original return
}
//End Change
}

I like the way that WinMerge will see this as two seperate blocks of change wrapped around the original code, its shows quite literaly that the original has been wrapped and not itself altered.

It is OK. Source line remain intact. "Start" mark in separate line. But Your actual code did not seems to follow your own rule.
There are many occasion like this:

//Addition LocalSpecialistYieldChanges by Impaler[WrG] 5/16/06
int iI;
if (m_ppaaiLocalSpecialistExtraYield != NULL)
{
for (iI = 0; iI < GC.getNumSpecialistInfos(); iI++)
{
SAFE_DELETE_ARRAY(m_ppaaiLocalSpecialistExtraYield[iI]);
}
SAFE_DELETE_ARRAY(m_ppaaiLocalSpecialistExtraYield );
}
//End

It has no "if (myModisEnabled)" part as I see.
If you didn't use #ifdef, you should use "if (myModisEnabled)" at least.
Use if (myModisEnabled)" on every code change occasion.

And look at this...

void CyCity::changeExtraSpecialistYieldOfType(int /*YieldTypes*/ eIndex, int /*SpecialistTypes*/ eSpecialist, int iChange) //Addition SpecialistTechCommerceChange by Impaler[WrG]


']
When I do a single line change I do it like such

//Start Change Mod Name Impaler[WrG]
//ORIGINAL CODE original-line-of-code
my-new-line-of-code
//End Change

I cant see how any diff tool or person would fail to see that as a change.


As I said, be consistent. Use "if (myModisEnabled)" and use same style with multiline change. There is no reason to treat tem specially.
']
I think we should try to stick with Firxais style, I have been trying to replicate their style both in the mechanicaly and stylisticly (ofcorse it helps that 90% of my changes are pastes from some other portions of the SDK). I see no real reason to go out of our way to keep changes spacialy confined, I do obvious stuff like putting two function that refference each other right next to each other but nothing besides that, you have to jump all over to understand Firaxis code anyway.

Because it will help to our code separate form Firaxis. It will also help other modder to distinguish original behavior and changed behavior. We should minimize impact on original source code as we can.
']
As I've said before I am against Ifdef, I see no value for the end users. The whole point of this project is that the end user is NOT competed at C++ and can not even understand let alone compile the code. The only arguable advatage for us is in debugging which I also find to be slim. Ifdef presents more wrinkles into the equation, makes the code harder to read and in my opionion is a way to excuse sloppy codeing, if its not working dont use it, if its is working it dosn't need an ifdef.
SDK code itself is of no value to end user from the start. It is for modder who uses this SDK code. Our target audiance is Python/SDK modder, not end player. Isn't it?
Feature selection will give these moder freedom to choose. It is our mis-conception that other moder will welcome and use all the features we had put in to this project. Let them choose feature whatever they want. It is our obligation to provide them means to do so if they choose to. We should not force-feed our features to all the modder.
This is what all the #ifdef is for.

The 2 expamples you site are both Additions not changes. I destinquish a change as something that radicaly changes the return value of a function or cause the function to not perform one of its previous tasks. An Addition dose neither of these things, rather it just adds another things for a funtion to do or adds another value for it to add to a large sum.

Both are taged as such. The First is a critical Array initialization within the Info initializer for an XML controled feature, it would neadlessly complicate things as well as introduce all kind of crash potential to have some kind of if statment or ifdef for a feature that is controled by XML tags in the Units, Tech or Buildings .xml The end user should get a feature which functions as much like a Firaxian function as possible so their is no conditional or game option that turn it off.

The second example is a whole function created from scratch, our comenting style holds that a tag on the first line of a function designates it as a new functions.

On end users: the Python Moders generaly dont know C++ and should not have to dive into it, thats not what they want. They just want nice usable hooks to hang stuff off of, they dont want to worry if the DLL they have is going to work or not because the feature was ifdef'ed out. We are not force feeding anything to anyone, everything is explicity activated by the end user (atleast in my code), I feel XML is the best most easily accessable newb friendly method of control, python is next best and ifdef the LEAST friendly and least practical as we would need to have seperate compiled binaries for every feature activation, it would be a compatability nightmare and pointless extra work for thouse able to compile the code.

']The 2 expamples you site are both Additions not changes. I destinquish a change as something that radicaly changes the return value of a function or cause the function to not perform one of its previous tasks. An Addition dose neither of these things, rather it just adds another things for a funtion to do or adds another value for it to add to a large sum.

It is YOUR criteria others are not aware of. The addition also incurs some overhead at least in code space and speed. Use consistent style, not ad-hoc style of convenience. It should be minimized. If the feature is not used, it adds dead weight on final DLL. It should be clearly identifiable from source and have minimal overehead.
']
Both are taged as such. The First is a critical Array initialization within the Info initializer for an XML controled feature, it would neadlessly complicate things as well as introduce all kind of crash potential to have some kind of if statment or ifdef for a feature that is controled by XML tags in the Units, Tech or Buildings .xml The end user should get a feature which functions as much like a Firaxian function as possible so their is no conditional or game option that turn it off.

You can have both XML enabled and feature selection/runtim-config enabled at same time. Having them XML enabled is not excuse for let the dead code left in active state. what is worse, it there is no single point of control the feature. You should edit whole XML to remove every instance of the XML attribute to disable the feature. It is much less flexible.
We should have single point of control to enable/disable specific feature.
']
The second example is a whole function created from scratch, our comenting style holds that a tag on the first line of a function designates it as a new functions.

On end users: the Python Moders generaly dont know C++ and should not have to dive into it, thats not what they want. They just want nice usable hooks to hang stuff off of, they dont want to worry if the DLL they have is going to work or not because the feature was ifdef'ed out. We are not force feeding anything to anyone, everything is explicity activated by the end user, I feel XML is the best most easily accessable newb friendly method of control, python is next best and ifdef the LEAST friendly and least practical as we would need to have seperate compiled binaries for every feature activation, it would be a compatability nightmare and pointless extra work for thouse able to compile the code.
It is your misconception that other modder don't have ability to code in C++. There are zillions of C++ coder out there. Much more than Python coder ( at least by 10 times as many as C++ coder than Python coder). Do you really belive that there are more Python-only coder than C++ only coder?
This is why I call your assumption as misconception.
They are not XML-only newbie. They are modder who is capable of programming of some kind. Dont underestimate modder here. I found that they are much more capable than myeself, guessing from their python proficency.
We should provide them with "hook" to do what these capable modder can do what they want.
Don't cripple these capable modder for XML-only newbies.

On commnet style on individual function.
How about to use Firaxis function commneting style, then.

From original Firaxis function. CvUnit.cpp

//------------------------------------------------------------------------------------------------
// FUNCTION: CvUnit::computeWaveSize
//! \brief Computes the wave size for the round.
//! \param bRangedRound true if the round is a ranged round
//! \param iAttackerMax The maximum number of attackers that can participate in a wave (alive)
//! \param iDefenderMax The maximum number of Defenders that can participate in a wave (alive)
//! \retval The desired wave size for the given parameters
//------------------------------------------------------------------------------------------------
int CvUnit::computeWaveSize( bool bRangedRound, int iAttackerMax, int iDefenderMax ) const
{


This is a very good idea. This style allows you to Doxygen the source code:

http://www.stack.nl/~dimitri/doxygen/

It's what I've been using for my mod. I've attached an early version of one page that Doxygen generated.
(I'm currently working with the Warlords SDK, and have cleaned it up a bit, but would probably get into trouble if I posted unreleased source code.)

It'll give you an idea of what it does but it doesn't allow you to see how easily you can browse through the Doxygened files.

Ok this is simply so unreasonable I am having trouble remaining calm in my reply. Everyone else I have talked with about this is fine with XML control only, run-time in addition is both unessary and ill advised. I have added 3x6 int matricies to City and Player, these objects have HUNDREDS of data member already, the overhead both in memmory and speed is piss in the ocean. All the combined changes of this project together add .001 MB to the DLL, our changes are like fleas on an Elephant! Overhead will not become an issue untill we get into deep AI re-programing and no I do not see a need to switch AI improvments at run time, no one would want that.

SimCutie I ask you to remember who your fellow project members are, we are mostly amatures working in our spare time hacking away at Firaxis work. Do not smother them with standards and practices that are inappropriate for the scale of this project. Dose anyone else agree with me on this point?

']Ok this is simply so unreasonable I am having trouble remaining calm in my reply. Everyone else I have talked with about this is fine with XML control only, run-time in addition is both unessary and ill advised. I have added 3x6 int matricies to City and Player, these objects have HUNDREDS of data member already, the overhead both in memmory and speed is piss in the ocean. All the combined changes of this project together add .001 MB to the DLL, our changes are like fleas on an Elephant! Overhead will not become an issue untill we get into deep AI re-programing and no I do not see a need to switch AI improvments at run time, no one would want that.

SimCutie I ask you to remember who your fellow project members are, we are mostly amatures working in our spare time hacking away at Firaxis work. Do not smother them with standards and practices that are inappropriate for the scale of this project. Dose anyone else agree with me on this point?
Hey Impaler, calm down and ask yourself. What is worng with my point? It doesn't matter at all here even if I am a dog and your are Mr. Bill Gates. You should answer with logical persuation, not anger or personal attack.
OK. overhead can be tolerated if it is not excessive. But having single point of control for given feature is widely supported convention of most open source software. Choose any respectable open source software and look at their code. They have lots of #ifdef to select featrues. It is not standard of commercial software, but standard of open-source software.
Why they do so? Overhead is not only reason they are doing so.
It is matter of freedom. freedom to choose.
Moder should have simple means to deactivate feature they don't want. That decision should be made by the modder, not by us. Let them choose what ever suits their need. It is pivotal characteristic of sucesss of open-source software.

Just to clarify, you are talking about modding features, rather than features that we do want runtime config on... like pretty much anything we have at the moment that isn't a modding feature.

I'm personally not too keen on the #ifdefs, and it doesn't seem that anybody else much is either. I don't see the overhead brought about by adding modding features to be that great when compared with the overhead of what is already there. Deactivating a feature will have no effect other than to reduce whatever overhead it produces, which, as I said above, should be minimal. XML control (where nothing there means the option is disabled) seems far simpler and more accessable to me. A modding feature doesn't do anything if the user doesn't use it.

This is not really like other open-source software either. From what I can tell the majority of modders aren't going to open up the SDK and disable the option. They won't have to, because it won't be enabled in the first place.

Personally, I think you're overestimating the talents of most Civ 4 modders. If you look at the large modpacks which are out there much of the code has been done by people who hadn't written a single line of code before Civ. We're opening up more options for the easy stuff rather than forcing them to delve into the hard stuff.

What is the actual version, what should I DL for testing? Anything I missed?

I think the current version is on the download thread. From what I can gather, it doesn't work, and crashes as SF described.

']Do not smother them with standards and practices that are inappropriate for the scale of this project. Dose anyone else agree with me on this point?We do need some standards, otherwise it's never going to work, and it's going to come out a mess. Personally, I wouldn't mind if everybody just kept to the commenting style, and tried to set out their code like Firaxis have set out theirs.

About DOXY - looks like a good method for documenting new functions. Is anybody against me putting this in the contributions guide (in the vain hope that somebody will read it ;))

OK. I will change #inclide position to Top of the file as Firaxis's way.
Instead, I suggest use of # ifdef for all our code be adpoted as general guide line.
Resolving overlapping #ifdef is exactly the work we should have to do.
The #ifdef section is not random peice of code. It is logical unit of change for a feature. So if same potion of code should be changed diffrently by combination of feature, it should be logically resolved depending on combination of feature. Not using #ifdef is hiding problem under carpet, not solving it. That is not right thing to do.
Current problem of merged version (by SF) is also same problem. Each piece of code worked without problem before merging. But when they are combined, it caused problem. So it is our task to solve it logically. This is what "integration" is for. if all code used #ifdef for each individual feature, the integration test will be much eaiser, not harder.
Most major open-source software developed by multiple developer adopts such convention (i.e. compile time feature selection by #ifdef adopted by apache web server)


SimCutie, I think the people who will to use the result of our work are either python modders, not able or willing to change or compile the SDK, or they are end users. You can't compare our product with an apache server, or something similar.
You're right, that testing might be easier when we have compiler switches, but in ONLY in one case :
- when we've problems in the merged version you can switch off different features and test if problem persists.
But this you have to buy with certain disadvantages :
- if there is a fault in the #ifdefs, you gain extra problems.
- if you have overlapping #ifdefs, you have to resolve the code. This is time consuming.
- the code is not that easy to read
For me there are more cons then pros it useing #ifdefs. If you like to use them, do so. They doesn't disturb anything what I'm doing, as long as they are all set active. But, PLEASE, don't start make your features as #ifdef options. Will say : if switch A than features X is active, if not feature Y is active.
Somehow, I'm getting tired of that discussion.

12m

Personally, I think you're overestimating the talents of most Civ 4 modders. If you look at the large modpacks which are out there much of the code has been done by people who hadn't written a single line of code before Civ. We're opening up more options for the easy stuff rather than forcing them to delve into the hard stuff.

Quoted for TRUTH!

The best mod creators are not necessarily the best programmers. If you want this project to lead to more innovative mods, make as much as possible editable with XML.

For this reason IMHO Impaler has the most useful modifications in the first release. :goodjob: I'm especially looking forward to the Universal Building Modifier in a future release.

Also while Python, I think this:
[SDK]GetXMLElement() extension to CvEntities. Allow from Python to grab an arbitrary XML element for a particular entity, allowing modders to add arbitrary additional xml elements to buildings, units, etc.
will be the holy grail for better modmaking. :)


Maniac - tester

Okies - from what I can tell people are generally against incorperating #ifdefs as a rule, but it doesn't matter if you use them. Coding style discussion seems to lean towards using Firaxis style where possible. Can people try and stick to this please? Any opinions on the doxy commenting?

I've kind of lost track of where we are. Am I right in thinking we haven't successfully combined the code yet? It seems we have an unknown glitch, which... nobody knows about. Can we make finding and fixing this our top priority so we can move on?

Regarding DOYGEN, I'm nut sure if its worth to use. Only a very few functions in Firaxis' code does use it and if we start to use it now for our few functions, I don't see any effort for it. As I said, I'm not sure but I'm also not strictly against it.
On the other hand we need comments anyway, so why not have a common style for it.

I downloaded the actual version yesterday from SF and was able to compile it. I will try to do some test runs this evening and maybe I found something.

12m

The dev branch on the CVS is working fine, I just compiled and played it.

I sugjest we release that as our first release by this coming weekend at the very latest as we are very much behind schedual. We can continue working on the error but I cant see us holding up the release any longer then that to get buggy code fixed and included. I recomend everyone grab a SandBox of the dev branch and start using that, SimCutie you may want to trim down to just the working Mods and include these. I realy recomend you drop that ifdefing as its plainly obvious we wont be adopting it as a standard or using it in anyway thus its just a source of buggyness. Also we now have the .cpb in the CVS, its a big hastle to repeatedly configure the .vcproj with proper build options everytime I want to compile so include and use that .cbp file.

Did a test of the dev branch as well and everythings fine. No crash or any other problem during normal play.

I'm not sure which changes are in that branch, I could only find Impalers and my ones. Nothing from SimCutie or anybody else. Did I missed something?
SimCutie, will you add your changes again?

12m

Did a test of the dev branch as well and everythings fine. No crash or any other problem during normal play.

I'm not sure which changes are in that branch, I could only find Impalers and my ones. Nothing from SimCutie or anybody else. Did I missed something?
SimCutie, will you add your changes again?

12m
Is the version in "dev" CVS branch finished version?
When I checked out latest dev branch and compiled and tested, it has same anomaly. (infinite loop when starting new game). please check it.
"dev" version in CVS I have tested has none of my code and tested with clean (empty) CustomAssets except the DLL.
It also cannot read old original savefile. If I load old save file, it quit to desktop without any message.

Hmmm - we really need somebody to sit down with the complete version of the code, and try to fix it. At the moment we don't seem to be getting anywhere fast.

At the moment it seems to me that the SourceForge CVS has all the updated files, and has had for 5 days. I can see submissions by SimCutie, and Impaler[WRG] (who included your files if I'm not mistaken 12m).

I'm not sure about Fruit's server. I can't seem to get to grips with the FTP program that's on the uni computers, so I can't check it.

Anyway, could somebody with a few hours spare please get the copy of SourceForge, and see if they can fix it?

We cant load old save games this has been discussed already, I can not yet implement the version checking scheem you recomended untill your code which provides that version check is in. In any event I dont feel we can delay the project to get it in their. It should be a goal for the second release.

The crash at load is a mystery I do not experience it when running the DLL alone, I DO get an imediate "you have been defeated" right after dawn of man this is probably due to not including Monkeys Python Assets as his changes involve the DLL calling outward to the Python layer, once his Python is included the game runs fine. This is not a major issue for me, we simply tell people to include these Python files as they are nessary for the improvments to take effect.

SimCuties changes are not on the CVS because I could never get them to compile so could not include them. If he gets his code working he should upload it or commit it.

I have tried to add SimCuties Code in one section at a time to Impaler and 12 Monkeys working code, but it is very hard b/c SimCutie has not defined very well what code is for what section in the readme (and even that is not very clear).

I downloaded the updated files on the SF (SourceForge) site and put in on the SF (SpoiledFruit) server, so the files in the CvGameCoreDLL folder are the current working one. SimCutie, since you know what you did better than the rest of us, could you mabey add your code in and make sure it works. Then you can just add it to both SF servers.

After this we are going to need to use the CSV from now on, either on my server (CSV is finally installed) or SourceForge. This cannot happen again as this seems to have killed the discussion and developent of the mod for the moment.

I just hope we can release a beta soon so we can generate more interest.

I have added the CoreDLL.dll to the Forge, it is a strait compiling of the current code, SimCutie test this DLL and see if your crash at load still happens. I agree we need to use the SourceForge from now on, its working very nicely

PLEASE: from now on when you commit changes please update this Binary as well so other can test your changes quick and easy.

Same sympthom persist with new downloaded DLL. The Assets folders are completely empty (only empty dummy folders) except the downloaded DLL.
If I remove the DLL from Assets folder and start new game, it works normally without any glitch.
I have merged version in CVS and my code. But it has same problem. So I am not releaseing it to CVS.
Please fix this problems first with 12Monkey-Impaler version.
']
The crash at load is a mystery I do not experience it when running the DLL alone, I DO get an imediate "you have been defeated" right after dawn of man this is probably due to not including Monkeys Python Assets as his changes involve the DLL calling outward to the Python layer, once his Python is included the game runs fine. This is not a major issue for me, we simply tell people to include these Python files as they are nessary for the improvments to take effect.

I should not work that way.
If a modder uses the 12Monkeys improvement, then they should add the modded "CvGameInterface.py". It is good and necessary.
But if player / modder don't use the 12Monkey's improvement, DLL should not require special modded "CvGameInterface.py" in their Assets folder to work normally.
If the file does not exist in the folder, it should work normaly just like unmodded DLL.
Isn't this minimum requirement of our project?

Same principle to savefile problem. If player don't have any Impalers extended XML attributes, then it should assume that the loaded game version is old vanilla savefile. and should be able to read original savefile.
If player has new XML attributes, then it read modded save file.
It should act same as original DLL unless it is activated by the new XML attributes. Isn't this what you have promised with XML-controlled DLL features?

PS) I have tested with Impaler's code and 12Moneys's code by adding #ifdef for each respective parts for testing purpose.
I have found that it is 12Monekys part that causes this problem. And savefile problem is only in Impalers code.

The point is that it does act exactly the same. By default the python will allow the SDK to do it's job, so will have absolutely no effect on the game. It would probably be better if it worked without the python layer being there, but it isn't critical. Should probably be fixed for the next release but it's not critical. Same with the save-game fix.

SimCutie - could you test it with the python files, and tell us if that works. If so, then we should release this version.

Also, can you suggest how Impaler would get your changes to compile? At the moment he won't be able to work on new projects as he'll be basing it off this code, which he can't compile!

The requirment that files other then the DLL be included is reasonable, all XML based changes require that modified Schemas be included for any of the changes to be activated without an error durring XML loading. Our "retain original game" doctorine never stipulated that a SINGLE file be nessary for that gameplay to be retained.

I know that my code breaks backwards savegame compatability and this will result in an immediate exit to desktop if incompatable games/senarios are loaded, but I still do not understand how 12monkeys code is causing an infinite loop. I can run the dev branch dll with or without his Assets and I get no loops, only the "you have been defeated" without his assets.

Give us more details on how you get this loop, is it only on a particular type of game (multi/single) any game options set? Try running the DLL from within a Mod folder, anything that might be having an effect.

I have attatched a save game made under the current DLL, try to load it and see if you still loop (it should not exit to desktop and have tested that it dose not for me).

What compiler are you using Impaler? Is it VS 2003 or something else. If you are using another program like Borland or VS 2005, there will be compiler errors. I think that VS 2005 has a workaround though.

VS 2003, I followed Kael's guild to the letter (well at first I screwed it up but once I was doing to to the letter it worked fine). I should be just like everyone elses compiler. Other people were experiencing the same problems with SimCuties code so its probably not a problem on my end, I suspect he included libraries or linkers or some other fancy thing that the rest of us dont have and this is the problem.

I am sick and tired of these delays, I have patiently waited and keept my code hiden away on this project rather then release it so as to make this project unique and exciting when released. I will be releasing MY code this weekend (and if 12Monkey aproves his code with it). If SimCutie has working code on the CVS before that point and wishes for it to be included I will do so, if not then tough for him, he can try for next release.

']The requirment that files other then the DLL be included is reasonable, all XML based changes require that modified Schemas be included for any of the changes to be activated without an error durring XML loading. Our "retain original game" doctorine never stipulated that a SINGLE file be nessary for that gameplay to be retained.

It seems that my intention is misunderstood. I will try to make it clearer.
When a player or moder decided to use specific feature of a DLL which requires specific XML modification or Python module modification, then he/she will install the moded DLL *AND* SET of multiple XML files ( new schema and new XML file with new XML attributes) and/or SET of multiple Python modules with required change. Then the new XML enabled feature/Python-enabled will take effect and work as intended. It is good and of no problem.

But unused/unseleced feature should not hinder or change normal operation of game or DLL. If player don't want feature "X", Then he will not install related XML files or Python files. then DLL should act externally as if feature "X" does not exist in the DLL.
I had meant above that *UNSELECTED* feature should not require any XML or Python files or any other Assets to be installed. "Selected" feature can require as many XML or Python files as requrired for proper operation of the feature.
"Selected" feature means that player or moder explicitely installed the related Python file or XML files or by clicking game Option checkbox.
If no new XML or Python or Assets are installed, then all the features are disabled, then it should act just like vanilla DLL in end-player game playing level.
']
I know that my code breaks backwards savegame compatability and this will result in an immediate exit to desktop if incompatable games/senarios are loaded, but I still do not understand how 12monkeys code is causing an infinite loop. I can run the dev branch dll with or without his Assets and I get no loops, only the "you have been defeated" without his assets.

Hmm.. I will try to pin-point the source of freeze on this weekend.
And even if it is solved, the "you have been defeated" behavior is also problematic. If DLL detects that his Assets does not exist, then it should fallback to original behavior, not "you have defeated" behavior.
']
Give us more details on how you get this loop, is it only on a particular type of game (multi/single) any game options set? Try running the DLL from within a Mod folder, anything that might be having an effect.

I put DLL from the CVS into the clean CustomAssets folder. then started Civ4 in windowed mode.
I selected Single Player/Play Now!/Pangea/Temperate/Medium sea-level/Standard size map/random shoreline/random civilization/Setter difficulty/Normal game speed/.. and started game. Then it shows first screen of Dawn of Man. but immedately it freeze and does not responds to any windows message. Progress bar stops with "Initializing....". The Audio narration and music continue to play but graphic is not updated any more.
The PythonDbg.log is same as I have posted previously. (infiniely repeated patterns and very big)
I also have tested it with DLL in ....\MODS\DLL Only\Assets MOD folder, But result is same.
']
I have attatched a save game made under the current DLL, try to load it and see if you still loop (it should not exit to desktop and have tested that it dose not for me).
Loading is Ok. But I can not select my own units. City selection is OK. And when I press "next turn" button, it crashs and shows MS "Error report" dialog.

It should fall back to the default behaviour, but it doesn't and won't for this release. If you just include all the files for now then that should be good.

At the moment we need to fix this infinite loop problem. SimCutie seems to have narrowed it down to something clashing with 12Monkey's code. Strange that it only happens with his version though. I take it you are runing Windows & patch 1.61, right? It might be something to do with windowed mode. Maybe test with full screen mode?

I can run windowed Mod no problem.

SimCutie post your most resent code here or create a SimCutie branch on CVS and place it their, I will try compiling and running that to see if the problem is their as well. Also try compiling the current CVS dev branch and comparing that with the Dll on the dev branch perhaps you will see some difference. I am starting to suspect the problem is in your Python interpriter or an inability of the interpriter to talk with the DLL.

']I can run windowed Mod no problem.

SimCutie post your most resent code here or create a SimCutie branch on CVS and place it their, I will try compiling and running that to see if the problem is their as well. Also try compiling the current CVS dev branch and comparing that with the Dll on the dev branch perhaps you will see some difference. I am starting to suspect the problem is in your Python interpriter or an inability of the interpriter to talk with the DLL.
Hmm. corrupted Civ4 Python interpreter.. Possible cause...
OK. I will uninstall my Civ4 Installation and reintall it fresh from DVD.
And I will test it again. Wait for a while.

PS) No Luck. Same freeze. But it seems that little bit changed. I will digress on it further.

It should fall back to the default behaviour, but it doesn't and won't for this release. If you just include all the files for now then that should be good.

At the moment we need to fix this infinite loop problem. SimCutie seems to have narrowed it down to something clashing with 12Monkey's code. Strange that it only happens with his version though. I take it you are runing Windows & patch 1.61, right? It might be something to do with windowed mode. Maybe test with full screen mode?
If all XML and Python file should be installed in players Assets even if the features are not used, it is different from of what we have intended and talked about "platform".
It seems that current version works without apparent problem if all XML/Python are installed in Assets folder.
Then, are XML/Python controlled feature enable/disable facility and savefile compatibility problems postponed to next release?
I am reluctant to release this version to public without feature enable/disable by XML/Python and savefile compatibility. But if other members wish to release current version as is, I will follow others opinion.
But AFAIK, the planned release date of warload expasion is abut mid-July (may be about a month or so from now). We may not have oppotunity to release 2nd version for original Civ4 SDK.

I think we can probably get another version out before Warlords. It's still 1.5 - 2 months away, and it's likely to be later in places other than America.

Modding features such as this don't need to have an enable/disable switch as they are passive. The modder might never use them. I agree that it would be good for them to be optional, but it's not nearly as neccessary as having switches on other things.

I think that we should force ourselves to release a public beta by the end of the week-end, even if it doesn't do everything we want it to. Otherwise, we will always get bogged down and never release anything. Also, we might get lucky and more people might decide to join us, which will make things a lot faster.

We will also discover once and for all if SimCuties error is occuring for anyone else, currently no one else can replicate it. We definatly need outside testing at this point. I will prepare some small XML mods that utilize my new features, they will serve more as examples of how to utilize and perhaps be usefull components rather then real mods. These will be offered as a seperate optional file from the CCP.

Goodo. All set for a beta release tomorrow evening (in about 24 hours) in the Mod Components forum then. This should allow us to (hopefully) track down that crash if we can't find it beforehand, and will get the first one out of the doorway so we can continue work on the second one.

So, current known issues:

Save games from previous versions will crash the game (will be fixed for next version)
Persistant loading crash on some machines. Not entirely sure of the cause. (I really would like it if you could nail this before tomorrow SimCutie!)

Any progress on this?

Which .dll should I link to on the forum post, also, is there a compressed package of our source code somewhere?

I was going to post it in 5-6 hours from now.

I have just sent an E-mail to your hotmail account...

From Impaler[WrG]

I have compiled the dev branch and extracted the latest Assets using an anomymous CVS checkout, the CVS folders and included here, the end users will be able to use this to update (But NOT Commit) the Assets as we do inevitable patching if they have Tortise (which I recomend) otherwise they will just be dead folders.

I recomend you use the CivFanatics upload as the Zip is too large to get on a post.

Please confirm secessfull reciving it, I recomed releasing as soon as you get it uploaded, just give an Introduction and then I will reply to your Post will information about my Mods and some compatable mods of my own.

I will also prepare a package containing only the Modified Source files.

Got it. This is without SimCuties files right? Or did you have some luck in compiling them?

BTW - I have absolutely no idea what you're talking about. I assume it has something to do with all these additional files. Can you possibly give me an explaination which I can just copy-paste into the post?

I had assumed he had not commited anything to the CVS because their was no post here as to him doing that, but I have just done a checkout and found he has, I will try to compile it. If I cant I still have the Assets I just sent you.

Also I am preparing a Posting on the Civ 4 Communit Mods site
http://civ4mods.loadedinc.com/ but will delay that for testing SimCuties code.

SimCutie: I got a Conflict oncheckout, why have you removed these files
CvGameCoreDLL.cbp
CvGameCoreDLL.depend
CvGameCoreDLL.layout

The layout and depend arn't so important as I belive they will be generated at compile time but cbp is a saved project file containing Compiling instructions and other important stuff (I think it also contains listings of all the files in the project), if you need to update it because of the files you added thats well and good but do not remove it, I will have to reset all the compiler and linker options and recreate it from the vcproj file now.

:) COMPILED 7min/13sec

:( Crash to Desktop when you press PlayGame after the gamecreating bar is finished.

']
:( Crash to Desktop when you press PlayGame after the gamecreating bar is finished.Sounds like that's exactly the problem SimCutie was reporting - is your python error log the same as the one on this post (http://forums.civfanatics.com/showpost.php?p=4123602&postcount=121)?

If so, it's a crash on "load_module CvGameInterface".

SimCutie said he had narrowed it down to 12m's code, when he had his and yours not running, although given that you had tested 12m's on it's own this is rather odd. Maybe a compare of the files might show something? (Don't have any compare tools here, but I might skim through with notepad...).

EDIT: And can you post that explaination I was after?

EDIT 2: Also, I have an exam tomorrow morning, and I'm planning to go to bed in about 40 mins... if somebody else wants to start the thread that's fine, as long as you don't go disappearing. I think I've pretty much got the complete changelog on post one of this thread, though I'm not certain. If nobody does post up the thread, I'll probably have it done ~1PM GMT tomorrow, after my exam.

EDIT 3: Ok, gone to bed.

When I merged the code together the first time, there were a few places where SimCutie's and 12monkey's code intersected. I have a feeling that it is in these places that we need to look at first to see where the problem is, because alone, each modification works fine.

I have never used the Pythonerrorlog but I think I managed to get it running properly and generate the type of log file you need.

From what I can see comparing it to the log by SimCutie you linked too its not the same problem, the section ware he looped infinitly is fine and it continues on to load several more Moduals. Then it looks like its going to save the game and the last thing it lists is loading Pickle.

TGA: I was refering to the Tortise CVS files, its the method I have been using to access SF, by including these files already configured and pointing at the correct site they wont have to do any configuring themselves they just need to install TortiseCVS and they can Checkout the Assets folder getting the new DLL and other files.

If you like I can make the release (of the earlier stable code I sent you) tonight ~3 hours from now, should I also release the Unstable stuff as an "Unstable v2.0 for testing perposes only"?

I have uploaded the stable Assets to the Civ4 Community Mods page with a voluminous explination and user guide, I included 12Monkeys and my own changelogs and logs for the other small mods that I included. Their admins will need to aprove it before it becomes public, that shouldnt take long, then I will link to it when I make the release Post.

Released under Mod Components, go make your reserved posts now!!

SimCuties latest upload to the CVS is still unstable, I have checked out a Copy of it and everyone else should as well, then we should revert to the last stable version say some time middle of this coming week so other moding can continue. Meanwhial Sim and Monkey can attack this crash problem. I will likly be preocupied with bug reports from the release.

It might be a good idea to get thouse individual branch folders on the CVS back up.

Merged version check-in in CVS dev branch. Please update and check. Crash impaler experinced is due to ActionButton python file version problem. I uploaded somewaht older version than matching CvGameCoreDLL.
Just update python Assets/Python/Custom/ActionButton.py. No change to CvGameCoreDLL.

PS) Sorry I didn't know about .cbp file. It is added again.

I think you got it their, loaded and ran fine. I saw your Test Buttons, the White Star on Blue that printed "Test Button 1" to the screen, the Pink button (must lack an ArtDefine) that centered units and the Button 2 with the Monarchy art that printed the date and time it was pressed.

Good job, I think we should do a bit more internal testing and fix what ever bugs are found in the 1.0 and we could have the 2.0 with your mods ready in no time. I am hopeing we can get some of Lopez's mods in as well, he has been quite prolific, your Python mod controls could be of great use to him.

You missed me by 2 minutes there! Ooops.

Can you update the change log on the post you made to include spoiler tags (like the one on this thread)? It makes it look alot neater, and some of the details of some stuff are rather expansive.

Other things - can we keep the version number as agreed. Version 1.0 makes it sounds like it is final, or at least part way to being final. This is v1.61.0001a.

I'd quite like the version including SimCutie's changes ASAP - he's made some quite large changes to the way the events are handled, and they really should be in from the start. When it's compiled could it get uploaded to a place where you can download it easily (similar to a release), so that the testers here can have a go with it first?

I was wondering how you did that with the little spoiler boxes, I've never used thouse before. I will definatly add them once I know how. Sorry about the version number I can change that, though to be honest v1.61.0001a. sound realy unessarily long and cryptic.

I am quite impressed with what SimCutie has done now that I am able to get my hands on it, should we sneak it in along with bug fixes made in the next few days or throw it out their right now? I have one or two other tests I would like to make.

On another though I think we should keep the Demotest buttons and other Demo materials that SimCutie made in a seperate download, that will keep the CCP core download from altering anything. I did something similar with some XML mods by providing them as addon Demo mods, we just specify. SimCutie could you move the files assosiated with thouse Demos out of the project Assets and provide them here on the forum and be prepared to post them when your mods are released.

this is a spoiler

is like that

Just use <square-brackets-on>Spoiler<square-brackets-off> this is a spoiler <square-brackets-on>/Spoiler<square-brackets-off>

<text> comes out as:

<text>

If you want to say what the spoiler is for you can do:

have big noses which comes out as:

have big noses

I agree about demo mods. Definatly should be in an additional download, and definately needed.

My thought for testing was that we would get the new .dll and files hosted somewhere where we can all download them (I'm not sure everybody who has access to this forum can access the FTP), so that we could test new features for usablilty, and bugs.

EDIT: As a side note the <text> tag allows you to post things like that without them getting changed by the forum.

Thanks for the tips guys, thats a rather usefull thing I will have to start using it.

The Release post is updated with the Spoilers, what do you think of it now?

I will see if I can get thouse Demos seperated (should be able to just move thouse Python files out, thats the whole point of SimCuties Eventmanager after all)

I did notice an odd behavior with SimCuties changes, at the corner of the screen the Pedia and MainMenu links disapear when the two < > city cycling buttons are pressedand then re-apear after selecting a unit or unit. Its anoying but not debilitating. Also changes made in the options panel dont seem to take effect untill I end the turn or do something else to cause a screen update, could the change effect be linked to the closing of the options menu that would ensure things update imediatly.

When I removed the Custom Buttons things worked fine, that Pink center unit button is still their. I realy like the effect and think it should be perminent as it is but it needs some Art pronto. Can someone scroung up an artist?

I sucsesfully loaded the Anchient Mediteranial Mod with the CCP in Custom Assets so its proving very compatable with normal Mods.

I think we can probably get another version out before Warlords. It's still 1.5 - 2 months away, and it's likely to be later in places other than America.

Modding features such as this don't need to have an enable/disable switch as they are passive. The modder might never use them. I agree that it would be good for them to be optional, but it's not nearly as neccessary as having switches on other things.
According to recent thread about WarLord expansion release date, it seems that the expansion will be released circa July 21 - 25.
I think that we should have next release no later than very ealy in July, preferabley until end of this June...
Considering such short period to work on second release, we should not plan major feature addition to second release. It should be just maintenace and supplementary release (like Demo, document, save file and Python/XML feature enable/disable)

http://forums.civfanatics.com/showthread.php?t=173224.

']Thanks for the tips guys, thats a rather usefull thing I will have to start using it.

The Release post is updated with the Spoilers, what do you think of it now?

I will see if I can get thouse Demos seperated (should be able to just move thouse Python files out, thats the whole point of SimCuties Eventmanager after all)

Good idea, but we dont have to put demo files in separate ZIP. We cound put the demo in same ZIP but in different folder like Document folder with direction on how to install the demo to Assets folder.

']
I did notice an odd behavior with SimCuties changes, at the corner of the screen the Pedia and MainMenu links disapear when the two < > city cycling buttons are pressedand then re-apear after selecting a unit or unit. Its anoying but not debilitating.

It is normal behavior of the game. when you press < >, then a city is cycled and selected. If you select any city (via clicking on the city), then Pedia and MainMenu should disappear.

']
Also changes made in the options panel dont seem to take effect untill I end the turn or do something else to cause a screen update, could the change effect be linked to the closing of the options menu that would ensure things update imediatly.

This option value go into effect imemdatly when you close the option screen. Main screen need redarw to see the effect. I found redrawing main screen too intrusive and inconsistent with other options that is not related to main screen. Any other option that changes screen behavior should redraw at event of "OptionEnd" event. SHould I redraw main screen, is it better behavior? It is simple one liner. Give your opinion.
']
When I removed the Custom Buttons things worked fine, that Pink center unit button is still their. I realy like the effect and think it should be perminent as it is but it needs some Art pronto. Can someone scroung up an artist?

I have ugly button for it but I fear that every one will laugh at that. So it is not included. But if you wish, I will include it as just "demo".
Is there any one who will donate better buttons image for it?

Agreed with the release timing.

I think we should be a bit more strict with the timing next time around. When the deadline arrives, code gets merged, and any code which isn't ready doesn't get in. It should be alot easier this time as we have a server to work with. We also should do a brief test cycle beforehand, as discussed earlier in this threadm, to ensure that the stuff we've added goes together, and the interface (modding, and game) is good enough.

This option value go into effect imemdatly when you close the option screen. Main screen need redarw to see the effect. I found redrawing main screen too intrusive and inconsistent with other options that is not related to main screen. Any other option that changes screen behavior should redraw at event of "OptionEnd" event. SHould I redraw main screen, is it better behavior? It is simple one liner. Give your opinion.
Can you not just set the relavent bits of the interface to be dirty, rather than the whole screen?
I have ugly button for it but I fear that every one will laugh at that. So it is not included. But if you wish, I will include it as just "demo".
Is there any one who will donate better buttons image for it?What does the button do? I might be able to knock something up, or, failing that, I know a few people who I can probably bully into doing it. ;)

Its a center screen on unit button, works just like the little Cicley pointer thing you get at the edge of the screen but because its consistently at the bottom of the screen and now racing all over the ege its a lot easier to click on. A simple bulls eye like Icon would work fine.

An alternative would be just displaying the Units own Button but this may become confusing to the player, what do yall think?

I think refreshing the display is advisable, its not that expensive. Infact that tiny pause blip you get is how you know its working (like the burning sensation you get from rubbing alcohol on a cut). It will also require less overhead for mod makers in the future as they wont have to pass any dirtybit information. If people feel its degrading performance we can always change it later.

At this point I am hopeing we can have next version out in a day or two, Is their any way for one of you to edit my release post with the new material as I will be working tonight and tommorrow. Wednsday is good for me though and I will update and start debugging then, I already found and corrected problems with my VoteModifier not passing the incressed votes to Python.

']Its a center screen on unit button, works just like the little Cicley pointer thing you get at the edge of the screen but because its consistently at the bottom of the screen and now racing all over the ege its a lot easier to click on. A simple bulls eye like Icon would work fine.

An alternative would be just displaying the Units own Button but this may become confusing to the player, what do yall think?
I think the unit's button would be confusing - too much like promotions. Can't you do something like this by double-clicking on the unit model in the bottom right or something. Maybe it's not the model, but I did think something down there did it.

']I think refreshing the display is advisable, its not that expensive. Infact that tiny pause blip you get is how you know its working (like the burning sensation you get from rubbing alcohol on a cut). It will also require less overhead for mod makers in the future as they wont have to pass any dirtybit information. If people feel its degrading performance we can always change it later.Good points. All of them.

']
Is their any way for one of you to edit my release post with the new material as I will be working tonight and tommorrow. Wednsday is good for me though and I will update and start debugging then...Nope - not possible. It can wait until Wednesday though.

I would like to bring back SimCuties discussion about enable/disable python hooks back on top. During my tests I recognized that some the python hooks (especially those within the CvUnit class) results in a remarkable performance loss. On large scenarions with lots of units, you can loose up to 50% between two turns.

Because this is not acceptable I would like to make them enable/disable in any case, independently if the correct python files are there or not. We can also add such a feature to the original python hooks to gain some game performance, allthough the gain may be not that big.

I remember that SimCutie added in one of his very early versions an automatic detection of the python hooks.

SimCutie : I'm not sure if this feature is still part of your current adoptions, but if so can you tell some more details about it, please? Especially I would like to know, if the existance of the python part is checked each call or only once during initialization.

12m

This is button I had made. How about that?
....
You! Dont laugh! I know that it is crude... :blush:

I would like to bring back SimCuties discussion about enable/disable python hooks back on top. During my tests I recognized that some the python hooks (especially those within the CvUnit class) results in a remarkable performance loss. On large scenarions with lots of units, you can loose up to 50% between two turns.

Because this is not acceptable I would like to make them enable/disable in any case, independently if the correct python files are there or not. We can also add such a feature to the original python hooks to gain some game performance, allthough the gain may be not that big.

I remember that SimCutie added in one of his very early versions an automatic detection of the python hooks.

SimCutie : I'm not sure if this feature is still part of your current adoptions, but if so can you tell some more details about it, please? Especially I would like to know, if the existance of the python part is checked each call or only once during initialization.

12m

bool hasPythonAttr(LPCSTR module_name, LPCSTR attr_name )
Check existence of Python attribute value.
param module_name Python module name string.
param attr_name Python attribute key name to check.

This is API of the call.
It is not good idea to check existance of the entry point before each call.
It is better to check at StartGame/OnLoad time and use it afterward.
'OnInit' event time is bit too early. Because python MOD can add entry point routine dynamically at OnInit time.

Or I can provide a function that returns same result with above call but that caches check result. Then Python entry point caller will check everytime before calling the entry point but actually it is checked only once at game startup / on load time.
It will remove burden of the each caller to keep track of the check result.
There are three choice.
1) bool CallGameEntryPoint("canUnitMoveInto", PyArgs argsList, long & lresult );
It will check existance of the entrypoint automatically.
If the entry point exist, it will call the entry point for you. It return true as function return value and Python call result is in &lresult.
If the entry point doe not exist, it will return false and lresult value is unchanged.

2) bool hasGameEntryPoint("canUnitMoveInto");
Only returns existance of entry point as bool.

3) Both 1) and 2)

12Monkey's GameIntarface entry point are great contribution to our project.
But some of the entry point name seems to be little bit not so intuisive or inconsistent.
Some name sound like as if it is action-performing funcrion, but it is actually a predicate or pre-conditioning hooking function.

ex: razeCity()
It sound like a directive or command that orders Python to perform razing city, but it is not.
Better : willPlayerRazeCity() :
Player is about to raze city, will player actually raze the city? if return true, player will. if return false, player will not.

So I suggest some entry point name to have more consistant name.

My opnion on Python entry point name sugestion:

razeCity ==> willPlayerRazeCity (it is consistent with canPlayerRazeCity())
playerFoundReligion ==> willPlayerFoundReligion()
groupStartMission ==> willGroupStartMission()
doUnitCommand ==> willUnitDoCommand()
unitUpgradePrice ==> calculateUnitUpgradePrice()
spreadReligionToCity ==> willSpreadReligionToCity()

OR

razeCity ==> doPlayerRazeCity
playerFoundReligion ==> doPlayerFoundReligion()
groupStartMission ==> doGroupStartMission()
doUnitCommand ==> doUnitCommand() (NO change)
unitUpgradePrice ==> calculateUnitUpgradePrice()
spreadReligionToCity ==> doSpreadReligionToCity()

OR better yet...
Combind canXXX wit willXXX

like canWillXXX( args, bOriginalResult, bWillXXXX );

Example:
canXXX(args)
{
bOrigRes = canXXX_Orig(args);
return canWillXXX(args, bOrigRes, false )
}

doXXX(args)
{
if !canWillXXX(args, canXXX_Orig(args), true)
return;
....... do XXX actually.
}



How about that?

It is useful to write self commenting code, code that has class, function, and variable names that refer to their place in the code functionality or at least give a good allusion to it.

Sometimes it is easy to name things in a way that I am familiar with but many others would misunderstand.
I try to read my code from other people's shoes and see if they would understand it.

Heck! I like to be able to pick up my own code later and understand it!:eek:

bool hasPythonAttr(LPCSTR module_name, LPCSTR attr_name )
Check existence of Python attribute value.
param module_name Python module name string.
param attr_name Python attribute key name to check.

This is API of the call.
It is not good idea to check existance of the entry point before each call.
It is better to check at StartGame/OnLoad time and use it afterward.
'OnInit' event time is bit too early. Because python MOD can add entry point routine dynamically at OnInit time.

Or I can provide a function that returns same result with above call but that caches check result. Then Python entry point caller will check everytime before calling the entry point but actually it is checked only once at game startup / on load time.
It will remove burden of the each caller to keep track of the check result.
There are three choice.
1) bool CallGameEntryPoint(&quot;canUnitMoveInto&quot;, PyArgs argsList, long & lresult );
It will check existance of the entrypoint automatically.
If the entry point exist, it will call the entry point for you. It return true as function return value and Python call result is in &lresult.
If the entry point doe not exist, it will return false and lresult value is unchanged.

2) bool hasGameEntryPoint(&quot;canUnitMoveInto&quot;);
Only returns existance of entry point as bool.

3) Both 1) and 2)
All sounds good!I would prefer option 3 (always better to have more possibilites). We then could also change the stadnard API hooks. In general we than could simply coment each hook in CvGameInterface.py (the standard ones as well) and the perfromance will get a boost. Did you already implemented such a function?12m

12Monkey's GameIntarface entry point are great contribution to our project.
But some of the entry point name seems to be little bit not so intuisive or inconsistent.
Some name sound like as if it is action-performing funcrion, but it is actually a predicate or pre-conditioning hooking function.

ex: razeCity()
It sound like a directive or command that orders Python to perform razing city, but it is not.
Better : willPlayerRazeCity() :
Player is about to raze city, will player actually raze the city? if return true, player will. if return false, player will not.

So I suggest some entry point name to have more consistant name.

My opnion on Python entry point name sugestion:

razeCity ==> willPlayerRazeCity (it is consistent with canPlayerRazeCity())
playerFoundReligion ==> willPlayerFoundReligion()
groupStartMission ==> willGroupStartMission()
doUnitCommand ==> willUnitDoCommand()
unitUpgradePrice ==> calculateUnitUpgradePrice()
spreadReligionToCity ==> willSpreadReligionToCity()

OR

razeCity ==> doPlayerRazeCity
playerFoundReligion ==> doPlayerFoundReligion()
groupStartMission ==> doGroupStartMission()
doUnitCommand ==> doUnitCommand() (NO change)
unitUpgradePrice ==> calculateUnitUpgradePrice()
spreadReligionToCity ==> doSpreadReligionToCity()

OR better yet...
Combind canXXX wit willXXX

like canWillXXX( args, bOriginalResult, bWillXXXX );

Example:
canXXX(args)
{
bOrigRes = canXXX_Orig(args);
return canWillXXX(args, bOrigRes, false )
}

doXXX(args)
{
if !canWillXXX(args, canXXX_Orig(args), true)
return;
....... do XXX actually.
}



How about that?
Mmmh. I named the function corresponding the their counterpart in the SDK. The standard API function did have similar namings but even without a calss info in the name.
Its the choice now, if we want to lean the naming to Firaxis stadnard or to our own standards.
I would like to keep them as they are now, because they are more similar to Firaxis stadnard, they version is alrady released and the function itself is clearly documented to that their is no misunderstanding.
What do the others think about that?

Mmmh. I named the function corresponding the their counterpart in the SDK. The standard API function did have similar namings but even without a calss info in the name.
Its the choice now, if we want to lean the naming to Firaxis stadnard or to our own standards.
I would like to keep them as they are now, because they are more similar to Firaxis stadnard, they version is alrady released and the function itself is clearly documented to that their is no misunderstanding.
What do the others think about that?
Firaxis seems to use second convention in their CvGameIntarface. (doXXX)

Another good news. I have succeed that DLL works well on empty Assets (DLL Only) and game does not finished with "You have defeated" behavior.
It needs more test but seems to work for now.

This is button I had made. How about that?

I actually quite like it!

Yes the button SimCutie has made is nice.

At the risk of being really annoying, I'm going to complain about the style of the mod thread again ;)

Needs more spoilers. You have 'bug fixes' and 'gameplay options' in spoilers, but not any of the first 4 catagories. IMO they should all be in spoilers, as each part is individual, and a particular reader may only care about one particular part. At the moment it doesn't really look like a list, as there is a huge gap between 4) and 5) with a bunch of spoilers in between.

In other news - I'm getting home in ~ 1 week, so I may actually start being able to make some contributions.

I have been getting an odd error that I belive is linked with SimCuties Custom Button modual not being fully loaded before the Dawn of Man screen comes up. I usaly get this if I try to click play very quickly after DoM screen comes up or if I am clicking durring the later stages of the load bar just before. If I wait and pont make any inputs for a second or two I wont get the error. The Python acception apears so imediatly that I never get to see any of the DoM screen, I can drag the python exception and close it but their seems to be an infinite stack of them, perhaps their being generated non-stop. It hasen't occured at any other time or part of the game, if I keep still durring thouse first seconds I can play the game fine with out any other errors.

Heres a Screeny

']I have been getting an odd error that I belive is linked with SimCuties Custom Button modual not being fully loaded before the Dawn of Man screen comes up. I usaly get this if I try to click play very quickly after DoM screen comes up or if I am clicking durring the later stages of the load bar just before. If I wait and pont make any inputs for a second or two I wont get the error. The Python acception apears so imediatly that I never get to see any of the DoM screen, I can drag the python exception and close it but their seems to be an infinite stack of them, perhaps their being generated non-stop. It hasen't occured at any other time or part of the game, if I keep still durring thouse first seconds I can play the game fine with out any other errors.

Heres a Screeny

Hmm.. it seems that player clicked screen before action buttons are fully inited. It is kind of race condition due to CPU is very busy while starting new game. I will fix it soon so that clicking action button is ignored before it is fully inited.

Is this fixed yet SimCutie? If I'm not mistaken this is the only reason left why we haven't updated the mod currently posted to include your changes.

I'm going to upload my Unique Units for Leaders mod, it also includes some fixes to the TraitVote mod. The UU shows up everyware you would want it except the Leader pedia page (it was crashing me badly so its comented out and will be completed someday). I didn't want to change the getCivilizationUnits() function due to the great variety of places and ways it was called. Instead I had to replace all calls to getCivilizationUnits with a new LeaderHeadInfo function which took the Civ as argument (you cant get the Civ from within the leaderHead). The Python export was re-routed to a new function that calls the ActivePlayer and then Civ and Leaderhead units. This makes it work with any and all Screen interfaces without modification.

TGA why dont you post the next release when its ready, this way you can maintain the thread to high standards (also I think we get benifit of more views/reads due to your greater name recognition)

On the whole I think we need to get more moders involved and interested in our work, I think if we could get Lopez to adopt the SimCutie eventmanager/Option screen and rework his mod library for it that would give us a lot of publicity and interest. I've been a bit disapointed with the response so far from the first release dosn't seem to be getting many testers.

With UU ready I am going to put my Univerasl Building Modifier onhold and move right into exploring modular XML loading. I will also try to get around to using SimCuties backcompatable savegame reader and updating all my current mods with it.

']
On the whole I think we need to get more moders involved and interested in our work, I think if we could get Lopez to adopt the SimCutie eventmanager/Option screen and rework his mod library for it that would give us a lot of publicity and interest. I've been a bit disapointed with the response so far from the first release dosn't seem to be getting many testers.

We need to get SimCutie's event manager released first. It would seem to me that his stuff contains many of the big features that make this mod a good base for others to work off (options screen & event manager).

After that's done, then we can start doing stuff for the next big merge (see the 2nd release thread), which may warrent a new thread - I don't think we really need a new one yet.

Yep, start up python error problem cleared. and Two new improvement.

1. Now DLL no longer require any Assets/XML or python file to installed in players assets folder to operate properly. If no Assets exist it will remain dormant. No "you have defeated". (Version in CVS dev branch)

2. DLL now can read old firaxis game save file.
But one problem. It clashes with Impaler's More Form of Commerce features.
It can be fixed but requires quite a work before we can have both features.
We should modify every read ( NUM_COMMERCE_TYES, ....) to be modified slightly. quiet a work. I have to disable More form of Commerce features disabled temporarily before modify them all. (working version)

We're not going to be able to maintain complete save-game compatablily with Firaxis saves for ever. Wasn't the plan just to make it so that it doesn't cause them to crash, but instead raises an error?

Will it be able to be complete for a release later today/tomorrow?

I've looked at the Code and I see you also deactivated the localized Specialist Commerce and Yield Changes. I am again quite peved at your misplaced priorities and disregard for others. Do you seriously think backward savegame compatability is so important that it warents throwing out two major new feature? Secondly why didn't you say something 2 days ago when you made the CVS comitment or *gasp* actualy ask other people what they thought of it. I'm not going to claim my code is infalible or that it must be included but not even asking is just plain rude. :mad:

Secondly please refrain from going through and trying to neaten/butify other peoples code to your personal standards. I see you have wraped comments around code that was already perfectly well commented with mod/name/date and someone (I'm not shure if this is intentional or being done unwitingly by you texteditor) is striping off trailing whitespace from hundreds of lines. Finding a bug or vulnerability is fine but totaly non-substantive changes make for endless pages of diffs on WinMerge greatly complicating code merger

I would ask you hold up for a day long so I can get my latest mod it, I need to resolve a conflict on several files and see that the merger compiles well, I hope to have it sometime late tonight if all goes well. I would also ask that the savegame conflict be discussed and we can come to a consensus on what is more important. I think you all know ware I stand on the issue.

I agree that removing your stuff isn't right - I hadn't actually checked the files but these will certainly not be released with at least the functionality of the old files. I had presumed that they would go back in once he had tweaked them so that they were save-game compatable.

I think I'll go and bump that thread on save-game compatablitly.

']I've looked at the Code and I see you also deactivated the localized Specialist Commerce and Yield Changes. I am again quite peved at your misplaced priorities and disregard for others. Do you seriously think backward savegame compatability is so important that it warents throwing out two major new feature? Secondly why didn't you say something 2 days ago when you made the CVS comitment or *gasp* actualy ask other people what they thought of it. I'm not going to claim my code is infalible or that it must be included but not even asking is just plain rude. :mad:

Secondly please refrain from going through and trying to neaten/butify other peoples code to your personal standards. I see you have wraped comments around code that was already perfectly well commented with mod/name/date and someone (I'm not shure if this is intentional or being done unwitingly by you texteditor) is striping off trailing whitespace from hundreds of lines. Finding a bug or vulnerability is fine but totaly non-substantive changes make for endless pages of diffs on WinMerge greatly complicating code merger

I would ask you hold up for a day long so I can get my latest mod it, I need to resolve a conflict on several files and see that the merger compiles well, I hope to have it sometime late tonight if all goes well. I would also ask that the savegame conflict be discussed and we can come to a consensus on what is more important. I think you all know ware I stand on the issue.

You mis-read source in CVS. The version in CVS has all Impaler's features intact including More form of commerce. I haven't touched features.
And I have no intension to throw away any features of Impaler's code except one: "RogerBacon's AirComatMod" (mutiple targetting per turn for air unit)
It is currently active without any switch or XML tag. It changes games behavior without players acknowlegement. So it is currently disabled until we have add switch to enable it with XML (like <MultipleTargetting>3</MultipleTargetting> ) or anything.

I haven't touched localized Specialist Commerce and Yield Changes featrues in CVS version and even in working version. Only More form of commerce is affected currently in working version (Not in CVS version)and it is temporary measure to debug. I said "I have to disable More form of Commerce features disabled temporarily before modify them all. (working version)" It will be fully restored in finished version.

Some of your code (especailly from Rogerbacons's codes) have serious ambigulity on where the change ends. I have to see original code to know where the mod ends. I added BEGIN/END comment in such case.
And As I pointed out some of your comment hides original line.
Ex)
ORIGINAL CODE:
a = 1;
YOUR COMMENT:
// Original a = 1;
a = 2;
CHANGED:
/*// Original
a = 1;
*/
a = 2

Keeping original line intact is important for using diff. tools.
It is not my arbitray personal taste. It is universal manner of any developer who work in a team.
Your code is not your personal property once it is commited to team project. It should be public shared property.

About stripping white space : I also object to stripping trailing white space in source.
My rationale : Keep original source line as much as it was before as possible.
I am not sure that it was my fault or not. But if it turns out my fault. I will try to restore it back to original as much as possible.

The incressed AirUnit combat dosn't require any control because all existing air units were given 1 movment by Firaxis in addition to the code setting their movment to zero after a single mission. The player would need to change the XML values to see any effect.

']The incressed AirUnit combat dosn't require any control because all existing air units were given 1 movment by Firaxis in addition to the code setting their movment to zero after a single mission. The player would need to change the XML values to see any effect.
Movement value should not used for that.
It is generally used as distance of land unit movement, not number of times for attacking enemy units per turn.
Think of the case like some other moder uses "AirRange" XML attribute of land units (they are all zero for all land unit) to set number of times land unit can attack multiple enemy per turn. Is it proper usage of "AirRange" attribute?
Multiple targetting of air uit should have explicit XML attribute for that purpose.

It is a perhaps a bit sloppy, but it keeps the schema and file neat...

I dont consider it bad because its logical, Firaxais already makes use of flexible interpritation of the the Movment value based on the Domain, Air units dont "move" (just place one with WorldBuilder and you will see) they have "missions" instead. Its logical for them to get more missions with more movment points as these concepts are equivilent when applied to the Air Unit. RB made good use of an existing data member and XML atribute that were basicaly being wasted. The fact that no change occures untill values are moded means it conforms to our standards for inclusion.

Using AirRange for any purpose on a Domain Land unit would be confusing because it would lack a clear meaning like the AirUnit had. The destinction is significant so I must disagree with you on RB's mod whial agreeing with your example being a bad behavior.

On the Commerce Mod, what is the ETA on finishing the backward savegame compatability and reactivating these features?

Also I fail to see how /* */ commenting is superior to a // when your dealing with oneline changes (Big blocks ofcorse its better). When you diff the first you end up with 2 seperate line addition blocks rather then one alteration block, this would seem to me to be much more straitforward and easier to get at with WinMerge as it produces fewer diff blocks to scroll through and the chance of missing one is reduced. We all agree original code presevation is important and this is achived. Everything beyond that is personal taste, you yourself continue to ifdef everything despite being told by almost every other member of the project that it makes the code hard to read and is useless for a project of this nature.

']I dont consider it bad because its logical, Firaxais already makes use of flexible interpritation of the the Movment value based on the Domain, Air units dont "move" (just place one with WorldBuilder and you will see) they have "missions" instead. Its logical for them to get more missions with more movment points as these concepts are equivilent when applied to the Air Unit. RB made good use of an existing data member and XML atribute that were basicaly being wasted. The fact that no change occures untill values are moded means it conforms to our standards for inclusion.

Is there any other case when move value is used for denote targetting number? None. Other (flexible) interpretaion of move in other domain always related to diatance not number of times.
Your interpretation of move value as targetting number is arbitrary choice not logical choice. How about interpreting move value of air unit as "re-base" diatance range limit per turn? It seems more logical to me than number of attack.
']
Using AirRange for any purpose on a Domain Land unit would be confusing because it would lack a clear meaning like the AirUnit had. The destinction is significant so I must disagree with you on RB's mod whial agreeing with your example being a bad behavior.

I agree. It will confuse ther moder. Your interpretaion of move valus is confusing, too. move should be always interpreted as distance (number of plots/grid) not number of times. they has different unit.
']
On the Commerce Mod, what is the ETA on finishing the backward savegame compatability and reactivating these features?

Current version in CVS does not have backward savegame compatability and but the version is Commerce Mod enabled.
I will not upload to CVS version with backward savegame compatability only version (but the with Commerce Mod disable.)
To have both features enabled, it is not so simple job, it may take few days.
']
Also I fail to see how /* */ commenting is superior to a // when your dealing with oneline changes (Big blocks ofcorse its better). When you diff the first you end up with 2 seperate line addition blocks rather then one alteration block, this would seem to me to be much more straitforward and easier to get at with WinMerge as it produces fewer diff blocks to scroll through and the chance of missing one is reduced. We all agree original code presevation is important and this is achived. Everything beyond that is personal taste, you yourself continue to ifdef everything despite being told by almost every other member of the project that it makes the code hard to read and is useless for a project of this nature.
With your way of //Original ... original line..., orginal lines are hided and buried in modified block. I should intentionally parse the modified block to know what part is original. and what part is modified code.
If we keep original line as unmodified by line itself, WinMerge will automatically diffrentiates original part and mdified /added /deleted part visually. That is the purpose we use the tool, isn't it?

If #ifdef was such a useless tools that only degrades code readablility, why is it used so widly in other commercail/open-source project? Have you ever did regression test of your code without #ifdef?
It is valueable tool that makes code maintenance and testing much easier than not using it at all.

Right, so we'll update when commerce thingy and backward compatabilty are both working, ok?

I've uploaded my latest UU 4 leaders mod along with some Bug fixes and a Dll based Debugging feature (a simple print text to screen feature) from 12Monkeys that I had forgoten to merge in to the first release (I put it on the Extentions.cpp)

I fixed quatation mark on CvExtentions that was causing a compiler error it now reads
GC.setDefineSTRING("EXTDLL_BUILD, EXTDLL_BUILDER , EXTDLL_VERSION", __TIMESTAMP__ );

and removed a extra </TEXT> tag in one of SimCuties text.xml's that was causing a load error. Game compiled and ran well for me.

Am now experimenting with Dales Bombardment mod, trying to convert it to a method which dose not remove original style fortification reduction. I will most likly break it into 2 buttons one for "Reduction" (eqivilent to old Bombardment) and one for "Bombardment" (new ability active only if unit has new XML tag with none zero value.

']
I fixed quatation mark on CvExtentions that was causing a compiler error it now reads
GC.setDefineSTRING("EXTDLL_BUILD, EXTDLL_BUILDER , EXTDLL_VERSION", __TIMESTAMP__ );

This is not what I have intended. "EXTDLL_BUILD" is setDefineSTING () first argument, variable key(name). But EXTDLL_BUILDER , EXTDLL_VERSION is macro symbol defined as string constant.
Define EXTDLL_BUILDER , EXTDLL_VERSION as compile time symbol definition in compiler/preprocess option.
In compiler cbp file, EXTDLL_BUILDER=""Impaler[WrG]"", EXTDLL_VERSION=""161.1.012"".
You may / may not need two consecutive double-quotation, because one(1) double- quotation mark will be eat up by Windows DOS command shell.
This should be equivalent to #define EXTDLL_BUILDER "Impaler[WrG]" in C++ source code text.

Then EXTDLL_BUILDER "," EXTDLL_VERSION "," __TIMESTAMP__ is 5 sting constant (no comma between all string constants) will merged as single C++ sttring constant like "Impaler[WrG],161.1.012,Wed Jun 21 13:22:52 2006"
and used as second argument to GC.setDefineSTRING().
This is used as DLL build identification. and will be print in log file like line:
"DLL Build: SimCutie,161.1.016,Wed Jun 21 13:22:52 2006".

That wont compile the Funtion sees it as an excessive number of arguments
Perhaps this is what you wanted?

GC.setDefineSTRING(" 'EXTDLL_BUILD','EXTDLL_BUILDER','EXTDLL_VERSION' ", __TIMESTAMP__ );

Do you want us to change thouse Defines each time we compile a Binary for Commiting to the CVS?

PS - I am still getting the crash at clicking Play on Dawn of Man screen, am I correct in thinking the fix
for this is not uploaded yet but you do have a fix ready?

']That wont compile the Funtion sees it as an excessive number of arguments
Perhaps this is what you wanted?

GC.setDefineSTRING(" 'EXTDLL_BUILD','EXTDLL_BUILDER','EXTDLL_VERSION' ", __TIMESTAMP__ );

Do you want us to change thouse Defines each time we compile a Binary for Commiting to the CVS?

PS - I am still getting the crash at clicking Play on Dawn of Man screen, am I correct in thinking the fix
for this is not uploaded yet but you do have a fix ready?
No. this should be equivalent like..

#define EXTDLL_BUILDER "Impaler[WrG]"
#define EXTDLL_VERSION "161.1.xxx"

GC.setDefineSTRING("EXTDLL_BUILD", EXTDLL_BUILDER "," EXTDLL_VERSION "," __TIMESTAMP__ );

first arg is "EXTDLL_BUILD"
Second arg is EXTDLL_BUILDER "," EXTDLL_VERSION "," __TIMESTAMP__
It is single sting, not 3 argument. Two "," is string of a comma, not argument delimeter.

Accessing undefined GC.getDefineSTRING("<undefine>" ) may cause crash.

Can I submit a last minute entry?

I have added these two functions to the end of CvUnit.cpp. What they do is self explanitory.


CvUnit.cpp

//Returns the number of units carried by this unit
int CvUnit::getNumberUnitsCarry( const CvPlot* pPlot ) const
{
int iNumUnitsPlot;
int iNumUnitsCarry;
int iI;
CvUnit* pLoopUnit;

iNumUnitsPlot = pPlot->getNumUnits();
iNumUnitsCarry = 0;

for (iI = 0; iI < iNumUnitsPlot; iI++)
{
pLoopUnit = pPlot->getUnit(iI);

if (pLoopUnit->getTransportUnit() == this)
{
iNumUnitsCarry++;
}
}

return iNumUnitsCarry;
}

//Returns the unit occupying a slot by this unit.
//Slots are 0 indexed
CvUnit* CvUnit::getUnitCarry( const CvPlot* pPlot, int iSlot ) const
{
int iNumUnitsPlot;
int iNumUnitsCarry;
int iI;
CvUnit* pLoopUnit;

iNumUnitsPlot = pPlot->getNumUnits();
iNumUnitsCarry = 0;

for (iI = 0; iI < iNumUnitsPlot; iI++)
{
pLoopUnit = pPlot->getUnit(iI);
if( (pLoopUnit->getTransportUnit() == this ) )
{
if( iNumUnitsCarry == iSlot )
{
return pLoopUnit;
}
iNumUnitsCarry++;
}
}
return false;
}




CvUnit.h


public:

int getNumberUnitsCarry( const CvPlot* pPlot ) const;
CvUnit* getUnitCarry( const CvPlot* pPlot, int iSlot ) const;

Can I submit a last minute entry?

I have added these two functions to the end of CvUnit.cpp. What they do is self explanitory.
......

getNumberUnitsCarry function seems to duplicated functionarity with CvUnit::getCargo() which returns number of cargo unit the transport Unit is currently carrying. What is difference with CvUnit::getCargo() ?
What is meaning of pPlot argument? Is it same as CvUnit.getPlot()?
!2Monkey's code has similar function that loops through all cargo unit of the transport unit. I will try to merge your code with 12Mokeys code.

OK. I added a function that returns list of cargo unit for given transport unit.

CLinkList<IDInfo> *CvUnit::getCargoList();
Retuens NULL if no unit is carried on the unit.

CLinkList<IDInfo> *pCargoList = pUnit->getCargoList();

number of cargo units = pCargoList->getLength();
get first cargo -->
CvUnit *pUnit = ::getUnit(pCargoList->head());
loop through all cargo Unit of pTransportUnit-->


CLinkList<IDInfo> * pCargoList = pTransportUnit->getCargoList();
CLLNode<IDInfo>* pNode = pCargoList-> head();
CvUnit *pLoopUnit ;
while ( pNode != NULL && ( pLoopUnit = ::getUnit(pNode)) != NULL )
{
pLoopUnit -> ............ // do some thing on pLoopUnit
pNode = pCargoList-> next(pNode ); // step to next in list...
}



How about that?

That wont compile, its like I said too many arguments, I think

GC.setDefineSTRING(EXTDLL_BUILD," EXTDLL_BUILDER, EXTDLL_VERSION, __TIMESTAMP__ ");

But now I see EXTDLL_BUILD is undefined, did you compile the code that was originaly on the CVS because I had the original problem with the code strait off the CVS without any modifications. We should always make shure that code being commited will at the very least compile.

Lord Olleus: If these new functions are to be used by Python Moders they need to be exposed to the Python layer which is relativly simple to do but just takes a bit more work. Was the intent of the second function to iterate through all the units in a Plot which are cargo (regardless of how many different transports they are in) whial skiping the transports themselves? Or is it for iterating through the Cargo of a single transport vessel. In the former the function should be called from CvPlot, in the latter case I agree the Plot argument is unessay it can be found internaly. Also you cant return false from a function that has a Pointer return type, you want to return NULL.

']That wont compile, its like I said too many arguments, I think

GC.setDefineSTRING(EXTDLL_BUILD," EXTDLL_BUILDER, EXTDLL_VERSION, __TIMESTAMP__ ");

But now I see EXTDLL_BUILD is undefined, did you compile the code that was originaly on the CVS because I had the original problem with the code strait off the CVS without any modifications. We should always make shure that code being commited will at the very least compile.

Lord Olleus: If these new functions are to be used by Python Moders they need to be exposed to the Python layer which is relativly simple to do but just takes a bit more work. Was the intent of the second function to iterate through all the units in a Plot which are cargo (regardless of how many different transports they are in) whial skiping the transports themselves? Or is it for iterating through the Cargo of a single transport vessel. In the former the function should be called from CvPlot, in the latter case I agree the Plot argument is unessay it can be found internaly. Also you cant return false from a function that has a Pointer return type, you want to return NULL.

Not EXTDLL_BUILD, but "EXTDLL_BUILD", this is string constant like "hello, world"

and 2nd argument is
WRONG: " EXTDLL_BUILDER, EXTDLL_VERSION, __TIMESTAMP__ "
RIGHT: EXTDLL_BUILDER "," EXTDLL_VERSION "," __TIMESTAMP__

Pay attention to every double quotaion and comma and white space.

ALL combinde should be.

GC.setDefineSTRING <LEFT-PARENSIS> <DOUBLE_QUOTE>EXTDLL_BUILD<DOUBLE_QUOTE> <COMMA> EXTDLL_BUILDER<SPACE><DOUBLE-QUOTE><COMMA><DOUBLE-QUOTE><SPACE> EXTDLL_VERSION<SPACE><DOUBLE-QUOTE><COMMA><DOUBLE-QUOTE><SPACE> __TIMESTAMP__<RIGHT_PARENSIS><SEMI-COLON><NEWLINE>

AND define EXTDLL_BUILDER and EXTDLL_VERSION as C++ STRING CONSTANT. ( "HELLO_WORLD", not HELLO_WORLD )

Use command line option -D or project property to define compile time preprocessor symbol. the symbol value should be string constant.
like -DEXTDLL_BUILDER=""Impaler""

You may need TWO CONSECUTIVE double quoation to define C++ string constant in DOS comamnd shell or project option.

Don't edit or modify
GC.setDefineSTRING("EXTDLL_BUILD", EXTDLL_BUILDER "," EXTDLL_VERSION "," __TIMESTAMP__ );
line. It has correct syntax. Edit compiler options/preporcessor symbol defintion part that looks like..

WIN32
NDEBUG
_WINDOWS
_USRDLL
CVGAMECOREDLL_EXPORTS
EXTDLL_BUILDER=""SimCutie"" <=== Edit This.
EXTDLL_VERSION=""161.1.016"" <=== This, too

Experiment with one double quotaion ("SimCutie"), two double quotaion (""SimCutie""), or <back-slash><doubel-quotation> (\"SimCutie\")
or <single-quote><double-quote>SimCutie<doubele-quote><single-quote> ('"SimCutie"') dependnding comand shell and IDE you are using. avoid special charter like * or [] in symbol value, that may be significant to command shell.

getNumberUnitsCarry function seems to duplicated functionarity with CvUnit::getCargo() which returns number of cargo unit the transport Unit is currently carrying. What is difference with CvUnit::getCargo() ?
What is meaning of pPlot argument? Is it same as CvUnit.getPlot()?
!2Monkey's code has similar function that loops through all cargo unit of the transport unit. I will try to merge your code with 12Mokeys code.

There is a ::getCargo() function? I spent ages looking for it. In this case my code is useless. The pPlot argument is there because it was easier for me to have it there for my particular mod.

Olleus: Always keep to the lowest number of arguments possible, any data that can be querried from the object internaly should be (it also avoids any possibility of an incorrect argument). Even if its easier in one mod (which is rather hard to imagine, perhaps your making use of a python argslist that already included the plot?) It might be harder for someone else in the future.

SimCutie: Ok I'll just ignore this piece of code for now, get it working how ever you like but please see that the project compiles for everyone else. Please add what ever configuring is needed in the .cbp file (I assume thats ware it goes as I have never heard of what your talking about) so we wont have this problem again.

Also is their any update for the freeze/coredump at Dawn of Man? I can run DLL only and dont experence any freezing (good work on eliminating the "You have been defeated" thing) so I belive its someware in your Python code. As I said the freezeing is intermitent and caused by rapid clicking of the Play Game button on DoM screen. Their may still be some code thats not loaded yet or its somehow crashing the game. Have you experienced this bug yet? Do you want me to upload a CoreDump?

We realy want to get this stabalized for the Mulitplayer game 12Monkeys is hosting and we also want to get that second release made this weekend. I wont be making any more Commits for this second release so if you can stablize the DoM screen I think we would have more then enough for another release. If backsavegame compatibility is not yet working then we should reactivate the Commerce Mod so as not to loss any features from the previous release.