Forcing Factions to use Custom Skins- HELP DEVS!!!

Stuck on this

from Elemental Forums

Ok, tonight Dhuran and I were trying to lay the basis for the update to Undead Rising which will have a custom Undead faction with Skeleton soldiers and Zombies. The problem is we can't get the faction to use my custom undead skins. I was trying some experiments to see if I could get the AI to use any of my custom skins and I found that I could but only randomly even after I tweaked the % values of what other skins they would use would show up to zero.

I fired up Stardock's Faction Creator and went to a race I know I had skinned, the Quendar. In the pic where it shows what Race you want your custom faction to be it shows a picture of the race. About 1 out of every 3 or 4 times it would shows a pic of my custom skin, like this:

What we need to accomplish to get the skins working for Undead Rising 2.0 is to FORCE the Faction/Race to use my skin all the time and NOT use the other skins that could go on that associated model. My undead skeleton skin uses the standard human model so it can shows up on a wide range of races in game. I only want it to show on one custom race, the undead, for making the undead faction. When we set the AI to play as the undead faction we want them to design units who's models use ONLY my custom skin and not any of the other human default skins. I'd also like to take this knowledge and apply it to updates for my other skins so the AI uses them instead of the default skins.

There are a couple different areas where we tried to tell it to use the skin. First we started in the obvious places. CoreSkins.Xml has these entries:

<RandomPeasantUnitLiklihood>50</RandomPeasantUnitLiklihood>
    <RandomMerchantUnitLiklihood>50</RandomMerchantUnitLiklihood>
    <RandomHeroUnitLiklihood>50</RandomHeroUnitLiklihood>

Which I tweak to 100 and then lower the likelihood of the other skins showing up to 0. Even doing that though my custom skin only shows up randomly 1 out of every 4 or 5 times. If I redefine the skin sets that the race can use it still uses the other one's associated with it's model type and doesn't always use mine.

Then we thought "Maybe we have to define a specialized undead race and tell it to only use the skin. So we checked out the Xml's dealing with Races, of which there are two. CoreRaceConfigs.xml and CoreRaceTypes.xml . Both of them have a value named:

<GenericUnitType_Male>Men_GenericBaseUnit_Male</GenericUnitType_Male>

That defines what model the race uses but Not what skin it puts on that model. Tweaking the likelihood of certain skins showing in the CoreSkins.xml doesn't work, and these two xml's don't even have a value line to define the skin. Can a line to define the skin a race uses be added so it doesn't use other skins that work with it's model?

Please tell me we can do this without needing to open the model files and define what skins it uses there, because we don't have the tools to open the model files formats which come in two flavors, HKB's and DDS's. There has to be some other way to define specifically what skin a model/race/faction will use and have it use no others.

Please Devs.....HELP!!!!! Anyone?

Note: Sorry if that seems confusing talking mostly about the Undead and showing the Quendar. I showed the Quendar in the example because I got it showing up (though only once every few tries of picking Quendar as a race). Once I figure out how to get the Undead skin to show for ONLY the undead "race" and get it showing every time the AI would make a unit, I can apply that knowledge to my Quendar and Urxen as well so I face the ones I skinned in battle and not the default ones. This will also come in handy for other mods and modders who want to force a race/faction to use a custom skin for making races in mods.

Thanks for the help.

 

5,434 views 22 replies
Reply #1 from Elemental Forums Top

 

Well, I havn't tried it myself but you seem to be go in the good way.

Have you tried to define a new race like in CoreRaceTypes.xml (linked to a new faction in CoreRaceConfigs.xml) like: 

 

