Captain to the Rescue

[Divine]

I noticed when making a law adding things like pagan_opinion = 10 does not seem to work in laws, is this a bug or could it be fixed? I need my one law to give postivie opinion bonus to other specific religions

Those modifiers only seem to work inside traits and it would require quite a bit of reworking of the code to get them to work in other places. So unfortunately if you really need that I guess you'll have to resort to maintenance events that add/remove a specific trait depending on the law-status.

 

[Hotl3looded]

I'm assuming that you use the 'filter = all' in the top of the decision.
But it seems that there might have been a possible issue with the exact combination of filter = all for settlement_decisions that could result in it not evaluating all of the decisions when updating the alerts. I've made a fix for it now.

Yes I am using using 'filter = all'. Thanks for the fix!

 

[starwarsfan541]

Those modifiers only seem to work inside traits and it would require quite a bit of reworking of the code to get them to work in other places. So unfortunately if you really need that I guess you'll have to resort to maintenance events that add/remove a specific trait depending on the law-status.

Ok, good to know it wasnt an error on my end

 

[Hotl3looded]

I'm trying to show the name of the province in a settlement decision... I tested [Root.Province.GetName], [Root.Location.GetName] and [Root.County.GetName] but they don't work. They show the name of the settlement as if I had written [Root.GetName]. Is this normal?

Also, after adding a holding modifier with 'add_holding_modifier' I wanted to disable the settlement decision if the settlement had the modifier but the condition 'has_holding_modifier' doesn't seem to work.

 

[Darkgamma]

I'm trying to show the name of the province in a settlement decision... I tested [Root.Province.GetName], [Root.Location.GetName] and [Root.County.GetName] but they don't work. They show the name of the settlement as if I had written [Root.GetName]. Is this normal?

Also, after adding a holding modifier with 'add_holding_modifier' I wanted to disable the settlement decision if the settlement had the modifier but the condition 'has_holding_modifier' doesn't seem to work.

This is more appropriate for the quick modding questions thread

 

[ngppgn]

@Divine , there are a couple potentially very useful debug console commands that seems broken as of 2.5.2: "reload <filename>" and "reloadinterface". Both display mesages of success when typed in the console but have no actual effect. Have them working would incredibly dpeed up interface modding, since currently we need to exit and reload the game each time we modify any value in a .gui or .gfx file.

 

[Divine]

@Divine , there are a couple potentially very useful debug console commands that seems broken as of 2.5.2: "reload <filename>" and "reloadinterface". Both display mesages of success when typed in the console but have no actual effect. Have them working would incredibly dpeed up interface modding, since currently we need to exit and reload the game each time we modify any value in a .gui or .gfx file.

Do you have any last known working version? So that I can see quickly if something has changed in between that might affect it.

 

[ngppgn]

Do you have any last known working version? So that I can see quickly if something has changed in between that might affect it.

No, sorry if my wording implied otherwise, but I never was able to use them.

 

[vukica]

Hi, I'm from CK2Plus. We had this reported.
https://forum.paradoxplaza.com/foru...g-reports-thread.876342/page-82#post-21636314

Is this a bug regarding moddabiltiy of terrain types, or are we missing something?

I've attached our terrain file, if it may be relevant.

 

[Divine]

No, sorry if my wording implied otherwise, but I never was able to use them.

Not really, it just makes my inspection of the code easier when we break things with patches to know the last known functional version.

Hi, I'm from CK2Plus. We had this reported.
https://forum.paradoxplaza.com/foru...g-reports-thread.876342/page-82#post-21636314

Is this a bug regarding moddabiltiy of terrain types, or are we missing something?

I've attached our terrain file, if it may be relevant.

Yes, the background sounds does seem dependent on quite hard-coded definitions for terrain right now. It doesn't sound that healthy either to spam the log with error messages. I've notified the team about it and hopefully they'll get some time to take a look at it. Otherwise I'll remember to throw an eye on it later this fall.

 

