Captain to the Rescue

[Alyph]

While doing some modding with the interface, I noticed some weird behavior as regards to how the title shield is rendered. I'm not sure if it's a bug, or as intended or just some limitation in the code, but please take a look at the images below:

Notice some shields are small while others are big. The smaller ones seem to use the randomly generated coat of arms whereas the bigger one uses the fixed hand drawn CoAs.

Here is another example, look at his primary title which has a bigger frame:

Digging into the code a little bit. In the domestic_dynastic.gui, it uses the GFX_shield_big/small for the shield texture, but how this texture is generated/defined is hidden behind the code. However there seem to be two things can potentially be used:

1. maskedShieldType, which defines bunch of GFX_shield_big/small_pagan/muslim/indian etc. and uses the bigger frame. I suspect this used for the fixed CoAs
   
2. CoatOfArmsType, which defines randomly generated coat of arm types, also different types of frames (unit type, plain type etc.) and I suspect this generats the GFX_shield_big/small for randomly generated CoAs

So Captain, can you confirm this is the case? And why such inconsistency exists. In general the fixed CoA with bigger frames look better on the UI (that's the main reason why I'm asking all these), and the smaller framed CoA all feel lacking (probably due to straight scale from the larger texture). I tried to mod it so they can look close to each other, but so far to no avail. Looks like too much is hard coded.

Is there something we can do at least here to make those shield look better? What is actually the logic behind determines which frame to use? And why does a CoatOfArmsType even need to define a frame, wouldn't it make more sense to have it simply generate the background of the CoA and let the UI or maskedShieldType determine which frame to use?

 

[zijistark]

The triggers/effects haven't been changed, but underlying values which causes this behavior. I will fix so the trigger/effect any_playable_ruler includes revolters as well.

Just checking: If you say that you've fixed any_playable_ruler, does that imply random_playable_player will also be fixed? [ I'd assume that the random_* effect variants are derived from the same code as their any_* counterpart and not even attempt to verify this with you to ensure that all the right fixes make it into a mainline patch ASAP, but there are so many any_* scopes without random_* effect counterparts that I'm forced to wonder just how tightly-integrated the two concepts are in the underlying code. ]

Thanks!

 

[fanoI]

The command create_title does not work as expected if the base title is a Family Palace in particular the problem seems to be in base_title because the new created title has not the dinasty COA but the "Rebel Flag!".

This the code I'm using to transform a Patrician title in a County level title:

character_event = {
   id = Rev.4
   title = EVTNAMERev.4
   desc = EVTDESCRev.4
   
   # For now...
   #is_triggered_only = yes
   trigger = {
     is_patrician = yes
     liege = {
       government = senatorial_republic
     }
   }
   
   option = {
     name = EVTOPTARev.4
     
     primary_title = {
          create_title = {
                tier = COUNT
                landless = no
                temporary = no
                custom_created = yes
                culture = ROOT
                holder = ROOT
                base_title = THIS
                copy_title_laws = yes
          }
     }
     set_defacto_liege = FROM
   }
}

Thanks for your help!

 

[zijistark]

The command create_title does not work as expected if the base title is a Family Palace in particular the problem seems to be in base_title because the new created title has not the dinasty COA but the "Rebel Flag!".

This the code I'm using to transform a Patrician title in a County level title:

character_event = {
   id = Rev.4
   title = EVTNAMERev.4
   desc = EVTDESCRev.4
 
   # For now...
   #is_triggered_only = yes
   trigger = {
     is_patrician = yes
     liege = {
       government = senatorial_republic
     }
   }
 
   option = {
     name = EVTOPTARev.4
   
     primary_title = {
          create_title = {
                tier = COUNT
                landless = no
                temporary = no
                custom_created = yes
                culture = ROOT
                holder = ROOT
                base_title = THIS
                copy_title_laws = yes
          }
     }
     set_defacto_liege = FROM
   }
}

Thanks for your help!

