Suggestions for Improved Moddability

[markmid]

Sorry to make this request so general.

Anything you can do at all, to make mods more easily compatible with the converter if they want to.

 

[quastra]

I've always wanted paradox to release official mod tools, like what fireaxis has done. Most of the current user made mod tools are either outdated or only run on windows.

 

[JonStryker]

There's the "tolerates_religion" modifier that can be used in traits.
I'd love to have the same for cultures and culture groups. If someone has a trait with that people of the tolerated culture would not have negative modifiers, provinces would not have revolt risk from foreign culture.

 

[Zaltys]

I'd love to have the same for cultures and culture groups. If someone has a trait with that people of the tolerated culture would not have negative modifiers, provinces would not have revolt risk from foreign culture.

Supposedly, that's what the 'culture_flex' trait modifier does.
But I'm not sure if it's actually working in the current version; the tooltip definitely works, but I haven't quite figured out how to test the effect.

 

[fanoI]

A way to order the characters resulting from "any_independent_ruler" / "any_vassal" for example I'd like to have them ordered by tier in other occasion I would have them ordered by prestige...

It could be used in this way:

any_independent_ruler = {
     order_by = tier # or "order_by = prestige" or "order_by = piety" etc...

     character_event = xxx # First the Emperors will get the event, then the Kings, then the Dukes and so on...
}

By the way is this thread yet maintained? The first page is not updated by months...

 

[theStormWeaver]

There are about a dozen different suggestions in the "localization" section, but I'd like to condense them down into just one.

Please normalize the localization implementation.
ANY localization key should support a culture(-group)/religion(-group) variant. In my mod, for instance, I'd like to have:

GOD_JUPITER;Jupiter;;;;;;;;;;x
GOD_JUPITER_greek;Zeus;;;;;;;;x
# Or even better
GOD_JUPITER_byzantine;Zeus;;;;;;;;;;x

I don't think you should drop support for the cultural naming in landed titles. There are too many mods out there that would suddenly lose all of their cultural title names. Large, popular, mods. But adding support for it in the regular localization files would be fantastic.

In the places where multiple variant localizations exist, culture should take precedence over religion, and specific ones over groups. Meaning culture > culture group > religion > religion group.
This would also allow you to remove the "priest_title" from religions and put it with the localization.
Because the localization is a localization and it belongs in the localization

 

[JonStryker]

Supposedly, that's what the 'culture_flex' trait modifier does.
But I'm not sure if it's actually working in the current version; the tooltip definitely works, but I haven't quite figured out how to test the effect.

Well I'd love to have it aimed at a specific culture or culture group. The culture_flex (supposedly) sets it for all foreign cultures at once, right?

 

[Jorlem]

Speaking of traits, I think it would be nice to have multiple groups of traits defined in trait that the person with the trait could have opinions of, instead of just opposing traits. So you'd have something like

some_trait = {

[INDENT]group_1 = { [/INDENT]
[INDENT=2]wroth 
[/INDENT]
[INDENT]}
group_2 = { 
[/INDENT]
[INDENT=2]lustful 
[/INDENT]
[INDENT]}

group_1_opinion = -10
group_1_opinion_if_same_religion = -15

group_2_opinion = -20
group_1_opinion_if_same_culture = 25
[/INDENT]
 }

 

[Romulien]

Please improve mod compatibility, as today medium-sized mods are most often incompatible with each other:
- Merge of on_action files (new events being added to the previous list of on_action, instead of replacing it)
- Merge of common/cultures/ files when redefining the same culture_group or culture in multiple files (using same behavior as common/religions/ !)
- Folder-based loading for defines.lua, coats_of_arms.txt, triggered_modifers.txt, combat_tactics.txt, disease.txt, etc.
- Extensibility of icon strips like GFX_religion_icon_strip (for instance using a namespace for frame index: icon = mystrip.9)
- Allow override of a vanilla decision, by redefining it with the same name in a different file (today it breaks the decision effect)

 

[zijistark]

