• 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.
Showing developer posts only. Show all posts in this thread.
It would be a good idea to add another pre-trigger named racial_trait = -something- as this would wastly improve the CPU of some of the world conversion mods out there. As there are many races which needs their own flavor events and considering how CPU heavy events already are so would this be very beneficial!
I think a better way of doing this is instead of a racial trait just allow culture to be a fast trigger, as many mods have culture specific events but less use culture traits
 
  • 1
Reactions:
I agree with their being a console command to show global flags (eg: show_global_flags which then prints all global flags in the console) and variables to be shown on charinfo
 
De facto liege is just their current liege, so just liege = { should work surely
The liege's primary title isn't necessarily the vassal's de facto liege title.
E.G., if you hold k_norway and k_denmark, with k_norway as primary, some titles may still be under k_denmark.
 
  • 1
Reactions:
Someone deleted this suggestion from the wiki?
ziji removed it with this justification: "Removed 'build_holding = { type = tribal }': All game mechanics related to tribal holding require them to be the province capital. A province can not lack a capital holding. Ergo, event-building a tribal holding makes no sense. Use convert_to_tribal = yes"

Which sounds entirely reasonable to me. If tribal holdings simply don't work properly when they're not the capital, there's absolutely no reason the game should let you add them arbitrarily.
 
I added in "An option for minor titles to not be visible in the council screen granting interface but instead only to be given by event" because in AGOT we use a minor title for Ser or Lady which are given by event but now they show up in the minor title interface but they cannot be granted to anyone and just take up space
 
Technically, event targets are usable as long as the event chain is ongoing, so you can set a character as an event target and send him a dummy event delayed by, say, 365000 day. Them you can reuse the target anywhere during a Standard playthrough. Isn't this what you are asking for, or I am understanding the "while the event chain is alive" part of the explaination?
Nah the event target can only be called from say event A -> B -> C not from A -> B with C triggered at another time and completely independent from the other events
 
What Zarathustra wants it I can take a decision and save an event target then get random MTTH event which references that event target. However at the same time someone else also took the same decision and got the random MTTH even referencing the event target.
Using the current global variables that wouldn't work but instead if a variable was saved to just the local character then it would work.
 
The ability to reference saved event targets in localization. Something like:

Code:
[event_target:my_event_target.GetTitledFirstName]
You can reference event targets in localisation, you literally just do [whatever_event_target.GetTitledFirstName] and that works perfectly fine
 
One thing I would really like to see, is some way to call a diplomacy menu from a decision. Let me choose multiple targets for my targeted events. Surely it is not hard to let us have a court/diplomacy scoped diplomacy menu from a decision?
That is already on the list I believe titled as third part decisions to simulate the selection of a third person when using targeted decisions.
 
  • 1
Reactions:
You'd think so wouldn't you, but from what I could tell, using PREV jumped me back to that scope, rather than adding PREV on top of the scope stack.
Which is unfortunate, since ROOT and FROM add the scope on top of the stack as you'd expect/
Code:
ROOT = { # <title:ROOT>
    create_title = {}
    new_title = { # <title:ROOT>, <title:new>
        any_title = { # <title:ROOT>, <title:new>, <title:potential>
            limit = { check_variable = { which = title_id which = PREV } # Titles with higher title ID
            PREV = { # <title:ROOT>, <title:new>
                # Expected <title:ROOT>, <title:new>, <title:potential>, <title:new>
                # PREV here is actually ROOT
                set_variable = { which = title_id which = PREV }
            }
        }
    }
}

PREV always refers to the previous scope that you were in - so you can't use it to "back up" into the scripted structure. Example:
Code:
A = {
   B = {
     C = {
       D = {
         PREV = { # Back to C
           PREV = { # Back to D
             PREV = { # Back to C
               etc.
             }
           }
         }
       }
     }
   }
}

If you try scoping to PREV when you're already in a PREV scope, it actually skips the current scope and goes to the scope two before the current one, instead of the one before. Very annoying, I agree.

Wrong, see explanation above for how it does work.

Unfortunately, changing PREV={ to behave like FROM={ and ROOT={ would probably break things.
I know I had some scripts that accidentally worked before I understood this behaviour because it happened that the nested PREV happened to refer to the right title.

PREV has never been designed to work "like FROM and ROOT". From and Root only changes when switching context - like from one event to another - while PREV is only used inside one context (i.e. an event, CB, decision etc.)

PREV does indeed behave kind of strange. Looking at the crusade CB, there's a weirdness that may do what you want. In very abbreviated form, it does this:

Code:
on_success_title = { # title scope.
    most_participating_crusader = { # character scope.
        PREV = { conquest_culture = THIS } # PREV refers to the title, THIS inside the PREV refers to the character.

take_spouse_out_of_hiding decision does a similar use of THIS inside PREV.

Both of these appears to be bugs. THIS always points to the current scope that you are in, so the title is setting its conquest_culture to its own culture.

Some confusion however does come from the CB file because scopes there are abused in a way they are not supposed to be (i.e. ROOT not pointing to the starting scope of a context and instead being "kidnapped" to point to something else).
 
  • 3
Reactions:
I've added two things to the list
  • an on_natural_death on action which fires whenever somebody is about to die from age, illness trait or lack of health with them just being ROOT
  • a cancel_death command which stops any death from age, illness trait or lack of health
The latter might be difficult to implement but we have the immortal = yes for traits which does the same thing but cannot stop a death in progress.
 
  • 2
  • 1
Reactions:
I added on to the list:
  • Ability to make a culture feminist = yes to negate negative opinion from female rulers or heirs in the same way it is possible in religions
 
  • 2
Reactions:
I'll admit, I'm loathe to add to this thread. I imagine, from the perspective of a developer who might happen to look at it, it's essentially a wall of text full of requests that are so specific in their application and devoid of context it'd be easy to dismiss them outright. Even so, we now have a developer in the form of @Divine actually working on CK2 at the moment, so I'm going to do it.

To admit my personal biases up front: I'm the head of CK2Plus, and even before I became the mod lead I was the primary coder for quite some time, so I'm quite familiar withe the API and ways to get around it. That said, CK2Plus's primary goal is to expand on CK2's scope and not to make it do things it wasn't really intended to do -- it's not a total conversion mod, doesn't try to take the game to an earlier or later timeline, and tends to avoid adding new features that can't be done using the current modding tools. I totally respect mods that do so (or attempt to do so), but that's just not where my interest lies, and I'm personally leery of asking devs to add modding tools useful only for turning CK2 into something it isn't. But that's just me.

With that in mind, a few things that CK2Plus could really use (and which I think would be useful to others):

1) join_faction and leave_faction: the API has back_plot and leave_plot, but nothing that does the same for factions. The only way to have someone join or leave a faction is to set a flag or otherwise change the condition on their joining and wait for the game to update their status...which can be awkward. I imagine it's never been done because, if you didn't change those conditions anyhow, they would just join or leave the faction on their own in short order. Timeliness is the important factor here, though -- being able to have someone join a faction as it's about to rebel, or as an effect for an event, would be way better than "I'll think about it and do it in a week or so".

2) verifying the checksum: this may only be possible if the checksum is actually stored somewhere, but it would be excellent if we could verify that the player's checksum is the one the mod requires. Our #1 issue as a mod is people having changed files (sometimes without their knowledge), then coming to report issues where our first question must always be "what is your checksum?" The ability to warn the player up front that their checksum is incorrect and what that means would be invaluable.

3) activating/deactivating trade routes: the trade route system was intended solely for the Silk Road -- I get that. That makes the system's moddability difficult, however. Of all the things I could ask for regarding making it more moddable, it would be the ability to turn a route on or off. If this doesn't involve a command, even having an entry in the route's definition which allowed for a date where the route is activated (or deactivated) would make it much more useful.

4) dynamic alert icons: you know the icons at the top of the screen that warn you about things like titles you can form, or children who require guardians? It would be lovely if there was some way for us to create alert icons of our own -- even if, say, it was something that could be added into the triggered_modifiers which essentially turned it into an alert rather than a modifier applied to the character (or both).

5) plot moddability: this is a bit more vague -- personally, I love the plot system, and I'd love to do more with it. Two big factors prevent this, however: a lack of ability to determine who's eligible (or willing) to join a plot, and a lack of ability to change what the reaction to a plot should be. If I were to make this more specific, I'd suggest an allow_join field for plots similar to that for factions, which can narrow the field of who can be approached. I'd also suggest an on_discovery field which determines the reaction someone has when they find out the plot exists -- which could be an opinion modifier (other than the one currently applied, which makes all plots considered equally bad, and a crime in the liege's eyes even if it's in their interests) or a specific reaction if the discoverer is the actual target.

6) allowed_to_grant and allowed_to_hold on landed titles: these fields exist on minor titles but not on landed titles, and it would be excellent to have them as optional. Obviously, they might not be able to override existing conditions (such as the limitations applied on gavelkind, or the requirement that you can only grant a non-titular duchy to rulers who own a de jure county), and allowed_to_hold would really be allowed_to_be_granted since you probably couldn't disqualify someone from having a title they already possessed...but if they could optionally add to those requirements, that would be really useful.

7) moddable autocephaly: this is really specific, I know, but it's been an annoyance for as long as I can remember that the autocephaly system for religions was clearly created to be specific to the Orthodox religion even though it's also applied to others like Miaphysite and Nestorian. If I were to give my top wants for how to change this? One would be to allow pentarch entries in the religions themselves, to identify which titles that religion considers to be part of their pentarchy. Another would be to add a command which can be used in title scope to change its pentarchy alignment (the command exists, actually, but is only usable in the title's history file). Lastly, and perhaps least importantly, the separation of autocephaly (kingdom- or empire-tier Lord Spirituals are the rightful religion head for the realm) from pentarchy (theocracies with the pentarchy title have primacy in their territory) in the religion defines.

There are likely other things, but I don't want to make the list any more giant than it already is, and I'm trying to restrict myself to requests that we can't code around on our own. I'll add these into the list on the wiki, if they aren't already there (they might be, but that list is long), but I thought for the moment I'd throw my pennies into the fountain along with everyone else. :)

