Proof-of-concept rework of the Constructor

[NathanKell]

After playing with NAR for a while, there were a few things that didn't make sense to me. Discussion in that thread led me to looking at how the code actually worked (see this post on how rate of fire is actually calculated), and that led me to using the awesome sledgehammer (scalpel?) that is Harmony to make some changes. Pretty soon things mushroomed. Discussion of where I'm currently at begins here but here's a screenshot to give you an idea:

Source is on GitHub.
Installation:

1. Install the latest NAR
2. Install MelonLoader. I suggest using the 0.6.3 alpha (the x64 Release link of your OS) since 0.6.2 sometimes fails to launch
3. Grab English.lng and replace NAR's.
4. Grab UADRealism.dll and put it in (UAD directory)\Mods

Note this probably won't work outside the constructor yet, but hey, maybe it will!

 

 

 

For now I've just made a couple changes to how guns work, but I'm looking into making some more changes (and would like to hear folks's suggestions/requests as to what changes they'd like to see that require code rather than just data work).

 

I'm currently working on ship design; you can see in the log the output of the detected block coefficient and calculated length along the waterline and beam (and draught, which doesn't need to be calculated, that can use the game's bounding box).

 

So here's the changes I've made so far:

• The influence of caliber change on guns (i.e. 5" to 5.2") is no longer linear. Currently I'm using the 1.5th power. In addition, stock applies a scaling factor of 0.975x to the higher caliber data; due to the nonlinear scaling I added (and because it doesn't make much sense since it's not a scalar to the lerp, it's a scalar to the data...) I've removed it.
• Player-set length changes no longer double-dip. In stock UAD, there's both a change to gun stats from caliber, but also a change based on the player-set length, so taking a 12"/45 and making it a 12"/50 manually will lead to it having different stats than a 12"/50 from a nation whose turrets are already 50-caliber-length guns. With this change, that double-dipping is removed, and you just get the regular scaling based off caliber length.
• Shell velocity no longer influences rate of fire. In stock UAD, rate of fire is scaled between 1x and 0.606x based on the shell's velocity (between 0m/s and 1500m/s). So for a 800m/s velocity, rate of fire is actually 0.7426x what you'd expect from the data.

 

Download: https://drive.google.com/file/d/1SO9cQX1J8MykY1Kg6FwJ0ttHizsfYdD-/view?usp=sharing

Note that you'll need to install MelonLoader first (see install instructions here), then drop the dll from the zip into the Mods folder in your UAD folder. Note that apparently MelonLoader 0.6.2 has a bug where sometimes it pops up with an internal error on load; that's fixed in bleeding-edge and will be fixed in next release, but if you just OK out of the error, wait a sec, and relaunch UAD it should work fine eventually.

 

Changelog:

v0.2.0.0 - Started working on ship design. Updated to 1.5.

v0.1.2.0 - Rewrote (i.e. reimplemented) GunData.GetValue (both versions) to remove the 0.975x factor. It might also be faster than stock, since I'm actually caching some values and avoiding some extra calls.

v0.1.1.0 - Got rid of Shell Velocity's impact on fire rate.

v0.1.0.0 - initial release.

Source on GitHub

Up next I want to tackle refits. I'm quite unsatisfied with the refit system, so here's the changes I'm looking at:

• You can no longer change armor type or thickness in a refit
• You only get the effect of certain techs (i.e. fire control, sonar, ammunition, propellant/explosive choice, etc) by default.
• You can no longer change bulkheads, flooding, double bottom, etc. You can increase torpedo bulkheads however.
• You can opt to do a major refit, which does apply certain other tech effects, and allows replacement of the engine and upgrading of gun marks.
• (Possibly: placing secondary weapons no longer triggers a major refit so long as they are the original type.)

That's obviously a bit more of a project, and will require poking at the UI some to lock away certain changes, but I don't see why it wouldn't be doable.

