Right, now the first one is pretty much locked to additions I'd thought I'd start of a thread for the second one.

I'd quite like to have from everybody who is thinking of contributing a general list of planned changes. It doesn't have to be very detailed - a brief outline with justification will probably do.

This will allow us to discuss options for implementation, as well as spot any possible conflicts as early as possible. Also, if anybody takes objection to what you are doing, then this can be discussed before you go and code the whole thing.

Next release will probably be late June/early July, depending on how things are going. It'll almost certainly be the last one before Warlords comes out.

Given that I may actually be able to get something done for this (I get home ~ 24th) here is my list of proposed changes:


TGA's Proposed Changes:

Attempt to build an AI testing rig so that multiple AI vs AI games can take place with no user interaction, with their performance logged.
Work on the City AI, both altering the way the governor works, and improving the AI city calculations. This will be tested to ensure that it is acutally improved using the above testing method.
Tweak CvMap::plot(...) to take X and Y wrapping into account
Improve CvCityAI::AI_neededDefenders() - reducing the number if the city is well within your borders. Also increasing the number of needed defenders based on a function to determine how likely an attack will be. It is currently based mainly on the city size.
Implement some rudementary "rush spotting" code to make the AI perform better against early attacks.
Add Teg_Navanis' Unit Statistics mod

My goals for next release:

Universal Building Modifer: likly my most ambitious mod so far, it will alow building effects to be modified by Civics, Wonders and Techs (in reality anything can easily be made to plug into it once it works). My plan is to operate it by means of a virtual building piggybacking on a real building. It will should be easily configureble in XML so anyone with half a brain can use it. I see LOTS of mod potential here for remakes of the Oracles "Double the effects of all Temples" and such.

Backward Compatability: Seeing as of how everyone is so hellbent on backward compatability I am likly going to need to make any future changes backwardcompatable. If SimCutie (who seems to be the expert on this) or anyone else can create a boolean call that will tell us the CCP version durring reading then I would be more then willing to go back and update all my current content with it.

GameOptions Menu: I see Dale is working on getting this fixed for us (thanks Dale!) but if he should prove unsuccesfull I would want to continue that effort and do what ever digger may be required to make it work.

Missilanious Improvments: What ever strikes my fancy, I read people ideas on the Forum and often get inspired by them.

P.S. I just did a little mod to improvements to allow them require another improvment as pre-requisite. I can throw this in version 1 along with by bug fixes, RogerBacaons Flying and Chalids slow Borders once SF is don with initial merging. By the way I already merged 12monkeys content with myown but haven't been able to compile SimCuities changes, it seems he is adding a whole lot of compiler stuff and I am getting a weird error that complains about a MicrosoftVisualStudio excpt.h file. Have never experienced it before.

My goals are ...

... still quite undefined ;). Just a very few things right now :

1.) a small change in the religions. I would like to make some religion founding a bit more restrictive, so that a player can found only a certain amount of religions.

2.) continue to improve the Ptyhon API where it is of use. Still one of my major targets in this project.

3.) Mergeing other mods into our project. Maybe scanning a list of the most popular SDk mods and merge them. If anybody wants to make proposals, please do so.

12m

My goals for this project:

1. Game options from the setup screen.
2. Investigate the potential for tri-party agreements.
3. Of course, continue with the combat mod cleaning out the last two bugs in stack attack, adding Select-A-Tile (Tm) to field bombardment, MAD (pre-targetting of nukes for auto-response on nuke attack), and adding a new mission for fighter escorts.

Sorry, my times limited by other stuff I'm doing with Firaxis. :)

Dale

My goals for next release:

1) Add new XML attributes for shrines (I want them to produce commerce, not gold)

2) Add new air misssion 'Air supperiority'. Fighter goes over to a particular square and tries to engage with enemy interceptors with a 50% chacnce of winning

3) Add promotions for air units.

LO:

Do you mean a mission for fighters where they'll engage anyone in range automatically? Or is it a "move there and intercept" manual mission?

The second one. You tell a unit to go to a particular square and it will fight with any interceptor which comes to attack it.
I have alread begun work on it. See here http://forums.civfanatics.com/showthread.php?t=172893

2.) continue to improve the Ptyhon API where it is of use. Still one of my major targets in this project.

Hmmm - I might as Locutus if we can use the script he uses to generate his API. Would certianly make the whole documentation easier.

There's a script which generates a file used for understanding scripts? Am I the only one which finds this slightly ironic?

Do you mean setting PythonHelp=1 in pyMain?

Yeah - something like that. However, locutus has this cunning way of making it into a funky webpage. I'm not sure how much he does by hand, but it doesn't seem to be that much.

http://civilization4.net/files/modding/PythonAPI_v160/

Ahhhhh yeah. He wrote that quite a while ago. Probably best to ask him about it. I didn't have anything to do with that one.

How about the Area Enterence/Exit or proximity/squre collison detection event?
For example, a certain event will be triggered when Unit move into city or go out of city or some square area, or Unit come to some proximity of other unit. This is alread done in original to alert player that enemy unit is approaching to their city and becomae menance of the Civ.
The location can be
1) Just one Plot Point like City or single improvement.
2) Staic square area like Area of Control for city or fort.
3) Moving squre area or point like proximity of Units

