CivEffects

I have run into a problem with iMissionariesNotCosumed.

The problem is that the setup makes no sense to me.

Column 1	Column 2
Value	Effect
<0	Missionary reappears at the start of next turn
0	missionary dies
>0	missionary reappears after X turns where X is the setting

This mean if the setting is 5, adding -1 makes it reappear in just 4 turns, which is a good thing. If the setting is 1 and you gain -1, then instead of reappearing next turn, the unit will die, which is a horrible improvement.

This will need a redesign. I'm thinking of say that the unit will reappear in 10 turns (perhaps a value in globalDefineALT). CivEffects can then add modifiers to the time. If the combined modifier is 0 or more, the unit dies. If it is less than 0, then the 10 turns are modified into the actual timer meaning -90% will make it reappear next turn. -50% will make it reappear in 5 turns.
Alternatively the setting is split into two settings, one for time modifiers and one for allow.

About the time itself, I would like to make 50% of the time fixed and the other half a random number, meaning rather than taking 10 turns, it would take 5-10 turns. Also adding modifiers for stuff like game speed and perhaps AI difficulty would make sense as well.

Is this a change we can agree on or am I missing something?

 

Yeah.


Ha ha, jk. I love it when someones asks me an either or question and I just say "yeah". They are like, "what, that doesn't answer the question??" ... "Yeah"

This is a great suggestion. When I designed it I wasn't thinking of there being any more effects added to or taken away from this, it was meant to be a one time deal. As also with the Traders Appearing later on after they setup a Trading Post, this would be set up the same way I bet and need fixing as well.

 

I wrote two suggestions (less than 0% modifier to enable or new enable XML tag), which mean your answer isn't that clear

And yet your code stacks contributions to make precisely what you didn't plan for

I kind of suspected that. I think I will write a function, which takes modifier and perhaps default value as arguments and then it returns the actual time needed. That way it can be one function with an access function for each type and we will not have two 99% identical functions.

I might also write a function, which gives a random number from 50% to 100% of the argument. If it can just call a function for that like we call random now, it will be a function we can reuse multiple times for all sorts of stuff.

 

Well in that case, just go with what you like best. As long as it works as intended I have no preference.

 

I like having the potential to influence positively and negatively, as well as switch on and off.

I haven't looked to closely at the planned proposal (as in whether either way it does positive and negative) but I say 'I'

 

I finally figured out what to do with free promotions from CivEffects. Despite the name, they aren't free promotions anymore. They are a type of their own. We now have:

1. Real promotions
   There can be picked when the unit has enough experience
2. Free promotions
   Given from python, buildings when constructed and so on. Saved!
3. Free promotions from CivEffects
   Having a sole source for calculation, these can be cleared and recalculated whenever needed

While writing this to explain, I came up with the idea to move free promotions from XML from 2 to 3 and rename 3 to FreePromotionsNotSaved. The reason is that when a savegame is loaded #2 is is read from the savegame and #3 is generated based on XML. By moving XML data such as profession and unit free promotions into #3, no units will be messed up by changing XML.

#2 will then the place for non-XML stuff, such as assigned free promotions from random events or if a certain building is present in the city it was built in. In other words: all the free promotions, which can't just be cleared and recalculated based on XML.

I was so happy that I finally finished this tricky task and now I realized I haven't finished yet anyway
However getting a system where savegames are less likely to break is a stated design goal meaning in a sense it isn't a diversion from the plan even though I didn't actually plan for this

 

I just made this task way easier as the perl scripts are now able to rename tags. This mean the risk of deleting tags is reduced greatly. However it isn't removed entirely because some tags do the same thing and has been merged.

We now have fairly generic perl code to modify XML files. If we combine the existing code correctly, it is able to update XML files from the layout of one release to another. It does require calling multiple scripts in the correct order, but a bat file can take care of that. This mean in the future when a new DLL file is released, non-M:C mods can pull the DLL submodule and execute a bat file and the XML files will be updated to fit the new DLL.


