DLL coding thread

[Kailric]

Well, 2071 should have the control to the new civics screen if orlanth wants 2071 to have civics. This should just be merged into 2071. I thought this was what was happening with the shared DLL. If a mod doesn't want to use Civics we would need to add a global define to turn it off.

Ok, yeah I wasn't meaning to up date the pak files every push. But when they are ready to be updated I'll know which one to use.

 

[Nightinggale]

I thought this was what was happening with the shared DLL. If a mod doesn't want to use Civics we would need to add a global define to turn it off.

I think you missed the issue. Col2071 want the civic screen and it has access to the DLL part. However there is an XML part too and nobody was aware that of that fact and it complained as the XML part was missing. However the error message more or less said that something went wrong with commands.

We should figure out a way to make other mods aware that XML updates are needed. I just have no idea how to do that without adding lots of manual work, which will most likely be forgotten next time it should be used.

 

[Kailric]

I think you missed the issue. Col2071 want the civic screen and it has access to the DLL part. However there is an XML part too and nobody was aware that of that fact and it complained as the XML part was missing. However the error message more or less said that something went wrong with commands.

We should figure out a way to make other mods aware that XML updates are needed. I just have no idea how to do that without adding lots of manual work, which will most likely be forgotten next time it should be used.

Ah, ok. Well, for the most part when we add new attributes to XML we just need to be sure to inform others in our commit and perhaps on the forums what we changed. Automation would be best but manual is better than nothing.

 

[Kailric]

I am still not sure what to do about the:

Assert Failed

File: CvXMLLoadUtilitySet.cpp
Line: 87
Expression: result == files.checksum
Message: Calculated checksum: eac9cbd967c10c3c805c50a07af99bef

Can you enlighten me some more?

 

[Nightinggale]

File: CvXMLLoadUtilitySet.cpp
Line: 87
Expression: result == files.checksum
Message: Calculated checksum: eac9cbd967c10c3c805c50a07af99bef

First there is an error message telling that your schema file is out of date and that you should update it unless you modified it intentionally.

Next there is an assert on the very same file. Here it tells where it asserts. If you open the file, you will see the previous lines contain the checksums for all schema files. Update those.

I did it for you this time: http://sourceforge.net/p/colonizati.../ci/facc9c7889295228fb16185b7c969fbd1a08e69d/

I made a pre commit checklist: http://sourceforge.net/p/colonizationmodcollection/wiki/Pre Commit checklist/
As you didn't use the standard intenting you clearly skipped the indent script. It is important to indent the schema files correctly as incorrect indents modifies the checksum. The script will help us to use the same indenting and hence the same checksums.

 

[Kailric]

First there is an error message telling that your schema file is out of date and that you should update it unless you modified it intentionally.

Next there is an assert on the very same file. Here it tells where it asserts. If you open the file, you will see the previous lines contain the checksums for all schema files. Update those.

I did it for you this time: http://sourceforge.net/p/colonizati.../ci/facc9c7889295228fb16185b7c969fbd1a08e69d/

I made a pre commit checklist: http://sourceforge.net/p/colonizationmodcollection/wiki/Pre Commit checklist/
As you didn't use the standard intenting you clearly skipped the indent script. It is important to indent the schema files correctly as incorrect indents modifies the checksum. The script will help us to use the same indenting and hence the same checksums.

Ok, thanks. Just how do you "Update those"? You mean by pulling files?

Indents are weird as I never like to have wild indents and strive to keep things inline. My files look great when I commit them so I haven't thought to do the indent script.

 

[Nightinggale]

Ok, thanks. Just how do you "Update those"? You mean by pulling files?

Update as in open them in notepad++ and edit them. If this is done every time somebody commits XML files, then indenting should be correct when pulling.

Indents are weird as I never like to have wild indents and strive to keep things inline. My files look great when I commit them so I haven't thought to do the indent script.

The problem is that XML editors tend to use tab. If I have a tab set to 4 spaces and you have it set to 3 spaces, then it would still look fine if we use tabs exclusively. However some editors replace tabs with spaces and all of a sudden some lines use tabs (4 spaces) while others use 3 spaces and we have the problem.