This can be implemented in Python with move or setXY event but it involves lots of overhead in Python. Instead, SDK will check collisiion of squares and event is tiggered only when there is some collision among the srqures, then Python event handler can check more detailed condition for real action.
It will drmatically reduce number of instance when Python check function should be invoked to check the proximity or enter/leave condition.

I am thinking about what kind of event model is suitable for notification.
Model 1 - Enter /leave model.
Event will be triggered only when the unit is come into and go out of the squre.
Model 2 - Area proximity model.
Event will be triggered in every turn when the unit remains inside of the squre area.
Or instead, We can provide some function which list all the relation incidence (point.point) (Point , squre), (Squre, Squre) which satisfies proximity/collision condition.

I'm not sure Model 1 would be neccessary - it would be very simple to check in python each move, and the check would be very quick to perform.

Model 2 sounds interesting, but how would you define which areas you were concerned about proximity around? Surely you'd have to trigger the event too all objects which are in proximity to all other objects... won't that get rather messy?

An addition by me - if no news arrives about diplmacy I'm planning on writing a python script for it which would overwrite all the default links the the diploacy screen, and redirect them to a python controlled interface. This should allow us to add new diplomacy options as well.

EDIT: Oh, and while I'm about it, just a general note asking people to keep their section on the "Mods in progress" thread updated - keeps the same work from being done twice.

TGA:

The base diplomacy/deal screen is in the exe. We've only got access to small parts of it.

The code for it is very very ugly. ;)

Dale

Can't we even set deals active/inactive? This would be all I think I'd need.

Can't we even set deals active/inactive? This would be all I think I'd need.

You can have some influence with CvPalyer::canTradeItem and ::canContact. Just have a look in there to check the possibilities.

12m

How is everybody doing with this? Personally, I still haven't started, but am home again in 4/5 days, and will get cracking then.

The first release overran by quite a lot, and is likely to be updated soon with a few fixes. Hopefully we can get this one out in the 1st/2nd week of July.

If were not releasing right now then lets aim for this coming weekend for the next release, dose that sound do-able. I have the UniqueUnits for Leaders mod up and running, it just needs a little Pedia Polish and to be incorporate the backward savegame compatability into it so its their right from the point it gets merged in, these can be ready by then. If SimCutie isn't able to adress the Commerce Mods savegame compatability I will try tackling that as well.

We should look for some outside mods to include, I would like to get some of Lopez's mods included, the Water animals is an XML controled mod. Dales missle mod is XML controled and shouldn't be hard to include. The rest of his very ambitious Combat mod still dose not sound stable enough to include at this point (it will also need to be extensivly re-worked to make it an option so 3rd release at the earliest).

Well I was thinking the backwards-compatabilty would be release #1.5 or something :p. We do that this weekend, and then this some time in the first half of July.

Considering the instability of the first release and the fact that the code in the CVS server at least plays a game without crashing. I think we need to at least release a less buggy version for the public to work with.

I will release it next weekend so get any STABLE code changes in by then with a readable changelog. This mean no more separate changelogs. I will set up a log guide so we have a set format one how to document committed changes.

I think that we should concentrate our effort/objective to "help other moder to write better mod" with our next release DLL rather than include various individual mod to DLL.
I.e. new feature should be useful to implemenent at least more than one other mod rather than implements the mod feature ourself and include it in DLL.
That means that we should generalized feature so that it can be used by various other mod.
Rather than implementing "XXX-trait" ourselves, we should provide general and generic mechanism and components which is useful to add or implement any general leader traits.

We are not targetting "big combined mod DLL", but "better common platform DLL" for mod writing.
12Monkey's Ehhanced game utils and Impaler's suggested plan about multiple XML loading should have been good example.
Even when we include some feature that can be considered to be mod of its own right, we should include only the improvement that will be welcomed and utilized by most of the players, especially enhancement that does not affects game play itself ( like "unaltered game play mod".)

I though we were going to be ready this weekend? If the current CVS is running smoth lets go for it, shurly the documentation can be wiped up quickly by pasting together our current changelogs?

EDIT: ok never mind the current CVS is generating a C++ exception when I try to view Civs under the Civilopedia and a crash from the darn Custom Button at DoM (fixing that should have been the priority NOT backward savegame compatability)

SimCutie I agree that we want a platform for better mod making but we will also need to include new features as well, end users dont realy care about "improved platform" stuff they want features and will shun our Dll is it dosn't have the cool new features they like. For example I am working with Dale's Field Artilery to make it project compliant, I know I want to play with it and probably so do a lot of people.

My philosophy is put in all the hooks we can, and have seperate downloads of Mods which actualy use the hooks. Thats what I did with the LeaderTraits, their are 4 new XML hooks for Traits anyone can use and I have a Mod that uses them as well.

About the XML loading, I mentioned earlier that the ModSwitcher program (if you havent checked it out please do so its incredible) basicaly achives the same thing but is even more efficient and flexible its makes thouse changes unessary so I wont duplicate effort their.

P.S. SimCutie I don't realy like the change to the Smiley face Icon can you switch it back, that set of Icons you added probably should have been a seperate download.

The Python exception at DOM

