The Great Apple
Big Cheese
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.

Is Custom Button at DoM error not yet fixed? strange...Impaler[WrG] said: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)
No. our main client/audiance should be moders, not general player.Impaler[WrG] said: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.
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.Impaler[WrG] said: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.
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.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.
Adding new trait is not much problem. But if you do it, it should be implemented in more or less generic way.Impaler[WrG] said: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 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.SimCutie said: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.
The Great Apple said: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.
Are these mutually exclusive? Can't we do both? All the features will be optional.SimCutie said:Is it making big combined feature-rich mod DLL or providing common platform DLL for moder?
If it was implemented that way, I wouldn't have pointed out from the start.The Great Apple said: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.
The implementaion is fixed to use specific tag and perform specific function. It is not parameterized or generalized.
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.
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?
It is conceptually flawed. The UU belongs to a Civ, not leaders.Impaler[WrG] said: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?