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 a