']
EDIT: ok never mind the current CVS is generating a C++ exception when I try to view Civs under the Civilopedia and a crash from the darn Custom Button at DoM (fixing that should have been the priority NOT backward savegame compatability)
Is Custom Button at DoM error not yet fixed? strange...
I can not reproduce the error however fast I click the button on start up.
Tell me little more about that..
Error on View Civs under the Civilopedia seems to be fixed.
']
SimCutie I agree that we want a platform for better mod making but we will also need to include new features as well, end users dont realy care about "improved platform" stuff they want features and will shun our Dll is it dosn't have the cool new features they like. For example I am working with Dale's Field Artilery to make it project compliant, I know I want to play with it and probably so do a lot of people.
No. our main client/audiance should be moders, not general player.
Our DLL should appeal to moder and let the moders make attractive mod to player using our DLL. Our success depends on how many moder we can attract, not how many player we can attract. By helping moders to write better mod using our DLL or let them adopt our DLL for their mod, DLL will be used widly by more players.
If our DLL become just big combined moded DLL like sevo combined mod, it is not welcomed by other modder. We should make DLL more mod component like SD-Tools, not sevo mod or Fall from the heaven mod.
']
My philosophy is put in all the hooks we can, and have seperate downloads of Mods which actualy use the hooks. Thats what I did with the LeaderTraits, their are 4 new XML hooks for Traits anyone can use and I have a Mod that uses them as well.
Good. But can the codes for your mod be used to implement other similar trait mod by other moder? I guess not. Your code are not general enough for that. It will be of little interest to other modder except for demonstration.
Including such thing for some demonstaration or adding attraction would be nice, but it should be kept minimum. Adding more mod to DLL should not be our objective. We should refrain from it and concentrate our effort to enhancing more general modability of DLL.

Originally Posted by SimCutie
No. our main client/audiance should be moders, not general player.
Our DLL should appeal to moder and let the moders make attractive mod to player using our DLL. Our success depends on how many moder we can attract, not how many player we can attract. By helping moders to write better modder or let them adopt our DLL for their mod, DLL will be used widly by more players.
If our DLL become just big combined moded DLL like sevo combined mod, it is not wellecomed by other modder. We should make DLL more mod component like SD-Tools, not sevo mod or Fall from the heaven mod.
I have to agree with SimCutie on this point. The project originally started out as a way to help other modders have more options within python and XML to do what they wanted without having to dive into the SDK. The idea was that if the dll was installed on its own, there would be no effect on gameplay, and only some UI changes that would make either more information available (like the unit stats) or easier to read (military advisor mod). While the new features such as the new specialists, leader traits, and action buttons are very good for their own mod, they really don't fit the reason for the project. Our goal is to add features that do NOT affect anything untill they are activated by python, XML, or an ini file.

We can easily start a new project whose goal is mod compilation, but I think we need to stear this project back on track to the original purpose. While it won't be nearly as easy as just compiling previously made mods, in the end I think it would be much more popular and widespread because it help modders create there ideas without worrying about what is in the code and thus more players will use it because it is included in more mods.

In effect we are targeting both audiences, but we just have our priorities backwards.

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

On a side note, The new buttons added to the main UI don't work well. One is missing the artwork and another is changing the commands of the other buttons behind it (the one with the star). I put all our files in a mod folder with its own ini.

I also rebuilt a new dll with the latest changes and I get a CTD when I click the play game button on the DoM screen for a new game even when it says play game.

We need to get this release stable right away. I now have some time so I can start helping and will begin by trying to fix this problem.

Actualy the hooks I added to Traits are rather flexible, anyone could use them to modify Happyness, FreeSpecialists, UN. Votes and Diplomacy bonuses. I even made Happyness and Diplomacy compatable with negative values even though my mod used only positive values. Firaxis themselves will be adding a Charismatic Trait almost identical too my own in Warlords. XML hooks have to do something specific and these were the ones I wanted to make. I might next create ones for

WarWeariness Modifier
Military Production Modifier
Combat Experience Modifier

I have plans to create a new Trait using thouse ofcorse but the XML could be used by anyone after that.


This project has been rather free-form so far each of us working on what we thought was usefull and so long as we obey the "no changes without explicit activation" rule we have done as we pleased. I dont ever intend to go against that principle, any outside Feature like SDK mode I incorporated would use somekind of activation probably in XML. XML hooks have become my specialty and I would like to keep doing them, I'm not realy big on the Python layer so I leave that to 12Monkeys and SimCutie who prefer to work their. You may feel the focus of the project is their but certanly you dont disaprove of the additions I have made? At worst no-one will use them and I will have only made a mod that I like to play (but so far we are getting some possitive feedback on these things).

I agree with Impaler. There is no reason why we shouldn't be quite diverse, as long as we keep within the basic guidelines.

When I made the first post I had intended this mod to be a mod for those who don't normally use mods. A bit like an unofficial patch, with improvements which very few will not agree are improvements. Modding improvements are a part of this, however other things definately have a place.

']Actualy the hooks I added to Traits are rather flexible, anyone could use them to modify Happyness, FreeSpecialists, UN. Votes and Diplomacy bonuses. I even made Happyness and Diplomacy compatable with negative values even though my mod used only positive values. Firaxis themselves will be adding a Charismatic Trait almost identical too my own in Warlords. XML hooks have to do something specific and these were the ones I wanted to make. I might next create ones for

