• We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
I'm not sure where you're getting the black and red from.
The vanille christian frame.dds is gold on transparent, just like my custom frames.
The vanilla plain.tga is white on transparent and cut to show the inside of frame.dds, just like my custom ones.

Yes, but the transparent areas still have color. Every pixel has a red value, a green value, a blue value, and a transparency value. For the masks, the red is all that has any effect.

The plain.tga is opaque white surrounded by transparent black. White is composed of red + green + blue. In my experiment, the red part was all that mattered. The white area could be red or purple or orange, anything with 100% red. The transparent area doesn't need to be transparent, just 0% red.
 
just played a bit with the white vs transparency plain.tga and it seems to work correctly :



I used paint.net an just save without changing anything to format (it didn't prompted me to choose anything ;) )
it doesn't affect the other partitions.

Are your transparent areas transparent black? Try the same experiment with opaque black instead of transparency. Or solid red on solid green. I spent 4 hours testing it, and all the produced the mask was redness.
 
not sure to follow you exactly but yes, it is transparent black. + when i open it in an editor that don't supports transparency the transparent part turn black.
since it works as is, I see no reason to turn it pure red versus 0% red. + we don't know if it would affect clickability.
 
not sure to follow you exactly but yes, it is transparent black. + when i open it in an editor that don't supports transparency the transparent part turn black.
since it works as is, I see no reason to turn it pure red versus 0% red. + we don't know if it would affect clickability.
Further experiments this morning: Any part of the mask that is 100% transparent is not clickable. The least bit of opacity (1 of 255) makes it clickable. Separately, the degree of redness (or whiteness if you prefer) determines the transparency on screen. So:
  • Transparent black neither draws nor clicks.
  • Transparent white draws but doesn't click.
  • Translucent or opaque black clicks but doesn't draw.
  • Translucent or opaque white draws and click.

Using shades of grey vs. shades of red shouldn't matter at all. With that part, I'm merely pointing out what the game engine actually does. It doesn't care about the blue or green.

Honestly, I don't see why they didn't just use a 1-bit black/white mask for both transparency and clickability, but I didn't program the game. :)
 
This doesn't seem to work for me. When shields are assigned randomly they show up correctly in game (for the religion group, even a custom made one) but when I try to specify a CoA for a dynasty in the 00_dynasties.txt file the way this guide specifies it only works for Christians and no matter what I add (religion=x or forced_coa_religiongroup="x_group") the game seems to use the religion_group = "christian" specification, i.e. I can get the custom shield to show up but only if I add the texture in the Christian group and refer to it as if the family was in the Christian group and the CoA show up in a christian shield in game.

I can make the game use the correct religion group if I use the same way of defining a CoA that are used in the game files, namely something like

coat_of_arms=
{
data=
{
0 2 0 0 4 10 9 }
religion="zoroastrian"
}

Where the first number doesn't seem to change anything, 2 = texture set, 3 = emblem or template?, 4 = internal texture and numbers 5,6 and 7 specify colours though there seem to be A LOT more options, I tried up to 103 (black).
 
Actually, the game has examples of both forms. Look at dynasty #2, Orsini and # 7, Ottoman, both at the top of common/dynasties/00_dynasties.txt.

For the COAs that are just a string of numbers:

• 'religion = X' tells the game which "culture" group in interface/coats_of_arms.txt this COA uses. Obviously, 'zoroastrian' tells it to use the one for 'religion_group = "zoroastrian_group"'.

• The 1st number in the data chooses the template within that culture. Under zoroastrian_group, 0 uses the template "coa_plain_muslim:1", while 1 uses "coa_plain_pagan:1". Both are simple circular COAs, so I don't know why it lists both. The ":1" at the end of each of those tells us there is 1 layer for that template. Your 0 chooses the muslim plain circle over the identical pagan plain circle. :)

• Each group of 6 numbers after that defines a layer. Within a group it's: texture, emblem, texture_internal, color (1), color (2), color (3). These are used exactly as Measter described in the OP. Because the zoroastrian_group only lists 2 textures, they are numbered 0 and 1. You have 2. At best, the game will wrap that around to 0, at worst it will cause a crash.

Important point about that: for many things, computers use 0-based counting instead of 1-based. You have to count 0, 1, 2, 3, etc. In COAs, template, texture, texture_internal, emblem, and color are all 0-based.

The reason you appear to see more colors is that the game tends to wrap numbers around. zoroastrian_group only has 14 colors defined (0 thru 13), so when you tell it to use 14, it uses 0. Tell is 15, it uses 1. Tell it 103, it uses 5. Any number greater than 13, subtract 14 repeatedly until it's less than 14: 103-14*7 = 5 ⇒ black. (I've never tried it, but I suspect if you give it a negative number, it will add 14 until it's not negative, because there's a simple math that handles both without actually repeating. I expect non-integers (5.4) will get either truncated or rounded.)

