Suggestions for Improved Moddability

[Slime99]

Okay, this is going to be alot to ask, but could airplanes be made moddable? Maybe taking them from HOI4 or give a modifier for units that allows them to "walk" on water.
This is no experienced scripting but it it could be something like this:
CAN_WALK_ON_WATER = yes

Or

WALKABLE_TERRAIN_TYPES = {
water
desert
....
}

 

[ngppgn]

I'm sure this was asked for many times, but i did not found any occurence, so i'll just ask. Can we have the ability to add custom sounds without having to overwrite the sound.sfx file? This would make compatibility between different mods way easier and i don't understand the reason behind why this was made possible for music but not for sounds.

Can we not add other .sfx files already?

 

[Vaweila]

Can we not add other .sfx files already?

Tried it today. Sadly we still have to copy over all the contents from the original which makes it impossible for mods to be compatible with other ones who also add new sounds without having to change files.

 

[jursamaj]

Tried it today. Sadly we still have to copy over all the contents from the original which makes it impossible for mods to be compatible with other ones who also add new sounds without having to change files.

Even if you add a .sfx file with a name besides sounds.sfx?

 

[Vaweila]

Yeah, but its actually 'sound.sfx' and not 'sounds.sfx' (thats weirdly still wrong in the wiki). If you have the same file in your mod-folder it will just overwrite the original, resulting in having no sounds except your modded sounds in the game. If you have any file not exactly named 'sound.sfx' it will not be processed.
Only way currently is to copy over all the contents of the original one to yours, which makes your mod kind of error prone when combined with other sound-changing mods :S

 

[theStormWeaver]

Can we get a random_mercenary_band to go with any_mercenary_band? It's a weird discrepancy and it's making a couple features I'm trying to develop much more resource intensive than they need to be.

 

[Chevaresqye]

Can we have a define option to choose a fixed day of a month for wealth/piety/prestige to update.

I am currently working on a new yearly based income/resource system that would override the vanilla tax system. I want to hijack the monthly income tooltip to display information to player, but I do not want the random resource update tick to be interfering with my system. In addition, having all the resource all update in same day would also allow modder manipulate vanilla tax system more easily.

 

[DC123456789]

An unsafe_character_event command (and comparable ones for province/letter/narrative/etc. events) that triggers the event regardless of whether or not the character meets the requirements would be useful.

 

[LordPeter]

An unsafe_character_event command (and comparable ones for province/letter/narrative/etc. events) that triggers the event regardless of whether or not the character meets the requirements would be useful.

Can you explain what you mean by that? Because I don't think I understand you.
Couldn't you just use an event with no requirements instead?

 

[DC123456789]

Can you explain what you mean by that? Because I don't think I understand you.
Couldn't you just use an event with no requirements instead?

For example, I have an event which can either be triggered either through a decision or by an MTTH timer. The decision might (intentionally) have different requirements than the event, so that it's possible that you can take the decision without being eligible to get the MTTH event. It's not that hard to work around (you can do some stuff with setting flags and instantly removing them, or creating a secondary shadow event that has the MTTH and triggers that fires the event you want), but it is kind of ugly and inelegant to do so (like how to work around war declaration triggers in the absence of unsafe_war/reverse_unsafe_war).

 

[ngppgn]

An unsafe_character_event command (and comparable ones for province/letter/narrative/etc. events) that triggers the event regardless of whether or not the character meets the requirements would be useful.

A slightly more elegant options would be an optional bypass_triggers = yes parameter in the already existent commands.

 

[Romulien]

For example, I have an event which can either be triggered either through a decision or by an MTTH timer. The decision might (intentionally) have different requirements than the event, so that it's possible that you can take the decision without being eligible to get the MTTH event. It's not that hard to work around (you can do some stuff with setting flags and instantly removing them, or creating a secondary shadow event that has the MTTH and triggers that fires the event you want), but it is kind of ugly and inelegant to do so (like how to work around war declaration triggers in the absence of unsafe_war/reverse_unsafe_war).