WarWeariness Modifier
Military Production Modifier
Combat Experience Modifier

I have plans to create a new Trait using thouse ofcorse but the XML could be used by anyone after that.


This project has been rather free-form so far each of us working on what we thought was usefull and so long as we obey the "no changes without explicit activation" rule we have done as we pleased.

I dont ever intend to go against that principle, any outside Feature like SDK mode I incorporated would use somekind of activation probably in XML. XML hooks have become my specialty and I would like to keep doing them, I'm not realy big on the Python layer so I leave that to 12Monkeys and SimCutie who prefer to work their. You may feel the focus of the project is their but certanly you dont disaprove of the additions I have made? At worst no-one will use them and I will have only made a mod that I like to play (but so far we are getting some possitive feedback on these things).
Adding new trait is not much problem. But if you do it, it should be implemented in more or less generic way.
Your code can not be utilized by other mod, python mod or SDK mod.
It does not add much value to modability of project DLL. Each feature does not have much relation to other mod included.
It would be much useful if you add general way to add XML addtibute to leader and generic method to add hapiness or vote to civ.

Even if the mods in question are XML controlled, it should not be excuse for making DLL just yet another combined mod DLL. Why do we such job as a collective project? If we plan to make our project as all-inclusive kitchen sink combined mod, we don't have to do it as collective project. Personal project by lonely developer would be enough for that. It does not need team. I advice you to start new separate "mega-feature-kichken-sink DLL" project.

I object adding random mod to DLL because it looks neat to have as long as it does not contributes to enhancing modability and usefulness to moder. Our main objective is not creating mod's of its own right.

The mods in question are XML controlled should not be excuse for making DLL just yet another combined mod DLL. Why do we such job as a collective project? If we plan to make our project as all-inclusive kitchen sink combined mod, we don't have to do it as collective peoject. Personal project by lonely developer can do that. It does not need team.I presume you're talking about the example mods he included, not the additional XML tags. It seems to me that having example files of the tags in use is useful, as it allows modders to work from an example. It's also a separate modcomp that can be used as well.

I think mods such as the unit stats mod are fine for inclusion - while they clutter up the .dll slightly, they are good mods, which are independant, and generally useful. If somebody wants to use the unit stats and something else, this would allow them to. This is good.

I presume you're talking about the example mods he included, not the additional XML tags. It seems to me that having example files of the tags in use is useful, as it allows modders to work from an example. It's also a separate modcomp that can be used as well.

I think mods such as the unit stats mod are fine for inclusion - while they clutter up the .dll slightly, they are good mods, which are independant, and generally useful. If somebody wants to use the unit stats and something else, this would allow them to. This is good.

No, no.. If it is real example, the more, the better. Then the example should serve as just as example, not integral part of project.

I pointed out that the implementaion of the feature is so rigid and limited that it is useless other than using "example" mod. Except for the "example" mod, the feature is nealy useless for other mod/moder/player. I did not mean that
the "example" mod is useless or not to players.

Lets clarify our main objective. Is it making big combined feature-rich mod DLL or providing common platform DLL for moder?

Adding Unit stat or any mod would be no problem if the hook added fot it can be utilized productively by other mod as well.

I would like to stress "the hook". DLL itself doe not implements unit stat mod. it just provides "hooks" or "mecahnism" needed for collecting data for the unit stat mod.

I guess that the unit stat mod has such feature. The hook and the statstic data collected for the unit stat mod can be utilized by other mod as well. It is hook is geneic enough to be utilized by other mod and they are not dependent on just the unit stat mod. It will add modability enhancement to our DLL.

He's adding generic tags, and then doing mods which use them. I really can't see the problem :confused:
Is it making big combined feature-rich mod DLL or providing common platform DLL for moder?Are these mutually exclusive? Can't we do both? All the features will be optional.

He's adding generic tags, and then doing mods which use them. I really can't see the problem :confused:
Are these mutually exclusive? Can't we do both? All the features will be optional.
If it was implemented that way, I wouldn't have pointed out from the start.
The implementaion is fixed to use specific tag and perform specific function. It is not parameterized or generalized.
Can we use the current implemenation to implement other new trait like "protective" trait or "Imperilistic" trait of the Warlord expansion? It seems not so to me.
So it is not generic at all.

As I said, if it it is our objective to make mega-feature DLL with all bell and whistle and kitchen sink.
We don't have to work in a team. Merging code patch from others SDK mod won't need any discussion or colleraborative work except resolving code line clash preblem. Isn't it?

The implementaion is fixed to use specific tag and perform specific function. It is not parameterized or generalized.

How could I add tags with out giving them a specific action/effect in the game? Perhaps your thinking of having data which is functionless at the C++ level and is just used for export to Python ware it gets used for what ever each indiviudal moder wants? I basicaly try to copy the Firaxis methodology (datamember, InfoClass read/write of the Tag, Schema with the Tag optional, code to effect the change, and Python export of data).

Your code can not be utilized by other mod, python mod or SDK mod.
It does not add much value to modability of project DLL. Each feature does not have much relation to other mod included.
It would be much useful if you add general way to add XML addtibute to leader and generic method to add hapiness or vote to civ.

