DLL coding thread

[Nightinggale]

I managed to split the horseman profession into two where neither has alt equipment. Setting up graphics for the new one turned out to be a hassle and I wrote a script to do that

The new type PROFESSION_CALVARY_LEATHER is a true new type just like any other types. This mean we can use it in other XML files if we want to. In fact it can be used in civics to enable the different subtypes based on different inventions.

I noticed that iPower isn't changed when switching to alt equipment. This is a bug as the AI uses this to determine the strength of a profession. I changed that and the new sub profession has +25 power (to a total of 175).

Next step is to merge the two professions into one in the GUI. I noticed that even though the two units aren't alike in combat power, they have identical pedia pages. That isn't that great as it reveals that the pedia skips important info.

 

[Kailric]

Next step is to merge the two professions into one in the GUI. I noticed that even though the two units aren't alike in combat power, they have identical pedia pages. That isn't that great as it reveals that the pedia skips important info.

Just let me know when you are ready to change out the Alt equipment with Subprofessions and I'll help with the xml on that. Have you ever looked at the vanilla profession pedia code? It is a nightmare!! I went through hell to get the code to function somewhat correct when adding tons of new profession.

 

[Lib.Spi't]

Sounds intrigueing!

If you want to split the xml Job, I could code in half the list if it helps, then you would just need to do a quick merge with my file? Don't know how much time this would save as you would need to write me a list of professions... but it might give me a chance to get my head around the prof code.. and might make life easier for you?

 

[Nightinggale]

Just let me know when you are ready to change out the Alt equipment with Subprofessions and I'll help with the xml on that.

If you want to split the xml Job, I could code in half the list if it helps, then you would just need to do a quick merge with my file

Those updates can be done already. Look at PROFESSION_CALVARY. Type needs to be unique like all other types. Description would look best if it is unique as well, but the game engine doesn't care. iPower can be a copy paste from parent or it could be increased a bit (increase is likely best).

Yield and promotions are copy paste from parent with the alt settings added.

https://github.com/Nightinggale/Medieval_Tech/commit/7af215a3daaf7ca2df59ed34b705fb890427b183

Art styles are added with scripts/subGraphics.pl. Art isn't critical. They can always be added later. However if you do have perl installed, then run the script and you will have art for the sub professions in no time.

Do remember that each subtype needs to be added to civics or they will be available from the start. However nobody said that it has to be the same civic as the parent.

I wonder if we should add some init invented store to professions. If we set it to -1, then it will only be invented when we have both +1 civics.

Have you ever looked at the vanilla profession pedia code? It is a nightmare!! I went through hell to get the code to function somewhat correct when adding tons of new profession.

I don't think it looks so bad. However I modified and couldn't tell any difference, then again and again. It turns out that the list is generated in two different places in two different files and neither of those places are getSortedListProfession(). Once I figured that out I changed those two places to call this function and now it just works.

Parent professions have been merged with their sub professions in pedia and I pushed this change. The link to the other type is actually a list of parent+all subtypes except for the selected profession. This mean it expands automatically when more subtypes are added in XML. I tested this, but I didn't add more subtypes to github as my test included a lame cloned profession with no gameplay value.

Next step is to merge the professions ingame.

 

[Kailric]

Sounds intrigueing!

If you want to split the xml Job, I could code in half the list if it helps, then you would just need to do a quick merge with my file? Don't know how much time this would save as you would need to write me a list of professions... but it might give me a chance to get my head around the prof code.. and might make life easier for you?

Ok, I'll have to familiarize myself with the new system and then get back with you on this.

 

[Nightinggale]

Now subtypes has been merged into their parents in choose profession popup. It ended up like this:

All professions appear normally except when you can make two or more subtypes (including the parent). If there are more (say a parent and a sub or just two subs and no parent), then the line will end with (2). If you click this line, the popup disappears and a new one appears with parent and/or subtype(s). This allows for say cavalry being a single line and if you click it, you pick which type of cavalry. This in turn allows us to have a lot of different military professions without filling up the profession list.

It should be noted that the code assumes the parent and subtypes to be ourdoor professions. I haven't tested this with buildings or plot professions, but I'm somewhat convinced that it will not work.

At the moment I have no further plans for profession subtypes. It appears that all features have been added to make it work just fine. This mean the XML editing phase can start

I can't figure out if it would be a good idea to start adding subtypes to units as well. It would be logical to have "free colonist" types shared in one group for pedia. However is that reason enough to code such a new feature?

 

[Kailric]

At the moment I have no further plans for profession subtypes. It appears that all features have been added to make it work just fine. This mean the XML editing phase can start

I can't figure out if it would be a good idea to start adding subtypes to units as well. It would be logical to have "free colonist" types shared in one group for pedia. However is that reason enough to code such a new feature?

Ok, I have tested out the new Subprofessions and all seems to be working as you say. However, , it is going to take a bunch of work to get the new system up and running.

I thought you would be able to take Existing Professions and just add them to a Subprofession list along with their states and graphics, but we are basically creating more Professions. Each new Subprofession is another profession that needs Graphics added as well.

So, Lib.Spi't, if you are up to starting on this that would be great. It appears that the Parent Profession retains his CombatGearsTypes, this is good, but at the moment we can not add new CombatGearTypes to the Subprofessions, so similar units with different CombatGears will have to remain as a parent, such as the Knight and Heavy Knight. So, can CombatGears be added to subprofessions, I would imagine right? Anyway, I'll list out possible combinations, dashes - means subtypes. You basically have to move the AltEquipment values to the Subprofessions, the remove the AltEquipment.

• Heavy Knight
• Knight
• Pikeman (Chain) - Heavy Pikeman (Plate)
• Heavy Calvary (Scale) - Heavy Calvary (Chain)
• Archer - Archer (Leather)
• Armed Peasant - Armed Peasant (Leather)
• Crossbowman (Leather) - Crossbowman (Chain)
• Longbowman - Longbowman (Leather) - Longbowman (Chain)
• Horseman - Horseman (Leather) - Horseman (Scale)
• Light Infantry - Infantry (Leather) - Heavy Infantry (Scale) - Heavy Infantry (Chain)
• Light Skirmisher (Leather) - Skirmisher (Scale) - Skirmisher -(Chain) - Skirmisher (Plate)

When naming these in the XML we can leave off some of the armor types from the Parents and Subs, like; Light Infantry, Infantry, Heavy Infantry, Heavy Infantry (Chain).

When all these are added to the Professions, we will then need to add the new SubProfessions to the different types of Civs in the CIV4UnitArtStleTypeInfos.xml so they will have the correct Art. This is faster than adding them to the individual Units. Here is where we can create new skins for the Subprofessions.

Well, I love the system, it is just going to be time consuming to work it all out.

 

[Nightinggale]

I thought you would be able to take Existing Professions and just add them to a Subprofession list along with their states and graphics, but we are basically creating more Professions. Each new Subprofession is another profession that needs Graphics added as well.

I noticed the graphics issue as well and then I wrote scripts/subGraphics.pl. Running this script will give graphics to all subtypes and it will clone the previous (usually parent) graphics. Edit professions, then run this script, wait 1-2 seconds and graphics will be set up.

So, Lib.Spi't, if you are up to starting on this that would be great. It appears that the Parent Profession retains his CombatGearsTypes, this is good, but at the moment we can not add new CombatGearTypes to the Subprofessions, so similar units with different CombatGears will have to remain as a parent, such as the Knight and Heavy Knight. So, can CombatGears be added to subprofessions, I would imagine right? Anyway, I'll list out possible combinations, dashes - means subtypes. You basically have to move the AltEquipment values to the Subprofessions, the remove the AltEquipment.

Combat gear... good idea to add this to sub professions. However I don't want to add it everywhere as quite a lot of subtypes will not have changes.

How about adding a bool for each big change (such as gear or promotions). It will then only read the subtype variable if enabled by the bool. In fact make that an int, then it can be 0 (clone parent), 1 (new setting), 2 (merge). The last can then have one promotion, which it then adds to the existing promotions from parent.

Well, I love the system, it is just going to be time consuming to work it all out.

I like it too. I totally think it's worth the time this takes to make this. In fact it can become way more interesting if there are multiple subtypes where we can have say 4 crossbowmen in one group.

One thing I really like about this is that it is mainly a GUI and XML change. At runtime the view from the AI is unchanged and it looks like somebody typed in a whole lot of professions and it can then use the vanilla AI code to decide between the many options, which it will hopefully do well. No vanilla code prepared it for equipment.

 

[Kailric]

I noticed the graphics issue as well and then I wrote scripts/subGraphics.pl. Running this script will give graphics to all subtypes and it will clone the previous (usually parent) graphics. Edit professions, then run this script, wait 1-2 seconds and graphics will be set up.

Oh yeah, I remmeber now you pointed that out. I haven't installed Perl yet, need to look into that. What file gets edited for graphics, CIV4Units.xml or the CIV4UnitArtStyleTypeInfos.xml?

How about adding a bool for each big change (such as gear or promotions). It will then only read the subtype variable if enabled by the bool. In fact make that an int, then it can be 0 (clone parent), 1 (new setting), 2 (merge). The last can then have one promotion, which it then adds to the existing promotions from parent.

Sounds good to me.

I like it too. I totally think it's worth the time this takes to make this. In fact it can become way more interesting if there are multiple subtypes where we can have say 4 crossbowmen in one group.

Yeah, then have them all skinned different based on their armor.

 

[Nightinggale]

Oh yeah, I remmeber now you pointed that out. I haven't installed Perl yet, need to look into that. What file gets edited for graphics, CIV4Units.xml or the CIV4UnitArtStyleTypeInfos.xml?

The source code is like a manual.

openFile('Civilizations/CIV4UnitArtStyleTypeInfos.xml');
updateFile('StyleUnit');
writeFile();

openFile('Units/CIV4UnitInfos.xml');
updateFile('UnitMeshGroups');
writeFile();

I see the file is outdated as it isn't using the module I just added. Now openFile() and writeFile() are in a module for easy reusability. A module is almost like a library in C++ where you can include functions you want to use in multiple scripts.

Being able to use the perl scripts is quite important considering the by now rather powerful scripts we have on github. Another really useful script is xmlTagAdd.pl, which automatically adds new tags to XML files. You add a tag, then you add a line to the script and execute it and then all units or whatever will have this tag with the default value.

EDIT: I just had a new idea. We can write a script to change graphics for a profession. If we give it the profession type and the art tag it should use, then it can loop though the affected files and replace to the new one whenever it finds files, which should be changed. One problem with graphics is that it appears to be the same over and over, which is really time consuming to change. At the same time it is ideal for scripting as it is the same over and over.

 

[Trade Winds]

I am also eager to help.

According to Nightinggale directions, the files to implement subprofessions are:

Spoiler :

CIV4UnitArtStyleTypeInfos.xml
CIV4CivicInfos.xml
CIV4ProfessionInfos.xml
CIV4UnitInfos.xml
CIV4UnitSchema.xml
CvInfoProfessions.cpp
subGraphics.pl

Where the last two are of SDK and I have no experience.

And the subprofessions we have to add in the XML according to Kailric's plan is:

Spoiler :

Heavy Knight [knight plate]
Knight [knight mail]
Pikeman (Chain) - Heavy Pikeman (Plate)
Heavy Calvary (Scale) - Heavy Calvary (Chain)
Archer - Archer (Leather)
Armed Peasant - Armed Peasant (Leather)
Crossbowman (Leather) - Crossbowman (Chain)
Longbowman - Longbowman (Leather) - Longbowman (Chain)
Horseman - Horseman (Leather) - Horseman (Scale)
Light Infantry - Infantry (Leather) - Heavy Infantry (Scale) - Heavy Infantry (Chain)
Light Skirmisher (Leather) - Skirmisher (Scale) - Skirmisher -(Chain) - Skirmisher (Plate)

So there is quite a bit of work to be done here in XML.

Therefore, if you don't mind, Lib.Spi't, if you all reckon that it is opperative to have one more monkey working here, I could start with one of the XML files.

But one of the problems of having different people working here is common names for tags. For example, the <ProfessionType> tag for pikemen is PROFESSION_INFANTRY3

So when we create the subprofession of Heavy Pikeman (Plate), should it be PROFESSION_INFANTRY3_PLATE or some other? How do we proceed for the following tags?

Similarly, I have to say that I will be yielding few hammers per turn because I am currently a bit busy. Taking all this into account, are my monkey tricks of any use to you?

 

[Kailric]

Similarly, I have to say that I will be yielding few hammers per turn because I am currently a bit busy. Taking all this into account, are my monkey tricks of any use to you?

Oh yeah, plenty of use. All you have to worry about modding is the CIV4Professionsinfo.XML. Either I or Nightinggale can run the script when that is done to get the graphics updated. Just make a post on there which ones of the Professions is on your todo list and give updates on your progress. It really want take all that long to do it all, just making the time to do it

As far as naming, just make sure you use different names than what is already there. PROFESSION_INFANTRY3_PLATE, could better be PROFESSION_PIKEMAN_PLATE, just use that naming scheme in the Subprofessions, Profession/Unit Name/Armor that makes it different. Anyway, questions just ask

 

[Nightinggale]

CIV4UnitInfos.xml

This is the only file we need to edit manually. The other files are either done or can be fixed by existing scripts.
EDIT: oops, copy paste error. It should have said CIV4ProfessionInfos.xml

But one of the problems of having different people working here is common names for tags. For example, the <ProfessionType> tag for pikemen is PROFESSION_INFANTRY3

So when we create the subprofession of Heavy Pikeman (Plate), should it be PROFESSION_INFANTRY3_PLATE or some other? How do we proceed for the following tags?

The game will tell you if you use the same tag (type) more than once. However it should be avoided as the game will not work as intended if that happens. Getting a general agreement on how to name professions is a good idea and the proposed PROFESSION_INFANTRY3_PLATE isn't bad. However multiple infantry sounds like a relic of the old system. Maybe infantry PROFESSION_INFANTRY3 should really be a subtype in PROFESSION_INFANTRY2 or maybe both should be in PROFESSION_INFANTRY1, which then becomes PROFESSION_INFANTRY. This is actually the really tricky part we face now. How to group the professions now that we can join an unlimited number into a single group. This is more of a design question than a technical question as the game itself doesn't care.

Maybe we should just postpone the group creation for now and focus on getting rid of alt equipment, which was the original goal.

 

[Kailric]

This is the only file we need to edit manually. The other files are either done or can be fixed by existing scripts.

Maybe we should just postpone the group creation for now and focus on getting rid of alt equipment, which was the original goal.

CIV4UnitInfos.xml? What exactly are we editing in that one? I thought we had to manually add in the Professions in ProfessionsInfo.xml?

While we are getting rid of alt equipment may as well add the subprofessions.

 

[orlanth]

I don't envision using a ton of military professions or sub-professions, but still like the new combat features (deflection and armor-piercing etc) and mainly wanted to be able to use these with non-citizen units which don't adopt professions (ie naval vessels and beasts, which don't take on or off equipment or work in professions). Even if the M:C base mod uses professions only, is there some way to also be able to apply these effects to normal units via promotions, so you could invest in techs that could apply one of those combat effects to certain classes of ships?

 

[Kailric]

Even if the M:C base mod uses professions only, is there some way to also be able to apply these effects to normal units via promotions, so you could invest in techs that could apply one of those combat effects to certain classes of ships?

We could add CombatGears to Promotions perhaps, but would then have to cycle through all acquired promotions to see if they have the CombatGears. There is probably a better way...

 

[Nightinggale]

I added geartypes to sub professions and pushed this change. I also added ArrayEnable.

<ArrayEnable>012</ArrayEnable>
<CombatGearTypes/>
<YieldEquipedNums/>
<FreePromotions/>

The options are:
0: use parent settings
1: use sub profession settings
2: merge sub profession settings with parent

ArrayEnable has 3 digits, one for each array. In this case the settings are
0: <CombatGearTypes/>
1: <YieldEquipedNums/>
2: <FreePromotions/>

Naturally any combo can be used.


As for assigning gear to promotions... hmmm... if we do that, then we certainly needs to cache gear in CvUnit. I'm not sure if that is a good idea or not.

I have been thinking of bool arrays. The compiler assigns 32 bit to a bool to optimize for CPU instructions. However the compiler is from 2003. Now memory latency is likely a bigger issue, which mean a bool should be 1 bit. I'm wondering if it is a good idea to make something like just-in-time arrays, but only for bools, in which case they are always allocated, but only use one bit for each bool. If I implement something like that, then the price of having bool caches in units is greatly reduced.

 

[Trade Winds]

Alright. Our monkey work is on CIV4Professionsinfo.XML and CIV4UnitInfos.xml.

I will start with CIV4UnitInfos.xml. As I am not good enough at github, and I don't
want to mess it up, I will work with the file on my computer.
I'll post my progress from time to time.

I will pick logical tags for the new subprofessions, but as you know, they can be easily changed later if we don't like them.

 

[Lib.Spi't]

I think Kails was pretty good, PROFESSION_UNITNAME_ARMOUR

Although I say that not yet having looked at the code

I shall look at profession.xml and see what is what!

 

[Nightinggale]

Alright. Our monkey work is on CIV4Professionsinfo.XML and CIV4UnitInfos.xml.

The recent change affects professions, not units. However I certainly wouldn't mind if you do something useful with units

I will start with CIV4UnitInfos.xml. As I am not good enough at github, and I don't want to mess it up, I will work with the file on my computer.

The idea with git is that you make a copy on your computer and then send it out once it works. You can revert a file to how it look at github in case you messed up and it isn't uncommon to do that. However as it is a local change, it is usually not mentioned on the forum
https://github.com/Nightinggale/Medieval_Tech/wiki/GIT-start-guide
https://github.com/Nightinggale/Medieval_Tech/wiki/GIT-usage

Besides you can't mess up the code on github without write permission

I will pick logical tags for the new subprofessions, but as you know, they can be easily changed later if we don't like them.

There isn't a specific plan for what to name the different kind of professions, though there are guidelines in this thread. Your ideas for naming could be as good as our. Don't hold back

I don't envision using a ton of military professions or sub-professions, but still like the new combat features (deflection and armor-piercing etc) and mainly wanted to be able to use these with non-citizen units which don't adopt professions (ie naval vessels and beasts, which don't take on or off equipment or work in professions). Even if the M:C base mod uses professions only, is there some way to also be able to apply these effects to normal units via promotions, so you could invest in techs that could apply one of those combat effects to certain classes of ships?

Basically you are saying you want to make say brontosaurus and then you want to give it the gear "big animal", which some promotions can then gain attack bonus against.

I think that would be doable. The info should then be placed in CvUnitInfo meaning it should be added to the unit XML. When it is used it will check both the profession and the unit and say it has the gear type if either has it. This is a fairly simple check while promotions is way more complex.

I have been thinking of bool arrays. The compiler assigns 32 bit to a bool to optimize for CPU instructions. However the compiler is from 2003. Now memory latency is likely a bigger issue, which mean a bool should be 1 bit. I'm wondering if it is a good idea to make something like just-in-time arrays, but only for bools, in which case they are always allocated, but only use one bit for each bool. If I implement something like that, then the price of having bool caches in units is greatly reduced.

I have been thinking. Such a change makes reading faster, but writing slower. If all 32 bits are known when writing then the CPU will just write it without caring for existing content. If less than all bits are known, then it will have to read first. This mean a size reduction might not be that ideal for memory often written to, but nice to have for write once, read many memory, like infos. This makes me question if it is a good idea for a cache in CvUnit.