Code: xml
  3. &lt;RaceType InternalName="Race_Type_Undead"&gt;
  4.     &lt;DisplayName&gt;Undead&lt;/DisplayName&gt;    &lt;RaceClassification&gt;Undead&lt;/RaceClassification&gt;    &lt;UnitScale&gt;1.0&lt;/UnitScale&gt;    &lt;UnitSkinColor&gt;215,150,100&lt;/UnitSkinColor&gt;    &lt;UnitHairColor&gt;155,110,75&lt;/UnitHairColor&gt;
  5.     &lt;!-- **    Base Units    ** --&gt;    &lt;MaleUnitType&gt;Undead_Sovereign_Male_Basic&lt;/MaleUnitType&gt;    &lt;FemaleUnitType&gt;Undead_Sovereign_Female_Basic&lt;/FemaleUnitType&gt;    &lt;GenericUnitType_Male&gt;Undead_GenericBaseUnit_Male&lt;/GenericUnitType_Male&gt;    &lt;GenericUnitType_Female&gt;Undead_GenericBaseUnit_Female&lt;/GenericUnitType_Female&gt;    &lt;!-- **   Special Units    ** --&gt;    &lt;StartingUnitType&gt;Undead_Pioneer&lt;/StartingUnitType&gt;    &lt;StartingUnitType&gt;Undead_Soldier&lt;/StartingUnitType&gt;    &lt;StartingUnitType&gt;Undead_Assassin&lt;/StartingUnitType&gt;    &lt;StartingUnitType&gt;Undead_Adventure&lt;/StartingUnitType&gt;    &lt;StartingUnitType&gt;Undead_thief&lt;/StartingUnitType&gt;    &lt;StartingUnitType&gt;Undead_Knight&lt;/StartingUnitType&gt;    &lt;StartingUnitType&gt;Undead_Guardians&lt;/StartingUnitType&gt;    &lt;StartingUnitType&gt;Undead_Enforcers&lt;/StartingUnitType&gt;    &lt;StartingUnitType&gt;Undead_Sions&lt;/StartingUnitType&gt;    &lt;!-- **   Trade Units    ** --&gt;    &lt;!--&lt;TraderUnitType&gt;Undead_Merchant&lt;/TraderUnitType&gt;    &lt;TraderUnitType&gt;Undead_Trader&lt;/TraderUnitType&gt;    &lt;TraderUnitType&gt;Undead_Caravan&lt;/TraderUnitType&gt;--&gt;    &lt;!-- **  Temp Units    ** --&gt;    &lt;TraderUnitType&gt;TraderTest&lt;/TraderUnitType&gt;    &lt;StartingUnitType&gt;Undead_Soldier&lt;/StartingUnitType&gt;    &lt;StartingUnitType&gt;Undead_Pioneer&lt;/StartingUnitType&gt;
  6.   &lt;/RaceType&gt;
  8. &gt;

 

and then creating all the needed entries in CoreUnits.xml (keeping the same model but assigning a new skin) to finally create new skins in CoreSkins.xml directing to your custom textures.

like:

Code: xml
  3.  "...  
  5.  &lt;UnitSkinTextureDef InternalName="F_Male_Undead_Texture_01"&gt;    &lt;DisplayName&gt;Undead&lt;/DisplayName&gt;    &lt;Icon&gt;Undead.png&lt;/Icon&gt;    &lt;SkinTextureFilename&gt;Undead_Skin_M.png&lt;/SkinTextureFilename&gt;
  6.     &lt;SupportedUnitModelType&gt;UndeadMale&lt;/SupportedUnitModelType&gt;
  7.     &lt;RandomPeasantUnitLiklihood&gt;70&lt;/RandomPeasantUnitLiklihood&gt;    &lt;RandomMerchantUnitLiklihood&gt;30&lt;/RandomMerchantUnitLiklihood&gt;    &lt;RandomHeroUnitLiklihood&gt;5&lt;/RandomHeroUnitLiklihood&gt;  &lt;/UnitSkinTextureDef&gt;
  9. ..."

 


Please tell me we can do this without needing to open the model files and define what skins it uses there, because we don't have the tools to open the model files formats which come in two flavors, HKB's and DDS's. There has to be some other way to define specifically what skin a model/race/faction will use and have it use no others
End of quote

The only models are in HKB format, dds is a texture format wich I assume is read by default by the game before any png (this format is more performant overall).

You can find some dds plugins on NVIDIA site for both photoshop and the gimp if you want to give it a try.

 


Edit:

Ok, I'm not very clear here, so, basically I think it works like this:

In CoreRaceConfig.xml you can link a race to your faction, the race is defined in CoreRaceTypes.xml

in CoreRaceTypes.xml you assign the various units for your race wich are stored in CoreUnits.xml

in CoreUnits.xml you define for each unit the model (HKB format) and the skin (not a file yet but a link to CoreSkins.xml)

in CoreSkins.xml you link the skin with the file (png) and the model type (in CoreUnits.xml)

 

And I think that's all, I can not test it and I'm maybe missing a link somewhere but I think it should work.

 

