Add related_transport_belt to LuaEntityPrototype

[PietersieliePC]

I've been working on a mod that adds some useful upgrade options and configurations when dealing with belt networks and spaghetti where dragging a base game upgrade planner is unfeasible. One of the features I want to add is upgrading only belts of the same tier as the originally selected belt. To do this, I need to be able to determine the splitter, transport belt, and underground belt of the relevant tier, e.g., if my initial selection is `fast-transport-belt`, I want to find `fast-splitter` and `fast-underground-belt` as well. Finding transport belts and underground belts that are related is easy given that the `related_underground_belt` property is exposed in `LuaEntityPrototype`. However, while `SplitterPrototype` has a similar `related_transport_belt` property, it is not exposed in `LuaEntityPrototype`.

My main motivation for this request is compatibility -- while I can easily make a list of known tiers and use those prebuilt tables, it would be significantly easier for other belt mods to ensure compatibility with my mod by allowing the tier table to be built at runtime request. If I can write all my code without once using a hardcoded prototype name, that would be great.

[curiosity]

related_transport_belt :: EntityID optional new
The name of the TransportBeltPrototype which is used for the sound of the underlying belt.

It doesn't mean what you want it to mean. Better check belt speed instead.

[PietersieliePC]

related_transport_belt :: EntityID optional new
The name of the TransportBeltPrototype which is used for the sound of the underlying belt.

It doesn't mean what you want it to mean. Better check belt speed instead.

Belt speed can conflict if multiple belt tiers have the same speed (e.g., Space Exploration express and space, or the various deep space belts). All I want is an identifier, and EntityID is enough for me to use or filter a search on.

[Muche]

How is your mod planning to cope with modded belts which leave the (optional) related_*_belt properties empty, or use the same reference for various splitter tiers?

[PietersieliePC]

How is your mod planning to cope with modded belts which leave the (optional) related_*_belt properties empty, or use the same reference for various splitter tiers?

If the property isn't set, it fails safely and I will add a message that the user should contact the author of the belt mod to add compatibility. If the demand is there, I might add a compatibility user option that will, if set, use the belt speed if the properties aren't set.

[curiosity]

If the property isn't set, it fails safely and I will add a message that the user should contact the author of the belt mod to add compatibility. If the demand is there, I might add a compatibility user option that will, if set, use the belt speed if the properties aren't set.

That's the trivial of the two situations. What about the other one? What will you do when there's a completely unrelated belt there (most likely a vanilla one)? It's a valid use of the API.
Not to mention that the other mod's author will be completely in the right to shoot down your (by proxy) request. They don't need an external belt sound for their splitter.

[PietersieliePC]

That's the trivial of the two situations. What about the other one? What will you do when there's a completely unrelated belt there (most likely a vanilla one)? It's a valid use of the API.
Not to mention that the other mod's author will be completely in the right to shoot down your (by proxy) request. They don't need an external belt sound for their splitter.

Why would they need an external sound to point to a belt that's not vanilla? The sound properties are set in the TransportBeltPrototype. I am unaware of a mod that adds only splitters and not a corresponding belt. Therefore, I don't think there's any reason except misunderstanding to have that property set to a vanilla belt rather than the corresponding mod belt, even if it is allowed by the API. Regardless, if the splitter is set up to have an unrelated belt in that property, then there is no way for my mod to know. I will leave it as a potential issue on the mod's description, with the recommended remedy for the belt mod. The only way for me to resolve it in my mod (rather than on the belt mod's side) would be to hard code the tiers for every mod that adds a belt tier, and update on every version that changes it. I do not think that is good development practice, especially when a relatively trivial and clean alternative is available. And while there is no obligation for other mod authors to set the two properties I use, there is equally no obligation on me to support those mods. Hard coding the vanilla tiers and leaving it at that would've been easier, but since there is a potential solution to support most if not all other belt mods, I don't see why it's not worth pursuing.

[protocol_1903]

When doing mods like these, I prefer to use entity-name instead of any other properties. (Most) mods follow the same conventions for naming similar entities (pipes, splitters, pipe to grounds, underground belts) so by knowing what the convention is, you should be able to find what the associated prototypes are.

[PietersieliePC]

When doing mods like these, I prefer to use entity-name instead of any other properties. (Most) mods follow the same conventions for naming similar entities (pipes, splitters, pipe to grounds, underground belts) so by knowing what the convention is, you should be able to find what the associated prototypes are.

There are many solutions, yes. But I'm not looking for a way to do it. I'm asking for the right way to do it to be made available. I have a working hack to smuggle the relevant information from the prototype/data stage through to the control stage. But that's not the right way to do it, and it adds an overhead to update if Factorio updates. If this property is available, it just simplifies any work I need to do and greatly helps compatibility with other mods.

[curiosity]

I'm asking for the right way to do it to be made available.

But it's the wrong way. The property doesn't mean what you want it to mean.

[protocol_1903]

There are many solutions, yes. But I'm not looking for a way to do it. I'm asking for the right way to do it to be made available. :D I have a working hack to smuggle the relevant information from the prototype/data stage through to the control stage. But that's not the right way to do it, and it adds an overhead to update if Factorio updates. If this property is available, it just simplifies any work I need to do and greatly helps compatibility with other mods.

If there's ever any convention, something's going to break it. You just need something that works 95% of the time, then you can work around the rest with a more manual approach. Most of my mods don't work in combinations because there isn't an established convention, or the established one is broken. Just gotta roll with it.