"Naval Arms Race" mod overhaul. BETA v11.3 - for UAD v1.5.1.5

[Azerostar]

On 6/11/2024 at 2:46 PM, brothermunro said:

I’m not sure when they did but currently the targeting is a lot more sensible, prioritising ships that are close, the AI isn’t as obsessed with sinking a destroyer on the other side of the battlescape anymore 😅

Have a look at v1.5.1.5, the battle AI performances still very bad in my opinion. Yeah the Dev had made some progress, as the AI not only look at DDs as they used to do. However, AI still can't chose right targets, they still prefer to use main guns at light armor targets first while facing player's battleline.

Obviously the Dev didn't built right rules for AI yet, just a clumsy attempt to make up for it.

[Nsalez]

does anyone know why some hulls (the N3s specifically) scale the draught so weird?

the freeboard always stays the same no matter the draught you have, giving it a weirdly tall look.

[NathanKell]

46 minutes ago, Nsalez said:

does anyone know why some hulls (the N3s specifically) scale the draught so weird?

the freeboard always stays the same no matter the draught you have, giving it a weirdly tall look.

Because scaling draught scales the hull section gameobjects but they also have position offsets from the ship object, so they scale around that positional offset (deck height) rather than the waterline.

I assume this is so that generally the deck doesn't move; if it did, all parts would need to be re-placed whenever you changed draught (because they didn't write code to move parts when you change draught).

 

Obvs I fixed both of these things. :]

[o Barão]

On 6/13/2024 at 9:29 AM, NathanKell said:

Sure! These aren't done in code. It's just simple tag-matching against (a) the parts themselves, and (b) the part classes in the randParts (or randPartsRefit) TextAsset.

That part I understand. Is not about that what I am talking about. In the list modifiers, I posted several examples. Those are not about what parts are going to be used in a hull, but are instead how the AI will design the ship.

If you can get the answer for those, it would be amazing.

[NathanKell]

8 hours ago, o Barão said:

That part I understand. Is not about that what I am talking about. In the list modifiers, I posted several examples. Those are not about what parts are going to be used in a hull, but are instead how the AI will design the ship.

If you can get the answer for those, it would be amazing.

That was the second (larger) half of my post, yes. That's exactly what I went into detail on.

 

Starting here: "As to what the autodesigner picks, that's controlled mostly similarly, i.e. by a lot of cross-linked strings. After a couple hours of digging, here's what I see:"

Edited June 15 by NathanKell

[Nsalez]

On 6/14/2024 at 2:04 PM, NathanKell said:

Because scaling draught scales the hull section gameobjects but they also have position offsets from the ship object, so they scale around that positional offset (deck height) rather than the waterline.

I assume this is so that generally the deck doesn't move; if it did, all parts would need to be re-placed whenever you changed draught (because they didn't write code to move parts when you change draught).

 

Obvs I fixed both of these things. :]

ohhh alr

Kinda funny how inconsistent it is from hull to hull.

do you know if it can be changed through UABE?

 

[o Barão]

2 hours ago, NathanKell said:

That was the second (larger) half of my post, yes. That's exactly what I went into detail on.

 

Starting here: "As to what the autodesigner picks, that's controlled mostly similarly, i.e. by a lot of cross-linked strings. After a couple hours of digging, here's what I see:"

Ah, I see!! Sorry If I misunderstood in the beginning. That was very helpful!! Many thanks.

[NathanKell]

20 minutes ago, o Barão said:

Ah, I see!! Sorry If I misunderstood in the beginning. That was very helpful!! Many thanks.

You're very welcome!!

 

I also realized I should probably back up and describe the whole AI ship generation process, which I'll do soon as well. That will give a better global overview. But I can definitely say that these are the main takeaways:

• There are very few hardcoded things. For the part selection, the rules I described are the only hardcoded ones worth mentioning.
• For part selection the only semi-hardcoded thing is the 'condition' column--there there are the limited set of choices, rather than you being able to define actual conditions in text.
• The game has a consistent bug where the "casemate" params often apply to guns < 2in in caliber, rather than actually to casemates. For example gun min length; you'd expect the regular one to be used for normal gun parts and the 'casemates' version to be used for casemates, but in fact the 'casemates' version is used for guns <2in in caliber, and the other is used for all other guns. I have no idea why the devs did this, and I've fixed it whenever I've rewritten code in my mod, but it's worth pointing out.
• While there are very few hardcoded things, a lot of ship design is very random. For example crew quarters, op range, survivability (what the "Bulkheads" slider is referred to as internally), and speed are all essentially random, as is part placement (and part selection!!) within the constraints set out above.
• There's a bunch of bugs I noticed, some of them blurring the line between "bug" and "the easiest way to disable a feature is to make it so buggy it doesn't ever apply".