The calculator says I'm done with 94% of the tags. However I'm not sure if I end up at 100% because I have both added and removed tags and I'm not entirely sure my total count is correct anymore and I didn't bother to verify . Either way this less than interesting part of the tasks is nearly complete.

EDIT:
The exe has code to call CvPlayer::changeUnitMoveChange(UnitClassTypes eIndex, int iChange)
I can't think of any reason why I want the exe to do that. This function has been rendered obsolete by CivEffects and I deleted the content. Even if the exe calls it, it will not actually do anything. I added an assert, which will always trigger, but so far I haven't managed to trigger it. It will be interesting to see if anybody ever manage to trigger it or the exe has a call in unreachable code.

 

Looks like exe can change UnitStrengthModifier as well, this may have something to do with debugging. You can bring up a Debug Menu (ctrl-D) click on the Game tab and then give your units 200 moves. This may be how they do that?

 

I'm done. I went though all tags and implemented everything, which already had an implementation. I skipped some, which appears to be planned features, but nothing in the code actually listens to the tag even before I started.

I will now review the tag names and very likely do some renaming. Once that is done, I will move to a new XML directory and split CivicInfo into multiple files.

To avoid complete chaos editing CIV4CivicInfos.xml is now banned in all branches
This ban is in effect until CivEffect is done and merged into Develop.

Yeah that is how it works. Well now I broke that feature
I just removed the function and assigning 200 moves then crashes the game. I kind of expected that, but sometimes it's good to confirm what you expect.

I should remove the assert, but the question is if I should fix the function. However personally I would prefer to ignore it and implement our own cheat if we need it. The simple +200 move is not without issues in my new cache implementation.

I'm not sure how useful that debug window is except if you are replacing graphics. However I noticed one potentially really interesting checkbox. It enables a python debugger. The question is how do we use it?

 

I finished moving files from GameInfo to a new directory.

In theory it's fairly easy, but I ran into all sorts of problems. Worst was the fact that I wrote in the DLL that it should read from CivEffect while I called the directory CivEffects. I changed that, but it kept reading from CivEffect until I finally decided to clean the build and compile all files all over. Then it magically fixed the issue