I admit some of the Trait mod stuff was "crude" at the code level because they were my first mods and in hindsight I probably should have created some new datamembers at player level which would hold the bonus for most of the new parameter and have better functions for altering them. Diplomacy is currently using a direct querry of the players Traits. I was thinking of adding more hooks for Votes and Diplomacy so buildings and Civics could affect it as well.

As I said, if it it is our objective to make mega-feature DLL with all bell and whistle and kitchen sink.
We don't have to work in a team. Merging code patch from others SDK mod won't need any discussion or colleraborative work except resolving code line clash preblem. Isn't it?

That alone is enough of a reason for us to be colaborating, were having stability problems as it is, I cant imagine how bad it would be if we all worked apart? Their are always going to be quality SDK mods made outside our project and incorporating them avoids fragmentation but even these mods need to have somone making shure nothing is broken when their added, outside programers arn't going to help us do that so any outside work we incorporate still constitutes a significant effort (though we do need to push for more people to write their mods onto our code base rather then the Virgin SDK and to assist in the merging process, we will likly have to reach a high degree of popularity before people start doing this of their own accord)

I do support the kitchen sink aproatch, I see the projects goal as avoiding Dll fragmentation, just as their are countless "tradional" non-SDK based mods out their and people are forced to spend huge sums of time merging them by hand we will run into the same problem with SDK based mods and people will be forced to choose between a DLL with feature A, B and C and one with Feature X, Y and Z. Mod makers dont want to be forced to make thouse kinds of hard desisions. And unlike traditional mods most people would'nt ever have any hope of combining these things on their own so we in essense create the Mega Mod DLL with all the bells and whistle included but turned off.

Latest CVS has the crash and C++ exceptions fixed but we now have a memory leak, the game gradualy slows down for me untill turn processing takes 5 minutes or more. When I opened the Task Manager Civ4 was using more then a Gig of Memory. And when I did exit the Process under TM wouldn't go away untill I manualy killed it at which point I got the memory back and could reopen Civ4 reload my very same game and have it playable again for an hour or two before it bogged down.

Perhaps this has something to do with the Python calls 12Monkeys did, the Python layer might be holding onto pointers that it shouldn't (Firaxis has a bunch of comments about not leting that happen so its my best guess). But I had not experienced this before (though maybe I hadn't played long enough to see it) so I we should look at the previous versions of the DLL and establish adsactly when it starts. Can someone else confirm my diagnosis?