PS: the specifics units for Fallen races are stored in different xml (ex: CoreQuendarBaseUnits.xml)

 

Reply #2 from Elemental Forums Top

I attempted to do this exact same thing using your skeleton skin, for use in a personal mod. I wasn't able to get it to use the skin on the GenericBaseUnit_Male & GenericBaseUnit_Female units, but I was able to create skeleton versions of the default Pioneer and Peasant units, and get them to show up as the 2 default units available in game.

 

Originally, the default NPCs didn't even have skins, they were just floating clothing and hair. I'm not sure what fixed that, but now they show up with an all black skin, instead of the skeleton skin.

 

Don't know how much help it will be, but here's my attempt at creating the Undead Race Mod: http://depositfiles.com/files/7mie0s347

Ashes of the Singularity II
Reply #3 from Elemental Forums Top

First, I think coreracetypes is no longer in use. Nothing I changed had any effect.

I got your texture to work on a faction's generic unit. This is how I did it

First, from your raceconfig:

<GenericUnitType_Male>yourunitnamehere</GenericUnitType_Male>

Then create a new unit with

 

        <ModelPath>Gfx\HKB\Units\K_Male_Mesh_01.hkb</ModelPath>
        <SkeletonPath>Gfx\HKB\Units\K_Male_Skeleton_01.hkb</SkeletonPath>
        <EyeTexture>gfx\Eyes\blinks\eyeblink_m1_brwn.png</EyeTexture>
            <Texture_Skin>F_Male_Skel_Texture.png</Texture_Skin>

http://img412.imageshack.us/img412/4225/elemental1283525021.jpg

Then go back to raceconfig because I forgot to change the basic color of the unit. I can't seem to find how to change the underlying skin of the unit (I think it may be shared by everything using the skin, so possibly hardcoded into HKB), so if you set

    <UnitSkinColor>0,0,0</UnitSkinColor>

You'll get a completely black skin.

http://img36.imageshack.us/img36/4441/elemental1283525088.jpg

Here's a simple mod that replaces Umber male units http://www.mediafire.com/?8br9xaot26z7u8o

Edit: Oh yeah, the unittype also has

    <UnitModelType>FallenMale222</UnitModelType>

to avoid other skins being written on it

 

Edit2: oh... THAT is what racetypes does! It manages the generic pre-designed race options for the faction editor. Once a race has been created, all those values are locked into their own, new tags under the raceconfig.

Edit3: An unfortunate side-effect of using a unique modeltype is that every item must be re-assigned to work with that type. Have fun.

 

Reply #4 from Elemental Forums Top

Thanks Guys!!! :) You were all a big help. Heavenfall, you're the man brother :).

Now, what about my Quendar and Urxen showing up randomly in the backgrounds and such when I want the race to use them 24/7?

Also what's up with

Edit3: An unfortunate side-effect of using a unique modeltype is that every item must be re-assigned to work with that type.
End of quote

Does this mean I'll have to make a duplicate of the items and tell them all to work with the sins I specificy?

Reply #5 from Elemental Forums Top

If you look at corearmor for example, each item lists what modeltypes it can be put on.

<SupportedUnitModelType>KingdomMale</SupportedUnitModelType>

Since we had to make a new modeltype, you'll have to make a new list of items with the new modeltype.

I'm not sure what you mean with

Now, what about my Quendar and Urxen showing up randomly in the backgrounds and such when I want the race to use them 24/7?
End of quote

are you trying to do something differently than how the undead is done?

Reply #6 from Elemental Forums Top

Quoting Heavenfall, reply 5
are you trying to do something differently than how the undead is done?
End of Heavenfall's quote

Kinda. See, the Quendar and Urxen are both races in game already with model types of their own. Each of their models has multiple skins and each of those skins has a % chance of showing on the model when they create a new unit. I lowered the chances of the default skins showing to 0 and raised the chances of it using my skins to 100, but it Still only uses my skins about 1 out of every 3 or 4 times when it designs a new unit. I want them to use Only my skin and Not the default skins.

Hopefully I want to avoid having to make new items lists like you describe above since they already have a proper model type. Even if I define a new modeltype using the current I think it would still do what it's doing now and only show up sometimes when I want the skin on Every unit of those factions.

Reply #7 from Elemental Forums Top

the only thing I can think of is doubling for those tags. try putting negative values in your mod to balance out the numbers already in. ie, don't reduce liklihood to 0, but set it to negative its original value.