What is needed to make a new schema file work (when the compiler isn't being stupid) is changing the directory string in the DLL (each file has a directory string in arguments). Then the XML files has the name of their schema file written in the first line. This needs updating too. That's it.

It would be good to add the schema file to the list of schema files in the DLL, but failure to do so will only miss the warning if the schema file is outdated, not fail to run the game. The same goes for updating the list of schema files in the script to move those files between the DLL and the mod.

In order to split the schema file, I added code to the perl scripts. When reading groups from an XML file, it will naturally know the names of all elements. Now it remembers if an element is used by another element and in the end it warns about unused elements, which is defined by not used by anything in the same file and name doesn't start with Civ4 or CIV4 (those are called from the DLL).
This meant splitting was just a matter of copying the schema file and remove the CIV4 elements no longer needed and delete whatever it warned about.

The perl scripts will no longer write to files if what it is writing is the same as what the file already contain. This avoids those annoying "file is modified. Reload?".

What is left is splitting civics into the different types it actually is. That might be the hardest part to get to work in the DLL, but clearly it should be possible to do. It's just a matter of how many places it will have to be updated.

 

Great news. I figured out how the XML cache works and now it's no longer called. This mean the XML files are read instead of the cache even if the cache is enabled in the ini file. Presumably we can avoid some bug reports this way as well as save our selves from really annoying problems.

I have finally reached the point where I am to split civics into multiple types. The question is how many we should make from that single file.

Column 1	Column 2
Name	Description
Civics	BTS style civic where you switch between them
Techs	BTS style techs where you research them
Trade Perks	"Researched" with trading points
Censures	Assigned to players by the pope/king
Tech Categories	Tells the type of Tech. Used for research bonuses EDIT: this shouldn't be CivEffects as all we need is BasicInfo. It should work like UnitCombatInfo types

Did I miss anything?
(I intentionally postponed any CivEffect not already part of CivEffects).

Another thing. I want to rename Civic, or rather I want to rename GC.getCivicInfo() and GC.getNumCivicInfos() as renaming will remove the exe exposed part of it as well as force the compiler to locate every single place in the code where it's used and that way allow me to review every single location for how to use the new types.

The question is: What should we call civics?

 

That sounds good overall, here are a few comments about TechCategories, Censures and Perks.

Civics BTS style civic where you switch between them, one active Civic in each CivicOption category (could call these Policies if you're in need of something different than Civics to call them?)

Techs BTS style techs where you research them

Tech Categories Tells the type of Tech. Used for research bonuses
Do you think it would make more sense to have TechCategories be their own entity like CivicOptions; or alternately you might not even need to declare the TechCategories on their own in an XML file, each tech would just have an entry <TechCategory>TECHCATEGORY_MILITARY</TechCategory> and CivEffects could reference a category they give a discount to, then on load the game would simply read all the TechCategories that occur and assert if there's a discrepancy. If there are enough Techs that the Techscreen starts to get crowded, it would be awesome to have an option to let each category have its own Tab in the Techscreen similar to how Founding Fathers screen works, then you could easily flip between them.

Censures -> to give these more versatility and distinction could represent these as "Conditions", meaning any involuntary CivEffect that applies to your civ and is usually temporary, these could be moddable to result either from a diploevent with your ruler or potentially be a condition triggered by an EventInfos random event if you want. You could use this to mod things like the Black Death which would happen involuntarily and last for a certain time applying a negative CivEffect; or positive Conditions like a Papal Blessing if the Pope is really pleased, or a Renaissance / Golden Age cultural growth period, etc etc. Perhaps all currently active Conditions could be listed in a single place (Domestic Advisor, or a single button on mainscreen interface) to avoid having to hardcode interfaces of lots of individual censures.

Trade Perks "Researched" with trading points
Currently it seems like these are essentially just like normal Techs except that they're assigned to <InventionCategory>MEDIEVAL_TRADE_TECH</InventionCategory>, appear in a separate screen, and the most important difference being they're purchased with FF points instead of YIELD_IDEAS, currently FATHER_POINT_REAL_TRADE (which is a bit confusing since there is already a vanilla FATHER_POINT_TRADE). To make this more versatile/straightforward for modding, Perks could be acquirable using any combination of FF point types you design.

 

In M:C I've been calling Civics Decrees, but Policies sounds good.

Conditions sounds good as well.

I started to make a "Tech Category" file with the CIV4GlobalCivicEffectInfos.xml file. This would just going to list the different Tech Types so it should be converted to do this very thing, perhaps renaming it to something else.

 

I kind of like policies. IN fact I like it better than civics, which is a word I never really liked. I'm not sure if it's the best name though, but it's the best so far.

However now that I think about it, nothing stops me from renaming them to cixxxics, update the code and review everywhere it's used. Once I'm done, I can just change the name back.

The exe exposed issue is a different matter. However it is possible to handle that as well. I can write getCivicInfo() and getCivicInfoDLL() and then conditionally add

PHP:

#DEFINE getCivicInfo getCivicInfoDLL
(might be some variation of () or (x) added to make it more robust

If the condition is right, then CvGlobals.cpp will have both functions and all other files will use getCivicInfoDLL, regardless of which of the two names they use. I think I will use this to control all exe exposed functions. This in turn allows us to return const pointers rather than references and we will never have to deal with bugs due to missing & again.

I suspect the exe will only have to access info arrays directly for XML cache (which I just disabled), but it is better to be safe than sorry and the define approach will allow the exe to access with references while the DLL use const pointers.

I planned for this and then I didn't write the plan, making it sound like I plan for something completely different
My plan is to make categories BasicInfo. This mean the read XML code and get functions are already present and it can quickly be implemented.

This will give us Type, which is precisely what we need. While we might not need anything else, it does give access to TXT_KEYs as well, which might be useful. We don't need anything else for this feature. Ok, maybe we need graphics for the tech screen, but we can worry about that later.

or alternately you might not even need to declare the TechCategories on their own in an XML file, each tech would just have an entry <TechCategory>TECHCATEGORY_MILITARY</TechCategory> and CivEffects could reference a category they give a discount to, then on load the game would simply read all the TechCategories that occur and assert if there's a discrepancy. If there are enough Techs that the Techscreen starts to get crowded, it would be awesome to have an option to let each category have its own Tab in the Techscreen similar to how Founding Fathers screen works, then you could easily flip between them.

The question is if we should call it censures if we also use it for plaque and stuff like that. We also discussed titles, which would have some trigger settings and move to the player with the highest trigger score.

The question is not if we should have those or not, but rather how many XML files we should have. I have designed CivEffects to cache 100% of the data and will never have to loop all CivEffects. The main goal of this is to be able to ignore which file the CivEffect comes from meaning it is designed to handle a huge amount of files. Performance isn't an issue either. In fact performance will benefit from using multiple files if it say has to loop all titles to see if one of them should be moved to a different player since it will not spend time looking at non-titles.

I actually planned censures for the pope only, which would allow us to add pope specific tags to them. Later I would like to add EventCivEffects, which is just a CivEffect (no extra tags), which can be activated by events. Titles could be added too with tags telling trigger conditions.

There is one exception to looping all CivEffects. There is a function, which resets the cache and sets it again using looping. However it is currently only used on game start (load included), but is intended for some debug features as well. There is also a function to make a CivEffect, which enables all Allow, which have not +1 settings. This is planned to only execute when the XML files have finished loading. However generally speaking, CivEffects will not be looped.

That would make perks one step away from being a player specific FF system, which could actually replace FFs. We could then add tags for

• can be researched if somebody else has it
• can be researched if freed (the owner dies)
• can be shared on a team
• can be shared with diplo relationship
• can be given away (donating player loses the Perk)
• can be conquered

This would allow a rather dynamic FF system where it isn't the end of the world if you miss a FF you really want. Also it would mean that trading perks would no longer be special since they would become some sort of trading FFs.

 

I have been meaning to ask you about that one. I moved it to CivEffects, but I haven't actually figured out what it does. If it is simply a tech category placeholder, then it could be renamed or simply deleted to make room for a proper one.

 

It does nothing, it was started but never finished so yeah, delete, rename, whatever works best.

 

I added Tech Categories and we really need to review what is in that file because not only are there no real tech categories, it has stuff like anarchy and censures. However it will do for now because right now my goal is to get the DLL to handle more files and it will not care for category names

There is native tech, which gave me an idea. If a player has a modifier of -100% (or possibly more than +500% or some other fixed value) in a category, that player will never be able to research the category in question. Spies, diplomacy and conquest could obtain such techs, but their own researchers can't. This way we can use traits to ensure that no player can research every single tech in the game. This could easily lead to balance issues and some players getting stuck in the tech tree if not done correctly, but I might figure out to make some "tech tree analyzer" to post XML read code, ensuring that no leader gets stuck. Something like having a bool in techs telling if it is a "goal" tech and the game will assert if a leader can't reach any of the goals.

Also I realized that Civics has to be called Civics because when changing a Civic, some exe magic takes place and sends an entire array in a network package. Renaming could easily conflict with this and I really don't feel like recoding network code. I have a theory that it could be possible to make custom sized packages using python, but until we know how to do that, we are stuck with what the exe provides.

 

Exe!

 

Well, it isn't for nothing that we execute the exe each time we want to play the game

 

Era Restrictions.

Could it be one of the things you might be missing?

Should this idea be included here at this point?