I'm not even asking for really complex statistics, like which start date is chosen more by those who have Unfit King turned on. I'm looking for simple statistics that *should* be relatively easy to compile.
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.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.
As per my information you cannot do this.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.
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.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?
In those instances, the mods are incompatible with or without philanthropic19's idea.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.
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.IWith his idea, many more mods will be compatible than are now. That's a pretty major benefit.
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.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.
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.
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.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.