• 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.
I don't want to know what joeSchmo9351 is doing when they are playing Ancient Religions. I wanna know what percentage of my users are playing with AI Revival turned on/restricted/off, or if they are using my Unfit King beta feature turned on. I wanna know which starts they tend to use, which characters they tend to play, and whether they Ruler Design. I wanna know what are the most common mods to be paired with my own.

I don't care about individuals, I want compiled statistics. This information can better inform me about what features my users like most, and what areas I can add new content to encourage a more diverse set of starts/decisions.
It doesn't really matter, compiling that information is a hot ethical point regardless of the subject. Many people are very frustrated that this is becoming the norm and that it's impossible to use services or games without giving their meta data to the company that provides the service.
 
Allow a mod to reference an event ID or decision in a vanilla file and overwrite said event or decision WITHOUT having to copy the entire file. This will allow so many more mods to be compatible with each other as long as they don't overwrite the same event or decision (this is obvious).
 
You can already do this for events, though being able to do it for decisions would be nice.
As per my information you cannot do this.

If you want to mod a vanilla event and leave all other events unchanged, you have to copy the vanilla file which contains that event into your mod. Then edit the file in your mod. Upon game launch your mod's file will replace vanilla file and hence the modified version of the event will be loaded.

If another person wants to modify a different event in the same file he has to do the exact same steps as above. Thus making the two mods incompatible even though they changed different events but used the same file.
 
As per my information you cannot do this.

If you want to mod a vanilla event and leave all other events unchanged, you have to copy the vanilla file which contains that event into your mod. Then edit the file in your mod. Upon game launch your mod's file will replace vanilla file and hence the modified version of the event will be loaded.

If another person wants to modify a different event in the same file he has to do the exact same steps as above. Thus making the two mods incompatible even though they changed different events but used the same file.

That would require far more alteration to the game than virtually any other improved moddability suggestion. You'd have to change to entire way that the game reads mods, and you would break every single mod when you implemented the change. Is that really worth it?
 
That would require far more alteration to the game than virtually any other improved moddability suggestion. You'd have to change to entire way that the game reads mods, and you would break every single mod when you implemented the change. Is that really worth it?

It honestly depends on how they store/reference events. If it's a string/object dictionary, his proposal should be relatively simple. If it's almost anything else, it'll be a nightmare.
 
That would require far more alteration to the game than virtually any other improved moddability suggestion. You'd have to change to entire way that the game reads mods, and you would break every single mod when you implemented the change. Is that really worth it?
Event IDs (namespace + id) are resolved into numbers upon game load. I would assume that they are stored as numbers in a list somewhere and from there they point towards the code which was actually the event code. All they have to do is to implement that if an Event ID is duplicated then the one that loads afterwards will replace the contents of the one before.

In fact, they can even implement a "overwrite = yes" command inside the overwriting event. If included in the event, this command will cause deliberate overwriting of the previously loaded event to be accepted by the game whereas accidental duplicate event IDs (where this command would not be present) would still throw an error.
 
How would that with the mod compatibility? It'd only work if only one mod tries to override the event.

But what if both mods have their own version of the event, which is usually the case...? Well, those would still need to be merged manually. Same goes for any instances where one mod relies on the vanilla version of the event, but another mod changes that event.

I don't see the benefits.
In those instances, the mods are incompatible with or without philanthropic19's idea.

With his idea, many more mods will be compatible than are now. That's a pretty major benefit.
 
IWith his idea, many more mods will be compatible than are now. That's a pretty major benefit.
Hardly. I've done enough mod merging to know that there's always some overlap that must be fixed manually. Unless it's some single-event mini-mod. And those rarely modify the vanilla events.

It wouldn't do anything for compatibility, as far as I can see.
 
Hardly. I've done enough mod merging to know that there's always some overlap that must be fixed manually. Unless it's some single-event mini-mod. And those rarely modify the vanilla events.

It wouldn't do anything for compatibility, as far as I can see.
Let's say a vanilla file contains 500 events. "Mod A" modifies about 200 of those events and thus has its own copy of that file included in the mod files which has all the 500 events with 200 of them edited by the modder. "Mod B" wants to modify 1 event in that file but that 1 event is not one of the 200 events modified by "Mod A". The only way to do this right now is for "Mod B" to copy the entire vanilla file into it and modify that 1 event. "Mod B" will then contain the entire vanilla file with all the events in their vanilla state except the 1 modified by "Mod B". Thus the two mods are incompatible as they provide a different version of the same file and only one version can be loaded upon game start.

If, however, "Mod B" had the possibility to just make a new .txt event file and write only 1 event in it with the same ID as that vanilla event it wants to edit, then both mods will be compatible as there is no file conflict. Hence it will increase mod compatibility by a HUGE margin. Take the HIP mod for example, what if I want to make a mod which is compatible with HIP but modifies only 2 or 3 events in vanilla files which files are present in HIP because HIP modifies some other events in there than the ones I want to modify? Currently, I can't do this in any way without making the two mods incompatible even though they change completely different events.