Even if we agree on width of tabs, we still have one tab vs 4 spaces, which would give different checksums. As we need to be strict about the checksum to make other mods aware that we updated the schema files, we need to be consistent regarding indents. It wasn't really important before the DLL started using checksums.

The whole idea with checksums is that now that we updated some files in M:C, the next time somebody pulls col2071, the DLL will warn that the col2071 version of the schema files are out of date compared to what the DLL expects. That should make it much easier to keep all mods up to date.

 

[Kailric]

Update as in open them in notepad++ and edit them. If this is done every time somebody commits XML files, then indenting should be correct when pulling.

Please forgive my ignorance but when I open them in notepad++ (do you have to use notepad++?) what do I edit? What am I suppose to edit or add or change? Can you give an example of this.

Sorry, I am not quite following you here.

The idea of checksums sounds great, I just haven't figured out how to do this.

 

[Nightinggale]

Err... let's try an example.

1. edit a schema file in notepad++ or whatever
2. save
3. run indentXML.pl
4. start the game
5. copy the calculated checksum from the assert message
6. paste the checksum to the line for the schema file in question in CvXMLLoadUtilitySet.cpp (around line 80)

It is supposed to be trivial enough to not restrict us from updating schema files if we need to do so.

The assert isn't strictly needed, but I added as a reminder where in the code you have to update and it shows the calculated value you need to insert to avoid having to calculate the checksum manually.

 

[Kailric]

I decided that I need to bring back the discovery of Spice Route by moving on to an access plot. However, I am having an issue:

CivicTypes eSpiceRoute = (CivicTypes)XML_TRADE_ROUTE_SPICE, is not returning the correct civic, it returns the enum value of XML_TRADE_ROUTE_SPICE being 127 instead of the TRADING_TRADE_ROUTE_2 CivicInfos value. I've had the kind of issue before, any ideas?

Also, I broke saved games with this update as I added a new FeatType, "FEAT_DISCOVER_SEA_TRADE_ROUTE", so perhaps FeatTypes need to be fixed to be moddable as I do have plans to add more.

I have also added a new popup for gaining new Civic Options. I would forget to check some times when I gained a new Tech to see if I had new Civic Options, so I would go many turns with inferior Civics. Now you get reminded each time you gain a new one.

 

[Nightinggale]

(CivicTypes)[B]GC.getXMLval([/B]XML_TRADE_ROUTE_SPICE[B])[/B]

XML_TRADE_ROUTE_SPICE is the index in the cache while GC.getXMLval() reads the actual value stored in the cache.

Remember that other mods use this source code too. Maybe you need

#ifdef MEDIEVAL_CONQUEST

I'm not 100% sure though as I'm not that much into how trade screen access works.

 

[Kailric]

That's it then. That was my issue too before I bet. I wasn't understanding how the system worked.

 

[Kailric]

I just deleted the old M:C and re cloned the new one. I attempted to build the DLL but YIELD_GRAIN is still used through out the DLL but has been replaced by YIELD_LUXURY_FOOD. Did you replace YIELD_GRAIN in all the cpp files, or the wrong cpp files get added??

 

[Nightinggale]

I attempted to build the DLL but YIELD_GRAIN is still used through out the DLL but has been replaced by YIELD_LUXURY_FOOD. Did you replace YIELD_GRAIN in all the cpp files, or the wrong cpp files get added??

Works for me. Looks like you are using an outdated source.

In directories, click on sourceDLL.
Click pull.

After that make sure you are using the master branch. Default is not using a branch, rather some specific revision in master. I'm working on a solution for that problem (git hooks).

The same goes for python. That one too should use master branch.

 

[Kailric]

Ahh yeah, the ole branch switch trick as before Ok, it is building now and is already into the python cpp files so, actually its done, so looks like that solved the issue. What would we do with out Night!

Boom, its completed successfully! Now, to see if the game loads

PS The game loads. One thing that annoys me as I load into a game the yields flash on the screen for a second. I haven't looked at it but can this be fixed?

 