Also I see that the behavior change to the Python GetCivilizationUnits call was returned to its original state, SimCutie did you realize thats nessary for the Leader Units mod to display correctly on the UI (without it the city build buttons for the whole class of Units wont apear and the Tech advisor dosn't show modified Units, though the UU dose show up on the "what to build next popup"), If your concerned about changing the logic of the Python calls and getting moders confused then the alternative would be to mod the MainScreen.py and TechScreen.py and substitute a new call for the old one. Thats probaly the cleaner/safer solution but it makes the Mod dependent on the Python UI layer which I would otherwise like to avoid. What do the rest of yall think?

']
Also I see that the behavior change to the Python GetCivilizationUnits call was returned to its original state, SimCutie did you realize thats nessary for the Leader Units mod to display correctly on the UI (without it the city build buttons for the whole class of Units wont apear and the Tech advisor dosn't show modified Units, though the UU dose show up on the "what to build next popup"), If your concerned about changing the logic of the Python calls and getting moders confused then the alternative would be to mod the MainScreen.py and TechScreen.py and substitute a new call for the old one. Thats probaly the cleaner/safer solution but it makes the Mod dependent on the Python UI layer which I would otherwise like to avoid. What do the rest of yall think?
It is conceptually flawed. The UU belongs to a Civ, not leaders.
Pedia screen should have separete entry for Leader specific UU.
When Civilopedia screen is invoked from main game menu,
no player or leader is selected for each Civ.
So leader UU can't be displayed in Civilopedia instead of Civ specifc UU.
That was cause of C++ error.
It is better to leave Civ specific UU as it is now
and modify Leader screen to have new pane for Leader specfic UUs
And use new Python API for getting leader specific UU
When you changed behavior of existing stock API,
It should behave like old API in default /trivial case.

Ah I see, my bad. Yes then it will be nessary to do it the other way.

On the Pedia I dont think its nessary to have a whole page just for Leader UU, rather when viewing the Units they will say

"Unique unit for LEADER_NAME"
"Replaces UNIT_CLASS"

just as they currently do for Civs, I already have that working. In addition I would like to get the units listed as hyplinks in the little box that tells the Leaders Traits and when you do the little mouse over popups but havent managed that yet. That should give one a clear indication of what the UU are.

Oh also that line of code for the EXTBUILDER thing is still not compiling, please get that fixed, I had to just coment it out when I compiled.

Can you reproduce the memmory leak I described?

Have you guys considered starting a public thread where modmakers can request addtions that would allow them functionality without changing the core game?

I thought we already had two public threads. The release thread and the original one started by TGA.

Guys,

I feel it's very important with a project like this, that if we add new outside mods that it is very easy to disable from outside the DLL. One optional xml tag, a config file (we could write a frontend for it to change the default options), or whatever.

For example:
My missiles code relies simply on a unit having an xml tag. If and only if that tag is present will the code run. All other situations cause the normal vanilla behaviour. Thus anyone can mod a unit to be a missile. Don't need to be a coding genius. Quite a few people with no coding/moding experience are using missiles now that they created themselves.

Dale

Is anyone else experiencing that Memory leak or have any idea what might be causing it?

I will be fixing up the UU mod with the modified Python and possibly including some other small XML mods. Can we aim for a release this coming weekend?

Thats what I was planning to do. I will release a new package this Saturday, so get your changes ready and load them up before Saturday evening.

Let me know if there are any new files I need to add to the base package (not the example mods).

UN Vote seems to be broken. All zero votes..
Please test it to confirm that it is reproducible error or not.

Why we should not take "big-combined kitchen-sink DLL approach"?
It is matter of resource.
Yes, Firaxis or any one could have various "nice-to-have" features added to DLL. But many of them are not welcomed by or not utilized by most game player.
Even vanilla Firaxis Civ4 is quite a resource hog that many not-so-top-calss machine has hard time to run it smoothly, especially machine with 512M RAM. Many player already complains on Civ4 for late game slow down and excessive memory usage even with 3.0GHz CPU and 1G RAM machine and suspects memory leak.

So we , and other MODer, must very careful when adding burden to memory.
Code memory size is nothing. Adding few 100K bytes of code will not make big difference in memory foot print.
But data member addition or array expansion is different. For example, adding arrayfor class member or new commerce type or yield type has quite large impact on each class and each instance.
Adding few mod will not make big difference. But if we take "kitchen-sink approach", it will become larger and larger as we adds more and more mods to project and bloat like rollling snow ball and take a big byte on size of memory working set. The size increment may not be make or break difference but it can be last straw to some players.
Extra CPU time for handling new MOD would be highly dependant on nature of the MOD. But we also must be careful not to burden CPU, expecailly in turn time.
As DLL become heavier, more and more player and modder will show cold shoulder to our project becauase our project DLL is too big and slow.
So we must maintain skinny, lean and mean DLL for COMMON platform.
Common DLL shoud be minimum common denominator for most of players.
This is why we should keep DLL as lean as possible. We should keep extra keen eye on resource usage of our project. We must always weigh benefits of MOD for general players and extra resource it uses.

This is why we should not take kitchen-sink approach.
If we add particular MOD to project, the mod should be general enough and should be welcomed and can be utilized by most players so that it can justify extra resource it uses.
Just adding XML attribute or switch to turn off the the feature is far from enough.

UNVotes: Though I had fixed that, will double check it

I have found that the DLL currently on the CVS is running and leaking BUT it is NOT the DLL you get from compiling current files! When I compile current files the resulting DLL is a MB larger :confused: and unstable and will imediatly freeze/coredump when pressing continue from DoM (all other Assets the same). If I play DLL only its stable, so Python interaction is the problem. I will try to see if it also leaks memory with DLL only.

I ofcorse disagree that we are coming anyware near a CPU usage issue, most especialy one caused by XML style additions. Warlords might even have higher system requirements then current game and Mores law is on our side. At the present rate of Moding we wont have any problems.

Memory leak is the same with DLL only run, by watching the Task Manager I can see the memory consumption go up each time I hit End turn, a large game will consume 50-100MB of additional memory every turn so its more acurate to say we are Hemraging memory.

It probably is a new or modified function that is not releasing its calls once it is done with is. Are you shure all the destructors are in place and releases the memory block when it is done?

Also we need to get the source code stable so I can compile all the new changes, the old DLL does us and me no good cause its too old.

I've been running the DLL whial watching memory trying to see if their was a pattern, all I can say is that in the early game memory consumtion goes up almost every turn often a small amount like 50KB sometimes lots more. Occasionaly it dosn't go up at all, it always goes up durring combat.

If one of the game objects wasn't releasing its memory then we would expect memmory to stay high when a unit/city ect dies and is deleated but were seeing memory go up just from doing nothing so I suspect its a python call not releasing a pointer. What do SimCutie and 12Monkeys think? Its going to be up to yall to fix these issues if their in the Python (the crash at DoM definatly is), the memory issue is still a mystery to me.

And SimCutie, stop making non-substantive changes to my code to satisfy your personal tastes in how to coment out a line of code, you need to stop being so anal about other people work and start bug fixing your own code which has never been anyware near stable. Do you do any testing before you commit these changes? We have seen code that wont compile and DLL's that imediatly crash when played being commited. I am not perfect myself but I feel I have keep it reasonable and have made shure I atleast dont make the DLL unplayable. I think we should go back to individual developer braches so these instabilites dont bring the whole project to a screeching halt.

']I've been running the DLL whial watching memory trying to see if their was a pattern, all I can say is that in the early game memory consumtion goes up almost every turn often a small amount like 50KB sometimes lots more. Occasionaly it dosn't go up at all, it always goes up durring combat..
<.....>

Memory consumtion on end turn itself is not problem. Original DLL also consumes memory at end turn. What is important is the amount of consumtion. Please test with same save file with both DLL (original /Project)
If difference is big enough, it may be sign of problem.
']
And SimCutie, stop making non-substantive changes to my code to satisfy your personal tastes in how to coment out a line of code

It is NOT non-substantive change.
You are not understanding how CVS update/merge work. If you does not preserve original line same as original, CVS update can not find orginal line and think the line is deleted and fails to automatically merge changes from multiple developer. other developer should manually merge the changed line. It failes purpose of CVS. I will not care your commenting style as long as
1) Original line should be preserved as it was. No change by line itself.
2) Each insert/change block should be marked clearly with START.. END
so that identfiable without parsing C++ block syntax.
3) Each change/addition should have no ambiguity where the change ends.

