You are overriding it with nothing, so it defaults to showing the localisation key.
Captain to the Rescue
- Thread starter Captain Gars
- Start date
-
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.
As part of improvements to the loc system, most things like this check for the presence of a loc key, rather than the loc key returning an empty string.
This generally makes the system more robust, but does mean that setting loc to blank doesn't eliminate that loc any more.
- Aug 28, 2013
- 2.414
- 8.556
Would the addition of using something like just _ or [Null] as being hardcoded to return a blank string be possible?
That wouldn't fix this issue, since this is about how job titles are localised based on culture and the like. That explicitly checks for the existence of the appropriate loc key, and then uses it if it exists.
The modder wants to fall back to some other loc, which it would if the key didn't exist to begin with. There's currently no way to delete a loc key except by literally removing it from the file.
With the beta patch 2.7.1 available we'll keep an eye on this thread if there pops up any unexpected and undesired changes to mod features from the 2.7-2.7.1 patches. Please help us get aware of those issues so that we can take action as soon as possible. We do however have a very limited time to patch the issues at the moment so focus on critical issues of changed behaviors.
Using conditions like culture, culture_group, portrait_society and probably more on undefined values now evaluates to true instead of false.
The previous behavior was useful for supporting different mods without duplicating scripts.
The previous behavior was useful for supporting different mods without duplicating scripts.
Could you give an example? I don't quite understand what the issue is.
- Aug 28, 2013
- 2.414
- 8.556
I imagine they mean if you do something like culture = orc in your mod as it can be used both in vanilla and a fantasy mod.
If you are just using vanilla if you previously did if = { limit = { culture = orc } blahh} then it would not run the if clause but now if you do the same thing that clause does get run? At least that is what I assume is being meant but I have not tested it out personally on anything before
That's right. For example, supporting HIP's north_african culture group now considers everyone in the vanilla world north african.
Well crap, I have some code that checks for SWMH cultures. Glad to know!
Using the statement "max_wives = 0" in a religion definition used to make it impossible for men of the religion in question to get married without the need for traits that bar them from being able to be landed. I was updating one of my mods for Monks and Mystics and discovered that this doesn't work anymore. I know that this was probably not an intended behavior of max_wives, but it was useful. Could that functionality be reimplemented?
I'm unable to actually reproduce this issue. I made a test decision with "allow = { culture = orc }", and that shows up as false, as one'd want it to.
I did spot one issue where it'd always return true if the scope you're in isn't something that has a culture, but that'll only cause issues if you're using the trigger somewhere you shouldn't. I'll fix it, but it doesn't match what you describe.
Could you describe in more detail how to repro your issue?
Edit: Oh, it only affects culture groups. Spotted it now. Will fix.
Also the portrait_society one as you mentioned; that's return true if someone didn't have a society, since that'd compare as the same as an invalid society.
Will fix that too.
If you notice other triggers with similar issues, do poke me. Though generally we do consider invalid RHS to be an error, which is logged when you use -debugscripts, so can't guarantee it'll always be fixed. When it is a change to behavior mods rely on already though, it'll generally get fixed.
But don't expect new triggers to work that way. Prefer using scripted triggers for that kind of thing so that you can just have the scripted trigger always return false if Orcs aren't a thing or whatever.
Was there some change to the way memory is addressed in the 2.7.1 beta patch? My enormous mod(over 10k provinces) stopped working in 2.7.0 and now it's back working on the beta. It just gave CTD with nothing in the logs and the dump shows exception: The thread tried to read from or write to a virtual address for which it does not have the appropriate access.
(I wasn't sure whether to post this here or in Bug Reports, so I've done both)
I've searched the changelogs and forums and haven't found any indication that this was intentional. I hope it wasn't intentional, as I really don't like this change.
In 2.6.3 and prior, historical characters (that is, characters defined in the history files) with no set dynasty would be lowborn, unless they were placed in a role that required a dynasty (e.g. if they were a feudal ruler). Additionally, characters randomly generated to hold a title (with no historical holder set) would also be lowborn unless otherwise required (again e.g. if they were a feudal ruler).
In 2.7.x, all historical characters (even those with no title whatsoever) are given dynasties regardless of whether any dynasty is set in the history files. Only 'effect = { dynasty = none }' can change this. Additionally, characters randomly generated to hold titles are also all given dynasties (and in that case any attempted script-based remedy would, I think, potentially take a fair bit of work to ensure it avoided false positives), regardless of the government type they end up with.
I've searched the changelogs and forums and haven't found any indication that this was intentional. I hope it wasn't intentional, as I really don't like this change.
In 2.6.3 and prior, historical characters (that is, characters defined in the history files) with no set dynasty would be lowborn, unless they were placed in a role that required a dynasty (e.g. if they were a feudal ruler). Additionally, characters randomly generated to hold a title (with no historical holder set) would also be lowborn unless otherwise required (again e.g. if they were a feudal ruler).
In 2.7.x, all historical characters (even those with no title whatsoever) are given dynasties regardless of whether any dynasty is set in the history files. Only 'effect = { dynasty = none }' can change this. Additionally, characters randomly generated to hold titles are also all given dynasties (and in that case any attempted script-based remedy would, I think, potentially take a fair bit of work to ensure it avoided false positives), regardless of the government type they end up with.
What's the expected behavior if the game loads two events with the same ID in the same namespace. From my previous scripting, it seems to use the last one loaded, but I haven't converted that to the latest version to test it. However, others have suggested that it uses the first version loaded, uses the vanilla event, or crashes the game. The wiki just says "[?]Merge", which seems to by what it lists when the result isn't known.
Is culture_flex actually working for character modifiers? I tried adding it to the character modifier of a government and it shows up in the tooltip, but the cultural differences opinion modifier doesn't seem to have actually changed.
- Aug 28, 2013
- 2.414
- 8.556
1) Please don't necro old threads
2) culture_flex should modify the opinion_realm_foreign_culture and opinion_realm_related_culture modifiers