Reply #8 from Elemental Forums Top

Quoting Heavenfall, reply 7
the only thing I can think of is doubling for those tags. try putting negative values in your mod to balance out the numbers already in. ie, don't reduce liklihood to 0, but set it to negative its original value.
End of Heavenfall's quote

See, that's where code looses it's logic to me. I can understand a negative number being lower than 0 of course, but when you set something to 0 it just shouldn't happen. 0 means no chance, none, so it shouldn't happen. This leads me to think something else in the code somewhere is over-riding it. I'll try the negative numbers as you suggest though. Thank you my friend.

Reply #9 from Elemental Forums Top

Quoting Raven, reply 8

Quoting Heavenfall, reply 7the only thing I can think of is doubling for those tags. try putting negative values in your mod to balance out the numbers already in. ie, don't reduce liklihood to 0, but set it to negative its original value.

See, that's where code looses it's logic to me. I can understand a negative number being lower than 0 of course, but when you set something to 0 it just shouldn't happen. 0 means no chance, none, so it shouldn't happen. This leads me to think something else in the code somewhere is over-riding it. I'll try the negative numbers as you suggest though. Thank you my friend.
End of Raven's quote

 

Agree with you there, 0 ultimately means nothing, or disabled. It has not value attached to it unlike -1- or 1+. IF this works please tell us! Thought I would be suprised o_O

Reply #10 from Elemental Forums Top

The reason to include negative values would be to counter previously positive values in the core files that you can't touch.

I'd say there's about a 10% chance that would work in this case. But it's the only idea I've got.

Reply #11 from Elemental Forums Top

Quoting Heavenfall, reply 10
The reason to include negative values would be to counter previously positive values in the core files that you can't touch.

I'd say there's about a 10% chance that would work in this case. But it's the only idea I've got.
End of Heavenfall's quote

 

Hmm I think I get your idea. But wouldn´t that mean, that somewhere the positive values are already set? Otherwise this would not work, or am I missing something? ^^"

Reply #12 from Elemental Forums Top

Yes, they're set in CoreSkins. CoreSkins is a list of skins that apply to the modeltypes under each internal. I believe the game takes CoreSkins and "reverses" the logic, so that instead of skin->modeltype the game has

ModeltypeKey[nameofmodeltype] { [appliedskin1] [appliedskin2] [appliedskin3] }

Then it chooses a skin from those.

The problem with modifying an already existing skin is that there already exists a skin under the modeltype.So

ModeltypeKey[UrxenMale] { [appliedskin1] }

becomes

ModeltypeKey[UrxenMale] { [appliedskin1] [ravensskin] }

That's why Raven X is trying to set it to likelihood 0.

Reply #13 from Elemental Forums Top

Quoting Heavenfall, reply 12
Yes, they're set in CoreSkins. CoreSkins is a list of skins that apply to the modeltypes under each internal. I believe the game takes CoreSkins and "reverses" the logic, so that instead of skin->modeltype the game has

ModeltypeKey[nameofmodeltype] { [appliedskin1] [appliedskin2] [appliedskin3] }

Then it chooses a skin from those.

The problem with modifying an already existing skin is that there already exists a skin under the modeltype.So

ModeltypeKey[UrxenMale] { [appliedskin1] }

becomes

ModeltypeKey[UrxenMale] { [appliedskin1] [ravensskin] }

That's why Raven X is trying to set it to likelihood 0.
End of Heavenfall's quote

 

I get that ^^, I thought Raven X had it set to 0 already, so Im a bit confused why the game STILL takes the other skins into account, since they shouldn´t be enabled anymore, at least in my book. Even if the game would reverse its own logic, for whatever reason ^^", 0 is still 0, no matter how you turn it.

Do you get my idea?

 

