v1.61.0002a (2nd release)

Well I was thinking the backwards-compatabilty would be release #1.5 or something . 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

 

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.

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.

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.

 

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.

 

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.

 

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

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?

 

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).

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.

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?

 

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