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

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.