PlanetsLib Entity Replacement system compatibility patch

[nicholasgower]

This PR makes MU train control scripts compatible with mods that create locomotive variants with PlanetsLib's entity replacement system. The Entity replacement system is intended to create variants of entities when placed on particular planets, and for all intents and purposes, these variants are expected to be treated the same by control scripts. This PR adds support for these entity variants to the mod using a table added by PlanetsLib to make compatibility patches like this one as simple as possible. I've tested this with the latest version of Muluna and the latest version of PlanetsLib, and it works.

[nicholasgower]

Also, if you have any suggestions on how to rotate a locomotive that is part of a train, I would like your help. I've noticed an issue with the PlanetsLib entity replacement system where it can preserve the orientation of lone locomotives, but it deletes rotation information of any locomotive connected to other rolling stock.

[robot256]

Hi, thanks for making me aware of the PlanetsLib functionality and for looking into compatibility. I'm reluctant to add any mod-specific compatibility code to control.lua if it can be done in the data stage.

Is the only desired effect that additional "std->mu" entity name pairs be added to MUTC's runtime entity mapping? You could do the same thing in the data stage by adding more dummy recipes to the dummy technology. Or I could add the necessary mods to MUTC's optional dependency list, assuming the variants are created in data-updates, and the automatic script would take care of everything.

But actually, I had been planning to migrate from dummy recipes over to mod data entries. Your use case is the motivation I need to complete that this week.

[robot256]

The new mod-data structure would look something like this:

data:extend{{type="mod-data", data_type="mutc-locomotive-map", data={ std="locomotive", mu="locomotive-mu" } }}

[robot256]

Also, if you have any suggestions on how to rotate a locomotive that is part of a train, I would like your help. I've noticed an issue with the PlanetsLib entity replacement system where it can preserve the orientation of lone locomotives, but it deletes rotation information of any locomotive connected to other rolling stock.

I'm not sure what you're talking about. You mean deleting the old locomotive and placing the new one with the same position and orientation passed to create_entity produces a different orientation?

Tbh, feel free to copy or depend on Robot256Lib "replace_carriage()". As of 2.1.12, it uses the apply_upgrade() funtion to change entities without disturbing the connection to the train and track at all. The library is still needed to copy over everything that apply_upgrade doss not.

[nicholasgower]

My concern with adding compatibility code to the data stage is that unless you make PlanetsLib an optional dependency so your data-final-fixes happens after PlanetsLib's and any mod that might depend on PlanetsLib, some mods might make new entity variants in data-final-fixes that are not caught by your data-level script. Doing the check in control eliminates all possibility of missing entities. In the case of Muluna and this mod, in data-final-fixes, Muluna creates copies of every locomotive that burns chemical fuel, modifies the fuel categories, and updates a mod-data object that tells control "If [locomotive] placed on Muluna, replace with [locomotive-muluna]". It naturally captured MU's locomotive variants already, but beyond that, the entity replacement system can't know for sure how your mod wants to process these entity variants. That's why I made a mod-data table to tell other mods about entity variants created by PlanetsLib, so that scripts that discriminate based on entity name can be quickly patched. It would be possible to do the same thing in data, but that brings risks that I find unacceptable.

If you're planning on migrating to a mod-data system soon, I'd be happy to help you make your new system work with the ERS.

[nicholasgower]

Also, if you have any suggestions on how to rotate a locomotive that is part of a train, I would like your help. I've noticed an issue with the PlanetsLib entity replacement system where it can preserve the orientation of lone locomotives, but it deletes rotation information of any locomotive connected to other rolling stock.

I'm not sure what you're talking about. You mean deleting the old locomotive and placing the new one with the same position and orientation passed to create_entity produces a different orientation?

Tbh, feel free to copy or depend on Robot256Lib "replace_carriage()". As of 2.1.12, it uses the apply_upgrade() funtion to change entities without disturbing the connection to the train and track at all. The library is still needed to copy over everything that apply_upgrade doss not.

Thank you for the suggestion to use apply_upgrade(). I now use that function when replacing a train already connected to other rolling stock, and it works perfectly.

[robot256]

I'm working on the design now. I'm trying to incorporate the ~5 other mod-specific compatibility features I support and simplify the overall interface. Each MU locomotive entry needs 2 to 5 parameters to cover every case.

Do you have strong feelings on whether to make a single mod-data prototype with a table of tables for all the entries, versus making a separate mod-data prototype with the same data_type for each entry?

[nicholasgower]

Most mods opt to use only a few mod-data names to make inspecting them in-game easier, so I'd vastly prefer you use the nested table approach.

[robot256]

Great point, I'll do that! For Cargo Ships I did it the other way, but luckily there are very few ship types amount mods so far.

…

On Mon, Jul 27, 2026, 8:25 PM Nicholas Gower ***@***.***> wrote: *nicholasgower* left a comment (robot256/MultipleUnitTrainControl#22) <#22 (comment)> Most mods opt to use only a few mod-data names to make inspecting them in-game easier, so I'd vastly prefer you use the nested table approach. — Reply to this email directly, view it on GitHub <#22?email_source=notifications&email_token=ADQ345AZ2SP7TIZOKCKPGWT5G7XGDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBZHAZTMOBRGAZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5098368103>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADQ345BHQV3XU2ECR5MYRYL5G7XGDAVCNFSNUABFKJSXA33TNF2G64TZHMYTONRRGMZDAMJXHNEXG43VMU5TIOJZGEZDGNBYGY2KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ADQ345HFJESNKVNWPDCECPD5G7XGDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBZHAZTMOBRGAZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/ADQ345FJXMQOKEJFNDMBQYL5G7XGDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBZHAZTMOBRGAZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[robot256]

I have implemented PlanetsLib compatibility in the https://github.com/robot256/MultipleUnitTrainControl/tree/mod_data_api branch. I did a quick test with Mulana and it appears to work. Could you please test that branch and make sure it meets your needs?

[nicholasgower]

Thank you! I can't test it now, but did you make sure to enable the runtime locomotive replacement in settings? I disabled it by default due to stability concerns after making this PR.

[robot256]

Yes, I found the setting and enabled it. I used the editor to make a locomotive on Mulana, saw that it was "locomotive-PlanetMulana" or whatever, and made a second one and saw they become "locmotive-mu-PlanetMulana". I saw that it did not make copies of se-space-trains or electric-trains locomotives.

[robot256]

Alright, the update is live!