Certainly there's nothing in there to do more intelligent selection of hulls or parts or shiptypes or whatever, something like "the finances aren't great, so choose a cheaper hull", let alone even just "this hull is newer and has better stats so it should be picked". And in terms of actually setting the ship's stats and parts, it just tries hundreds of times making random choices (within constraints) until it gets a result that meets the shipType's requirements.

[o Barão]

@NathanKell again, thank you. This info opens a new interesting thing to study and experiment and maybe get some improvements in the way how AI design ships.

[NathanKell]

33 minutes ago, o Barão said:

@NathanKell again, thank you. This info opens a new interesting thing to study and experiment and maybe get some improvements in the way how AI design ships.

Yay! Glad to hear it!!

[NathanKell]

13 hours ago, Nsalez said:

ohhh alr

Kinda funny how inconsistent it is from hull to hull.

do you know if it can be changed through UABE?

 

No that won't work. The centers for the various ship sections are above the waterline so you need to dynamically move then as they scale from draught changes. You might be able to do something where you add intermediate game objects between the Sections object and those individual sections but I don't think the code will play nice with that.

[Nsalez]

8 hours ago, NathanKell said:

No that won't work. The centers for the various ship sections are above the waterline so you need to dynamically move then as they scale from draught changes. You might be able to do something where you add intermediate game objects between the Sections object and those individual sections but I don't think the code will play nice with that.

damn alr

I guess its just another weird quirk of the game then. 

 

[NathanKell]

Ok, here's my full writeup on autodesign. I need to do a deeper dive into AddRandomPartsNew (the thing that uses randParts that I discussed above) but I covered the basics already.

 

Terminology: 

