[2.0.23] Platform tiles can be built underneath thrusters if sufficiently far

[IsaacOscar]

Bassically, you can place a platform tile below a thruster if it is at least 93 tiles below the top of the thruster:

Screenshot 2024-12-07 161030.png (800.31 KiB) Viewed 907 times

As you can see in the above image, the red area prohibiting platform tiles from being placed under the thruster is only 88 tiles high.

This means you can make a platform with lots of thrusters, but small width, and thus get a much faster ship than would otherwise be possible (see 122717)

[eugenekay]

The Thrusters' hitbox cannot be Infinitely long, since it is always possible to build the Factory (and Platform) to be a bit bigger.... The size of the hitbox corresponds well to the "exhaust cloud" graphics, so I think it looks / works good.

Yes, it is possible to build a "long ship" with multiple banks of thrusters overlapping. Yes, this makes a very fast ship (this example manages 500km/s through the Inner solar system, if Ammo production can keep up).

No, you don't have to build your ship like this if you don't want to. No, Factorio is not "realistic".

Outside of Factorio, the "engines forward" design tradeoff can make more sense for some designs which have a high Mass-Fraction, such as sublight travel between solar systems. The ISV Venture Star uses a Tensile structure with the engines at the Forward end of the ship, separating it from the Payload (to lessen the effects of Radiation, without heavy Shielding), giving a lighter structure (Wires are lighter than Beams, think about large Suspension Bridges on Earth), and it looks cool. The Cosine thrust losses at 89° are only about 1.7%; the structural weight savings (and corresponding lessening of overall Fuel requirements) can more than make up for this.

Screenshot 2024-12-07 124149.png (3.01 MiB) Viewed 850 times

Screenshot 2024-12-07 123935.png (51.1 KiB) Viewed 850 times

[IsaacOscar]

The Thrusters' hitbox cannot be Infinitely long, since it is always possible to build the Factory (and Platform) to be a bit bigger....

Well, there's already a 200 tile limit for how far above the platform hub you can build (due to a cheese where someone used platform tiles as shields against asterooids). So having an overal height limit doesn't seem too bad.

The size of the hitbox corresponds well to the "exhaust cloud" graphics, so I think it looks / works good.

Hmm, the gap looks unecessarily longer than the animation.
Also the animation goes out to the sides as well.

Yes, it is possible to build a "long ship" with multiple banks of thrusters overlapping. Yes, this makes a very fast ship (this example manages 500km/s through the Inner solar system, if Ammo production can keep up).
No, you don't have to build your ship like this if you don't want to. No, Factorio is not "realistic".

Well using a circuit network contraption I came up with, a 100ton ship with two engines stacked on top of eachother
took 50 seconds to travel from nauvis to vulcanus, with a maximum speed of 320 km/s, and average of 298 km/s
Whereas the following 66tone ship:

Screenshot 2024-12-08 125642.png (633.16 KiB) Viewed 786 times

Took 67 seconds, with a maximum speed of 238 km/s, and average of 224 km/s. (So about 25% slower)

So I do consider this bug to be an "exploit" and not just allowing for strange looking platforms.

I'd expect the speed difference to be even bigger if you stack more engines vertically vs. horizontally.

[eugenekay]

