DLL coding thread

[Kailric]

That looks great. I have no idea how you did that though

Ah ha, seems I have one up on you now, or better yet, one up closer

Right now subs use the same graphics as parent. I plan on writing a script to alter graphics of a specific profession like profession X now uses graphics string Y. It's more complex as just replacing because archer graphics shouldn't be changed.

You mean like a perl script? I am thinking, could we add the art tag to subprofessions, and then couldn't we simply adapt the dll to pick up that art tag, so that's all we have to do is add the new art tag to subprofessions?

I know you can change unit graphics in the DLL because for the Saracen Marauders I have it coded (somehow but can't remember and don't have the time to look) so that when they move to water their graphics change to a Raiding Galley then changes back when they leave water. I'll have to look up what I did there when I get back home.

 

[Nightinggale]

Ah ha, seems I have one up on you now, or better yet, one up closer

I never hid the fact that I haven't figured out how to do graphics. In fact it says so on page 1 in the RaRE thread (asking for help).

You mean like a perl script? I am thinking, could we add the art tag to subprofessions, and then couldn't we simply adapt the dll to pick up that art tag, so that's all we have to do is add the new art tag to subprofessions?

We can do that, but isn't there a point in having the same string in many places? I mean can we come in a situation where it would be beneficial to us to have different strings?

Apart from that I like the idea of only writing the string in a single location.

I know you can change unit graphics in the DLL because for the Saracen Marauders I have it coded (somehow but can't remember and don't have the time to look) so that when they move to water their graphics change to a Raiding Galley then changes back when they leave water. I'll have to look up what I did there when I get back home.

If you had used git back then, then we could just look in the log and quickly get an overview of precisely what you changed

 

[Kailric]

Yeah, I thought of that on ride to school. It's not really practical because different Civs can have different graphics for the same profession as well as units like Masters, so scratch that

 

[Nightinggale]

Yeah, I thought of that on ride to school. It's not really practical because different Civs can have different graphics for the same profession as well as units like Masters, so scratch that

The idea is not that bad. It just needs to be done correctly. Say we add the string to profession info. We can then optionally add it everywhere else and if it isn't added, it will fall back to use the one written in profession.

 

[Kailric]

Well, I tell you what would be cooler is that addition to Civ4 that I never seen any results of, that being promotions changing up graphics. Ive mostly just heard of it, but have been meaning to look into it.

 

