amram
New Member
Posts: 8
|
Post by amram on Jun 7, 2019 2:09:24 GMT -6
I've known for a little while now that there is some strange behaviour with machinery at higher speeds, the ones I knew off off hand were 53,900tons @ 34kts, and 21,900tons @ 35kts. I got curious about what other weirdness there is in the curves, so I found the relevant memory addresses, wrote a script to record them, and scrolled through the tonnages in the designer, imported the results into excel, charted, posted to imgur, and now here: Turns out ideal tonnages for super low weight, low cost machinery are 6900t@38kts, 10900t @37kts, 17900 @36kts, 21900t @35kts, and 53900t @34kts Those were all version 1.03, 1900 start, turn one. |
|
|
|
Post by garrisonchisholm on Jun 7, 2019 5:12:34 GMT -6
Huh. & I would never have found this in any testing I did because I seldom even build 32 knot ships at any stage, and certainly not in 1900.
Well, welcome to the forums! An auspicious first post!
|
|
|
|
Post by dorn on Jun 7, 2019 5:34:56 GMT -6
It seems that illegal speed/displacement is just one knot higher and at last allow increse of speed to max. there is wrong HP requirement. May be limit should be 1 knot lower as there is curve going bad.
|
|
|
|
Post by christian on Jun 7, 2019 6:20:47 GMT -6
i believe this has already been posted but it seems it was not noticed
although yeah the best way is to just cheeze the weight system to have super fast super cruisers
|
|
amram
New Member
Posts: 8
|
Post by amram on Jun 7, 2019 14:22:38 GMT -6
Huh. & I would never have found this in any testing I did because I seldom even build 32 knot ships at any stage, and certainly not in 1900. Well, welcome to the forums! An auspicious first post! if you want the excel sheet with all the data collected, or even the script I collected the data with, I can send that, just let me know where. It seems that illegal speed/displacement is just one knot higher and at last allow increse of speed to max. there is wrong HP requirement. May be limit should be 1 knot lower as there is curve going bad. everything seems to work just fine(other than some odd wobbles in the curves at various points) until the last 900 tons before illegal, then they just crash in hp needs. Rather than change the limit speed. if the solution isn't a fix to the math behind the curves, then I'd bandaid it with a changing the illegal tonnage limit to be 1000 tons lower and calling it illegal, to the last tonnage before they rapidly decline. Its a reliable thing, every one of them made it to the last full thousand before faceplanting.
if it turns out that the only reason they get declared illegal is that they go negative, ....one could always help it along intentionally inverting the values at 6100t @38kts, to make it illegal, so 6000 is the last valid tonnage, just apply it over the 900 tons of the crashing slope. Ditto for 10kt@37, 17kt@36, 21kt@35, and 53kt@34
|
|
|
|
Post by entropyavatar on Jun 7, 2019 14:30:39 GMT -6
everything seems to work just fine(other than some odd wobbles in the curves at various points) until the last 900 tons before illegal, then they just crash in hp needs. Rather than change the limit speed. if the solution isn't a fix to the math behind the curves, then I'd bandaid it with a changing the illegal tonnage limit to be 1000 tons lower and calling it illegal, to the last tonnage before they rapidly decline. Its a reliable thing, every one of them made it to the last full thousand before faceplanting. I wonder if the system calculates every 1000 tons and linearly interpolates in between. So it determines that say 10,000 tons is valid but 11,000 isn't (so sets to zero), then just draws a line from 10,000 to 10,900. |
|
|
|
Post by garrisonchisholm on Jun 7, 2019 14:55:06 GMT -6
Huh. & I would never have found this in any testing I did because I seldom even build 32 knot ships at any stage, and certainly not in 1900. Well, welcome to the forums! An auspicious first post! if you want the excel sheet with all the data collected, or even the script I collected the data with, I can send that, just let me know where. It seems that illegal speed/displacement is just one knot higher and at last allow increse of speed to max. there is wrong HP requirement. May be limit should be 1 knot lower as there is curve going bad. everything seems to work just fine(other than some odd wobbles in the curves at various points) until the last 900 tons before illegal, then they just crash in hp needs. Rather than change the limit speed. if the solution isn't a fix to the math behind the curves, then I'd bandaid it with a changing the illegal tonnage limit to be 1000 tons lower and calling it illegal, to the last tonnage before they rapidly decline. Its a reliable thing, every one of them made it to the last full thousand before faceplanting.
if it turns out that the only reason they get declared illegal is that they go negative, ....one could always help it along intentionally inverting the values at 6100t @38kts, to make it illegal, so 6000 is the last valid tonnage, just apply it over the 900 tons of the crashing slope. Ditto for 10kt@37, 17kt@36, 21kt@35, and 53kt@34
(Just so you can see this) |
|
amram
New Member
Posts: 8
|
Post by amram on Jun 7, 2019 15:15:38 GMT -6
everything seems to work just fine(other than some odd wobbles in the curves at various points) until the last 900 tons before illegal, then they just crash in hp needs. Rather than change the limit speed. if the solution isn't a fix to the math behind the curves, then I'd bandaid it with a changing the illegal tonnage limit to be 1000 tons lower and calling it illegal, to the last tonnage before they rapidly decline. Its a reliable thing, every one of them made it to the last full thousand before faceplanting. I wonder if the system calculates every 1000 tons and linearly interpolates in between. So it determines that say 10,000 tons is valid but 11,000 isn't (so sets to zero), then just draws a line from 10,000 to 10,900. plausible - all the curves generally have 1000t of consistent-ish rate of change. There is definitely another factor involved though, either manual massaging by the devs, or its not just the interpolation at work, see here: imgur.com/a/PNXez5mthats the rate of change for the 37kn and 38kn curves, from 200t through 11,000t, arbitrarily set the lower chart limit at -1000 as otherwise it would need -14k to show their rate of decline at the end. Still, there are some big aberrations at 4400t and 38kts where it declines by 173 rather than the 1452 increase(each) of the last couple hundred tons, and 4100-5200 and 5400-5500 are both 3000hp decreases. All the curves show this same trend of odd dips, and they share common points for when too. For 33kts, from 4000t to 5000t, the rates of change are: 1361, 1362, 1362, 433, 1347, 1346, -602, 1316, -694, 1286 |
|
|
|
Post by williammiller on Jun 7, 2019 16:52:55 GMT -6
if you want the excel sheet with all the data collected, or even the script I collected the data with, I can send that, just let me know where. everything seems to work just fine(other than some odd wobbles in the curves at various points) until the last 900 tons before illegal, then they just crash in hp needs. Rather than change the limit speed. if the solution isn't a fix to the math behind the curves, then I'd bandaid it with a changing the illegal tonnage limit to be 1000 tons lower and calling it illegal, to the last tonnage before they rapidly decline. Its a reliable thing, every one of them made it to the last full thousand before faceplanting.
if it turns out that the only reason they get declared illegal is that they go negative, ....one could always help it along intentionally inverting the values at 6100t @38kts, to make it illegal, so 6000 is the last valid tonnage, just apply it over the 900 tons of the crashing slope. Ditto for 10kt@37, 17kt@36, 21kt@35, and 53kt@34
(Just so you can see this) Noted...will point Fredrik onto this for a look-see. Note that in simulating something as complex as all of this you are likely going to have a few out-of-scope points in the data, which sometimes requires a bit of manual correction to limit those points. |
|
amram
New Member
Posts: 8
|
Post by amram on Jun 7, 2019 17:31:22 GMT -6
Noted...will point Fredrik onto this for a look-see. Note that in simulating something as complex as all of this you are likely going to have a few out-of-scope points in the data, which sometimes requires a bit of manual correction to limit those points. no worries, I've done some sim programming myself, there's always edge cases, so don't take any of it as a complaint, just some observations, lol. |
|
|
|
Post by srndacful on Jun 7, 2019 23:57:44 GMT -6
TBQH, I've seriously wondered, ever since RtW1 launched, why Fredrik didn't simply use the good ol' "weight + hydrodynamic resistance of water at given speed = horsepower needed" formula.
It's relatively easy to set up (hell, I coded it on my 386 back in high school) and gives a lot more smoother curve for lot less fuss. Sure, it might give some odd results sometimes - but nothing as bad as this.
Also, it gives me an excuse to propose an introduction of configurable length-to-beam ratio (and it's associated bonuses and maluses) into RtW2, giving the player the option of choosing between higher speed - or higher accuracy (just as a random example).
|
|
|
|
Post by namuras on Jun 8, 2019 3:37:36 GMT -6
TBQH, I've seriously wondered, ever since RtW1 launched, why Fredrik didn't simply use the good ol' "weight + hydrodynamic resistance of water at given speed = horsepower needed" formula. It's relatively easy to set up (hell, I coded it on my 386 back in high school) and gives a lot more smoother curve for lot less fuss. Sure, it might give some odd results sometimes - but nothing as bad as this. Also, it gives me an excuse to propose an introduction of configurable length-to-beam ratio (and it's associated bonuses and maluses) into RtW2, giving the player the option of choosing between higher speed - or higher accuracy (just as a random example). Wider ships usually turn better...
But adding width to accuracy calculations goes a bit far. Even if it is grounded in reality, but imho that goes a bit to far. One might introduce a "seakeeping" factor maybe. Owning to good construction practices that might make ships take less of an accuracy hit in heavy weather due to shipping less water.
|
|
|
|
Post by srndacful on Jun 8, 2019 4:26:27 GMT -6
TBQH, I've seriously wondered, ever since RtW1 launched, why Fredrik didn't simply use the good ol' "weight + hydrodynamic resistance of water at given speed = horsepower needed" formula. It's relatively easy to set up (hell, I coded it on my 386 back in high school) and gives a lot more smoother curve for lot less fuss. Sure, it might give some odd results sometimes - but nothing as bad as this. Also, it gives me an excuse to propose an introduction of configurable length-to-beam ratio (and it's associated bonuses and maluses) into RtW2, giving the player the option of choosing between higher speed - or higher accuracy (just as a random example). Wider ships usually turn better...
But adding width to accuracy calculations goes a bit far. Even if it is grounded in reality, but imho that goes a bit to far. One might introduce a "seakeeping" factor maybe. Owning to good construction practices that might make ships take less of an accuracy hit in heavy weather due to shipping less water.
I'm gonna run the risk of being a nitpicker, here, and say that it's usually the shorter ships that turn better ...  OTOH, yes - a 'seakeeping factor' is exactly what I meant when I said 'random example' - there are tons of bonuses and maluses to be applied here. Wider ships being a more stable gun platform, for example, could get a accuracy bonus - or narrower ships an accuracy malus - or both. Carriers might get a 'chances of aircraft successfully landing' bonus/malus instead of (or even in addition to) the accuracy one, etc ... All my 0.02$, of course. |
|
|
|
Post by namuras on Jun 8, 2019 4:37:11 GMT -6
Wider ships usually turn better...
But adding width to accuracy calculations goes a bit far. Even if it is grounded in reality, but imho that goes a bit to far. One might introduce a "seakeeping" factor maybe. Owning to good construction practices that might make ships take less of an accuracy hit in heavy weather due to shipping less water.
I'm gonna run the risk of being a nitpicker, here, and say that it's usually the shorter ships that turn better ... OTOH, yes - a 'seakeeping factor' is exactly what I meant when I said 'random example' - there are tons of bonuses and maluses to be applied here. Wider ships being a more stable gun platform, for example, could get a accuracy bonus - or narrower ships an accuracy malus - or both. Carriers might get a 'chances of aircraft successfully landing' bonus/malus instead of (or even in addition to) the accuracy one, etc ... All my 0.02$, of course. To be even more nitpickier: it's comes down to length : beam ratio... And on how many propellers, rudders, how they are arranged, etc... Edit: Yamato's (244m pp x 38,7m) 680m vs Iowa's (262m pp x 33m) 800m as an example. |
|
|
|
Post by umbaretz on Jun 8, 2019 15:44:31 GMT -6
And if we go into that hole further, we'll be choosing hull forms and therefore available turret considerations (so 4x2x15" Hood would be viable, and 2x4x15" would not, since the turrets would be too wide to fit (and many other factors). Also one of the reasons why quaruples weren't such a thing historically.
|
|
_(edited)_Screenshot_(739).png?width=180&height=180&fit=bounds)