For those who read it, thanks for listening.
Your requests are very good, even though I am the not actually lead developer of AGOT I am still gonna give my 2 cents...
The join_faction and leave_faction commands would be amazingly useful in all mod scenarios and even good for making vanilla events force people into factions, it would eliminate the need for having to make the ai check their logic for things which we know we want them to do. The ability to create our own custom alert icons would also be amazing, it would be a much cleaner and nicer system than maintenance events to prompt you to do something or warn you of an impending issue.
Like you and zijistark have said the wiki's list is huge and full of highly specific things or things that are just gonna be far too difficult to fulfill easily, speaking of which I think compiling a list of the requests that are generic enough to benefit everyone and also easy to implement would be a good idea and might actually be something I will work on. I feel bad for Divine though, only recently here as the CK2 user mod coordinator and already getting bombarded with all of our requests...
 
  • 4
Reactions:
Holding true to what I said I have compiled a not too biased (I hope) list of suggestions that should benefit most people. This is only a list of things that (in my not so well educated in coding a game view) will not be to difficult to add in and are not suggestions that as of now have reasonably easy workarounds for (with a couple of minor exceptions) or ones that are very specific to certain situations that only one or two mods may ever use.
The aim of this list it narrow down the things for @Divine to look at as higher priority suggestions as opposed to going through the suggestions page on the wiki which has many ideas to specific or difficult to every be useful to most modders and also had suggestions which are already implemented but have not been moved yet on the wiki.
  • Ability to select characters who have a pseudo-landed titles in the character select screen, at the moment they are not selectable but do not game over if you console to them
  • Make the spawning of new characters from the create a vassal function (right click on a barony holding) a fully moddable decision. Or at least an on_action.
  • Allow the new council added with the 'Conclave' DLC to vote on targeted decisions (and perhaps normal decisions). The current command 'enable_council_voting_on_issue =' currently only works on the existing decisions intended for use in vanilla.
  • even_if_dead versions for all types of familial relation scopes (real_father_even_if_dead, any_child_even_if_dead, random_child_even_if_dead, any_dynasty_member_even_if_dead, random_dynasty_member_even_if_dead, any_sibling_even_if_dead, random_sibling_even_if_dead)
  • Add the scopes any_tributary and random_tributary. Thus allowing one to scope from a suzerain to one of their tributary characters. Currently it appears that it is only possible to scope from tributaries to their suzerain.
  • A can_inherit = yes/no character trigger; currently one has to check for every trait that prevents inheritance. similar to the can_marry trigger
  • A way to start a disease outbreak in a province by event/command.
  • A way to stop a disease in progress in a province by event/command.
  • War-scope effects add_attacker = CHAR, add_defender = CHAR where CHAR is a character
  • Effects leave_faction = name, join_faction = { faction = name who = CHAR } where the CHAR is optional and only relevant for faction types with a 3rd-party actor
  • The ability to maximum for scaled_wealth commands, there is already the ability to set a min but not a max
  • scaled_piety and scaled_prestige to go along with scaled_wealth, also having min and max for them
  • Allow buildings other than those in a [Patrician-only] family_palace holding to apply general character modifiers to their holder (such as boost intrigue/stewardship)
  • Option to have only female priests in a religion
  • Option to have randomly generated female mayors, or only female mayors
  • Enable female polyandry (e.g., max_husbands = N and females_can_have_consorts = yes as new religion properties)
  • Split the pentarchy from autocephaly
  • The ability to mod caste and religious sect traits more. I.e. making more castes for other cultures. Right now making new castes only seems to appear for Indian religions, even if you add an allow = {} when making new caste traits.
  • Ability to make a culture feminist = yes to negate negative opinion from female rulers or heirs in the same way it is possible in religions
  • Similar to duchy_revokation for the Byzantine Empire, add barony_revokation, county_revokation, and kingdom_revokation
  • Allow pass_effect in succession and gender succession laws as is allowed with de_jure_laws (extension to demesne laws would also be nice)
  • Allow ai_will_do in gender succession laws (currently does not work)
  • Allow calling events through the laws "effect" and/or in (if it is added) pass_effect.
  • CB actions on_invalid and on_invalid_title that trigger right before a war invalidates (the latter allows referencing the CB target title and is the most critical)
  • Add a can_assimilate flag for titles. can_assimilate = no would prevent the title from assimilating duchies/kingdoms INTO the title, would then need to clarify the existing assimilate = no used by k_jerusalem
  • The cannot_marry = yes trait effect blocks a character being given titles, now that can_hold_titles = no has been added remove the inability to grant people titles when they have cannot_marry = yes traits
  • An enatic = yes equivalent to agnatic = yes, so infants will always inherit a trait from their mother.
  • Third-party title/character support for targetted_decisions (to allow diplo-actions in the form of Arrange Marriage or Grant Landed Title)
  • Allow AI job action scripting (currently only uses vanilla job actions) can be worked around by the new ability to force a councillor to perform an action in a province but this would be much easier
  • A way to add new death reasons without having to make a dummy trait and use trait_death_reason
  • A defines to revert alliances to pre 2.5.x version where you had a choice to join a war
  • Ability to make a characters dynasty coat of arms their title flag
  • Make set_coa persist through saves instead of resetting
  • Expand the moddability of DNA. Number of option slots should not be hardcoded
  • Add a set_dna command which can take a dna string
  • Add a copy_dna command which takes a scope eg: copy_dna = FROM