• prewarming is the setup phase of the campaign.
• lerp means linearly interpolate (i.e. to lerp between a and b using t, you get a + (b - a) * t). If t is less than 0 or greater than 1 it's clamped.
• inverse lerp means go the other direction (i.e. inverselerp(a, b, val) = (val - a) / (b - a). If val is less than a or greater than b it's clamped.
• Remap a value from1->to1 to from2->to2 means inverse lerp between from1 and to1 and then use that to lerp between from2 and to2. Sometimes this is clamped and sometimes it's not, I'll try to note when it's clamped; usually in the designer it's clamped, but elsewhere in the code it's often not.

A note on armor generation: Ship.GenerateArmor is used by the designer independently, and also as part of Ship.AdjustHullStats (which is called when you change hull, and as part of the autodesign process). It works as follows Remap the design year from 1890->1940 to 1.0->0.85 and then multiply that by a random number between 1 and 1.3. Then multiply that by the shiptype's armor value and by 25.4 (inches to millimeters). Then pass that "armorMaximal" value to Ship.GenerateArmor. That function converts that general value into armor values for each of the armor zones. To help describe this, I'll describe a function which I'll call ConvertYearMultToArmor. It takes a year-based multiplier and generates an armor value. Pick a random number between 0.05 and 1.1 if the shiptype is dd, otheriwse a random number between 0.75 and 1.1. Multiply that by the armorMaximal value that got passed to GenerateArmor and divide that by 11. Finally multiply by the year multiplier that this function gets passed. Now that that function is defined, the actual zones can be covered. The first is the main belt. Here we set a shiptype multiplier: 1.5 for bb, 1.385 for bc, 1.05 for ca, 0.38 for cl, 1.2 for dd, and 1 for everything else. Now the year multiplier becomes a clamped remap current year from 1900->1940 to 12->(14 x shiptype multiplier). (Yes, this means cl armor multipler goes down over time whereas others go up.) That is passed to ConvertYearMultToArmor and the resulting value is set as the main belt armor. The fore/aft belt armor is ConvertYearMultToArmor of a clamped remap of year from 1900->1940 to 3.5->7.5. Main deck is ConvertYearMultToArmor of a clamped remap from 1900->1940 to 1.25->7.5. Fore and Aft decks are the same except changing 1.25 to 1.5 (yes, that means in 1900 fore and aft decks default to thicker than main). ConningTower is the converted remap of 14.0->16.0. Superstructure is the converted remap of 1.0->(random between 0.5 and 1.5). However, if it's an academy mission and its params has 'crutch_ironclad' and the hull's name is 'monitor' or 'virginia' then the remap has 9 added to it (before being passed to Convert). Turret Side is another shiptype dependent one. The shiptype mult here is: 0.065 for bb, 0.08 for bc, 2 for ca, 5 for cl, 40 for dd, and 1 for everything else. That is then multiplied by the year remap of 1900->1940 to armorMaximal->(armorMaximal x 1.7). If it's a mission with 'crutch_ironclad' and the hull name is monitor or virgina, add 13 to this value. Then do the usual convert step. Turret top armor is a traditional convert of the year remap to 3.0->12.0. Barbette type-based, first the converted remap of armorMaximal x 3.75->armorMaximal x 5. Unlike the other ship type specific ones however, the multiplication here happens after conversion. So the conversion result is then multiplied by 0.0135 for bb, 0.04 for bc, 1.8 for ca, 50.0 for cl, 75 for dd, and 1.0 for all other types. Once this is all done, for each armor zone visible in the UI (i.e. all the zones available to the ship), the current value is clamped between the min value allowed (which is just the shiptype's min armor) and the max value allowed (which is based on the gun caliber for turret/barbette armor, and the outer layers for citadel armor). The citadel armor is generated next. For each layer of citadel armor, the usual remap->Convert steps are done. Belt1 uses 3->9, Belt2 uses 2->7, Belt3 and Deck1 use 1.5->5, deck2 uses 1.25->4, and deck3 uses 1.2->3. If the ship already has armor, these values are clamped based on their outer citadel/belt layers, otherwise they are left unclamped and will be clamped later.

 

Next, on to the design process as a whole.

Every turn, there's a 1/3 chance the AI decides to do ship designing (100% chance if prewarming). If there's a ship type with no active design, the AI decides to design something for that. As far as I can tell the following logic seems to be trying to have the AI produce multiple starting designs if prewarming (there's a prewarming and >=5 designs check) but I don't think it's working properly, and I'm not going to investigate too hard. Similarly there's a check for if it's been a random time (3-5 years or so) since a design was designed and if so that becomes eligible for replacement (again, doesn't look like it would work right). Lastly, if there's a shared design that would work here (right type and year and techs), designing is skipped.

With a shiptype selected, the AI selects a hull. This is simply (a) a random hull that the player can build (tech tonnage limit and shipyard tonnage limit and hull unlocked by tech) and (b) hasn't already been used in a design this iteration. Then the game enters the Constructor scene and calls Ship.GenerateRandomShip(). 

This is where things start if it's a mission or the AI is designing a ship based on human request, since the shiptype and hull are already known.

Ship.GenerateRandomShip keeps trying to generate until the number of designing tries allocated is exceeded. When calling the Generate function, it says to use a small number of tries (4) instead of the usual number (20) that you'd get by engaging the dsigner yourself. It allos all adjustments and has no custom overrides.

The generate function does the following steps in a loop (waiting a frame after each one):
1. Setup: It saves the speed if refitting, otherwise it sets a min (well, min starting) speed of whichever is greater, the shiptype's min speed or the hull's speed limiter x 1.02.

2. Part removal: If it's a refit, it sees if any parts are invalid. If so it removes them and sets the refit to not be a simple refit (if it was set to be a simple refit). If it's not a refit, it removes all parts.

3. Beam/Draught: If it's not a simple refit, it sets random beam and draught, with the randomness a kind of pseudo-normal distribution centered on the ship's current beam and draught (which will be 0 at the start). If it is a simple refit, it just sets random beam and draught. This logic seems the opposite of what I would expect, and I wonder if there was a typo here.

4. Tonnage: There are multiple cases. The standard case, the 'random_tonnage' case, and the 'random_tonnage_low' case. The standard case first. Set a tonnage floor by multiplying tonnage_not_maximal_ratio by a random number between 0.01 and 1.5. Use that to lerp between min tonnage and max tonnage (as limited by tech and by shipyard), that's the tonnage floor. If the shiptype's params contains 'random_tonnage' then use a random number between min and max tonnage as the tonnage floor instead. If the shiptype's params contains 'random_tonnage_low', then 80% of the time lerp between min and max tonnage using tonnage_not_maximal_ratio, and then use a random number between that and min tonnage as the tonnage floor. 20% of the time, pick a random number between min tonnage and max tonnage and use that as the tonnage floor. To get the final tonnage, pick a random number between the tonnage floor and the max tonnage.

5. Regardless of if it's a refit, clamp the tonnage to within the tech and shipyard limits. If it's > 1.2x the limit, set tonnage to between 40% and 100% of the limit and set new random beam and draught that are weighted above minimums; if it's only a bit over, just set new random beam and draught and hope it works out. If it's under the limit, just refresh the hull geometry.

6. Set base hull stats. Pick a random level of crew quarters (and, if not campaign, crew training between 17 and 100). Pick a random speed between 0.9 and 1.1x the speedlimiter of the hull and clamp that to the min and max speeds of the shiptype. Set a random operational range. Pick a random bulkhead level. If it's less than high, set it to medium if the ship type is DD or TB, otherwise clamp it back to high. Generate random armor levels for the ship.

7. Adjust Hull Stats: Ship.AdjustHullStats gets called to reduce speed, armor, oprange, and crew quarters in order to make sure enough free tonnage is available. However, this function is bugged in multiple ways. First let's discuss the stop condition for the adjustments. That condition is reached when the ratio of used weight divided by total tonnage is less than a ratio computed by: remap year from 1890->1940 to 0.8->0.6, multiply that by a random number from 0.875 to 1.075, and subtract all that from 1. Finally clamp the result to between 0.25 and 0.55. Once inside AdjustHullStats, if the ship's weight to tonnage ratio already meets the stop condition, nothing happens. If not, we continue. First we establish a min operational range. It's Very Low if the shiptype has no min_range, otherwise it's whatever the min_range is. (This is never used due to a bug, see below.) Next, if the shiptype has armor_min_hint that's used to multiply shiptype's armorMin times 25.4 and fed to GenerateArmor, which is then stored as the min armor. Otherwise if the ship is type dd then a random multiplier from 1 to 1.3 times 25.4 times a remap of year from 1890->1940 to 1->0.85 is passed to GenerateArmor and stored. If it's a different shiptype, no min override is stored. Next the current speed, crew quarters, and armor are stored. The ship's speed is set to the min speed set in step 1. The ship's crew quarters are decued to cramped, and the ship's armor is reduced to the min armor calculated above (or 0, if none was stored above). Now, if the code weren't bugged, it would then go on and start adjusting things around to meet the stop condition, but one of the bugs in this function is that instead of comparing the passed target ratio (which is the same as that used for the stop condition) to weight / tonnage at this point, it compares the passed ratio to weight itself. Since the weight will always be greater than the target ratio (which is in the range 0-1 by definition), the function quits here and it doesn't continue to adjust stats and test against the stop condition. (Another bug with this function is that it thinks shipType's min and max speeds are in m/s like how speed for ships is stored; they're not, which means when speed is clamped, it's clamped wrongly). Anyway the end result of the bug is that most of the time the ship will end this step with no or minimal and armor and cramped crew quarters.

8. Update Hull Stats. This updates all the calculated stats like range multiplier from beam, engine weight from draught, etc. (See stats and statsEffects TextAssets.)

9. Add parts to the ship. See my previous post on how this is done.

10. AdjustHullStats again, this time to increase weight. Here the ship tonnage is passed in as the target ratio, which gets around that bug. Also a function that always returns false is passed in as the stop condition (!). As before min op range and armor min hints are calculated, and existing speed and crew quarters and armor are stored. Then the function tries a maximal approach to using tonnage. It sets crew quarters to spacious, sets armor to the maximum possible for each zone, and sets speed to the following. First remap year from 1890->1940 to 1->1.12, multiply that by the hull's speedLimiter times 0.51444 (i.e. kts to m/s, what speed is stored as on ships) and multiply that by 1.15 if the hull is cl or dd, and 0.9 otherwise. If all that is still less that 99.7% of total tonnage, stop there. Otherwise reset speed, armor, and crew quarters to what they were. Then enter a loop to increase stats bit by bit. Calculate a new speed which is current speed plus speed_step knots more. Clamp that new speed to between the saved min speed in step 1, and speedLimiter times (1.7 if cl or dd, 0.95 otherwise) times the clamped remap of year from 1890->1940 to 1->1.05. Then the next bug in this function occurs, the previously-mentioned one about m/s vs knots. Because this new speed (which is in m/s) is then clamped to between the shiptype's min and max speeds (which are both in knots). That means in effect that the actual (minimum speed for the ship (if applied by this function) will be 1.944 times the shipType's minimum speed. If 1.944x that speed is higher than 0.95 (or 1.7) times the speedLimiter speed, then speed will always be kept at 1.944x shipType's min speed (because the two clamps will fight each other, one bringing the speed down to its max, and the second bringing it up to its min). After setting that potential new speed, next new potential crew quarters are set, as 1 above the current value. The new potential op range is set to one higher than current, and that clamped to between the min op range (or Medium, if none is specified in the shipType). Finally a weighted-random armor zone is selected to increase. (The weighted-random selection works like this: sum up all the weights, select a random number between 0 and the total, and keep going through items adding their weights until you pass that number.) You can see the armor priorities here: https://github.com/NathanKell/UADRealism/blob/010803fbad56381565df9bd9e27160a34a4f3c52/Harmony/Ship.cs#L685-L701 This zone gets its armor increased by armorstep (whatever the armor step is in the UI, fractions of an inch or mm). Once all that is done, a value is selected to increase by weighted-random. The weights are: speed is 350, crew quarters is 150, armor is 850. If any of the values are unchanged (e.g. crew quarters already at maximum), they're not included as options. Once an option is selected, the ship's new weight is tested and if it's greater than 1.2x the ship's tonnage, everything gets reset to the start of the loop (except armor, it's kept increased!) and it adds the next item, if any exist. If weight is less than or equal to 1.2x tonnage, then we stop if this is not a mission, or the ship's owning player isn't the main player of the mission (i.e. the human), or the ship isn't the main ship of the mission, or the cost is less than or equal to the player's cash in the mission. Otherwise the next item gets applied. If there are no items left to apply and none of those conditions are met (i.e. weight is greater than 1.2x tonnage, or it's a mission and the main player and...) then the function stops increasing weight and returns. Otherwise the stop condition is tested. Since the stop condition here always returns false (see above), it never stops, which means the next set of increases are calculated. It's worth noting that (a) op range is never actually increased (the line was probably commented out?), (b) in practice this loop will keep executing until weight is above 1.2x tonnage or cost is above player cash for a main-ship-main-player-mission case.

11. All parts on the ship get updated (their colliders updated, their caliber lengths calculated, etc).

12. Verify guns. If this is not a simple refit, then make sure that parts aren't overlapping and weapons have reasonable firing arcs. Any that fail are removed. Next check that there are at least as many main caliber turrets as the hull requires and as many barrels across those turrets as the hull requires. If not, go back to step 2. If so, or if it's a simple refit, continue.

13. Select Components and reduce weight. It's important to point out that until now, the hull has had the default components for the current tech and the hull / ship type. Obviously that means the weights before will be screwy, which is why adding random parts succeeds so long as weight is less than 1.5x tonnage, and AdjustHullStats goes up to 1.2x tonnage. The component selection logic is simple. For each allowable component type (i.e. available to the ship type and the UI would display the component choice, so no torpedo type components if there are no torpedo parts--this is why component selection occurs after part addition, I assume), find all allowable components for that component type. Then select one via weighted-random (using the weights as defined in the components TextAsset). Once that is done Ship.ReduceWeightByReducingCharacteristics is called. This returns immediately if the ship is type tr. It also returns if weight is not over tonnage, or if the ship is type dd and has no armor set. Then it sets up an armor reduction queue. This is pulled from the ship for bb, bc, ca, cl, and dd. The default order (for everything else) is Fore Belt, Aft Belt, Fore Deck, Conning Tower, Aft Deck, Main Deck, Fore Belt, Belt1, Belt2, Belt3, Deck1, Deck2, Deck3, Turret Side, Turret Top, Barbette, Superstructure. Then it starts a loop which runs while weight is greater than tonnage. Each iteration it goes through the armor reduction queue, reducing armor in that area by armor step times 20 (it looks like the code tried to scale by tonnage but either that was disabled weirdly, or it's yet anothre bug, because it always returns 20 now). This reduced value is then clamped between the min and max armor for the zone, and set to the zone. If weight is now at or under tonnage, the queue traversal stops, otherwise it continues. At the end of this the main loop checks weight vs. tonnage again and continues if necessary. Then it does the whole thing again in reverse if weight is now too low, adding back armor the same way it took it away (note the priority is the same, so it will add back the armor that was the highest priority to remove, not armor in the order of the add priority queue, see below). Next it moves on to speed. If the type is dd, potential new speed is the clamped remap of year from 1890->1940 to hull speedLimiter x 0.7 -> hull speedLimiter x (random number from 0.925 to 1.0). The minSpeed is the speed from step 1 plus speed step. Otherwise, if the hull is generation 1, potential new speed is the clamped remap of year from 1890->1940 to hull speedLimiter x 0.85 -> speedLimiter x (a random number from 0.8 to 0.89). For generation 2, the values are remap to speedLimiter x 0.75 -> speedLimiter x (random between 0.85 and 0.94). For generation 3, the values are remap to speedLimiter x 0.75 -> speedLimiter x (random 0.81 to 0.92). For generation 4, the values are remap to speedLimiter x 0.7 -> speedLimiter x (random 0.8 to 0.92). For anything else, the values are remap to speedLimiter x 0.7 -> speedLimiter x (random 0.89 to 0.92). In all cases the new speed is clamped to between minSpeed and the ship type's maximum speed. Once this is calculted, if weight is greater than tonnage and this new speed is greater than current speed, speed is reduced by speed_step at a time until either it's at the new speed or weight is no longer above tonnage. If weight is still above tonnage, and operational range is greater than Medium, operational range is reduced one step at a time (including down to Very Low--it's weird this can't happen if it already starts below Medium!). Finally reduce Bulkheads to high one step at a time (if they're not already at High) until weight is under tonnage. With all that done, finally any unused barbettes are removed from the ship.

14. Add tonnage usage. This is broadly the reverse of the previous step and is designed to bring the ship up to its tonnage limit. It stops immediately if the ship is type amc. Then it calculates three stop points: weight to stop increasing armor (the full ship tonnage), weight to stop increasing op range (some level below full tonnage), and weight to stop increasing bulkheads (another level below full tonnage). It then creates the armor add priority queues. Specific ones are specified for bb, bc, ca, cl, and dd. The default is turret side, barbette, main belt, main deck, belt fore, deck fore, turret top, belt aft, deck aft, conning tower, belt1, deck1, belt2, deck2, belt3, deck3, superstructure. The logic for armor is the same as reduction: loop until all armor is added or at the weight limit. On each iteration, loop through the queue. Again, the function that returns the multiplier to the amount to change things by is bugged; it's supposed to change based on ship tonnage, but due to checking vs weight rather than weight / tonnage, it always reutrns the small numbers (2 for armor, 1 for everything else). So armor change is always armor step times 2. It then runs a second copy of this whole process if weight is now above tonnage, and reduces armor by a step each in priority order (note, armor add priority not armor reduce priority...) until weight is back at or below tonnage. Next it moves on to speed. If speed is below the shiptype's max speed, it increases speed by speed_step at a time until either the ship is at the shiptype's max speed, or weight is at the ship's tonnage. Then, if step 13 reduced op range, it increases it one step at a time until at the weight limit for op range increases (see start of step 14). Then, if step 13 decreased bulkheads, it increases bulkheads one step at a time until at the weight limit for bulkhead increases (see start of step 14).

15. If weight is less than 99.2% of max, it runs step 14 again.

16. If weight is greater than 100.1% of max, it runs step 13 again.

17. If weight is less than 99.2% of max, it runs step 14 again. Then it checks instability. It calculates stats and gets the stat values for Instability X and Instability Z. If the hull is not b1_maine and the ship is not type tr, it passes if X is 0 and the absolute value of Z is less than or equal to 100. Otherwise it passes if the absolute value of X is greater than or equal to 0 (Z only fails if its absolute value is less than 0, so it always succeeds). Then cost and requirements are checked. If it's a mission and the ship cost is greater than player cash and crew training can't be reduced, it fails. If the ship fails to pass any shiptype requierement, it fails. If any parts report they can't (that is, can no longer be) placed, it fails. Then it checks barbettes and rechecks weight and cost. If weight or cost checks fail, or there is a barbette with no part mounted to it, it fails. If the ship's tonnage is not allowed for the player (due to tech or shipyard), the design fails. If the ship passes all those checks, the design is good and the designer stops. Otherwise it starts again at step 2.

[HE4DEYES]

is this compatible with the latest 1.5.1.6 patch?

[A.R.Euro XVIII]

yes

[DougToss]

On 6/14/2024 at 2:04 PM, NathanKell said:

Because scaling draught scales the hull section gameobjects but they also have position offsets from the ship object, so they scale around that positional offset (deck height) rather than the waterline.

I assume this is so that generally the deck doesn't move; if it did, all parts would need to be re-placed whenever you changed draught (because they didn't write code to move parts when you change draught).

 

Obvs I fixed both of these things. :]

I think it's funny that it also distorts the lifeboats and davits, like a ship with a deeper draught needs deeper lifeboats. 

[NathanKell]

1 hour ago, DougToss said:

I think it's funny that it also distorts the lifeboats and davits, like a ship with a deeper draught needs deeper lifeboats. 

Yep those are just children in the object hierarchy so any beam/draught changes get applied down the chain.

[SpardaSon21]

@NathanKell So, let me get this right.  The designer is literally just throwing shit at the wall to see what sticks?  There's not a single bit of actual intelligent design to it?  And that of course doesn't take into account the bugs in it.  It sounds like its up to modders to make sure everything is tagged properly and you to fix the bugs in the designer code.

How much of this have you submitted to the devs via either bug reports or suggestions?

Edited Wednesday at 12:11 AM by SpardaSon21

[DougToss]

32 minutes ago, SpardaSon21 said:

@NathanKell So, let me get this right.  The designer is literally just throwing shit at the wall to see what sticks?  There's not a single bit of actual intelligent design to it?  And that of course doesn't take into account the bugs in it.  It sounds like its up to modders to make sure everything is tagged properly and you to fix the bugs in the designer code.

How much of this have you submitted to the devs via either bug reports or suggestions?

The text for using shared designs says something about the AI designer repeatedly failing and rerolling, so I suppose something like this could be inferred, but I assumed they were using templates by nation and year like Rule the Waves and then adding variables. That would make ship design dramatically more historically accurate (and similarly tactically and strategically useful). I would not have guessed at the level of randomness. 

 

e: Because of course, ship design wasn't really random, you can see the design logic, and continuity in historical warship designs. Italian cruisers were not a random assortment of guns, superstructure and funnels on a hull, there was a clear design lineage, where arrangements that worked were retained, like the preference for double turrets on treaty cruisers. 

 

ee: Why not build around the core values ships were designed around? A power plant and hull to achieve a target battle speed/crushing range, armament (I grant you, armament was often designed independently and then fitted to ships, so if your nation had 4.7 inch guns, your destroyers and light cruisers had... 4.7 inch guns. Separately are guns designed for specific ships, like the BL 18 inch guns designed for Furious and then reused for monitors), and then protection against that armament at battle ranges (this would change over time obviously, and with deck armour growing important). RTW does that, and it's the simplest way to understand armour, all else being equal, something like, belt thickness equivalent to the calibre of the main armament, or that protects against the same at half of max range? 

Adding everything and then randomly deducting armour seems like it would lead to a lot of glass cannons?

Edited Wednesday at 12:46 AM by DougToss

[SpardaSon21]

22 minutes ago, DougToss said:

Adding everything and then randomly deducting armour seems like it would lead to a lot of glass cannons?

Which is exactly what people tend to see in-game, over-armed glass cannons with cramped crew quarters.  On the one hand I don't mind some randomness in design because nobody wants to see identical or near-identical ships, but the complete lack of any selectiveness frequently leads to designs that match the requirements but are effectively useless in combat.

[XerMGGW-2]

9 hours ago, SpardaSon21 said:

Which is exactly what people tend to see in-game, over-armed glass cannons with cramped crew quarters.  On the one hand I don't mind some randomness in design because nobody wants to see identical or near-identical ships, but the complete lack of any selectiveness frequently leads to designs that match the requirements but are effectively useless in combat.

Don't also forget that the designer tries so hard to have hulls be at their designed top speed, and sometimes even higher than that, which is often not possible to achieve and ends up wasting huge amounts of time for faster hulls scrapping designs over and over, per era.

Edited Wednesday at 10:41 AM by XerMGGW-2

[DougToss]

2 hours ago, XerMGGW-2 said:

Don't also forget that the designer tries so hard to have hulls be at their designed top speed, and sometimes even higher than that, which is often not possible to achieve and ends up wasting huge amounts of time for faster hulls scrapping designs over and over, per era.

In my campaign, Germany just scrapped all of its ships but two while at war! It was 1894, the game had started in 1890, those ships were all perfectly serviceable. Every month the news ticker shows the major powers scrapping essentially their entire navies. 

 

France and Germany, Spain and America, and China and Japan are all at war, and yet all of them insist on taking major warships to the breakers, rather than refits to give them smokeless powder or whatever. It's only been four years, triple expansion engines and slightly better shells are not worth not having any ships at all. 

Edited Wednesday at 12:45 PM by DougToss

[Kraut]

1 hour ago, DougToss said:

In my campaign, Germany just scrapped all of its ships but two while at war! It was 1894, the game had started in 1890, those ships were all perfectly serviceable. Every month the news ticker shows the major powers scrapping essentially their entire navies.....

Its not as bad in my two campaigns (one on the last patch und one now), but i can see the same pattern. after some years, usually around 4-7, ships getting scrapped. 

I mean, on one hand im glad that i dont have to grind thru many clown cars anymore, on the other hand its even easier now, since the computer doesnt even have teh numbers advantage anymore... quiet the opposite in fact.

Thx to even more money then ever recently? I can field now a Navy with over 20 Capital ships kinda right from the Start and increasing onward, while the Computer will barely evar reach 12-15 Caps. Ofc the Computer builds alot of CAs/ CLs, but i find them very useless for a 1910 Start (Ger) since they are much slower as the BCs, so i dont see any point in having those. And since all Nations kinda swimm in money, atleast that shouldnt be the issue to make the computer keep its ships around for longer.

 

Is it just me or has anyone else the feeling, that the Accurracy increased? @o Barão Did you accidentally copy the acrade files in the realistic folder?

But even with a seemingly higher ACC on Big Primary gunz, the acc of secondaries is still so low, that Destroyers reign the Battlefield. Dunno if Torpedoes need a nerf or something, but for quiet a while now ( if not "always has been") its Admiral Destroyers 😛 

On the previous patch i had a battle with around 95% torpedo dmg out of 400k total. Due to mopping up the rest the total % sank at the end of the battle, but Destroyers do the main work for me, especially now with the reduced Acc compared to Vanilla.

Since its my first Post here and i just started a short while ago playing NAR i also want to thank @o Barão and everyone else involved for the great work. I especially like the educational part about the different armour types and chemicals. And the fact, that balacing the ship is no pain anymore, makes designing soooooo much better and finally really enjoyable.

 

Although that friend doesnt like ships at all he made a very accurate comment on my most recent design in my current campaign so id thought i share that with you:

"...: that looks mean
...: like its gonna punch me and totally get away with it"

Thats what he looked at:

 

was really funny for me, how accurate his impression was, given the fact thats probably the first modern BB II laid down and with a speed of 30 knots faster than atleast all of my preceeding BCs.

 

[daniel1212]

can you give me the link to this please i couldnt find it in this forum thanks nvm i found it 

 

 

Edited Wednesday at 11:42 PM by daniel1212

[DougToss]

I think it's just that torpedo accuracy is greater than it ever was. Reading up on capital ship torpedo tubes, people thought they would pose a danger, the British assumed the German High Seas Fleet would rapidly close to 4000m and fire torpedoes, it was part of the reason for the all-big-gun battleship, but it seems like torpedo accuracy was historically just not very good. In the game, even the earliest torpedoes can hit, hit hard, and hit often.