These are imortant substantive matter that can't and should not compromised.
']
you need to stop being so anal about other people work and start bug fixing your own code which has never been anyware near stable. Do you do any testing before you commit these changes? We have seen code that wont compile and DLL's that imediatly crash when played being commited. I am not perfect myself but I feel I have keep it reasonable and have made shure I atleast dont make the DLL unplayable. I think we should go back to individual developer braches so these instabilites dont bring the whole project to a screeching halt.
Compiler failure is your personal problem. how can I do development if it would not compile. You didn't understand how preprocessor symbol work. Read C++ manual on preprocessor symbol.
Instability? I can finish game from start to end without hitch with my code ( except UN vote mentioned above).
Your code seems not tested in debugging mode. It fails on some debugging assert statement. I fixed them all and put these change into the CVS. But you overrided/ignored the change and backed to your buggy code. I guess that you CVS update failed to merge changes from my code. ( due to missing "original line" ). This illustrates why we should preserve original line for CVS merge.

']How could I add tags with out giving them a specific action/effect in the game? Perhaps your thinking of having data which is functionless at the C++ level and is just used for export to Python ware it gets used for what ever each indiviudal moder wants? I basicaly try to copy the Firaxis methodology (datamember, InfoClass read/write of the Tag, Schema with the Tag optional, code to effect the change, and Python export of data).

See "[SDKMOD] Scriptable Leader Traits" (http://forums.civfanatics.com/showthread.php?t=175537 ) by TheRopez.
This is just version 0.1 and rather primitive for now.
But it looks much more promising and flexible than Impalers leader trait mod.
I think it is the approach we should take.
This Mod is much appropiate MOD to include in our project than unmoddable Impaler's leader trait mod.
IMHO, it would be better if impalers should announce your mod as separate personal SDK MOD, not as part of our project to enhance modability of SDK DLL.

I conducted a simple, crude experiments on memory leak..

I played a peliminary session with a save file to stabilize disk cache buffer.
Each main session was about 20 turns long after 10 "warm-up" turns starting with same game save file.
I played game with vanilla DLL ( with same save file) and mesured increment of total memory usage between these 20 turns.
Then I played with our project DLL. Again I played with vanilal DLL, and played again with project DLL.
For each session, I measured memory usage increment during same 20 turns.
Conclusion:
The memory usage is little different depending on DLL. But it was far from meanigful amount (less than few percent of vanilal DLL increment).
I can not say that there is meaningful amount of additional memory leak due to project DLL.
This game save file is early-mid ear( about turn 150 out of 430) of quite standard game, mostly peaceful world.
This is very simple and crude experiment so I can not conclude that there is no memory leak, too.
But it seems that there is no apparent and big memory leak hole out there.
It will take longer and more controlled expreiment to detect more subtle memory leak.

Ok I have reached a conclusion because I am sick of delays caused by other peoples unstable code and elitist atitudes, I am going to stat my own branch on the CVS and include only the content I wish on it, how I want it, when I want it. I will aim for public release every 2 weeks and will rely heavly on outside mods. If it is agreeable to TGA and other members of the project these can be released under a "CCCP all inclusive" title and SimCutie can focus on "CCCP lite" or what ever he wishes to call such branch as he creates and maintaines. Anyone may copy materials from my branch but no one but myself will commit to it (Such configuration is I belive possible with SF and am asking for it to be done once I have the branch up). If and when code made by other members of the project is stable and usable I will consider it for inclusion.

As much as I hate to see division, I feel that an "all inclusive" .dll is much more what I had in mind when I first posted about this project. My original intent was not to target the modders, but the players, giving them more options to improve their game, with the emphasis being on the fact that the options are options. Modding content has it's place, but is not the be all and end all.

I would certainly support many more releases, along with much more content, as long as they are kept stable. If other people's code causes errors, then it just doesn't get included, and we release the mod without the features.

If we stick to a set release timing, say, every two weeks then everybody will know what is going on. If somebody sumbits code which doesn't work, it gets dumped, and they have two weeks to fix it. We should keep a dev branch, where work in progress is added, and tested as it is made, and a stable branch, where only work which works fine with the existing .dll is added. Stable is then released every 2 weeks regardless (unless there is nothing added at all, but I can't really see that happening).

Have you guys considered starting a public thread where modmakers can request addtions that would allow them functionality without changing the core game?