[knuckey]

Just found a bug. The condition has_plot = yes does not seem to work, returning false if a character actually does have a plot. I'm using plot_target_char = { always = yes } as an alternative for now, but has_plot = yes is used in vanilla.

 

[michaelpetska]

Our mod uses ranges to keep characterIDs in the history files separate from eachother; it's split up by culture, so a given culture might have a range of 1000-2000, and if it has 9 historical entities, they'd be ID'd as 1001, 1002, 1003, and so forth.

We're considering cleaning them up so that they're more sequential, and we get lower character IDs. We were wondering what impact, if any, do numerically high Character IDs have on game performance?

 

[Alphathon]

I have another question/bug report regarding the renaming of titles.

It would seem that using name = X in the title history does not work at my first bookmark (which is 486.1.1), i.e. the name of the tile is the default name (so k_france shows as France etc). However, if I add another bookmark at an earlier date (e.g. 400) then the renaming at 486 does work, suggesting that to me that for whatever reason the game doesn't load name changes from the history at the first bookmark. This happens both in-game and on the character selection screen/map. I have tried putting the name = X both at 486.1.1 and earlier dates and the behaviour remains the same.

I do not know if this applies to all first/earliest bookmarks, those before a certain date or if there is something else at play. I am assuming this is a bug of some kind, although if I am missing something (like a define I have missed) of course please let me know.

EDIT: I should probably note that this also seems to apply to adjectives, but I haven't checked to see if it applies to flags/coats of arms.

EDIT 2: It should also be noted that it seems to be working for some titles. The titles that I have it working for are a duchy and several counties, while the ones which aren't working are both kingdoms. I don't know whether it is because they are kingdoms (EDIT 3: it isn't – it also seems to be affecting one of my counties), because they are independent, or some other reason.

 

[zijistark]

I have another question/bug report regarding the renaming of titles.

It would seem that using name = X in the title history does not work at my first bookmark (which is 486.1.1), i.e. the name of the tile is the default name (so k_france shows as France etc). However, if I add another bookmark at an earlier date (e.g. 400) then the renaming at 486 does work, suggesting that to me that for whatever reason the game doesn't load name changes from the history at the first bookmark. This happens both in-game and on the character selection screen/map. I have tried putting the name = X both at 486.1.1 and earlier dates and the behaviour remains the same.

I do not know if this applies to all first/earliest bookmarks, those before a certain date or if there is something else at play. I am assuming this is a bug of some kind, although if I am missing something (like a define I have missed) of course please let me know.

EDIT: I should probably note that this also seems to apply to adjectives, but I haven't checked to see if it applies to flags/coats of arms.

EDIT 2: It should also be noted that it seems to be working for some titles. The titles that I have it working for are a duchy and several counties, while the ones which aren't working are both kingdoms. I don't know whether it is because they are kingdoms, because they are independent, or some other reason.

Quick gotcha: do the affected kingdom titles have dynamic localisation for their names [culture/culture_group/religion_group variants]? The title naming effects in history do not work correctly with such titles. It occurs to me that my team has indeed diagnosed this issue and worked around it for some time as "tribal wisdom," but I don't know if the bug has ever actually been reported.

 

[Alphathon]

Quick gotcha: do the affected kingdom titles have dynamic localisation for their names [culture/culture_group/religion_group variants]? The title naming effects in history do not work correctly with such titles. It occurs to me that my team has indeed diagnosed this issue and worked around it for some time as "tribal wisdom," but I don't know if the bug has ever actually been reported.

I'm not quite sure I understand. While culture can be achieved in a landed_titles file using culture = name (e.g. welsh = "Brythoniaid"), I am unaware of any way to automatically change the name of a title based on religion or culture group. (Incidentally if there is a way to do the same thing for culture groups I'd love to hear it as it would allow me to simplify my files somewhat.) If you mean something else then please elaborate.

