ah, And I want to add: Would be very nice to have more conditions for artifacts, such as:
is_stackable = yes/no
.
Thank you very much.
is_stackable = yes/no
.
Thank you very much.
-
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.
Under 1.19 Titles I added
* Add the option of making (landless?) titles "is_unique = yes" like minor titles. So when you are granted/inherit this title, you must abdicate all other titles to their perspective heirs (without dying).
I am working a "Roman Revival" mod (another one?! yes, cause I didn't find any *historically accurate* ones. The Pontifex Maximus is the landed religious head of the roman religion, but that religion also had 15 Imperial Flamenes (priests), 3 maiores and 12 minores. I wanted to simulate that by making the k_pontifex_mximum title have 15 de_jure titles: 3 duchies and 12 counties, each with the appropriate title. BUT, it's key that such flamens can never hold other titles, ANY other landed title (They must also remain prepetualy titular, but that's doable through "assimilate = no").
As of now, I made them into minor titles granted by the holder of k_pontifex_maximus (with "is_unique = yes" and allowed_to_hold = { has_landed_title = no } ), but that's significantly less than I wanted.
* Add the option of making (landless?) titles "is_unique = yes" like minor titles. So when you are granted/inherit this title, you must abdicate all other titles to their perspective heirs (without dying).
I am working a "Roman Revival" mod (another one?! yes, cause I didn't find any *historically accurate* ones. The Pontifex Maximus is the landed religious head of the roman religion, but that religion also had 15 Imperial Flamenes (priests), 3 maiores and 12 minores. I wanted to simulate that by making the k_pontifex_mximum title have 15 de_jure titles: 3 duchies and 12 counties, each with the appropriate title. BUT, it's key that such flamens can never hold other titles, ANY other landed title (They must also remain prepetualy titular, but that's doable through "assimilate = no").
As of now, I made them into minor titles granted by the holder of k_pontifex_maximus (with "is_unique = yes" and allowed_to_hold = { has_landed_title = no } ), but that's significantly less than I wanted.
Use a maintenance event that gives to flamen a trait that forbid them to inherit titles, it should do.
My god... I just read what HoI4 is going to get: https://forum.paradoxplaza.com/forum/index.php?threads/hoi4-dev-diary-modding-and-traits.1117516/
I am aware CK2 might be a bit old, but is there any chance we might be getting some of these features, too?
I'm thinking especially of Meta-Effects & Meta-Triggers, as well as Dynamic modifiers.
Never knew I wanted them, but now I really do
I am aware CK2 might be a bit old, but is there any chance we might be getting some of these features, too?
I'm thinking especially of Meta-Effects & Meta-Triggers, as well as Dynamic modifiers.
Never knew I wanted them, but now I really do
Meta-blocks are ugly as hell though
(Both for aesthetics and for the 'type system', or whatever is in place of one in the game's script. Arrays, on the other hand, we really could use those.
(Both for aesthetics and for the 'type system', or whatever is in place of one in the game's script. Arrays, on the other hand, we really could use those.
I really want the stellaris short-hand for scope traversal.
From.father.any_sibling = {
}
is so much cleaner than the alternative and speaks to my software engineer soul.
From.father.any_sibling = {
}
is so much cleaner than the alternative and speaks to my software engineer soul.
Such large changes are unlikely to happen to CK2 but I'll keep them in mind for the future of the scripting language.
The meta-script is actually pretty fine for the system, it just evaluates it as normal and will log errors once you get it wrong. Under the hood it effectively just makes a virtual file and writes the effect/trigger and fills in the parameters then parses that virtual file as normal to generate the real output of the effect/trigger. So you get the same error logging as if you had just manually typed out the entire thing.
The meta-script is actually pretty fine for the system, it just evaluates it as normal and will log errors once you get it wrong. Under the hood it effectively just makes a virtual file and writes the effect/trigger and fills in the parameters then parses that virtual file as normal to generate the real output of the effect/trigger. So you get the same error logging as if you had just manually typed out the entire thing.
Although I will leave it to others to add to the WIKI page you created, I would suggest adding a "has_mod" condition (similar to the existing "has_dlc" condition) that will let mod authors add customizations for their own mods to reliably interact with the features of other mods, without requiring a strict dependency.
Axe all the revoke_allowed and ai_will_revoke blocks from laws and decisions, since they are never used and now validator throws an error on them.
This might be a bit of a long shot, but hear me out: scripted chance modifiers/factors.
I recently realized that in my (personal) mod, the modifier blocks for random, MTTH, ai_will_do, ai_chance, etc, etc, amount for over 30% of the line count in my event and decision files, and there are large overlaps between most of them, which just screams for deduplication.
Therefore, let's put them in macros. They would work similar to scripted triggers and scripted effects, but contain lists of modifier = {} instead of triggers or commands.
For example, they could look like this:
Which could then be used, for example, in some way like this:
This would allow me - and I'm sure many others as well - to eliminate large amounts of duplicate code, and seems like a fairly elegant solution overall to me.
Of course, something even more powerful could be achieved if we were allowed to use variables for factors, but that inelegantly requires an effect be called beforehand, and seems less in line with the established way things work.
I recently realized that in my (personal) mod, the modifier blocks for random, MTTH, ai_will_do, ai_chance, etc, etc, amount for over 30% of the line count in my event and decision files, and there are large overlaps between most of them, which just screams for deduplication.
Therefore, let's put them in macros. They would work similar to scripted triggers and scripted effects, but contain lists of modifier = {} instead of triggers or commands.
For example, they could look like this:
Code:
selfish_for_modifier = {
modifier = {
factor = 0
trait = content
}
modifier = {
factor = 4
trait = ambitious
}
modifier = {
factor = 0.5
trait = charitable
}
modifier = {
factor = 2
trait = greedy
}
modifier = {
factor = 0.625
trait = kind
}
modifier = {
factor = 1.6
trait = envious
}
modifier = {
factor = 0.625
trait = humble
}
modifier = {
factor = 1.6
trait = proud
}
modifier = {
factor = 0.8
trait = just
}
modifier = {
factor = 1.25
trait = arbitrary
}
modifier = {
factor = 0.8
trait = honest
}
modifier = {
factor = 1.25
trait = deceitful
}
}
Code:
ai_chance = {
factor = 1
selfish_for_modifier = yes
}This would allow me - and I'm sure many others as well - to eliminate large amounts of duplicate code, and seems like a fairly elegant solution overall to me.
Of course, something even more powerful could be achieved if we were allowed to use variables for factors, but that inelegantly requires an effect be called beforehand, and seems less in line with the established way things work.
Scripted modifier blocks in separate files would also (especially if it was implemented in vanilla; that might be a rather big task, though) be an efficient way to ensure that the logic for something is consistent everywhere instead of varying rather significantly in some places (e.g. the logic for how the AI responds to tumbling suggestions varies vastly from place to place, and in some cases there isn't even an option to refuse).
The ability to disable hardcoded interactions for specific characters with e.g. a character flag (both ad the target and as the decision-taker) would be nice if you want to add special decisions/logic for one or a few exceptional characters (e.g. you want to write special alliance logic for the Pope) without tearing out the whole interaction and rewriting it for everyone.
I'm gonna go one step further and would want repeat my call for a simple "behaves_like_offmap" type flag that disables ANY type of default interaction for the character in question.
They would not get events, decisions, CBs, marriage interactions, nothing - except if said interaction includes a special flag that designates this event/decision/whatever as being eligible to fire for the special character.
So basically the exact same mechanic that offmap characters use, just on-map.
In fact, this the most important request I have. I may be bugging about other important stuff (ability to check for minor rivers, more modifiers for buildings, etc.); but these can all be implemented via complicated workarounds.
The ability to exclude one character from any interaction is, however, simply impossible. And thus, imo this (and maybe other "currently impossible to workaround" problems) is the highest priority to get before the end of the game's life cycle.
(And frankly, if we haven't gotten it by then, I might still keep nagging about it to you until all eternity, so beware!
)But the idea by @Silversweeeper is also nice, to just disable specific interactions with a special flag. Might be a bit more time consuming to implement maybe, but even more useful.
Full disabling could be an option in some scenarios, but I think disabling things individually would be a lot more useful since there might be lots of things you want to use the standard decisions and logic for (e.g. war declaration and peace offers might be something you decide to leave alone while you want a specific character to not be able to get Favours or owe them unless moddable events or decisions hand them out).
It would be nice if we could assign icons to targeted decisions (like the marriage and plot interactions have).
A few things that would be useful for religion modding:
- Having the hardcoded vanilla DLC locks for playabilitiy check both religion group and specific religion name so that we can restructure/split them without breaking the DLC locks required by Modding Rule 7. Unlike how JD treats Bön/etc., this would mean that, unless vanilla defined the "bon" tag to be unlocked by tOG, JD, and HF, access to the DLC that unlocks the group the tag belongs to (pagan_group, in vanilla) wouldn't be a sufficient condition for vanilla religion tags but any non-vanilla tags in a group would be unlocked (without any added blockers or the ability to new unlock tags in locked groups with alterntive DLCs; see below) with the DLC that unlocks the group.
- Similarly, adding the ability to lock the playability for new religions/religion groups to a certain DLC would make it possible to structure them any way we want without running into Modding Rule 7 issues. For example, if you wanted to create a devil_worshipper_group and lock that to MNM, that would be possible with a custom lock system for new groups, and you could potentially also put a new "trollcrafter" tag in pagan_group and lock that to MNM (and tOG/HF, to unlock the group in the first place) or put that tag in devil_worshipper_group and lock it to tOG/HF.
- If feasible, being able to define alternative unlocks for new tags in existing locked groups would also be great, e.g. if we wanted to put a "shinto" tag in indian_group (a.k.a. "Eastern") and want to unlock that with JD like Taoism. I am not sure how feasible this would be since it potentially would lead to DLC locks being circumvented if there are things that only check for the group instead of group + DLC, but since you can add more restrictive conditions to events/decisions/etc. already it should be possible to remain Modding Rule 7 compliant by simply making sure that e.g. all vanilla events/etc. that check for muslim_group also check for SoI so that a separately unlocked religion in the group doesn't get access to anything it shouldn't.
- The ability to activate/deactivate religions during play, with fallbacks if some character is created/switched to a deactivated religion. This would make e.g. conversion to a random heresy easy to restrict to a certain period (e.g. you only want Lollards toward the end of the 14th century and later and having the religion deactivated ensures that there won't be Lollards before you active it) or to have inactive "blank" heresies you could "reform" with HF.
- Having the hardcoded vanilla DLC locks for playabilitiy check both religion group and specific religion name so that we can restructure/split them without breaking the DLC locks required by Modding Rule 7. Unlike how JD treats Bön/etc., this would mean that, unless vanilla defined the "bon" tag to be unlocked by tOG, JD, and HF, access to the DLC that unlocks the group the tag belongs to (pagan_group, in vanilla) wouldn't be a sufficient condition for vanilla religion tags but any non-vanilla tags in a group would be unlocked (without any added blockers or the ability to new unlock tags in locked groups with alterntive DLCs; see below) with the DLC that unlocks the group.
- Similarly, adding the ability to lock the playability for new religions/religion groups to a certain DLC would make it possible to structure them any way we want without running into Modding Rule 7 issues. For example, if you wanted to create a devil_worshipper_group and lock that to MNM, that would be possible with a custom lock system for new groups, and you could potentially also put a new "trollcrafter" tag in pagan_group and lock that to MNM (and tOG/HF, to unlock the group in the first place) or put that tag in devil_worshipper_group and lock it to tOG/HF.
- If feasible, being able to define alternative unlocks for new tags in existing locked groups would also be great, e.g. if we wanted to put a "shinto" tag in indian_group (a.k.a. "Eastern") and want to unlock that with JD like Taoism. I am not sure how feasible this would be since it potentially would lead to DLC locks being circumvented if there are things that only check for the group instead of group + DLC, but since you can add more restrictive conditions to events/decisions/etc. already it should be possible to remain Modding Rule 7 compliant by simply making sure that e.g. all vanilla events/etc. that check for muslim_group also check for SoI so that a separately unlocked religion in the group doesn't get access to anything it shouldn't.
- The ability to activate/deactivate religions during play, with fallbacks if some character is created/switched to a deactivated religion. This would make e.g. conversion to a random heresy easy to restrict to a certain period (e.g. you only want Lollards toward the end of the 14th century and later and having the religion deactivated ensures that there won't be Lollards before you active it) or to have inactive "blank" heresies you could "reform" with HF.
I was just thinking about something like this!
This would indeed be very useful - I'd personally would want to split the Indian group, because Taoism doesn't fit there (it's not even "Indian").
@blackninja9939: Since mods adhering to modding rules and not circumventing DLC restrictions is very much in your (Paradox) interest, could you consider adding this? Especially the first two options, which would just go one-way and pose no risk of undermining DLC restrictions at all; much to the contrary.
With Holy Fury and the potential (as mentioned by @Snow Crystal ) to create reformed heresies of reformed pagan religions, it'd be really cool to make that possible ahead of time with a mod. For instance, I'd really like it if Britannic could be made reformed, instead of pre_reformed.
Especially since pre_reformed religions seem to cause CTDs fairly regularly.
Especially since pre_reformed religions seem to cause CTDs fairly regularly.
I'd really love to see the criteria for electoral and papal successions surfaced more fully for modding. In particular, I'd love to be able to make it so that certain traits add electoral popularity - but perhaps only if the holder is of a certain culture - or if the title is a particular title.
So something like
voter_friendly = {
vassal_opinion = 5
elector_opinion = 5
if = {
limit = {
culture = French
}
elector_opinion = 5
}
if = {
limit = {
election = k_papacy
}
elector_opinion = 10
}
}
This pseudocode is intended to show a trait which makes the subject's vassals like them a bit more, and makes them a bit more popular in any election. The electoral bonus is increased by 5 if the subject is French, and by 10 if the election in question is a papal conclave.
(As far as I know, the condition 'election =' is completely invented; the intention is that it should return true during the evaluation of an election (of any type) for the named title, and false at any other time.)
nd
ETA: It would be great to be able to specify the conditions under which a character becomes (a) an elector and (b) a potential candidate for a given title.
So something like
voter_friendly = {
vassal_opinion = 5
elector_opinion = 5
if = {
limit = {
culture = French
}
elector_opinion = 5
}
if = {
limit = {
election = k_papacy
}
elector_opinion = 10
}
}
This pseudocode is intended to show a trait which makes the subject's vassals like them a bit more, and makes them a bit more popular in any election. The electoral bonus is increased by 5 if the subject is French, and by 10 if the election in question is a papal conclave.
(As far as I know, the condition 'election =' is completely invented; the intention is that it should return true during the evaluation of an election (of any type) for the named title, and false at any other time.)
nd
ETA: It would be great to be able to specify the conditions under which a character becomes (a) an elector and (b) a potential candidate for a given title.