[Lib.Spi't]

Yeah that is the promo reference in civ, and I think you jsut link it to a nif (I think it is the nif... I forget which thing handles what in the graphics... it might even be .dds... Ugh I don't know!
It is basically a reskin from what i have sseen it used for.

I have seen it used to make infantry with medic armbands for the medic promos

<LayerAnimationPath>NONE</LayerAnimationPath>

However I don't think it works for unitartstyles... as it would essentially replace an asian model with the euro model with a medic armband I think... So suddenly compulsory plastic surgery would come with a medical qualification...

 

[Nightinggale]

Well, I tell you what would be cooler is that addition to Civ4 that I never seen any results of, that being promotions changing up graphics. Ive mostly just heard of it, but have been meaning to look into it.

I don't know how somebody else did it, but I have a pretty good feeling that it could be done with this function:

const CvArtInfoUnit* CvUnit::getArtInfo(int i) const
{
	//Androrc UnitArtStyles
//	return m_pUnitInfo->getArtInfo(i, getProfession());
	return m_pUnitInfo->getUnitArtStylesArtInfo(i, getProfession(), (UnitArtStyleTypes) GC.getCivilizationInfo(getCivilizationType()).getUnitArtStyleType());
	//Androrc End
}

I have an idea for an improved version.

const CvArtInfoUnit* CvUnit::getArtInfo(int i) const
{
	return this->getCachedArtStyle(i);
}

If we cache which art to use, then we will be free to write slow code to figure out which art style to use, like looping all promotions. Caching this might be a good idea anyway as it appears to use pretty static data. It needs to refresh cache when changing profession, but apart from that the rest might be static. I wonder about i. It's an index, but how many can there be? With a bit of luck it's always 0.

 

[Kailric]

Yeah that is the promo reference in civ, and I think you jsut link it to a nif (I think it is the nif... I forget which thing handles what in the graphics... it might even be .dds... Ugh I don't know!
It is basically a reskin from what i have sseen it used for.

I have seen it used to make infantry with medic armbands for the medic promos

<LayerAnimationPath>NONE</LayerAnimationPath>

However I don't think it works for unitartstyles... as it would essentially replace an asian model with the euro model with a medic armband I think... So suddenly compulsory plastic surgery would come with a medical qualification...

What version are you using or mod? I can't find this code in my civ4 bts?

 

[Nightinggale]

I found this thread on how to override unit art styles.
http://forums.civfanatics.com/showthread.php?t=285992
It wants to do so from python. Somehow I prefer to do it in DLL if possible.

Funny thing is that I was actually looking for something completely different

 

[Kailric]

Well, it seems like pretty much with this code, we can put UnitArt Infos anywhere we want. Androrc made up an entire new system and it works great. I would love to be able to do both, change the texture or the whole unit graphic, as sometimes you can just add small changes to the Texture, like I did with the Archer(Leather). Or sometimes you may want to add a new weapon type, or add a shield. In that cause you'd have to have the UnitArtInfo.

const CvArtInfoUnit* CvUnit::getArtInfo(int i) const
{
	//Androrc UnitArtStyles
//	return m_pUnitInfo->getArtInfo(i, getProfession());
	return m_pUnitInfo->getUnitArtStylesArtInfo(i, getProfession(), (UnitArtStyleTypes) GC.getCivilizationInfo(getCivilizationType()).getUnitArtStyleType());
	//Androrc End
}

Edit: Couldn't we simply add a new attribute to Units that stores a PromotionArtInfo and then getArtInfo checks to see if there is PromotionArt saved to the unit, if so it uses that. That way when the Promotion is applied it changes that variable. We'd have to have an Hierchy of Promotion art so the code knows which one it should be used in case a unit could have more than one Promotion Art style. Then we may can add Promotion Art to the Civilization Art sytles.

Edit: Note to self, I need to change the Saracen Marauder effect of changing graphics when it moves to a water tile. This needs to be an XML settings because at the moment I have it set up so that any unit with the MoveAllTerrain bool will change graphics. I coded it for testing and never made it modable. Done talking to shelf.

 

[Lib.Spi't]

ah yeah I took that line from my mod... must have come from BUG or K-mod or one of the other million mods in there!! Sorry!

EDIT: As I think on it more I think it comes from the TLO Tags mod, which adds a lot of tags to promotions, and I think one of his example uses was the medic promo for modern infantry units..

Yeah from what I understand of the issue, the best place for it to be would be to add a subprofessionart tag to the unitstyles file no?
So that way you know if you add a subprofession, you know you need to add the same subprofession to the artstyle.

So you would have
Unitartstyle: SARACEN
Profession: BOWMAN
tag: /faceache/cheese.dds
Subprofession: BOWMAN_LEATHER
tag: /faceache/cheese_leather.dds

although you would want all the art tags, for .kfm and .nif

This is actually a feature that I wanted for FTTW as well for promos as with certain mod comps it was coming very close to being able to make a fully equipment based promotions system. Where you only build a 'basic' unit, and then you get equipment based on available resources.

Is there a need for promotion based art in Col? As with yields and professions, to choose what your unit is equipped as is it ot the subprofessions that need it more than promotions?

Of course if you want to program both I certainly won't argue The more XML tags the merrier as far as I am concerned!

I know this is stating lots of obvious things without doing any of the actual difficult stuff

I don't know how the subprofession code works, but I assume this would be check civ, check civ artstyle, check profession, check subprofession, if not sub profession return profession, ifnot artstyle return standard profession/subprofession art.

I think from an organsiational perspective, keeping all the artstyle information in one place is helpful.

I have now finished wasting everybodies time

 

[Kailric]

I am thinking of dropping the CIVICOPTION_INVENTIONS altogether perhaps so as to better seperate Civic Options from Techs. Right now I have to skip the first civic option in my code, if (CivicOptionType == CIVICOPTION_INVENTIONS) then skip. Plus when I have to build an array of CivicOptions I keep having to build an extra one that isn't used.

I believe this could easily be done. When you do a search for getCivicOptionType most places it appears is where CIVICOPTION_INVENTIONS appears as well. And sense CivicOptions have no real data other than its name there shouldn't be any instances where data is being pulled from a Civic or Tech and accidentally pull a -1 on it's option.

All the places that currently have CIVICOPTION_INVENTIONS can instead use NO_CIVICOPTION or the check could simple be removed depending on that code. If it is NO_CIVICOPTION, then we know it is part of the Tech system. Techs themselves use a <InventionCategory>MEDIEVAL_TECH</InventionCategory> tag to deferentiate between the say MEDIEVAL_CENSURE and MEDIEVAL_TECH.

I am presenting this to Nightinggale to see if there is anything wrong with this approach.

 

[Nightinggale]

Plus when I have to build an array of CivicOptions I keep having to build an extra one that isn't used.

Removing the first civic option should be piece of cake and I think you should be able to do that without problems. Calling it NO_CIVICOPTION could be a problem though as the XML reader is unaware of this name. There are two solutions to this problem

1:
Use NONE instead as the XML reader translates this to -1.

2:
Add NO_CIVICOPTION to the XML reader and hardcode it to -1. This is done in CvXMLLoadUtility::LoadPlayerOptions() (second last function in the file). I used setInfoTypeFromString() to add NONE as -1 there and you should be able to add another -1 on the next line. In fact you can write whatever string you want and then which int it should translate to and then XML will know this without any other code.

In fact using option 2 we can set CIVICOPTION_INVENTIONS to -1 and it will work without modifying CIV4CivicInfo.xml.


First I misread the problem as you wanting to split CIV4CivicInfo.xml and wrote a solution and then I thought about it and I kind of like the solutoin to "the other" problem

I am thinking of dropping the CIVICOPTION_INVENTIONS altogether perhaps so as to better seperate Civic Options from Techs.

The whole invention cache is designed around having techs and civics in the same vector. Splitting them would mean a whole lot more code there.

Right now I have to skip the first civic option in my code, if (CivicOptionType == CIVICOPTION_INVENTIONS) then skip.

Easy solution: do the same as yields. We have cargo and virtual yields in the same array (enum for performance reasons). We define NUM_CARGO_YIELD_TYPES as the first virtual yield meaning if we only want to loop cargo yields, we loop from 0 to NUM_CARGO_YIELD_TYPES. If we want to loop virtual yields we loop from NUM_CARGO_YIELD_TYPES to NUM_YIELD_TYPES.

In case of civics we can make a cache in GC telling the ID of the first non-tech civic. This cache can then be used to loop a sub section of the vector. This will preserve the ability to loop though all techs and civics when figuring out if player can use a certain unit or whatever.

In fact we can extend this system to make a list of first civic of each type and then we can easily find each type if we need to loop a single type (whatever the type is). It will put a demand on XML modders, but I have an idea which will read the XML file, sort the indexes and then read it again. That will allow storing the civics in a different order than in XML, which in turn allows optimized looping due to knowledge of placement.

 

[Kailric]

Add NO_CIVICOPTION to the XML reader and hardcode it to -1. This is done in CvXMLLoadUtility::LoadPlayerOptions() (second last function in the file). I used setInfoTypeFromString() to add NONE as -1 there and you should be able to add another -1 on the next line. In fact you can write whatever string you want and then which int it should translate to and then XML will know this without any other code.

In fact using option 2 we can set CIVICOPTION_INVENTIONS to -1 and it will work without modifying CIV4CivicInfo.xml.

This seems like the simplest solution then. So, all we need to do is like you say:

GC.setInfoTypeFromString("NONE", -1);
GC.setInfoTypeFromString("CIVICOPTION_INVENTIONS", -1); //Tk Civic Change

And then Remove CIVICOPTION_INVENTIONS from enum DllExport CivicOptionTypes

Correct?

 

[Nightinggale]

And then Remove CIVICOPTION_INVENTIONS from enum DllExport CivicOptionTypes

Correct?

Correct, but I don't like DllExport. I wonder if it will screw up something in the exe if we modify anything here. Then again that something would break by adding inventions in the first place, which mean it will likely be ok.

 

[Lib.Spi't]

phew I am so glad that is resolved, your last post made my face hurt NG I really should stop reading this thread it is bad for my health

 

[Nightinggale]

phew I am so glad that is resolved, your last post made my face hurt NG I really should stop reading this thread it is bad for my health

This thread is intended for DLL coding issues and DLL internal design debate. This mean posts like that belong here and if you don't get it, then feel free not to read it.

Besides you should go see a doctor. Your head hurts way too often

 

[Kailric]

Correct, but I don't like DllExport. I wonder if it will screw up something in the exe if we modify anything here. Then again that something would break by adding inventions in the first place, which mean it will likely be ok.

Ok, cool. I'll do this at some point

phew I am so glad that is resolved, your last post made my face hurt NG I really should stop reading this thread it is bad for my health

Then try out this thread instead, I could use some feedback

 

[Kailric]

omited. why can't we delete posts?

 

[Nightinggale]

omited. why can't we delete posts?

Presumably we would need admin permissions to do that. It doesn't look like the forum has a history of giving that to modders, though I have no idea what would happen if we ask them. It isn't a major concern for me and haven't really considered it until I read your post.