Not to interject, but regular, non-baron-tier titles simply don't use the same CoA system (baron-tier use the dynastic system, while higher-tier use straight bitmaps-- not defined by texture indices defined in coats_of_arms.txt, in a nutshell), so it's definitely expected that you'd get a random(ish) CoA if you tried to base a higher-tier title upon a family palace dynamic barony holding. Surprised it works otherwise, though.

EDIT: Should really stick to bug reports / issues outstanding in this thread, I think. So, in conclusion, that's no bug such as a lack of a major feature.

 

[fanoI]

Yes I hoped to promote that behavior to count level characters as Patricians do not work in not Merchant Republics but I need at the same time something similar and as barons are not playable...

Muslim can use their dynasty COA as title COA so the game engine supports this so the ability to create a title based on the character dynasty will be useful.

 

[Zarathustra_the]

I second that, the ability to use the dynasty COA as a Title COA would be amazingly useful!

 

[fanoI]

I have found a way to do this there is another class of characters that are not barons and not Muslims but that on the other hands use their dinasty as title COA: Nomads!

Effectively create_title has a "nomad" flag so I tried to change my previous code to:

character_event = {
   id = Rev.4
   title = EVTNAMERev.4
   desc = EVTDESCRev.4
  
   # For now...
   #is_triggered_only = yes
   trigger = {
     is_patrician = yes
     liege = {
       government = senatorial_republic
     }
   }
  
   option = {
     name = EVTOPTARev.4
    
     primary_title = {
       create_title = {
         tier = COUNT
         landless = yes
         temporary = no
         custom_created = yes
         culture = ROOT
         holder = ROOT
         base_title = THIS
         copy_title_laws = yes
         nomad = yes
       }
     }
     set_defacto_liege = FROM
     set_government_type = senatorial_republic
   }
}

And surprise! The county level title created has the same flag of the dynasty (probably I do not need to create a Patrician title that the game discards after a day and that nomad does all the trick) but the problem is that the government is after a day overwritten as "nomadic" he gets the clan interface: a count level nomad that could potentially have other baron levels clan as vassals? Interesting in particular if we could mod that interface to show 24 Senators not clans...

I needed to do two things to enforce my government modify nomadic government potential:

    potential = {
       NAND = {
         controls_religion = yes
         NOT = { religion_group = muslim }
         NOT = { religion = norse_pagan_reformed }
       }
       NOT = {
         liege = {
           government = senatorial_republic
         }
       }
       is_patrician = no
       mercenary = no
       holy_order = no
     }

and adding this to Senatorial Republic potential:

potential = {
            OR = {
                has_landed_title = d_ancona
                liege = {
                    government = senatorial_republic
                }
            }
}

It is apparently working but it is a kludgy solution I'd prefer to have the possibility to set the title COA as the same of the dynasty in the create_title command...

 

[Captain Gars]

Just checking: If you say that you've fixed any_playable_ruler, does that imply random_playable_player will also be fixed? [ I'd assume that the random_* effect variants are derived from the same code as their any_* counterpart and not even attempt to verify this with you to ensure that all the right fixes make it into a mainline patch ASAP, but there are so many any_* scopes without random_* effect counterparts that I'm forced to wonder just how tightly-integrated the two concepts are in the underlying code. ]

Thanks!

Yes, I've fixed that one as well. And no, they don't derive from each other. And in theory their should be a random_something for every any_something trigger.

 

[knuckey]

There is about something we discovered regarding patrician families in republics that has arisen since patch 2.4.

Previously you could add patrician families to merchant republics using scripting commands so that there would be more than 5 families, we have a special realm where there are 10 families for example. This made the republic interface a bit untidy, but it worked fine otherwise. But it seems now since patch 2.4 the game engine automatically removes excess patrician families. First whilst playing it removes all families from the republic interface, then upon loading save-reloading it removes random families so only 5 are left. So my request is, can this excess patrician maintenance be made soft-coded/stopped via a defines?

 

[Zarathustra_the]

To build on Knuckey's suggestion, I would quite like being able to set a realm specific limit to the patrician families, I know it used to sometimes bug and you would end up with more families than you wanted. If we could instead define it per realm how many patricians you can have, this would be significantly more useful. Also perhaps in the realm of fantasy, but the ability to have a patrician house as another government type would be absolutely awesome.

 