I hope everyone agrees these are some generally good suggestions and not to ridiculous, hopefully this will allow @Divine to have an easier time at seeing the more plausible suggestions.
 
  • 4
  • 1
Reactions:
Fix the broken scripting interface fundamentals associated with tribal vassals that have been called to war so that basic vassal-liege, title, and war scripting assumptions will work properly with them
  • Though they appear like a normal vassal, is_liege_or_above and related are broken in a fully ambiguous way for scripting
    • Their liege scope resolves to themselves, and so does their liege_before_war scope (!).
    • If it is a defensive war (or at least for certain types of them), they also do not show up within the war scope any_defender as war participants (their liege being the primary defender). They are not even hostile toward, i.e., war_with the attacker.
    • There is effectively no way at all to deal with the hard-coded magic from patch 2.2 that still binds them to their real liege / discern tribal realm structure from script.
I did some checks starting as a tribal realm, starting some wars and calling my vassals to the war. Everything seemed to resolve as it should in script with the vassals still being able to scope to me as their liege and being able to access the vassals through any_attacker scope inside the war scope.

Am I misunderstanding the post in the wiki-list or can people confirm if this is still a valid issue? I would be grateful if this could be cleared up because it does sound like a nasty issue but I can't reproduce any of the effects.
 
Alright, thank you for the first one. It'll come in handy.

As for the second one: are these the stem names? As in, the ones after the _ in the normal name list? If yes, all my qualms have been solved.
Note for the first one that if no value is specified the default is 100