• 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 thought this was already possible, cf vanilla:
Code:
b_cluny = {
   coat_of_arms = {
        data = { 0 4 12 45 2 2 2 0 0 19 2 1 3 0 0 19 2 1 3 0 0 19 2 1 3 }
        religion="catholic"
    }
}

That's still a random engine COA. I mean an actual b_amsterdam.tga coat of arms.
 
That's still a random engine COA. I mean an actual b_amsterdam.tga coat of arms.
Only because it uses texture #4 (2nd number in the 'data'). That uses pattern4.tga. You could easily set it to use a dynasty TGA texture, or a custom one of your own. All the options for coats of arms are available in a landed title coat_of_arms block.
 
Only because it uses texture #4 (2nd number in the 'data'). That uses pattern4.tga. You could easily set it to use a dynasty TGA texture, or a custom one of your own. All the options for coats of arms are available in a landed title coat_of_arms block.

I see, I didn't know that.
But honestly, that's waaay too much effort and Paradox could also just implement a system that autogenerates only when b_x.tga is not found in gfx/flags, because if you do the COA-generator way it's like being unable to set your chicken-egg-collector robot to collect duck eggs too so you need to dress up your ducks in a chicken suit and designate them as a specific chicken breed. It can't be that hard.
 
Last edited:
I see, I didn't know that.
But honestly, that's waaay too much effort and Paradox could also just implement a system that autogenerates only when b_x.tga is not found in gfx/flags, because if you do the COA-generator way it's like being unable to set your chicken-egg-collector robot to collect duck eggs too so you need to dress up your ducks in a chicken suit and designate them as a specific chicken breed. It can't be that hard.
I'm not sure what motivated the decision in the 1st place, or what would convince the devs to change it now.
 
Its a little nuanced, but heres how it works:

1. In buildview.gfx, create a new spritetype:

spriteType = {
name = "GFX_buildview_my_strip"
texturefile = "gfx\\interface\\buildview_my_strip.tga"
noOfFrames = 200
}

2. In buildview.gui, replace "GFX_buildview_building_strip_small" with GFX_buildview_my_strip

*NOTE: if your strip is not long enough, you will see a black box. So if you have a strip with 10 frames, it will cover 5 buildings. (or 4 buildings + 5th building will lose icon on 2nd upgrade)
To cover every holding you will need a lot of frames.

3. The result is that each subsequent building will skip 2 frames at level 1.

*This means that building 1 gets the icon in frame 2, building 2 gets the icon in frame 4

**But this causes an issue which can be solved. Namely, if building 1 has 3 upgrades, it will crossover into frame 4.

To solve this, you can put in a dummy building:
ca_dummy_1 = { potential = { FROMFROM = { always = no }}

Thus, the dummy would never show but would allow you more frames before interfering with the next building.

Its an extremely tedious and exhaustive process, but this seems to be the only possible way to display unique icons for buildings.
It's intriguing that in buildview.gui, the building strip is defined with:
Code:
        ### TEMP moved outside window.
        iconType =
        {
            name ="icon_type"
            spriteType = "GFX_buildview_building_strip_small"
            position = { x= 9993 y = 3 }
            Orientation = "UPPER_LEFT"
            frame = 1
        }
Notice that comment (and the X position). I checked my archive, and it's been "temporarily" moved outside the window since at least 1.06b, the oldest version I have. Looks like the devs planned to do more with it, and have just never gotten around to it. Instead they rely on the GFX_buildview_level to provide a roman numeral.
 
I'm not sure what motivated the decision in the 1st place, or what would convince the devs to change it now.

I consider myself to be a very special person with special privileges so that'd motivate them. Of course, that's not true, but I never said that I'm a grounded person.
 
Last edited:
Add ai_target_filter = diplomatic_distance to targeted decisions. It's less cpu intensive than "all" but it allows us to use targeted decisions for things outside of realm for the AI without breaking the game.

If a character actually stores a list of targets within range, that'd be great to have indeed (though I doubt they do).
 
@Meneth How hard would it be to port over the event scroll bar code from EUIV into CKII? This would really help with a lot of code I have worked that uses a rotational menu now to select appropriate options. By having a scroll bar I could put all things in a single master decision rather than making everything have to rotate in a massive menu. Would seriously help Gehimisnacht and other mods move away from clunky hackery...
 
Would it be possible to have "tax/levies to liege" modifiers for individual characters, or would that fall foul of hard-coded stuff?

I mean, I'm pretty sure I already know the answer, but I just wanted to float the idea because a lot of ideas I have fall flat due to these not existing.
 
@Meneth How hard would it be to port over the event scroll bar code from EUIV into CKII? This would really help with a lot of code I have worked that uses a rotational menu now to select appropriate options. By having a scroll bar I could put all things in a single master decision rather than making everything have to rotate in a massive menu. Would seriously help Gehimisnacht and other mods move away from clunky hackery...

Look up the Bigger Events mod. It's on LoversLab, I'm sure you can find it elsewhere (otherwise PM me).
 
Look up the Bigger Events mod. It's on LoversLab, I'm sure you can find it elsewhere (otherwise PM me).

That doesn't increase the number of options listed so it doesn't help with rotational event menus unfortunately.
 
That doesn't increase the number of options listed so it doesn't help with rotational event menus unfortunately.

Yeah Korbah has the gist of it, I would imagine your in much the same boat as I am with respect to event options old chap! We old timers have to stick together and all that :D
 
Could you also make Pentarchy titles and names dynamic? Like, "AUTOCEPHALOUS_REL_HEAD_mimamsa" to allow a Mimamsa Religion to have its own titles and tooltips for its Pentarchies. (That way, they could be called Abbots for one religion and Patriarchs for others, and Matriarchs for still others, and so on.)
 
Allow kingdoms to have different Autocephaly religious heads based on religion: e.g., that if the ERE is Miaphysite, it answers to the Patriarch in Antioch, if Paulician, to Rome, and if Orthodox, to Ecumenical Patriarch, and so on and so forth. "K_ITALY = { MIAPHYSITE_PENTARCH = X ORTHODOX_PENTARCH = X }".

Likewise, please make it so that "SET_PENTARCHY" Comamnd can be done for only one religion, as opposed to everyone.
 
Last edited:
These have very probably been mentioned before, but On_Actions triggers for the (non-birth) spawning of a new character and the completion of a building would be very useful. They'd be much more effective than relying on maintenance events both in the case of adding traits to random characters, and granting event modifiers to the owner of a building.

Also, I don't know if it's the right place to ask, but I'm hoping we'll be able to set who can access the China/offmap power(s) menu(es) by other rules than diplomatic range.
 
@Meneth can we get a diplo_range target filter for targeted decisions? It might help for those decisions where we currently need to use the any target filter when more appropriately only characters in diplomatic range would be appropriate.
 
@Meneth can we get a diplo_range target filter for targeted decisions? It might help for those decisions where we currently need to use the any target filter when more appropriately only characters in diplomatic range would be appropriate.
Diplo range is a somewhat expensive check, so having that be the first thing you filter on doesn't really make much sense.
In almost all cases it'll likely be cheaper to do all_characters and then have some cheap conditions, and only finally check diplo-range.
 
Diplo range is a somewhat expensive check, so having that be the first thing you filter on doesn't really make much sense.
In almost all cases it'll likely be cheaper to do all_characters and then have some cheap conditions, and only finally check diplo-range.

Surely though for simple diplomatic action additions, it would be cheaper to do diplo_range as a decision filter, rather than doing all, and then checking for diplo_range?