Please improve mod compatibility, as today medium-sized mods are most often incompatible with each other:
- Merge of on_action files (new events being added to the previous list of on_action, instead of replacing it)
- Merge of common/cultures/ files when redefining the same culture_group or culture in multiple files (using same behavior as common/religions/ !)
- Folder-based loading for coats_of_arms.txt, triggered_modifers, combat_tactics.txt, disease.txt, etc.
- Extensibility of icon strips like GFX_religion_icon_strip (for instance using a namespace for frame index: icon = mystrip.9)
- Allow override of a vanilla decision, by redefining it with the same name in a different file (today it breaks the decision effect)

How could you forget allowing defines.lua to be folderized?

They're easily-separable key-value pairs that currently force control of the whole bloody game to one mod that just needed to change a single define.

 

[Romulien]

How could you forget allowing defines.lua to be folderized?

They're easily-separable key-value pairs that currently force control of the whole bloody game to one mod that just needed to change a single define.

Agreed, that was a tragic omission ! (though covered by the etc. at the end of the list )

 

[JonStryker]

Please improve mod compatibility, as today medium-sized mods are most often incompatible with each other:
- Merge of on_action files (new events being added to the previous list of on_action, instead of replacing it)
- Merge of common/cultures/ files when redefining the same culture_group or culture in multiple files (using same behavior as common/religions/ !)
- Folder-based loading for defines.lua, coats_of_arms.txt, triggered_modifers.txt, combat_tactics.txt, disease.txt, etc.
- Extensibility of icon strips like GFX_religion_icon_strip (for instance using a namespace for frame index: icon = mystrip.9)
- Allow override of a vanilla decision, by redefining it with the same name in a different file (today it breaks the decision effect)

That would be great!
But aren't culture groups extendable already? I distinctly remember to have done that 1-2 weeks ago.

 

[Romulien]

That would be great!
But aren't culture groups extendable already? I distinctly remember to have done that 1-2 weeks ago.

In my tests the groups don't "merge", for instance adding a new culture to a vanilla group in a file mymod_cultures.txt:

celtic = {
  gaulish = {
    #Definition of gaulish culture
  }
}

Then in-game, if you compare culture_group between an Irish and a Gaulish character, the condition evaluates to false (different group).
Also, in ruler designer 2 culture groups appear.

But maybe there is another syntax ?

 

[zijistark]

Since Gars will be back on the job soon enough now, I guess that I should start weighing-in. Here's a really obvious and easy moddability suggestion that would do a huge favor to multiplayer mods:

Trigger (character scope): is_multiplayer_host = yes/no

A lot of mods offer or require customization decisions (usually upon scenario startup but sometimes also mid-game). Currently, there's no automatic, fool-proof way (the only other way is literally asking all players) to detect which player is the host of the game and thus the ONLY one who should be able to modify the scenario or rules of the game. This is currently a big barrier to seamless multiplayer deployment for some major mods.

Footnote: The trigger ought to return true for the sole player in single-player, for consistency. In this vein, it might be better: is_player_host = yes/no

 

[zijistark]

Another very simple suggestion. This time, let's talk variables.

Effect (character, province, or title scope): clr_variable = <var_name>

Why? Currently, there appears no way to free the memory (and variable hash table allocation) associated with having used a variable. set_variable = { which = <var_name> value = 0 } will ensure that, once the user _saves and reloads the game_, the variable is no longer cluttering game data structures, but until then, the variable, once used, will remain allocated and set to 0 for that character/province/title.

This really wouldn't be too big of a deal if it weren't for the fact that using variables across scope boundaries (e.g., summing a variable score across a large set of objects) requires heinous amounts of temporary variable copying across scopes (oft into improperly-named local variables so as to be able to compare/multiply/whatever with another variable in a different scope).

The effect should be dirt-simple to implement, is consistent in interface with the clr_<whatever>_flag = <flag_name> and remove_<whatever>_modifier = <modifier_name> syntax, and would actually allow me to justify usage of extended cross-scope variable operations in mods that care about performance and memory constraints.