Regardless, I don't see how that would affect things only at the first bookmark.

By the way, it should perhaps also be noted that if I add an earlier bookmark the name change doesn't take effect unless I select the earlier bookmark then the one at 486; if I just go straight to 486 it exhibits the same behaviour.

 

[Molech]

I'm not sure this is the perfect place for this since I don't think it is mod specific but it is impacting my mod in particular because it has so many demense holdings. I've run into an issue where every month depending on how many days in the month the game freezes, the core that CK2 has access to goes to 100% and ck2game.exe shows not responding. This goes on for a while but eventually will start responding again. I ran a trace on the game process and from my limited ability to read it seems like all the troop calculations are being done for everyone at the same time.

CDemesne::CalcTotalMaxTroopCount and the associated sub processes seems to be what it's spending all it's time doing. My guess Is that this calc is done monthly for all characters on the 2nd, 18th or 25th depending on the month since if each char had their own it would be slow the same day of the month.

Would decreasing the number of troops per holding speed this up or the only way is to decrease the number of holdings?

 

[ngppgn]

I'm not sure this is the perfect place for this since I don't think it is mod specific but it is impacting my mod in particular because it has so many demense holdings. I've run into an issue where every month depending on how many days in the month the game freezes, the core that CK2 has access to goes to 100% and ck2game.exe shows not responding. This goes on for a while but eventually will start responding again. I ran a trace on the game process and from my limited ability to read it seems like all the troop calculations are being done for everyone at the same time.

CDemesne::CalcTotalMaxTroopCount and the associated sub processes seems to be what it's spending all it's time doing. My guess Is that this calc is done monthly for all characters on the 2nd, 18th or 25th depending on the month since if each char had their own it would be slow the same day of the month.

Would decreasing the number of troops per holding speed this up or the only way is to decrease the number of holdings?

IIRC, they said in a DD that calculation of threat will be changed so it doesn't apply to every character the same day. Probably that's related to your issue, so perhaps 2.6 will fix it!

 

[Molech]

IIRC, they said in a DD that calculation of threat will be changed so it doesn't apply to every character the same day. Probably that's related to your issue, so perhaps 2.6 will fix it!

I'm hoping it's included when they said:

• We’ve gone through cases where map modes, names, etc. were being marked as “outdated” on the map and in the UI, and ensured they’re actually only updated when truly in need of update. As an example, previously the occupation overlay would sometimes be marked as needing an update when no occupation status had actually changed, which of course would waste CPU cycles
• Several computations that used to be single-threaded are now multi-threaded
• Various improvements to a variety of performance-intensive computations

Thinking about it I'm pretty sure they could get away with doing the troop calc less frequently. Given how long wars are and how long build times are it seems unlikely a characters troop levels would change that frequently (monthly) so this would be a case where flagging to be updated only when a troop level change occurred may save CPU cycles.

I know the game will get faster after the patch. Every patch so far has sped up my games and I'm extremely thankful to the hard work it takes to make that happen. Keep up the good work guys!!

 

[Meneth]

Thinking about it I'm pretty sure they could get away with doing the troop calc less frequently. Given how long wars are and how long build times are it seems unlikely a characters troop levels would change that frequently (monthly) so this would be a case where flagging to be updated only when a troop level change occurred may save CPU cycles.

Levy calculation isn't an especially major consumer of CPU time in vanilla. More than it probably should be, but not enough to have a massive impact.
I don't see any real way it'd have a disproportionate impact in mods either, but it is entirely possible I'm overlooking something.

 

[Molech]

Levy calculation isn't an especially major consumer of CPU time in vanilla. More than it probably should be, but not enough to have a massive impact.
I don't see any real way it'd have a disproportionate impact in mods either, but it is entirely possible I'm overlooking something.

My mod has over 10000 provinces so it probably is not that comparable to what happens in vanilla. I'm sure it's a corner case