Edited May 20 by NathanKell

[SpardaSon21]

I'll check this out after the beta goes live, but be sure to make the devs themselves know what you've done, too.

[NathanKell]

3 hours ago, SpardaSon21 said:

I'll check this out after the beta goes live, but be sure to make the devs themselves know what you've done, too.

These aren't bugfixes, they're balance changes; I'm pretty sure that the devs intentionally made these choices in the service of game balance. The caliber length one is kinda weird and could use some reworking, but it's clearly a design choice to penalize the player a bit for altering their gun's caliber length.

[SpardaSon21]

7 hours ago, NathanKell said:

These aren't bugfixes, they're balance changes; I'm pretty sure that the devs intentionally made these choices in the service of game balance. The caliber length one is kinda weird and could use some reworking, but it's clearly a design choice to penalize the player a bit for altering their gun's caliber length.

Yeah, but as you said, it interacts weirdly with existing barrels, and muzzle velocity affecting reload rate seems like an odd choice.

 

EDIT: If possible, I'd rather you look at how pitch and roll are calculated instead of refits.  The game has a very strong bias towards citadel armor and the engines when it comes to things that reduce pitch and roll, so lengthening your citadel and putting a ton of deck armor on your ship reduces pitch and roll, when in reality deck armor was a major cause of instability in designs.  Meanwhile just about everything else increases pitch and roll, including things traditionally used as ballasting such as fuel and torpedo bulges.

Edited March 9 by SpardaSon21

[anonusername]

On 1.5 this seems to cause the game to load infinitely on start.

[NathanKell]

On 3/9/2024 at 9:54 AM, SpardaSon21 said:

Yeah, but as you said, it interacts weirdly with existing barrels, and muzzle velocity affecting reload rate seems like an odd choice.

 

EDIT: If possible, I'd rather you look at how pitch and roll are calculated instead of refits.  The game has a very strong bias towards citadel armor and the engines when it comes to things that reduce pitch and roll, so lengthening your citadel and putting a ton of deck armor on your ship reduces pitch and roll, when in reality deck armor was a major cause of instability in designs.  Meanwhile just about everything else increases pitch and roll, including things traditionally used as ballasting such as fuel and torpedo bulges.

Well, that was a slog but I kinda-mostly know how it works now. So I can start tweaking things. (Although if @Nick Thomadis has a managed dll hanging around, I'd be much obliged. Trying to read vector/floating point disassembly is way more taxing than more regular gameplay code.)

I wouldn't expect ballast per se to make roll better; indeed, while it increases stability by increasing metacentric height, I take roll ingame to mean "how stiff is the roll", and for a stable gun platform you want a slow, easy roll (though that's real bad for flooding, of course).

To properly calculate stiffness in pitch and roll you'd want to take into account a combination of the moments of inertia and the metacentric height. Certainly the game is doing the former; I _believe_ it's trying to do the latter, but it's much harder to tell what's going on, not least because there's an absolute smorgasbord of lerps, lemme tell you--I presume that's all tuning factors to get good gameplay and approximate / "feels right" results.

11 hours ago, anonusername said:

On 1.5 this seems to cause the game to load infinitely on start.

I would expect so. As I mentioned in the OP this is for 1.4.1.1 and I need to update and recompile.

[NathanKell]

Ok I got fully nerdsniped and ended up implementing calculation of block coefficient (which involved detecting actual length along the waterline, LWL, and actual beam at the waterline, via a rendertexture). Probably going to go ahead and work on voxelizing the hull so I can get the real center of buoyancy and calculate that vs an estimated center of mass to get metacentric height and the real stability figures.

 

So, uh, thanks a lot.

I'm including some examples of the rendertexture because I think it's cool. It's simple once you have that, just count the pixels along the top row and divide by total width (512) and multiply by the bounds, and you get beam and LWL.

[PalaiologosTheGreat]

On 3/8/2024 at 5:14 AM, NathanKell said:

You can no longer change armor type or thickness in a refit

Btw, is it possible to make it so you can change the deck but not the belt? Deck armour refits were done historically

[NathanKell]

Yeah so per the NAR thread I took a week's vacation and then got super busy at work. But I did make some progress on this, I've got basic ship coefficients getting calculated, and ships getting scaled to the size they should be for their displacement and block coefficient. And you can control the length/beam ratio, rather than it being set by the tonnage slider (!) as in the vanilla game. Calculating actually-needed horsepower is in progress. Then I can tackle seakeeping and metacentric height / stability calcs.

 

Once I get done with the giant rabbit hole @SpardaSon21 then I'll get back to my original plan re: refits.

Edited April 17 by NathanKell

[SpardaSon21]

21 hours ago, NathanKell said:

Yeah so per the NAR thread I took a week's vacation and then got super busy at work. But I did make some progress on this, I've got basic ship coefficients getting calculated, and ships getting scaled to the size they should be for their displacement and block coefficient. And you can control the length/beam ratio, rather than it being set by the tonnage slider (!) as in the vanilla game. Calculating actually-needed horsepower is in progress. Then I can tackle seakeeping and metacentric height / stability calcs.

 

Once I get done with the giant rabbit hole @SpardaSon21 then I'll get back to my original plan re: refits.

I'll be happy with just the gun and ship balance changes.  Mildly surprised you've needed to put so much work into them, though.  Did the devs really screw things up that badly with them?

[NathanKell]

2 hours ago, SpardaSon21 said:

I'll be happy with just the gun and ship balance changes.  Mildly surprised you've needed to put so much work into them, though.  Did the devs really screw things up that badly with them?

Eh? No, it's more like I said I got nerdsniped into going _very_ hardcore, wherein on game load I render every hull model at every possible midships section count in 3 views so I can compute a bunch of stats about the hulls, then change how hulls get refreshed on change so they now scale properly to their displacements whenever you change the displacement slider. And I'm unsatisfied with SpringSharp's resistance/power approximations (which I was going to go with initially) since we actually _do_ have hull geometry here, so I've been trying to find better ways of estimating resistance. Taylor's method is good (and highly appropriate) but it's designed for use by humans with rulers. Holtrop and Mennen's paper is straightforward to implement but doesn't produce as good results for the kind of vessels we're talking about.

There's definitely some things that have caused me to scratch my head in the game, however, like how foul weather is pretty much a flat penalty to speed rather than being based on seakeeping--destroyers, let alone early TBDs or TBs, should get absolutely pounded in a sea, and at best make a dozen knots or so, while 30kt+ dreadnoughts should laugh off the waves.

[SpardaSon21]

Gotcha, gotcha.  Also, gave this a download and I think you forgot to actually compile into a .dll.  The 2.0 update zip you link to just has a bunch of .cs files in it, and one each of a .csproj and a .sln, but no .dll's.

[NathanKell]

On 4/28/2024 at 5:59 PM, SpardaSon21 said:

Gotcha, gotcha.  Also, gave this a download and I think you forgot to actually compile into a .dll.  The 2.0 update zip you link to just has a bunch of .cs files in it, and one each of a .csproj and a .sln, but no .dll's.

lol whoops. Sorry!

Note I'm still on 1.5.0.5 because that's the dll I've done most of my IDA markup on and I don't want to lose that info, I'll try to update to the latest version soon and recompile. I'll update soon and reupload a proof-of-concept, because...I've been busy and things are finally working, mostly.

 

As you can see I've finally got my hull detection working, and I also hooked things up so ships scale with respect to displacement (no more fixed sizes pre displacement range!) and you can set length/beam and beam/draught ratios (rather than just beam percent and draught percent), and I added a fineness slider. It's basically just a proxy for number of middle sections, because block coefficient (and prismatic coefficient and waterplane area coefficient) are a function of that in the game.

