Current and Future Developments

There are some grammar issues or missing words (I think?), that make some sentences more difficult to follow.
We should all have write permission to the wiki. I'm busy coding, meaning you are supposed to fix non-coding issues like this :p

Be thankful that I took the time to even write this. That's better than the average programmer :lol:

The XML files for the types, which get icons from GameFont all have a (?) called iChar. Simply write which GameFont ID you want the yield/unit/whatever to use and it will use it.
We call those things for tags.

I don't know if it can support pictures, but I think that would help clarify some of the descriptive sentences about the layout of IDs/icons, etc.
Somehow I managed to add screenshots to the git guide. I just don't remember how I did that. It would be good to know the wiki syntax and not having to look up everything every time you need it.

I can sort of follow it, it would possibly be easier if I was going through the files/screens and looking at them while reading your descriptions, but somethings are a bit difficult to understand what you are referencing.

Such as:
The Gamefont.tga file
or maybe an xml layout
Let's remember who the intended reader is. It is somebody who added something to XML and needs to add icons to it.

The page starts out telling that it will not explain how to edit GameFont.tga, but it refers to GameFontEditor. Most people would open GameFont.tga in GameFontEditor at that point, which would beat any screenshot.

I don't think it would make a whole lot of sense to explain how to add iChar to XML. If the reader just added 5 new units, that person can presumably figure out to add iChar to one or more of those units.

There is a reference to CIV4GameFontInfos.xml. If you open the file, you will see
Code:
<GameFontInfo>
    <iRussian>8483</iRussian>
    <iYield>8547</iYield>
    <iMission>8633</iMission>
    <iUnit>8759</iUnit>
    <iBuilding>8834</iBuilding>
    <iBonus>8884</iBonus>
    <iFather>8909</iFather>
Just before that, there are 11 lines of comments to explain how to use this file. Writing more about that would be pointless.

or maybe an 'imaginary' layout that the computer uses.
That sounds like a good idea. However I'm clueless on how to do that. The best I can do is to tell people to open DA and take a look. The imaginary single line is displayed here.
 
I added a new wiki page. Civic XML.

It's a little different this time because it's autogenerated. I wrote a perl script, which reads the schema file and is able to write in a way, which the SF wiki reads as a table.

Text outside the tables is untouched and comments on the tags are kept too, even if the order of tags changes or new ones are added in between. Renaming tags is a different story though.

Now it's time to fill in the comments on all of the tags. Particularly the last group as that is the one, which still needs to be sorted.


The perl script isn't directly designed for civics. All it needs is a schema file and a txt file to update. It then loops though the file and triggers on two things:
  1. ### ElementType name (such as <ElementType name="CivicGroupCivicData" content="eltOnly">)
  2. ---|---
The first is a wiki header, which doubles as telling what to look up in the schema. The second is the start of a wiki table. The script will then add/remove rows in the table to match the schema.

I see no reason why we shouldn't be able to make such a page for all important XML files.
 
I added a new debug screen in Domestic Advisor and I added a DLL backend to it. The idea is that it shows a bunch of ints and there is an interface to change those. I added a new enum to name each option and set the number of options.

To get the one of the numbers, you use GC.getDebugValue(enum value) and this function is python exposed (so is the enum).

To add a new number, just add it to the enum and the code will handle the rest.

The idea is that right now we have a bunch of hidden options, which can be activated by changing obscene settings in XML and nobody knows all of them. If we place all of them in this screen, we will know how many there are. Also by placing setup in the game, it can be changed without restarts.

So far I only added one option: special building reload + city redraw code.

The screenshot is fake in the sense that I added a bunch of options which does nothing :p

TODO: figure out a way to set useful strings without making it too difficult to add new settings. Also it would be a good idea to have some sort of setup with init, min and max values for each number. Some help popup string system could also be useful.

I made a spreadsheet like layout rather than lines. The number of "column clusters" depends on screen resolution (they have fixed pixel width). This concept can be copied to other screens if we want to.