In such case I use the secondary event you mention:
- 1 triggered_only event with the event stuff
- 1 MTTH hidden event with specific restrictions and that fires the triggered_only event. There may also be some ping events to setup ROOT/FROM scopes correctly, if needed.
- 1 decision with specific restrictions that fires the triggered_only event

In my opinion it's cleaner and more flexible/maintainable !

 

[DC123456789]

In such case I use the secondary event you mention:
- 1 triggered_only event with the event stuff
- 1 MTTH hidden event with specific restrictions and that fires the triggered_only event. There may also be some ping events to setup ROOT/FROM scopes correctly, if needed.
- 1 decision with specific restrictions that fires the triggered_only event

In my opinion it's cleaner and more flexible/maintainable !

Yes, but it would still be a lot cleaner to have the specific command. Especially when you're converting old code and you don't actually have any convenient event ids to spare...

 

[Silversweeeper]

A on_de_jure_drift on_action would be nice so that it e.g. would be possible to restore something to whatever its previous de jure was dynamically if it drifts into something that shouldn't have a certain de jure vassal (or any de jure vassals at all).

 

[loup99]

A on_de_jure_drift on_action would be nice so that it e.g. would be possible to restore something to whatever its previous de jure was dynamically if it drifts into something that shouldn't have a certain de jure vassal (or any de jure vassals at all).

Wouldn't the opposite of assimilate = no to ensure titles can not drift into a title at all be more helpful in the case you describe?

 

[Silversweeeper]

Wouldn't the opposite of assimilate = no to ensure titles can not drift into a title at all be more helpful in the case you describe?

That is also an option, though with an on_de_jure_drift on_action you could account for special cases if you want to disallow specific cases of de jure drift (e.g. land belonging to d_brittany cannot drift out of k_brittany, but any other land belonging to k_brittany can drift out of it).

 

[loup99]

That is also an option, though with an on_de_jure_drift on_action you could account for special cases if you want to disallow specific cases of de jure drift (e.g. land belonging to d_brittany cannot drift out of k_brittany, but any other land belonging to k_brittany can drift out of it).

If you don't want d_brittany to drift out of k_brittany, a special flag on d_brittany for it to not drift away at all would work and be better than an on_de_jure_drift on_action which would trick the player into believing titles are drifting.

 

[Silversweeeper]

If you don't want d_brittany to drift out of k_brittany, a special flag on d_brittany for it to not drift away at all would work and be better than an on_de_jure_drift on_action which would trick the player into believing titles are drifting.

Yeah, on further thought that might work (at least most of the time), though things could be messy if you want to restrict valid new de jure lieges (e.g. d_brittany can drift into k_france (and back into k_brittany), but not into any other kingdom).

 

[loup99]

Yeah, on further thought that might work (at least most of the time), though things could be messy if you want to restrict valid new de jure lieges (e.g. d_brittany can drift into k_france (and back into k_brittany), but not into any other kingdom).

Definitely, in that case the on_action would be better.

 

[TheDarkMaster]

Yeah, on further thought that might work (at least most of the time), though things could be messy if you want to restrict valid new de jure lieges (e.g. d_brittany can drift into k_france (and back into k_brittany), but not into any other kingdom).

This whole discussion makes it sound like it would be a good game rule for the base game.

1. Allow all duchies to De Jure drift freely
2. Disallow duchies in special titles like Jerusalem from De Jure drifting away or specific titles like the papacy from gaining De Jure duchies
3. Restrict kingdoms to a maximum duchy/county size they cannot grow beyond
   
4. Restrict kingdoms to a minimum duchy/county size they cannot shrink past
5. Alternatively to 4, restrict historical capital duchies of kingdoms so they cannot De Jure drift
6. Various combinations of rules 2 to 5.