The nagative value suggestion seems interesting, but it doesn`t make much sense to me. UNLESS the positive values are stated somewhere else than those values that are already changed. Wich would mean that likelyhood 0 wouldn´t mean anything.

Reply #14 from Elemental Forums Top

The values are set in the core files already. And Raven X knows he shouldn't modify those, because in a month or two nobody will use modded data.zips

Anyway, I found a reasonable workaround. If you're using an existing modeltype, you can just set your new skin to have a huge likelihood.

    <UnitSkinTextureDef InternalName="F_Male_Urxen_Texture_02">
    <DisplayName>Urxen</DisplayName>
    <Icon>Urxen_M.png</Icon>
    <SkinTextureFilename>F_Male_Skel_Texture.png</SkinTextureFilename>


    <SupportedUnitModelType>UrxenMale</SupportedUnitModelType>


    <RandomPeasantUnitLiklihood>99999999999999999999999999999999999999999999999</RandomPeasantUnitLiklihood>
    <RandomMerchantUnitLiklihood>999999999999999999999999999999999999999999999999</RandomMerchantUnitLiklihood>
    <RandomHeroUnitLiklihood>99999999999999999999999999999999999999999999999999</RandomHeroUnitLiklihood>
  </UnitSkinTextureDef>

You'll still get 0.0000000000(00000)000000000000000000000000001% of the pop using the normal skin, the rest will use the new skin. I have no idea if this will bring a performance problem.

Reply #15 from Elemental Forums Top

Quoting Heavenfall, reply 14
The values are set in the core files already. And Raven X knows he shouldn't modify those, because in a month or two nobody will use modded data.zips

Anyway, I found a reasonable workaround. If you're using an existing modeltype, you can just set your new skin to have a huge likelihood.

    <UnitSkinTextureDef InternalName="F_Male_Urxen_Texture_02">
    <DisplayName>Urxen</DisplayName>
    <Icon>Urxen_M.png</Icon>
    <SkinTextureFilename>F_Male_Skel_Texture.png</SkinTextureFilename>


    <SupportedUnitModelType>UrxenMale</SupportedUnitModelType>


    <RandomPeasantUnitLiklihood>99999999999999999999999999999999999999999999999</RandomPeasantUnitLiklihood>
    <RandomMerchantUnitLiklihood>999999999999999999999999999999999999999999999999</RandomMerchantUnitLiklihood>
    <RandomHeroUnitLiklihood>99999999999999999999999999999999999999999999999999</RandomHeroUnitLiklihood>
  </UnitSkinTextureDef>

You'll still get 0.0000000000(00000)000000000000000000000000001% of the pop using the normal skin, the rest will use the new skin. I have no idea if this will bring a performance problem.
End of Heavenfall's quote

 

Nice workaround!

Now I get what you meant, since the values are already set in the core files, the moded xml has to balance out in a way, right? Hmm what if the moded xml would refer to the original setting, "replacing" it with its own settings. Of course that would change teh base race itself, but wouldn´t it also "negate" unwanted skins? Since the core values are edited by an external mean, it would be pretty easy to turn off, if not wanted, given that it works the way I just talked about ^^

 

Reply #16 from Elemental Forums Top

Unfortunately, in this case it appears that even if you use the same internalname, it does not overwrite the existing skin linked to the modeltype. Instead it just adds another skin link.

Reply #17 from Elemental Forums Top

Quoting Heavenfall, reply 16
Unfortunately, in this case it appears that even if you use the same internalname, it does not overwrite the existing skin linked to the modeltype. Instead it just adds another skin link.
End of Heavenfall's quote

 

Ah as I thought than, to bad, well we have your workaround ^^, thanks for that!

Reply #18 from Elemental Forums Top

Uh I just created an xml that distributes my selfmade skins to my race, I simply set all likelyhoods to 0 except my skins and it works without problems oO

 

The downside is, that there are more entries in the skin section at SOV creation.

Reply #19 from Elemental Forums Top

Quoting Heavenfall, reply 16
Unfortunately, in this case it appears that even if you use the same internalname, it does not overwrite the existing skin linked to the modeltype. Instead it just adds another skin link.
End of Heavenfall's quote

 

That's ultimately the problem we were running into. It looks like you need to define a new model type so that you can have a model that is linked only to that skin. The only other thing I could think of to be 100% sure of only getting that skin on a model is to remove an existing models reference to other skins. But that would effectively take one of the other races out, and replace them all with whatever skin you're using.

Reply #20 from Elemental Forums Top

Out of curiosity, cant we define a new race and than apply the skin to that race via .xml?

Reply #21 from Elemental Forums Top

Yes, we can. That was the first solution I posted. A new modeltype.

Reply #22 from Elemental Forums Top

Quoting Heavenfall, reply 21
Yes, we can. That was the first solution I posted. A new modeltype.
End of Heavenfall's quote

 

I realized that just now ^^"