NathanKell

Thanks, my major update at work shipped and while I was dumb enough to sign up for a bunch of work on the next one, it's not as bad, so I hope to have more time. There's definitely something hosed with that method. I need to figure out exactly what the stock method is doing, and maybe I have to just rewrite it with checks in place to be sure things don't keep blowing up.

Updated to UAD 1.6.1.4. Thanks! On top of work being busy we had a lengthy power outage last week so I'm just now getting back to things. I haven't looked at the new dll yet so I don't know what ConfigValidation is, I assume they added something to check to see if game data was modified. My guess is it'll only cause issues in multiplayer though. As to the freezes, that seemed mostly related to incorrect borders which The Baron has been fixing. The OP describes installation instructions, it mostly involves unzziping a TAF release. Fixed. Apologies for delay!

If folks encounter further crashes (well, freezes--as far as I can tell no one has actually reported a crash, just the game freezing up) after that update, I should be able to debug them by locally reimplementing the function that is causing the problem and spewing debug information.

Dunno, you'd have to try it and see? Depends how much work you want it to do and how well you write it.

This hasn't been updated since 1.4 or 1.5. I've been busy with TAF and haven't touched my more-extreme work in 6+ months. So that would be why, it's no longer compatible.

Sure it's possible, you'll need to hook into AIManageFleet probably?

If you started from a fresh dump of provinces from 1.6.1.3 then my only guess as to why it's causing issues for NAR and not for vanilla is because some of the minors have become majors so there are different minor nation checks? I'll read through the function in question. If the provinces.csv dates from an earlier dump, then perhaps the devs encountered these same issues and fixed them themselves once having these bugs started causing real problems for them (thanks to the new features). It's also worht mentioning that, if memory serves, much of this data is saved in save games so if there is an existing save, simply fixing the provinces.csv file won't necessarily result in a fix to the save game.

3.16.5 * Support enforcing maximum speeds during ship generation, even if there is spare tonnage * Recompile for UAD 1.6.1.3 and MelonLoader 0.6.6

Then that may well be a stock bug, and is worth trying to repro in stock, I guess?

Are you absolutely sure you're on 3.16.4? Because I don't see that in the code, and besides which unless you set taf_peace_check to 1 my code isn't even running anymore. It's possible that that's a stock bug?

I've defaulted the peace stuff to off, and updated to 1.6.1.2.

Yes the underlying code of the game around this stuff changed drastically so using a params file from 1.6.0.6 is not going to end well. You can try diffing 1.6.0.6's vanilla params vs 1.6.1.1's and porting those changes while keeping NAR's to get a working hybrid file, I guess?

Sorry for the absence folks, combination of continued recovery from illness, plus extreme busyness at work. I've uploaded 3.16.3 which supports 1.6.1.1 Optx2, and hopefully fixes the peace issues. Please let me know of other issues you encounter, and when you do please upload the entire Melonloader log (UAD\MelonLoader\Logs\<log date/time>.log). Thanks!

Thanks! Yep I released a TAF last night updated to 1609x3, but Nick's been busy. I'll update to 1.6.1.0 tonight but if you don't get a warning dialog on game start saying there is a version mismatch and forcing the game to quit, TAF should be fine. (I added warning dialogs a bit back. ) Yep, those are easy to do 👍 To do this I need a list of the hulls you want changed, and a way to describe these mounts. If you have not yet played with UnityExplorer, that's how to find this out. Launch the game with UnityExplorer installed, go to the constructor and set to that hull. Hit F7. Change from Constructor to DontDestroyOnLoad, open ShipsActive -> your ship -> Container -> Hull -> your hull partname -> go through the hierarchy to find the mounts you care about and see what's unique about them. It's possible that's what the issue was, but I'm doubtful, sorry! That sounds like something a user could do; the code generating the ship always picks a tonnage within the limit as far as I can tell. But it's very possible other changes in the last few updates fixed the issue you're seeing. Can you give me examples of things that don't work the way you expect? Also I will add a feature to TAF that will output, for each hull, all the rules that apply to it. Hopefully that will help? It will output more rules than will actually apply in practice, because often there are multiple rules doing the same thing, for example multiple rules that add a main tower, and only the first rule that succeeds will apply. Later rules may also fail if there is no longer space on the hull to mount what they call for (for example there could be 3 different funnel rules, but the by the third funnel rule, the remaining space has been filled by guns so no funnels can be mounted and the rule does nothing).

I can try to compare the prewarming steps in 1.6.0.7x5 and 1.6.0.9x3 but anything more than a fairly shallow look is not terribly viable time-wise. Here's something you can do to compare: start a save in 1607 and one in 1609 . Convert them to json. Count how many designs there are in the json. What may be the case is that 1608+ is generating more designs during prewarming than it used to. (That's the expensive step.) The pref issue with TAF is that any kind of modding of an Il2Cpp game involves replacing native methods with managed ones, and managed is super slow in comparison. Even if the change is only "set a bool when this method runs", the way method patching works, that means replacing the original method with a new one that sets the bool and then calls the original. And the new one is managed. So you eat the trampoline cost as well as the cost of managed code being way slower.