I changed the criteria for when debug buttons appear in DA. They will now also show up in assert builds (as well as debug). This is because XML modders should use assert DLL files and the debug options so far are all aimed at XML modders.
 

Attachments

  • debug options.JPG
    debug options.JPG
    131.5 KB · Views: 167
I'm hard at work making a "tag organizer", which is to reorder the tags in XML according to how they are written in the schema. The idea is that to make a change, all you have to do is make the change in the schema and then run the script and the XML file will appear in the new layout. This being adding new tags, sorting them or move tags in/out/between subgroups. In other words it is a tool to make it a whole lot easier to place tags in groups and more importantly: way faster :)

There is a problem though. The design will delete all comments when using this design and the only solution I can come up with is to move all comments to the start of the unit/civic/whatever. Do anybody think this will be a problem? :hmm::shake::dubious:
 
Nope, don't bother me. Our Wikis will help with modders wanting to know what does what.
Yeah I thought about that too after I wrote the post. Just for the record, the source code for the wiki pages are in sourceDLL/schema/wiki. That might even be better than the wiki because it works offline (the server is broken right now) and it also provides a different version for each branch.

The only thing left is the plan for each class instance (like each unit), but the modder should make a document somewhere else rather than spray comments out all over the XML files.
 
My script is working :woohoo:

In fact it turned out even better than I originally planned and it can be used for way more than just placing tags in groups.

When the DLL is updated and requires updated XML file(s), all the modder has to do is:
  1. Run update_MOD.pl
    This copies the schema files from the DLL into the mod
  2. Run tagUpdate.pl
    This will update the XML files to fit the new schema files
That's it. The only thing, which can go wrong is tag renaming. If a tag is renamed, it will be viewed as obsolete and deleted. It will then insert a new empty tag in the new name. We might need a tag renaming script or we can just avoid renaming.

Optional tags containing 0, nothing or NONE will be removed. (I wonder if we have non-zero defaults in the DLL :think:)

Non-optional tags, which aren't present will be added with
Code:
<Tag>!!! MISSING !!!</Tag>

Another bonus is that since the tags are reordered according to the schema file, modders can add new tags whereever they want in the info class as long as it is at top level or top level of a group. Running tagUpdate.pl will then move the newly added tag to the correct location and taking great care of tag ordering when adding new ones is a thing of the past.

Issues:
The script setup is horrible. I want some autoconfiguring setup. I want to change it to something, which will not need to be updated.

Plan: give it all the schema files. It will then work on all XML files in the same locations as the schema files. No need to update just because we add a new XML file.

That just leaves one issue: how does it know which elements are groups, it should pay special attention to? Right now it lists all of them, but I want it to be automatic.

Question:
Let's use one of the existing group names as an example
Code:
CivicGroupGrowthImmigration

I have come up with the idea to rename it to
Code:
[B]SmartGroup[/B]CivicGrowthImmigration
The idea is that the script will trigger on all elements, which name starts with SmartGroup. That will be self configuring (sort of) and fairly easy to understand.

The question is if I picked a good name. I'm not sure. Maybe it should be TagGroup or something. It has to sound right and tell what it is all about and at the same time be generic enough to fit all XML files, not just civics. Any ideas?
 
So, all we have to do is say, add something to the Infos.cpp and then run the scripts and the scripts will add the XML stuff?

I like TagGroup best as it is shorter, or perhaps even just Group. And perhaps since we are in the CivicInfos we can just drop the Civic name since we know it deals with Civics and not necessarily Civics but Techs as well, so the example would be called GroupGrowthImmigration.
 
So, all we have to do is say, add something to the Infos.cpp and then run the scripts and the scripts will add the XML stuff?
It has to be added to the schema as well, but otherwise yes, it will add missing tags. The original goal was to fix incorrect order of tags, which mean it will do that as well.