[fanoI]

Also perhaps in the realm of fantasy, but the ability to have a patrician house as another government type would be absolutely awesome.

This was surely possible before patch 2.4x, using county level nomads (see my previous posts) partially works but it is a kludge nothing else...

So to summarize:

1. Add to defines how much Patrician Families a Merchant Republic could have. If they are more than 5, in "The Republic" interface a scroll bar should be shown
2. Permit to have Patricians outer of Republics. Again if this could be a problem in vanilla CK2 (in older version when Republics ended Patrician families continued to exist, sometimes they were integrated in other Republics if it annexed totally another) add a define to permit this or a specific flag in governments

 

[zijistark]

Yes, I've fixed that one as well. And no, they don't derive from each other. And in theory their should be a random_something for every any_something trigger.

I'm sure you're probably aware, but there are definitely a lot of missing random_* effects for corresponding any_* effects. Three that happened to be annoying me just today are the lack of random_attacker (war scope), random_direct_de_jure_vassal_title, and random_de_jure_vassal_title.

Also, on a related note, there are a ton of triggers that do not work as effects (and vice versa) when, by all reasonable interpretations, they absolutely should (either because the effects are just well-known to be bugged-- such as any_demesne_province, or because they just don't exist in the EXE). As a super-simple example, it would be tremendously useful if `any_de_jure_vassal_title` (not the DIRECT version, but all `de_jure_vassal_or_below` titles) was available as a trigger and not just an effect.

If you're interested, me and @Rylock can put together a quick list of the most offending / highest impact violators of the above two classes of problems (we'd already chatted about this briefly in response to your quoted comment). Most, of course, can be worked-around, but some-- all those mentioned except `any_demesne_province` included-- actually make certain classes of problems extremely difficult to solve efficiently or pseudo-elegantly.

 

[Alyph]

I've been seeing lots of these asserts:
[effectimplementation.cpp:8549]: Assert failed for 'change_variable': false && "Invalid scope for variable effect"
[effectimplementation.cpp:8549]: Assert failed for 'change_variable': false && "Invalid scope for variable effect"
[effectimplementation.cpp:8427]: Assert failed for 'set_variable': false && "Invalid scope for variable effect"

seems like the code always reports this error whenever set_variable is used, spamming the error.log a lot. Is this a bug? I was worried my variable setting wasn't working, but seems like other than this error, everything else is fine...

 

[richvh]

The asserts are in error, and will be fixed in next patch (see the first couple of pages, it's one of the first things the Captain fixed.)

 

[Alyph]

The asserts are in error, and will be fixed in next patch (see the first couple of pages, it's one of the first things the Captain fixed.)

Ah I see. Thanks! Hope it gets in soon!

 

[ngppgn]

Is it WAD that republics can't build in coastal trade road peovinces unless they own the county?

 

[TheDungen]

there are two scopes for scoping a suzerin

suzerin = {}
and
any_suzerin = {}

The latter does not seem to function in triggers, I have not tried the former in commands (where the latter is used by vanilla) but wouldn't it be better to just go with one scope which works on both cases? Since they basically do the same thing.

 

[burny26]

I got an invalid node "any_close_relative" in scope Charcommand ,but can't see what i am missing.
The event works perfectly if I cancel it.
The point of the code is to give any close familymembers of the FROM a negative opinion of the ROOT because it executed FROM

    option = {
        name = "EVTOPTBanda.4"
        FROM = {
            death = {
                death_reason = death_execution
                killer = ROOT
            }
            any_close_relative = {
                opinion = {
                    modifier = opinion_killed_close_kin
                    who = ROOT
                }
            }
        }
    }

 

[richvh]

If the event works, but Validator complains, then report it in the Validator thread; it's a problem with Validator, not with the game.

 

[burny26]

If the event works, but Validator complains, then report it in the Validator thread; it's a problem with Validator, not with the game.

With the event 'works' do you mean if it just gives me an empty message (so not WAD for me ),or that it works like intended?

Because the way it is now ,the close kin doesnt get modifiers nor are they represented in the option bar