Power requirements use a tweaked version of the Holtrop-Mennen method; ideally I'd use Taylor's data (it's even period-appropriate!) but I don't know of a source of that data in computable form rather than just graphs you have to use a ruler on. I also need to add Savitsky's planing method to account for semi-planing hulls (TBs and DDs)--as you can see, the Fletcher is at 72kSHP rather than 60kSHP. Power also respects IHP->SHP losses from reciprocating engines, with a factor of ~0.8 for compound, 0.88 for VTE, and a max of 0.92 for M-Exp II. There's also an increase in power estimated for early, poorly-shaped hulls (i.e. it's a function of Hull Form value when less than 80).

Rather than trying to do something fancy for propellers, I just assume an open-water efficiency of 0.65, a pitch/diameter ratio of 0.9, and a diameter/sqrt(beam*draught) ratio of 0.29. That's a reasonable approximation and doesn't require any further work.

 

Sadly a bunch of the hulls have quite strange modeling, so Cb and Cp are sometimes a bit wonky, and there's _definitely_ some weirdness where some hulls have beam/draught ratios of nearly 1. For those hulls I had to just fake the draught numbers. Destroyer hulls are also a problem; they need modified block and midships area coefficients to be sane. Lastly, most hulls have lower midships coefficients than they should, so that also needed some massaging. In the end, however, the numbers are fairly reasonable, and that leads to reasonable power requirements (and will lead to reasonable hull weight figures).

 

EDIT: And here's the code and a dll if anyone does want to either try to run it on latest (probably won't load), or wants to recompile locally. Note that the loading scene takes longer now, since I render all the hulls. That data could of course be precomputed and cached to disk for faster loading, but I haven't bothered yet. https://drive.google.com/file/d/1TKBeFDiN3wPcPs6V06gQIliVFACb_A88/view?usp=sharing

Edited May 12 by NathanKell

[HMS Implosive]

Very nicely done!👏

Does the AI ship constructor know how to use your new sliders?

[NathanKell]

On 5/12/2024 at 5:39 AM, HMS Implosive said:

Very nicely done!👏

Does the AI ship constructor know how to use your new sliders?

Thanks!
And, sort of. Making it choose a random fineness is easy enough. The issue is that the random ship creator currently just picks random beam and draught (!) rather than trying to do the smart thing of taking speed and desired stability into account. So now that they have an even stronger influence on required power, that just won't do. Which means I have to try to rewrite chunks of the ship generation code, which is tough because it's just a few giant functions running as coroutines...

[SpardaSon21]

On 5/12/2024 at 3:04 AM, NathanKell said:

*Words*

I barely understood what you said but it sounds like you've completely rewritten a massive chunk of the ship designer.  Which is incredibly impressive, and surprising to see.  Are you a naval designer when you aren't writing code?

[NathanKell]

40 minutes ago, SpardaSon21 said:

I barely understood what you said but it sounds like you've completely rewritten a massive chunk of the ship designer.  Which is incredibly impressive, and surprising to see.  Are you a naval designer when you aren't writing code?

Thank you  
Nope, I'm not. I'm a game developer. But I more or less taught myself rocket science to write the realism mods for Kerbal Space Program (so there's precedent ) , and I did a fair amount of research on resistance-estimating methods used in preliminary ship design so I could figure out what to implement. I've also designed my fair share of ships in SpringSharp, so I was at least a little bit familiar before starting (though SpringSharp has a much simpler model of resistance).

And yes, I've rewritten some of the constructor; by the standards of "no one's done it yet" I guess it is massive--and I'm certainly changing a bunch of behavior. But by the standards of, say, RP-1, where we completely replaced multiple subsystems and more or less wrote a whole new game layer, it's not that much. The annoying thing here is that the code uses IL2CPP so I have to try to wrap my head around x86 decompile rather than nice managed C# decompile, and that also makes it somewhat harder to mod. Like, right now I'm trying to figure out why hooking Ship.AdjustHullStats is crashing rather than just throwing a managed-code exception. I only expect to have to fight full crashes in my day job!  So the fact it's in IL2CPP has probably made things about 10x as slow for me as I'd be if I could trivially read the decompile in ILSpy.

[Astor]

I knew it that your name sounded familiar

Love your KSP mods!

Also very impressive work done with the designer.

Edited May 14 by Astor

[SpardaSon21]

On 5/13/2024 at 9:27 PM, NathanKell said:

Thank you  
Nope, I'm not. I'm a game developer. But I more or less taught myself rocket science to write the realism mods for Kerbal Space Program (so there's precedent ) , and I did a fair amount of research on resistance-estimating methods used in preliminary ship design so I could figure out what to implement. I've also designed my fair share of ships in SpringSharp, so I was at least a little bit familiar before starting (though SpringSharp has a much simpler model of resistance).

And yes, I've rewritten some of the constructor; by the standards of "no one's done it yet" I guess it is massive--and I'm certainly changing a bunch of behavior. But by the standards of, say, RP-1, where we completely replaced multiple subsystems and more or less wrote a whole new game layer, it's not that much. The annoying thing here is that the code uses IL2CPP so I have to try to wrap my head around x86 decompile rather than nice managed C# decompile, and that also makes it somewhat harder to mod. Like, right now I'm trying to figure out why hooking Ship.AdjustHullStats is crashing rather than just throwing a managed-code exception. I only expect to have to fight full crashes in my day job!  So the fact it's in IL2CPP has probably made things about 10x as slow for me as I'd be if I could trivially read the decompile in ILSpy.

Ah, gotcha.  Well, if you've worked on KSP mods that certainly explains why you're so dogged and determined here.  Don't forget to look at the weight calcs on parts, too.  From my best guess parts are coded via Boolean to have either an increasing or a decreasing effect on pitch and roll, calculated based on their relative weight percentages, but with no regard for actual weight placement.  So a ship that has 6" of uniform armor across citadel, bow, and stern will have pitch and roll increase as you shorten the citadel down, but as you increase the citadel the pitch and roll will decrease, even if you move the ship's main guns towards the extreme ends of the ship to do so.

Edited May 16 by SpardaSon21

[NathanKell]

3 hours ago, SpardaSon21 said:

Ah, gotcha.  Well, if you've worked on KSP mods that certainly explains why you're so dogged and determined here.  Don't forget to look at the weight calcs on parts, too.  From my best guess parts are coded via Boolean to have either an increasing or a decreasing effect on pitch and roll, calculated based on their relative weight percentages, but with no regard for actual weight placement.  So a ship that has 6" of uniform armor across citadel, bow, and stern will have pitch and roll increase as you shorten the citadel down, but as you increase the citadel the pitch and roll will decrease, even if you move the ship's main guns towards the extreme ends of the ship to do so.

I'm just a sucker for anything I can throw a spreadsheet at, especially if legos are involved, so UAD hits the spot.

 

And it's been a couple months since I read through CalculateInstability() but I don't believe that's how it works. A lot of the problem comes from treating the entire mass of hull + engine + armor + fuel as a point mass because it's just tracked as part of hull mass since the hull is only 1 part. And that mass is applied at the origin, which happens to be at the waterline. But no, parts are generally treated (broadly) correctly; their weight offsets and moments of inertia are calculated up as you'd expect. The distribution of armor is a unitless factor though, and not the one I would expect when it comes to pitch and roll stability (though what I would expect for weight offset). It's the way citadel length and armor offset is handled unitlessly that's the problem here that you're describing.

[TK3600]

On 3/8/2024 at 5:14 AM, NathanKell said:

 

So here's the changes I've made so far:

 

• The influence of caliber change on guns (i.e. 5" to 5.2") is no longer linear. Currently I'm using the 1.5th power. In addition, stock applies a scaling factor of 0.975x to the higher caliber data; due to the nonlinear scaling I added (and because it doesn't make much sense since it's not a scalar to the lerp, it's a scalar to the data...) I've removed it.
• Player-set length changes no longer double-dip. In stock UAD, there's both a change to gun stats from caliber, but also a change based on the player-set length, so taking a 12"/45 and making it a 12"/50 manually will lead to it having different stats than a 12"/50 from a nation whose turrets are already 50-caliber-length guns. With this change, that double-dipping is removed, and you just get the regular scaling based off caliber length.
• Shell velocity no longer influences rate of fire. In stock UAD, rate of fire is scaled between 1x and 0.606x based on the shell's velocity (between 0m/s and 1500m/s). So for a 800m/s velocity, rate of fire is actually 0.7426x what you'd expect from the data.

 

This section right here. What we need is not barrel erosion. We just need to fix this bug.

@Nick Thomadis

Is the bug still present in current build?

[NathanKell]

1 hour ago, TK3600 said:

This section right here. What we need is not barrel erosion. We just need to fix this bug.

@Nick Thomadis

Is the bug still present in current build?

That reminds me, back in march I PM'd Nick about a bug in CalculateInstability, never heard back. It probably partly explains why it behaves oddly.

 

When calculating armor fore/aft offset for xx stability, the following code is used (as far as I can tell):

armorOffsetFactorXX = Mathf.Clamp(
    (armor_deckBow + armor_beltBow - armor_beltStern - (armor_deckStern * 2.0))
    * 4.0 / ship_hullWeight * Mathf.Pow((hull_length - citadel_length) / hull_length, 5.5),
    -1.0,
    1.0);

 

Note that though the stern deck armor value is doubled (like usual), the bow deck armor value is not, even though it is for zz stability (and is in the other places I've seen this kind of formula). So my hunch is this is just a typo.

[TK3600]

24 minutes ago, NathanKell said:

That reminds me, back in march I PM'd Nick about a bug in CalculateInstability, never heard back. It probably partly explains why it behaves oddly.

 

When calculating armor fore/aft offset for xx stability, the following code is used (as far as I can tell):

armorOffsetFactorXX = Mathf.Clamp(
    (armor_deckBow + armor_beltBow - armor_beltStern - (armor_deckStern * 2.0))
    * 4.0 / ship_hullWeight * Mathf.Pow((hull_length - citadel_length) / hull_length, 5.5),
    -1.0,
    1.0);

 

Note that though the stern deck armor value is doubled (like usual), the bow deck armor value is not, even though it is for zz stability (and is in the other places I've seen this kind of formula). So my hunch is this is just a typo.

Where did you find these values? Which file so I can take a look?

[TK3600]

Another question, what did you set for turret armor weight values?

I noticed my turret roof is often more heavy than main deck armor, despite same thickness. This is obviously not right. Main deck is obviously much bigger area than turret top area. Ex: Chinese BC2 using 13.8in guns.

Another issue is casemate guns being much heavier in gameplay despite 0.7 weight multiplier.

[NathanKell]

41 minutes ago, TK3600 said:

Where did you find these values? Which file so I can take a look?

GameAssembly.dll, in Ship.CalcInstability().

3 minutes ago, TK3600 said:

Another question, what did you set for turret armor weight values?

I noticed my turret roof is often more heavy than main deck armor, despite same thickness. This is obviously not right. Main deck is obviously much bigger area than turret top area. Ex: Chinese BC2 using 13.8in guns.

Another issue is casemate guns being much heavier in gameplay despite 0.7 weight multiplier.

I haven't set anything for any of that. This thread is about rewriting the game's code, not changing data values / params. It's of course possible the issue you're describing is a code bug, but I don't recall seeing that in the function that calculates mats for turrets. In fact IIRC I reimplemented that as an exercise, though it's commented out.