[Nightinggale]

What would we do with out Night!

Presumably sleep during the day

One thing that annoys me as I load into a game the yields flash on the screen for a second. I haven't looked at it but can this be fixed?

We talked about moving the yield row(s) to a python file of its own to make it dynamically add/remove yields during the game. That will fix this issue. I looked a bit at it but never really did anything to it.

Other than that I don't think anybody really looked into why the yields flash like that.

 

[Kailric]

I just had an idea. We can make m_eOriginalOwner and then the unit will use graphics from that player, even after being captured. With a bit of clever coding we can skip having Viking/Arabic versions of units. Instead we use this variable to assign graphics.... somehow.

I see where you messaged this, I don't know if you looked into it or not but it looks possible. In Unit.cpp we can intercept the Unit art style code, check for previous owner, and then use their art style instead.

For the Natives I would need to create a None profession unit. Right now, since Natives are never on the map with out a profession they use their Warrior profession art as default. So, I could create a none weapon holding native Unit for this feature. Some how we would have to work out the Profession art though. Say, If you have a convert that uses its original art, what profession art will it use? It starts to get complicated...

 

[Nightinggale]

For the Natives I would need to create a None profession unit. Right now, since Natives are never on the map with out a profession they use their Warrior profession art as default. So, I could create a none weapon holding native Unit for this feature. Some how we would have to work out the Profession art though. Say, If you have a convert that uses its original art, what profession art will it use? It starts to get complicated...

Use the arts from the original civ. Natives don't have the worker profession, but they can still have the art for it (I think). We can then make them use the default art unless specified otherwise. That way somebody can add the art later or we can skip special art for some professions etc.

I seriously haven't thought this one through. Maybe it is a bad idea because it takes too much time compared to what we gain.

 

[Kailric]

I seriously haven't thought this one through. Maybe it is a bad idea because it takes too much time compared to what we gain.

Welcome to my world, that's why M:C was such a jumbled mess when you arrived

Just what do we want from this feature?

If we capture or convert a Unit we want to keep it's original graphic if the unit has no outside profession? Is that what we want?

We should keep all profession art for the player the same as it could get really confusing, like all Infantry units should be the same. Other than the textures for wearing Leather armor and such.

So, when the Convert/Captured unit is in its default profession (PROFESSION_BRAVE for Natives) it will use the previous owner's graphic for PROFESSION_BRAVE. There is no art assigned to PROFESSION_BRAVE so it will use <ProfessionType>NONE</ProfessionType>, which default is ART_DEF_UNIT_MAGYAR_WARRIOR, unless specified different in Civ4UnitArtStyleTypeInfos.

So, I would need to create Art for them being PROFESSION_COLONIST, if we want them to look the same but carry no weapons, that is have no outside profession.

Natives currently have no Worker art. When I make them more like Minor Civs, should we allow them to improve the land? Anyway, that is a discussion for another thread

On a different note I discovered a new app for my phone that will allow me to access my PC, run programs and such, even M:C. It has the ability to do this even away from home but I will need to set it up just haven't done that yet. M:C is playable from my iphone now It is a bit tedious however, but with some practice and some autokey scripts it would get easier perhaps. I can at least let the AI run through some turns and even debug to a certain extent. All the more reason to get an smart phone Night

 

[Kailric]

I found another failed assert...

When you learn a tech that allows a profession and disallows another the code cycles through all Units, finds the disallowed profession and force applies the new Profession. This however, causes issues if the two professions require different Equipment if the city in question does not have the equipment it will be set to negative numbers, thus causing a failed assert.

This code is old and I remember I had crash issues of units having profession's that were no longer allowed so I forced the change.

The tech in question is the Longbow tech were it allows Longbowmen and Obsoletes Archers. This issue arises because Archers require Tools and Longbow requires Weapons. So, to address this at the moment I removed Archers from being obsoleted by Longbow techs. Since they use different equipment now it would seem there is no need to obsolete anyway.

But, in the future this would be an issue, so we need to look into addressing this.