It doesn't mean what you want it to mean. Better check belt speed instead.related_transport_belt :: EntityID optional new
The name of the TransportBeltPrototype which is used for the sound of the underlying belt.
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.curiosity wrote: Sat Feb 08, 2025 3:27 pmIt doesn't mean what you want it to mean. Better check belt speed instead.related_transport_belt :: EntityID optional new
The name of the TransportBeltPrototype which is used for the sound of the underlying belt.
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.Muche wrote: Sat Feb 08, 2025 10:16 pm 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?
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.PietersieliePC wrote: Sun Feb 09, 2025 4:33 pm 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.
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.curiosity wrote: Sun Feb 09, 2025 10:37 pm 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.
