Start date order is causing issues with trade posts
thefinestsieve opened this issue · 25 comments
Vanilla has a known bug (something Paradox is either unable or unwilling to fix, according to their replies) where if a start date is selected and then you switch to an earlier start date, the game will load up with broken trade posts which cause crashes if selected. Because PB doesn't have the start dates in chronological order, this issue is prone to happen to any users who select the 867 bookmark. I suggest moving them back to chronological order.
Unable or unwilling to fix? Wha?
Well, I suppose that I suggest moving them back to chronological order, even though that really sucks. [867 is really not the place for users' game to default.]
Does this happen always when an earlier start date is selected after a later one? So always when going backward in time or selecting an earlier bookmark? That's just not acceptable. They need to remove the ability to go backward in time from the UI then...
Meanwhile, nonsensical possibly-EMF CTDs related to just scrolling the map to a specific area over here... Coastal, FWIW...
I'm prepared to swear I read a Paradox employee reply about the issue, but upon searching I can't find anything. At any rate, they haven't replied to about half a dozen bug report threads on the issue stretching back to at least the beginning of the public beta. And yes, it seems to always happen if you load an earlier bookmark after a later one; I don't know if it also happens just by manually rolling time back, but I assume it does.
A Paradox Moderator commenting on it probably never getting fixed:
(MFCamillus sent me that link.)
Should we just tell users that's how Paradox games are, or should we subject them to a default 867 start to get around something that's presumably more fundamental than just bookmark-jumping (which is bad enough as it is) and definitely more fundamental than trade posts, no doubt.
AndrewT makes a hidden point for us, though. If you can't go back to the main menu and not have to jump to a bookmark backward in time to get to a legitimate start date, then we're not allowing the users, no matter how smart, any way to follow best practice to avoid bugs like these. They will always be affected by the bug with a pre-1066 start-- not just be prone.
That moderator response is pretty pathetic. "The bug won't be fixed because it's been there a really long time."
I'd like for us to at least put some pressure on Paradox to actually fix it before doing anything about it.
@Meneth : Can you do that? I'll support you, of course.
In the interim, we should switch to a chronological order, because currently, we've a fundamentally broken-always 867 start date (no workaround, no matter what you do), and one thing's for sure: even if they fix the bug, it won't be fixed soon, while we'll probably put out a maintenance release today with a fix for the claimant faction CB being broken and various SWMH fixes.
Can't we fix the problem by event?
I have no idea.
I don't think there's a way to destroy trade posts by event. Certainly not create them. You can seize them...
I think there's an event code to destroy trade posts.
I would say embargo any_playable_ruler = { is_merchant_republic = yes }, but the problem is specifically that no characters actually own the trade posts.
destroy_tradepost = FROMFROM
As long as we can scope to them there's no issue. They seem to take a province as scope.
So simply a list of trade posts to destroy and we've fixed the issue, I think?
Who's FROMFROM? A character? If so, that's trouble. I'm assuming the enclosing scope is province.
We can't scope to nonexistent characters.
Definitely takes a province, not a character.
I'm not super-familiar with this bug, but I think we'd have to take the approach of destroying all provinces' tradeposts, because the affected province set depends upon which bookmarks (or where in time, generally) from which you jumped back to the 867 bookmark before starting.
The only important thing to fix is 867 since that's the only bookmark where you're guaranteed to jump back.
(Well, first 1066 bookmark too, but I assume since all the characters are still alive that won't cause issues)
Is there some way to tell by event the difference between a legit tradepost and one that isn't? Can we scope to the tradepost owner from a province? [Should be able to...]
- I don't want to compile an SWMH and non-SWMH set of affected province IDs.
- If we're going to fix the bug, we should fix the bug. Merely clicking on another bookmark beforehand breaks any strategy but looping over all provinces.
/2. It's a vanilla bug.
Surely there's a tradepost_owner or some such. If there is, we can test tradepost_owner = { always = yes } in combination with something that confirms the province has a trade post (I assume there's a boolean check) on all provinces on startup, then destroy the trade posts that have no valid owner. Then we fix the actual bug and don't have a fragile set of province IDs that has to be collected for each map (I'm not volunteering to do that).
Yep, there's trade_post_owner.
Looks like there's a has_trade_post trigger as well. That should theoretically be enough if destroy_tradepost works as you mention.
I'll test an implementation out now.
Internal game state is too screwed-up for a by-event fix for this, not even with static province IDs (which can only be collected from a savegame extraction due to the way the ghost TPs present in-game).
Conclusion:
Action Item: Re-order bookmarks.txt chronologically, possibly adding a font-color/weight-highlighted prefix to the TOG scenario description such as [ Preferred bookmark: William the Conqueror ].