Factorio Forums

TL;DR

The recent (0.17.56) change in the modability of rail bounding boxes breaks part of the cargo ships mod (https://mods.factorio.com/mod/cargo-ships) and i d be extremly happy if another solution could be found.

What ?

I am not sure what exact the issue the devs fixed with this change, but in the case that the issue concerned mainly smaller-than vanilla rail bounding boxes, maybe the fix could be altered to allow making the bounding boxes larger, but not smaller?

Why ?

The cargo ships mod relies on modded rails that for a number of reasons have bounding boxes larger than the vanilla rails.
Since the ships (modded trains) are wider than the vanilla trains, the bounding boxes of the rails are wider too, for one to enforece their placement on water to have a minimal distance from the next land tile, but more importantly for pumps to be able to connect to tankers (modded fluid wagons) from a greater distance that corresponds to the ships greater width. Those mechanics are broken in the newest update.

This mod has used that mechanic for quit some time now, and it be awesome, if a solution to the issue could be found, that does not break existing mods.

From what I understand, Very Bad Things happen to a map if rail bounding boxes of any entity on the map changes. A mod author typically no reason to change the bounding boxes after the initial release, but Wube needs a guarantee that a future mod update or an unrelated mod will never change them. The modding system is not designed to provide that kind of guarantee.

One way to implement this guarantee is to store the initial bounding box of every rail in the save file. This adds 4 bytes of overhead for every entity.

Another way is to make a lookup table of rail entity names and bounding box sizes, and store that in the save file. If the save detects that any bounding box has changed, it will refuse to load.

DaveMcW wrote: Fri Jul 12, 2019 1:26 pm From what I understand, Very Bad Things happen to a map if rail bounding boxes of any entity on the map changes.

No one bad thing comes, it will be ignored or migrated.

darkfrei wrote: Fri Jul 12, 2019 3:08 pm

DaveMcW wrote: Fri Jul 12, 2019 1:26 pm From what I understand, Very Bad Things happen to a map if rail bounding boxes of any entity on the map changes.

No one bad thing comes, it will be ignored or migrated.

Incorrect. If the rails start getting merged when they weren't before it fails the consistency checks and the game will crash on load. That's the main reason why rail bounding boxes where hard coded.

Rseding91 wrote: Sat Jul 13, 2019 10:51 am

darkfrei wrote: Fri Jul 12, 2019 3:08 pm

DaveMcW wrote: Fri Jul 12, 2019 1:26 pm From what I understand, Very Bad Things happen to a map if rail bounding boxes of any entity on the map changes.

No one bad thing comes, it will be ignored or migrated.

Incorrect. If the rails start getting merged when they weren't before it fails the consistency checks and the game will crash on load. That's the main reason why rail bounding boxes where hard coded.

Does the mean there is no chance that the feature is coming back? Also i'd only need the "width" of the bounding boxes to be moddable, does the merging issue also occur when the width changes?

It occurs with any size changes in rail bounding boxes. And most likely it will not be coming back.

I would like to echo the mod creators request.

Can you explain to me which situations could occur that are now fixed with this change? If there is a change made to a system which has been there for a long time, I would really like to understand the need for it to change

A possible solution could be:
- add an optional secondary collision box, that only applies for placement checks, leaving the boxes the trains actually use alone
- add some parameter to pumps to allow them to connect further away (similar to how inserters have customizable pickup/dropoff points)

@SaintFlow
I guess it may have to do with all the train related changes that where required because of https://www.factorio.com/blog/post/fff-299

To go with Choumiko’s suggestions, the mod author can probably add custom pump entities for use with the ships.

It sucks, yeah, but it would allow it to continue to work.

Choumiko wrote: Sat Jul 13, 2019 3:20 pm A possible solution could be:
- add an optional secondary collision box, that only applies for placement checks, leaving the boxes the trains actually use alone
- add some parameter to pumps to allow them to connect further away (similar to how inserters have customizable pickup/dropoff points)

@SaintFlow
I guess it may have to do with all the train related changes that where required because of https://www.factorio.com/blog/post/fff-299

Not just. If you want to go see the public face of the root cause, there are two different bugs in the appropriate forum about rail related bounding box issues.

In one case a cross-over of two parallel rails didn't merge as expected, in the other I think there was an additional missing collision check permitting trains through each other.

As a developer elsewhere my rule of thumb is: bug happens once, fix it and move on. bug happens twice with a common root cause? you have a systematic problem, and if you don't fix that root cause you will be fixing the same bug once a month until the end of time. The FFF changes may be involved, but I'm pretty confident it was fixing the root cause bug forever that did in the "rail bridges" mod, and this, by way of the fixed and immutable bounding boxes.

I agree that allowing more distant pump connections would be a good potential solution; failing that, I'd probably look at a nasty hack to produce a graphically modified pump that looked less overlapping. :/

So this change not only breaks rail bridge crossings but also cargo ships.
I'd take potential crashes, that never happened to me using cargo ships for over a year now, over loosing two great mods like these.

Optera wrote: Sat Jul 13, 2019 8:03 pm So this change not only breaks rail bridge crossings but also cargo ships.
I'd take potential crashes, that never happened to me using cargo ships for over a year now, over loosing two great mods like these.

Here is another problem: mod authors don't get statistics about crashes because of their mods.

I expect some instability when using mods. That's a part of the deal.

Lubricus wrote: Sun Jul 14, 2019 1:47 am I expect some instability when using mods. That's a part of the deal.

Yup, me too.

This wasn't a mod causing a crash. It was a feature in the base game that mods happened to utilize, but that somehow caused unintended behavior with vanilla entities in un-modded games. I don't know why or how hard-coding the hitboxes for vanilla rails makes them less buggy than before, but the devs clearly thought that was the best (or only) solution to the problem.

It remains to be seen whether they will make accommodation for Cargo Ships, or if many of us will be stuck on 0.17.55 for modded games.

robot256 wrote: Sun Jul 14, 2019 5:41 am This wasn't a mod causing a crash. It was a feature in the base game that mods happened to utilize, but that somehow caused unintended behavior with vanilla entities in un-modded games. I don't know why or how hard-coding the hitboxes for vanilla rails makes them less buggy than before, but the devs clearly thought that was the best (or only) solution to the problem.

Just simpler; I'm confident it would be possible with infinite time, money, and effort, to make modifiable bounding boxes work correctly, and bug free. The challenge is that simpler systems also make things work correctly, and bug free, and cost a whole lot less of all those things.

robot256 wrote: Sun Jul 14, 2019 5:41 am It remains to be seen whether they will make accommodation for Cargo Ships, or if many of us will be stuck on 0.17.55 for modded games.

Keep in mind that (as far as I understand it) Cargo Ships isn't exactly "broken", just bruised and battered. More hacks required to make it nice, but unlike the rail bridges deal I don't think this has killed it off. unless the author drops it because it now sucks to write so many hacks, anyway. again, this is my personal understanding, and I don't write the code of the mod, so I don't know with certainty that I'm correct.

Rseding91 wrote: Sat Jul 13, 2019 11:24 am It occurs with any size changes in rail bounding boxes. And most likely it will not be coming back.

Rsedling91, it'd be kind if you and the team could consider if there was some way to support what I personally see as a common factor between the Cargo Ships mod, and a bunch of other mods: they are train-network-like, but different in some interesting way.

The long version follows, but the executive summary: could we get something that'd allow more flexible train-like networks that (a) are distinct from and don't interact with the "train" network, and (b) allow some degree of greater customization, even if that is in the form of "here is some pathfinding help, have fun"?

Mods that I think of as having "train-like network" behaviours, and interesting trade-offs from just trains, bots, and belts, as concrete examples of my thesis that this is a valuable area to allow modders to add significant replay value:

• Cargo Ships, which are trains except on water.
• Logistic Carts, which are a fusion of "tiny slow" trains and "tiny slow stuck on the ground" logistics robots.
• AAI Programmable Vehicles, the logistics parts, which are trains, except trucks, the way I wanted to use (this part of) the mod. *
• Asphalt Roads, and Place Roads Like Rails, which also point toward a way to get the logistics parts with, uh, trucks.
• Aircraft, the logistics parts, in which the cargo planes are what I wanted: trains only "they can fly." **

* I liked the "dynamic pathfinding" bits too, for off-fixed-track stuff, but mods can already do that, so it isn't needed in scope of this question.

** I actually wanted them to be "build airports, define flight lanes between them, they are trains only flying", but they are not. I was starting to think about what I'd need to do in order to mutate rails to provide the "flight lanes" parts of this myself. Most of the actual vehicle part, other than graphics, is pretty much a basic train-like thing, and that'd give me routing for "Free" too.

Some explanations of why I think these are different, and add replay value and/or fun value to the game for me:

Slow boats, but crossing water, since I love me some islands in my maps by way of that 600 percent water coverage, feels much better than just running trains over what I want to imagine as "oceans"; certainly they are 1/2 to 1 KM stretches of clear deep water at times, so while I could just run rails over them with one of the mods letting them place on water, I'd much prefer the boats.

The difference between a train network for transport and a automobile network: like in the real world the later is better for short distance but small delivery, the former for long distance but bulk transport. By using both - more the Logistics Carts mod, uh, model, no pun intended - I can build a factory that has a very different set of logistics paths than trains and either belts or bots for the last mile.

Flying cargo ... well, fast vs cheap, and similar trade-offs, if you require airports with their significant infrastructure investment, make an interesting choice vs trains in a number of situations, I think. Certainly, I would much more happily commit a cheap to run train full of supplies for a mining outpost when the demand was small ("we need a couple dozen repair kits, and two robots to replace the melted ones") than an aircraft ("just gonna throw down a big ol' airport next to you here"), but on the other hand, small airfields with "Cessna 150" or so plains are ... effective, but not cheap, unless you look at the defense logistics of all that rail just sitting there being all tasty for bugs and all....


My thesis about what the common parts are from a modding API perspective, and questions about what might satisfy those needs:

I think the common element of all that is the desire to have a "separate but equal" network to trains and rails, with different trade-offs. I also think that is the sort of "what if" question that mods are excellent good for asking, and which can add a lot of replay value for a relatively small investment in changes. In the hope I get what I want, even if I have to write it myself:

Would it be possible to allow the declaration of separate static rail system "types" in the data / prototype phase that have different bounding boxes, statically, and which cannot interoperate at all? (pretty sure the last is the most complex part, TBH, but ... something toward it, anyway?)

If "flexible" bounding boxes were out of the question, would uniform scaling of the rail bounding boxes be possible? With limits (eg: minimum size, max size ranges enforced, or whatever)

Finally, if none of that could be done, would it be possible simply expose some part of pathfinding such that something - ideally without a proxy character / unit - could be told to do pathfinding, but to restrict valid locations to "these tiles / entities", so that we get both pieces we need to do our own version of distinct train networks?


I'm sorry if this is long, and I'm of course happy to create a separate top level request if you prefer.

While i wish there would be another solution, i to a 100% respect the decision of the devs to remove features that might cause future instabilities.

robot256 wrote: Sun Jul 14, 2019 5:41 am It remains to be seen whether they will make accommodation for Cargo Ships, or if many of us will be stuck on 0.17.55 for modded games.

The current version of the mod actually "works" again, with the main issue being, pumps and ships now overlapping graphically, which while not perfect certainly isn`t game breaking.