It can be made more systematic by adding a new event command such as "overwrite = yes". It would work like this: if this command is included in an event written by a modder, then this event will overwrite any other event with the same ID. If this command is not included in the event, then a duplicate event ID is accidental and not intended and hence should throw an error.
 
I only modify two events in the soa event file for demonspawn events. The odds I'll have to update my overwrite of those events is tiny, I wouldn't even bother looking at the file most of the time.

If they did the same thing for CBs, it would be even better. I only modify Imperial Reconquest, Crusades, and County Conquest. Those CBs barely ever change. It would drastically improve my ability to create a com-patch for HIP too, as I could minimize the footprint of ACR.

Arguing that the ability to overwrite single events wouldn't help is like saying the change that made on_action modifications additive instead of overwriting was pointless. It's ridiculous.
 
Let's say a vanilla file contains 500 events. "Mod A" modifies about 200 of those events and thus has its own copy of that file included in the mod files which has all the 500 events with 200 of them edited by the modder. "Mod B" wants to modify 1 event in that file but that 1 event is not one of the 200 events modified by "Mod A". The only way to do this right now is for "Mod B" to copy the entire vanilla file into it and modify that 1 event. "Mod B" will then contain the entire vanilla file with all the events in their vanilla state except the 1 modified by "Mod B". Thus the two mods are incompatible as they provide a different version of the same file and only one version can be loaded upon game start.

If, however, "Mod B" had the possibility to just make a new .txt event file and write only 1 event in it with the same ID as that vanilla event it wants to edit, then both mods will be compatible as there is no file conflict. Hence it will increase mod compatibility by a HUGE margin. Take the HIP mod for example, what if I want to make a mod which is compatible with HIP but modifies only 2 or 3 events in vanilla files which files are present in HIP because HIP modifies some other events in there than the ones I want to modify? Currently, I can't do this in any way without making the two mods incompatible even though they change completely different events.

It can be made more systematic by adding a new event command such as "overwrite = yes". It would work like this: if this command is included in an event written by a modder, then this event will overwrite any other event with the same ID. If this command is not included in the event, then a duplicate event ID is accidental and not intended and hence should throw an error.

If you see conflicting files, use WinMerge or similar to compare and change them. Simple fix, instead of rewriting the whole engine to read events in a different matter. That's not going to happen either way.
 
Anyway, to get back on-topic;

A way for cultures to be moved from a culture group to another. Like a command, "set_culture_group = N", which you can issue in events. This would be great for melting pots; depending on how it was merged (majority was culture A and the ruler was culture B, so it goes in A's culture group, or visa-versa)

A way for cultures to be renamed the same way you can rename titles; this, too, would be great for melting pots, so you can rename something Anglo-French or Franco-English depending on how and where the melting pot appeared.
 
Anyway, to get back on-topic;

A way for cultures to be moved from a culture group to another. Like a command, "set_culture_group = N", which you can issue in events. This would be great for melting pots; depending on how it was merged (majority was culture A and the ruler was culture B, so it goes in A's culture group, or visa-versa)

A way for cultures to be renamed the same way you can rename titles; this, too, would be great for melting pots, so you can rename something Anglo-French or Franco-English depending on how and where the melting pot appeared.

This would only be useful if there existed some way to create a new culture from two other cultures. If suddenly french becomes part of the west Germanic group but still has entirely french names, then it'd be utterly useless.
 
This would only be useful if there existed some way to create a new culture from two other cultures. If suddenly french becomes part of the west Germanic group but still has entirely french names, then it'd be utterly useless.
I think his point was rather to have a melting pot culture with mixed names that e.g. was included in the west_german group, but that by event you could instead move it to the latin group, depending on circumstances of the game.
 
To improve modding potential of artifacts, could the following trigger and scopes be implemented?

is_equipped
any_equipped_artifact
random_equipped_artifact

Maybe also artifact equip on_actions?

on_artifact_equip
on_artifact_unequip
 
Last edited:
Is there a possibility of adding "sibling" cultures, or a chained "parent-child"?

What I mean is like, say we have the core "English Culture", that it could have two children, say "Southern English" and "Northern English". Right now, they can both have 'English' as their parent culture, but they will regard each other as "foreign". Trying to Multi-tiet the parents (so "Southern English" is a child of "Northern English" which is itself a child of "English") does not appear to work, as the second-tier and above cultures are still treated as completely separate.
 
Yeah, it's impossible to do anything more complicated than culture_group > culture. I'd love to be able to have something akin to subgroups, or the ability to simulate it by saying "these two cultures like each other slightly better than normal." So I could make Scots and Irish folk dislike each other slightly less than they dislike the Welsh and Bretons (who they obviously dislike less than people in completely different groups).