edit: So your basic error here appears to be using the non-existent texture 2 in a zoroastrian_group COA.
 
Actually, the game has examples of both forms. Look at dynasty #2, Orsini and # 7, Ottoman, both at the top of common/dynasties/00_dynasties.txt.

For the COAs that are just a string of numbers:

• 'religion = X' tells the game which "culture" group in interface/coats_of_arms.txt this COA uses. Obviously, 'zoroastrian' tells it to use the one for 'religion_group = "zoroastrian_group"'.

• The 1st number in the data chooses the template within that culture. Under zoroastrian_group, 0 uses the template "coa_plain_muslim:1", while 1 uses "coa_plain_pagan:1". Both are simple circular COAs, so I don't know why it lists both. The ":1" at the end of each of those tells us there is 1 layer for that template. Your 0 chooses the muslim plain circle over the identical pagan plain circle. :)

• Each group of 6 numbers after that defines a layer. Within a group it's: texture, emblem, texture_internal, color (1), color (2), color (3). These are used exactly as Measter described in the OP. Because the zoroastrian_group only lists 2 textures, they are numbered 0 and 1. You have 2. At best, the game will wrap that around to 0, at worst it will cause a crash.

Important point about that: for many things, computers use 0-based counting instead of 1-based. You have to count 0, 1, 2, 3, etc. In COAs, template, texture, texture_internal, emblem, and color are all 0-based.

The reason you appear to see more colors is that the game tends to wrap numbers around. zoroastrian_group only has 14 colors defined (0 thru 13), so when you tell it to use 14, it uses 0. Tell is 15, it uses 1. Tell it 103, it uses 5. Any number greater than 13, subtract 14 repeatedly until it's less than 14: 103-14*7 = 5 ⇒ black. (I've never tried it, but I suspect if you give it a negative number, it will add 14 until it's not negative, because there's a simple math that handles both without actually repeating. I expect non-integers (5.4) will get either truncated or rounded.)

edit: So your basic error here appears to be using the non-existent texture 2 in a zoroastrian_group COA.

Thanks for the walk-through of how the number string method works.

The reason I used texture 2 was that I added a new texture to the zoroastrian group. I've obviously tried using the normal ones. (And the CoA used in the example does work) The problem persists though, I seem to be unable to assign anything but a christian CoA to a specific dynasty with the method described here.

By the way, the Ottoman dynasty looks like this in my game files.

7=
{
name="Ottoman"
culture="turkish"
religion="sunni"
coat_of_arms=
{
data=
{
0 1 0 43 12 3 10 }
religion="sunni"
}
used_for_random=no
}

I did find examples of the method used here though, not sure how I missed that before.
 
Last edited:
Thanks for the walk-through of how the number string method works.

The reason I used texture 2 was that I added a new texture to the zoroastrian group. I've obviously tried using the normal ones. (And the CoA used in the example does work) The problem persists though, I seem to be unable to assign anything but a christian CoA to a specific dynasty with the method described here.

By the way, the Ottoman dynasty looks like this in my game files.



I did find examples of the method used here though, not sure how I missed that before.
Yeah, I pointed to both to show both methods are used. But yeah, the full text method isn't used much, only 19 instances.

In my current game's save file, my own custom Germanic Pagan dynasty is defined thus:
Code:
        10292908=
        {
            name="Aelfricson"
            culture="welsh"
            religion="norse_pagan"
            coat_of_arms=
            {
                data=
                {
0 0 0 19 7 8 0                 }
                religion="norse_pagan"
            }
            flags=
            {
                strange_chest=802.6.2
            }
        }
On my character page, in the character finder window, and in the dynasty window, it shows the round pagan shield. Notice there is a religion="norse_pagan" both inside the dynasty clause and inside the coat_of_arms clause. The one inside coat_of_arms determines which form the COA uses. (Verified with some other dynasties.) I'm not sure what effect the other has, and not all dynasties have it.

Ooh, looking at this tells me somebody in my dynasty found the Strange Chest! Hopefully I'll find the key some day…