I have posted this (http://forums.civfanatics.com/showpost.php?p=4226318&postcount=25) in the Mod Components Request thread, but of course I'm actually hoping these would be included in CCCP.

Btw, sorry for not being active here. After the expansion pack is released though and the CCCP works for it, I hope to start planning a liberal conversion of SMAniaC to Civ4 and will use CCCP for it.


I've got some requests, most to make SDK stuff moddable in XML.

Great People

Currently the GPP threshold increase is 100 for the first ten, then to 200, 300... Except for the first ten threshold increases, the GPP threshold is unmoddable. So I'm wondering if it would be possible to mod in GlobalDefines.xml:
set the increase (or decrease) rate yourself instead of it automtically switching to 200.
define after how many GPs the threshold increases changes (instead of the current fixed ten).


Hurrying Production

Currently you can set units to hurry production with < iBaseHurry>0< /iBaseHurry> in Civ4UnitInfos.xml.

However currently you can only hurry building production this way. I'm wondering if it would be possible to make units hurryable.

Also currently production just adds an absolute number of hammers. Would it be possible to let this be affected by production modifiers at the city where you want to hurry?

Eg a supply crawler adds 100 hammers, but you're playing an industrious civ and have a resource which doubles production, so the supply crawler adds 250 hammers. Or the other way around, you have a civic which gives you -20% military unit production, so the crawlers should only give 80 hammers when hurrying military unit production.

As far as I can see there should be some exceptions though to avoid that modifiers are counted twice.
[list] Buildings shouldn't add their production modifier. Eg a forge with +25% production shouldn't make the supply crawler give 125 hammers.
Other general production modifiers, eg any civic or leader trait that affects ALL production.


Specialists increasing the unit upkeep limit

Allow specialist to increase the unit support limit. Useful for eg a Soldier specialist that allows you to support three extra units and give some GP points to get a Great Warlord.

I guess this could be done in the SDK by adding these tags from Civ4CivicInfos.xml to Civ4SpecialistInfos.xml

< iBaseFreeUnits>0< /iBaseFreeUnits>
< iBaseFreeMilitaryUnits>0< /iBaseFreeMilitaryUnits>


Terrain improvements and units providing resources

Or take them way, by giving a negative value. This could allow a quantified resources system. Thus make these tags from Civ4BuildingInfos.xml usable multiple times in Civ4SpecialistInfos.xml and Civ4ImprovementInfos.xml:

<FreeBonus>NONE</FreeBonus>
<iNumFreeBonuses>0</iNumFreeBonuses>

Multiple times so you could have a specialist take away raw resources and convert it into an industrial resource.

release 1.61.0003a is now out. next version will be v1.61.0004a

I'm also starting a new thread with our next version.

I'm trying to play the downloaded release and am getting Python errors from all of 12Monkeys new game Utility calls (this never happened before), its seems that his CvGameUtil.py is not being found/used. And as always I get the CustomButton problem at the Dawn of Man screen which forces me to quit Civ4.

I am wondering do people test with Python Error supressed? This is the only way these bugs could have gone un-noticed by their creators for so long. Its critical to have all the Python Error popups and logs on when testing the game or else your not acomplishing anything.

']
The Python exception at DOMI too have this.

From the log:
Traceback (most recent call last):

File "CvScreensInterface", line 598, in forceScreenRedraw

File "CvMainInterface", line 672, in redraw

File "CvSimCutieMainInterface", line 606, in updateSelectionButtons

File "ActionButton", line 314, in DisplayCustomButtons

File "PyCivSim", line 333, in triggerEvent

File "CvEventInterface", line 44, in onEvent

File "CvSimCutieEventManager", line 455, in handleEvent

File "DEMO_ActionButton", line 43, in onShowButtons

File "ActionButton", line 291, in createButton

File "ActionButton", line 178, in __init__

AssertionError: CvPyActionInfo().create() failed
ERR: Python function forceScreenRedraw failed, module CvScreensInterface

I changed source to fix Python exception at DOM.
But I am not sure that it is really fixed or not bacuse I can not reproduce the DOM error in my computer ( Python exception Error report enabled, of course). I got such error before long in 1st release days but I have thought that it had been fixed in 2nd release and did not get the error from then ever. It was race condtion error.
So please heavy stress test this new version in your installation to make sure that it will not cause trouble in most of players computer and tell me the error happens again or not.

I also added AI Auto play by jdog_5000 and some of LunarMongoose's bug fix
and (tried to) fixed some strange error that rarely happens at start up when I switch between vanilla DLL and our project DLL (hard to reproduce error so not sure of its cause or if it is fixed completely or not but I tried)

PS) all of 12Monkeys new game Utility calls should be activated by python mod before use (in 'Init' time for example)
This is change to avoid memory leak. ( Not extensively tested yet)
ex) PyCivSim.activateGamEntryPoint("canPlayerFoundCity")

On first inspection the Momory leak seems to be fixed on latest build, I will test it with my own compile and on longer games to make doubley shure.

Good job on the inclusion of jdogs AI auto-play, I know TGA is going to be using that as a base for some of his "Auto-AI-game" stuff. Of Mongooses stuff did you include just his StrikeChances fix or other mods? Most of his game play altering mods could be usefull as options but they will likley need work before they can be used.

BTW, you need to include the firstStrike fix of mongooses. I had it confirmed by Alex that it's an error, and it will be fixed in Warlords too.

Dale