I like TagGroup best as it is shorter, or perhaps even just Group. And perhaps since we are in the CivicInfos we can just drop the Civic name since we know it deals with Civics and not necessarily Civics but Techs as well, so the example would be called GroupGrowthImmigration.
TagGroup it is. Group is too short because it adds the risk of false positive. Imagine a promotion with a tag called GroupDefenceBonus, which will then give defence bonus to all units on the plot... or anything else starting with Group. False positive could be a real issue because there is a script limitation, which says there can only be one tag with each name on the top level of the info class as well as in all TagGroups for that class (that is one in total, not one in each). If we have a false positive on an array, it screws up big time.

The main reason for using Civic is to tell where it belongs in the schema. We have quite a lot of XML files in just one schema file.
 
I finished the tag moving script (tagUpdate.pl). It is now able to find files with no setup as it scans the XML dir. Also it triggers on tag names starting with TagGroup meaning we don't have to tell the script with groups to look into. I also made it indent all lines it comes across (partly because the tag moving screwed up indenting).

I also updated the wiki and added another column. It shows either X or nothing. X mean minOccurs="0" is present in XML and the tag can be skipped.
 
Finished grouping civics. (finally).

https://sourceforge.net/p/colonizationmodcollection/wiki/Civic_XML/

I have been thinking about how to split civic into multiple files. I think we should have the following:
  1. Civics
  2. Inventions
  3. Trade techs (we need a better name)
  4. Censures
  5. Traits
  6. Effects
By splitting them like this, we can make the CvGlobals aware of index range of each, which will allow us to loop just one of them if that is what we want (like for civic screen, tech screen...). Pedia will also be able to split them based on this alone.

Another bonus in splitting is that we can force some files to show certain things while they can't be set in others, like Inventions needs to set where they are in the tech tree.

Do you think this will be too many files for more or less the same thing?
 
  1. Trade techs (we need a better name)

Do you think this will be too many files for more or less the same thing?

I'd say depends on how much time it would take and if there is more important stuff to do right now. It would be totally cool to have it setup that way though.

Trade techs...

TradePerks
TradePoints
Trading
 
I always think smaller files grouped in a folder is a good thing, as you can find and deal with exactly what you want.
You are saying we should move it out of GameInfo and into CivicInfo (or whatever er call it). That's actually a good idea. GameInfo is too big as it is.

I think we should come up with a new name for the collection of all the types using CvCivicInfo since civics is just one of them. Civics being both the class and one of the types is confusing.

I'd say depends on how much time it would take and if there is more important stuff to do right now. It would be totally cool to have it setup that way though.
The concept requires a bit of coding, but there is no real difference between having 3 files or 8. It would more or less be a loop.
 
If it is not much work to give it a seperate folder, it would be good. It now contains such a broad game wide impact of abilities, it should probably get it's own folder. In bts techs have their own folder and it just has 2 files in it!

I agree gameinfo seems to be a bit of a dumping ground for files, it was like they got fed up of making folders so just said... "lets just make a gameinfo folder, dump it all in there and go home!"

What about Social/Societal/Cultural Effects? I am trying to think of a single word....

It basically holds all of the elements connected with the Evolution of Society or Civilization.
Technology, the Popes Judgements of Society, the Traits that predispose your leader to a certain way of leading Society, the way you choose to lead your society.

To be honest I think Civics as a 'shortest possible descriptor' works quite well. They all work off the same code bundle and they are all connected to the concept of Civilization Evolution.

Or maybe GameEffects, as it is similar to gameinfo
 
To be honest I think Civics as a 'shortest possible descriptor' works quite well. They all work off the same code bundle and they are all connected to the concept of Civilization Evolution.

But like Night says, there is also a Civic Category so it can lead to confusion.

I started to go with GlobalEffects, but some of the techs and such aren't really Global, so perhaps simply CivEffects.

Out of Lib's I like SocialEffects.
 
Back
Top Bottom