[Though, I'd trade this for a solution to the need for all those temporary variables in the first place!]

 

[fanoI]

Two things could help modder a lot:

1. A lot of times one creates a lot titles in the landed_titles file and the game load apparently correctly but in reality all the COAs are wrong! You have forgotten to add the flags of the new titles... but as the thing is subtle to notice you could find this day after the fact! Now what were these title I added? Good luck with that! The game could simply show a placeholder flag for the titles without COA instead to do all that mess, is this possible?
2. The error.log file should be more useful, the case of before should be really logged so as others (file encoding wrong, no valid characters in file and so on...) yes we have the Validator but this should be Paradox work IMHO...

 

[zijistark]

A lot of times one creates a lot titles in the landed_titles file and the game load apparently correctly but in reality all the COAs are wrong! You have forgotten to add the flags of the new titles... but as the thing is subtle to notice you could find this day after the fact! Now what were these title I added? Good luck with that! The game could simply show a placeholder flag for the titles without COA instead to do all that mess, is this possible?

FWIW, the Validator will already tell you when you lack a flag for a title. Precisely which ones.

The reason the game "fails hard" is due to an optimization/simplification of the already-intensive flag-cache calculation and processing that needs to be done at game startup (everytime). IMHO, this is a case where modders should just use existing tools (again, see: Validator) or modding discipline to ensure that they don't screw-up the flag cache.

The error.log file should be more useful, the case of before should be really logged so as others (file encoding wrong, no valid characters in file and so on...) yes we have the Validator but this should be Paradox work IMHO...

Certainly the lack of reasonable debugging output sucks. A lot of this, though, is because the engine itself doesn't check for any of those types of errors-- not that it fails to report what it knows. File encoding errors are nontrivial to detect, e.g. What you're asking for would be great (an engine that actually failed early and often with a useful message rather than one that blunders right over bad input and fails catastrophically), but I doubt that Captain Gars could possibly make a dent in the sheer amount of [lack of] error-checking in the retail EXE that needs to be addressed. He could perhaps, however, try to get more of the existing debug asserts into the retail EXE (and fix the -debugscripts command line option, which was already inadequate but apparently seems to have become nonfunctional somewhere around patch 2.2).

Finally, I do recommend running the CK2 EXE under the debugger of gdb or MSVC++ (both of which are free or have free editions). Even the retail EXE dumps a lot of very useful errors in this mode (only really useful for debugging the startup sequence, though).

 

[IratePirate-]

Allow holding icons to be added for specific counties. e.g. if I wanted to give the temple holding of Canterbury its own symbol I could do so without it overriding every single temple icon in the game.

 

[Meneth]

With Gars' permission, I've moved the list to the wiki: http://www.ckiiwiki.com/Modding_suggestions

This means that anyone can now add to the list, though I'll probably rewrite suggestions for clarity and readability. Registering to the wiki is not necessary, but recommended.
If vandalism becomes a problem, editing will be restricted somewhat (requiring users to actually register and edit something else first), but I don't expect it to be necessary.
Note that there's a significant backlog of suggestions. Only suggestions from before 2014-08-11 are on the list, so if you've suggested something after that you should add it to the list.
This thread will still remain for discussion, and it is recommended to post in this thread whenever one adds to the list.

 

[knuckey]

Thanks Meneth. I've moved all the suggestions that I'm aware have been implemented to the 'Implemented suggestions'. This includes:

Spoiler

Title-level flags (code, not gfx)
The ability to modify succession crises by the new ruler's age, traits or stats
Ability to change portrait sets by event
Ability to add new diplomatic interactions
Add an on_startup on_action
Add a way to check that a certain number of conditions within an OR are true, rather than just one. E.G., requiring that at least two of the conditions be true in order for an event to trigger
Make it possible to weight the options in a random_list using modifiers. E.G., one of the random outcomes being 5 times as likely if the character is brave
Make it possible to check the culture/religion of a title as defined in landed_titles (titles can currently have culture and religion fields that determine the culture/religion of generated rulers). E.G., kingdom = { culture = ROOT }
Export the 1 crown law change per life limit to defines
Allow using localisation commands (E.G., [Root.Religion.GetName]) in nicknames
Allow overriding event localisation dynamically (E.G., "if = { limit = { culture = norwegian } text = EVT1000.norwegian })
Allow inserting arbitrary numbers into custom tooltips (E.G., having [GetCustomTooltipValue] be replaced by a value parameter (value = 100, or value = variable))
Allow localising nicknames based on culture/religion/gender
Ability to change the relative frequency of names. (E.G., William might be set to three times as common as Godfrey)

There are probably others I've missed in the list somewhere.