As linked in the previous report (#122717), the formula space_platform_acceleration_expression is well-published:

Code: Select all

space_platform_acceleration_expression = "(thrust / (1 + weight / 10000000) - ((1500 * speed * speed + 1500 * abs(speed)) * (width * 0.5) + 10000) * sign(speed) )  / weight / 60",

Or, refactoring the mathematics a little bit for readability:

_________________________Thrust_________________________
( 1 + Weight / 10M ) - ( 1500(Speed² + Speed) * Width/2 + 10K )

Then, divide again by Weight*60 to find the Acceleration. I am ignoring the Absolute Value and Sign functions; those seem to handle cases where the ship is traveling "backwards" due to insufficient Thrust.

While I am sure that Wube gave much careful consideration and balance testing to the Constants, they are indeed not based in "Earth Physics". It is a Game, not a Space Simulator. The only "exploit" I see here is that yes, the Scaling (0.5) and Balance ( + 10000 )factors for "width" result in a larger Dividing effect upon the Thrust, than the "1+Weight/10M" adds, for ships smaller than 10 Million Tons. My Borg Cube (512 x 512) weighs in at 52 607 Tons, but it already has issues with insufficient Asteroid collection to sustain itself. Being able to double/triple/quadruple the "Thrust" value (as in my Arrow-ship) permits you to, well, increase the amount of Thrust that is being Divided. The increases in Weight*60 (as the bottom-most Divisor) have a much lesser effect, but I have not done the math / testing for the effect with more banks of thrusters..... I prefer not to use Infinity Pipes/Chests for synthetic testing in-game. The in-game "realistic approach" feels more Fun.

I'm not sure if it is possible to modify these Constants in a mod? The most Realistic change would be to eliminate the usage of Width entirely here; its implicit purpose is to provide "Friction", which.... makes about as much sense as the density of Asteroids measured in Meters; or the paltry "15 000 km" between Planets that needs to be increased to the scale of Hundreds of Million Kilometers. The "drag" factors would presumably need to be eliminated entirely, giving no upper Speed Limit - very useful for crossing the chasms of real space.

[IsaacOscar]

While I am sure that Wube gave much careful consideration and balance testing to the Constants, they are indeed not based in "Earth Physics". It is a Game, not a Space Simulator.

At no point do I care about realism here, I just want the game to be fun, look cool, and be understandable. (And factorio absolutely does an excellent job of the first two points!). It's the last part that I'm mainly concerned with here as you can see from my other bug post, the fact that 'width' even has an effect on platform speed is completely hidden from the player, but using another hidden mechanic (the fact that the thruster 'hitbox' is only 83 tiles high) you can bypass this. Also, I'd argue it's less fun to have to build ships in this weird format to maximise speed, personally I would just have speed be limited by the weight alone and not allow anything below thrusters. Then you have to make ships with thrusters at the bottom, but are free to work out how to optimise the weight.

I prefer not to use Infinity Pipes/Chests for synthetic testing in-game. The in-game "realistic approach" feels more Fun.

Sorry, I was just being lazy. But yes, a real ship would need to be wider to support asteroid defense and produce fuel. But once you've got your minimum width, you can just copy and paste it vertically (as in your arrow ship) to arbitrarily increase your speed and not have to further suffer the width penalty.

I'm not sure if it is possible to modify these Constants in a mod? The most Realistic change would be to eliminate the usage of Width entirely here; its implicit purpose is to provide "Friction", which.... makes about as much sense as the density of Asteroids measured in Meters; or the paltry "15 000 km" between Planets that needs to be increased to the scale of Hundreds of Million Kilometers. The "drag" factors would presumably need to be eliminated entirely, giving no upper Speed Limit - very useful for crossing the chasms of real space.

It is, see https://mods.factorio.com/mod/Rocs-Impr ... tform-Drag, as for the 83 tile limit, that can easilly be changed by modifying https://github.com/wube/factorio-data/b ... s.lua#L799

[IsaacOscar]

So I fiddled around with the bottom of the red 'hitbox' (which defaults to 90.3), and I got strange results:

1. Setting it to infinity causes my mod to fail to load (telling me the value can't be finite)
2. Setting it to roughly 10^306 or larger causes factorio to crash on startup (telling me an "unexpected error has occurred").
3. Setting it to roughly 10^10 or larger causes the red 'hitbox' to totally disappear (so you can build anything right below the thruster)
4. Setting it to roughly 6×10^6 (i.e. 6 million) or larger makes it behave like the default 90.3
5. Setting it to a number of at most 5×10^6 (i.e. 5 million) however seems to work without problem

For reference, the default width and height limit of a factorio map (including planets and platforms) is 2 million, so 5 million is more than enough.

I'm wondering if I should make a seperate bug report for the above weird behaviour (in particular, point #2).

[eugenekay]

Signed 64-bit Integers max out around 2^63 =~ 9.22 x 10^18. I would not expect values larger than this to reasonably work in the Factorio engine, for any Numeric value.

The Vertical limit for Platforms is around 1000200 tiles, which would be a reasonable value to "Fix" this.

But I don't think it's a Bug, just a Design Decision. And I like Arrow ships. They're a fun expression of the "tile space" problem that Platforms bring.

[IsaacOscar]

Ok so my little mod that change the limit to 5 million, causes factorio to hang when destroying thrusters, or putting one in your cursor.
So I guess there is a reason Wube gave it a relatively low limit.

[Rseding91]

As far as I know it is intended that you can not build tiles or anything behind engines. But as you’ve found setting the exclusion range to a huge value has massive performance issues and no other solution has been found so far.

[spacedog]

A simple solution would be to have a hard cap on the number of engines that can be placed anywhere in the surface, based on platform width (i.e. dividing the platform width by 4). At that point, the impracticality of defending such a long ship will make the problem mostly self-correcting.

Otherwise, I'd definitely vote to leave it alone if the fix would cause performance issues for the 99% of people not doing this, because the thrust calculation already has severe diminishing returns in place based on the platform width. Adding a second set of thrusters behind the first set doesn't double ship speed -- it takes 3 extra sets of thrusters (like the image above) to double your speed. And then you have to ensure your front weapons can keep up with the speed.

Plus once you get up over 500 km/s, the majority of the transport speed bottleneck starts to come from waiting for cargo pods to come and go. A little extra speed just doesn't have a huge impact on throughput, since the distance between planets is so small. It's fun to play with this, but it's not (IMO) the best platform design.

[GTG3000]

As far as I know it is intended that you can not build tiles or anything behind engines. But as you’ve found setting the exclusion range to a huge value has massive performance issues and no other solution has been found so far.

Couldn't you just keep a map of {x: y} data to say "at this X coordinate, you can't build anything below Y value because that's where the engine ends" ? It's a pretty considerable addition to the build code, but space platforms are already pretty special I think.

[edit]
At the second thought, I see the issue with this approach - it only covers cases *after* the thruster was placed. Deconstructing all in a line would require an additional script to run down the chunks and check everything. Hm.

[braxbro]

As far as I know it is intended that you can not build tiles or anything behind engines. But as you’ve found setting the exclusion range to a huge value has massive performance issues and no other solution has been found so far.

Couldn't you just keep a map of {x: y} data to say "at this X coordinate, you can't build anything below Y value because that's where the engine ends" ? It's a pretty considerable addition to the build code, but space platforms are already pretty special I think.

[edit]
At the second thought, I see the issue with this approach - it only covers cases *after* the thruster was placed. Deconstructing all in a line would require an additional script to run down the chunks and check everything. Hm.

Easy solution to that; keep a map of x:y for the current bottommost y-value, and a map of x:y for the y-value limit for that column. Then, when a thruster is being placed:

• Check if the new y-value limit is more restrictive than the bottommost y-value in the column. If it is, deny placement. Otherwise, do normal placement checks for the thruster.
• Then, update the y-value limit and bottommost y-values to account for the placed thruster.

Of course, I don't think hardcoding such a change would be positive for the game overall, considering that it'd be effectively enforcing the developers design principles on the entire modding scene. The current solution may be open to minor exploits, but I don't see a huge issue with it especially with how it is only relevant once you start scaling stupidly large in space (which is already afaik discouraged by finite resources being available per platform, regardless of width?)

[GTG3000]

As far as I know it is intended that you can not build tiles or anything behind engines. But as you’ve found setting the exclusion range to a huge value has massive performance issues and no other solution has been found so far.

Couldn't you just keep a map of {x: y} data to say "at this X coordinate, you can't build anything below Y value because that's where the engine ends" ? It's a pretty considerable addition to the build code, but space platforms are already pretty special I think.

[edit]
At the second thought, I see the issue with this approach - it only covers cases *after* the thruster was placed. Deconstructing all in a line would require an additional script to run down the chunks and check everything. Hm.

Easy solution to that; keep a map of x:y for the current bottommost y-value, and a map of x:y for the y-value limit for that column. Then, when a thruster is being placed:

• Check if the new y-value limit is more restrictive than the bottommost y-value in the column. If it is, deny placement. Otherwise, do normal placement checks for the thruster.
• Then, update the y-value limit and bottommost y-values to account for the placed thruster.

Of course, I don't think hardcoding such a change would be positive for the game overall, considering that it'd be effectively enforcing the developers design principles on the entire modding scene. The current solution may be open to minor exploits, but I don't see a huge issue with it especially with how it is only relevant once you start scaling stupidly large in space (which is already afaik discouraged by finite resources being available per platform, regardless of width?)

Yeah, the current situation isn't much of an issue, I feel. Thrusters simply having huge hitboxes is an elegant enough solution that doesn't require additional logic.

I can't really think of a way to make it mod-friendly other than splitting it into four maps - x:y up/down and y:x left/right - for limits and an "onplace" hook to ask the object if something offends it that's already there.

Probably way too much effort for not enough of a usecase.

[mmmPI]

There should be no hitboxes, instead the thrusters should burn whatever is behind if there is enough fuel for the trail of flame to reach it.