[1.12.2] Changing UUIDs of external mod blocks at server startup
MrTroble opened this issue · 3 comments
Hallo,
I am the maintainer of a signal mod, and we got notified of changing UUIDs by one of our users with the following issues Issue 107 [while the start of this report is in English most part is German so I will summarize below].
General
This issue was confirmed on
- OC-Version: 1.7.5.218
- MC-Version: 1.12.2
- GIRSignals: 1.0.968
Several other mods where present (some interacting with OC)
| ID | Version | Source |
|:----------------------- |:--------------------- |:--------------------------------------------- |
| minecraft | 1.12.2 | minecraft.jar |
| mcp | 9.42 | minecraft.jar |
| FML | 8.0.99.99 | forge-1.12.2-14.23.5.2860.jar |
| forge | 14.23.5.2860 | forge-1.12.2-14.23.5.2860.jar |
| opencomputers|core | 1.7.5.218 | minecraft.jar |
| cd4017be_lib | 6.4.17 | CD4017BE_lib-1.12.2-6.4.18.jar |
| circuits | 6.1.6 | AutomatedRedstone-1.12.2-6.1.6.jar |
| codechickenlib | 3.2.3.358 | CodeChickenLib-1.12.2-3.2.3.358-universal.jar |
| df-roads | 1.5.2-mc1.12.2 | df-roads-1.5.2-mc1.12.2.jar |
| forgelin | 1.8.4 | Forgelin-1.8.4.jar |
| forgemultipartcbe | 2.6.2.83 | ForgeMultipart-1.12.2-2.6.2.83-universal.jar |
| microblockcbe | 2.6.2.83 | ForgeMultipart-1.12.2-2.6.2.83-universal.jar |
| minecraftmultipartcbe | 2.6.2.83 | ForgeMultipart-1.12.2-2.6.2.83-universal.jar |
| furenikusroads | 1.1.9 | Fureniku's+Roads-1.1.9.jar |
| opencomputers | 1.7.5.218 | OpenComputers-MC1.12.2-1.7.5.218.jar |
| girsignals | 1.0.899 | GIRSignals-1.0.899.jar |
| journeymap | 1.12.2-5.7.1 | journeymap-1.12.2-5.7.1.jar |
| malisiscore | 1.12.2-6.5.1-SNAPSHOT | malisiscore-1.12.2-6.5.1.jar |
| malisisdoors | 1.12.2-7.3.0 | malisisdoors-1.12.2-7.3.0.jar |
| mrtjpcore | 2.1.4.43 | MrTJPCore-1.12.2-2.1.4.43-universal.jar |
| ngtlib | 2.4.18 | NGTLib2.4.19-35_forge-1.12.2-14.23.2.2611.jar |
| rtm | 2.4.21 | RTM2.4.22-40_forge-1.12.2-14.23.2.2611.jar |
| oc_rtm | 1.0.0 | OCRTM-1.0.0.jar |
| projectred-core | 4.9.4.120 | ProjectRed-1.12.2-4.9.4.120-Base.jar |
| projectred-integration | 4.9.4.120 | ProjectRed-1.12.2-4.9.4.120-integration.jar |
| projectred-transmission | 4.9.4.120 | ProjectRed-1.12.2-4.9.4.120-integration.jar |
| projectred-illumination | 4.9.4.120 | ProjectRed-1.12.2-4.9.4.120-lighting.jar |
| quickhotbar | 1.05 | quickhotbar_1122_1.05.jar |
| shadowmc | 3.8.0 | ShadowMC-1.12-3.8.0.jar |
| redstoneremote | @VERSION@ | RedstoneRemote-1.12-1.1.0.jar |
| thutcore | 5.21.0 | thutcore-1.12.2-5.21.0.jar |
| thutcore_compat | 1.0 | thutcore-1.12.2-5.21.0.jar |
| thuttech | 6.1.6 | Thutmoses-Elevators-Mod-1.12.2.jar |
| gvc | 1.2.0 | Voice+Chat+Reloaded-1.2.0.jar |
| worldedit | 6.1.10 | worldedit-forge-mc1.12.2-6.1.10-dist.jar |
| wrcbe | 2.3.2 | WR-CBE-1.12.2-2.3.2.33-universal.jar |
| fix-rtm | 2.0.20 | fixRtm-2.0.20.jar |
Implementation detail
We use the SimpleComponent interface from the OC API in our signal controller which can be found here SignalControllerTileEntity.
It exposes several methods and provides the component name as described by the documentations
@Callback
@Optional.Method(modid = "opencomputers")
public Object[] hasLink(Context context, Arguments args);
@Callback
@Optional.Method(modid = "opencomputers")
public Object[] getSupportedSignalTypes(Context context, Arguments args);
@Callback
@Optional.Method(modid = "opencomputers")
public Object[] changeSignal(Context context, Arguments args);
@Callback
@Optional.Method(modid = "opencomputers")
public Object[] getSignalType(Context context, Arguments args);
@Callback
@Optional.Method(modid = "opencomputers")
public Object[] getSignalState(Context context, Arguments args);
@Override
public String getComponentName() {
return OC_INTERNAL_NAME;
}that is the whole interaction with the OC API
Reproduction
- We started the given test server (provided by our user)
- We tested each controller block with an analyzer
- Sometimes (apparently random) the uuids would be different
- If they changed we mostly could observe the following message:
A component of type 'signalcontroller' disappeared ({uuid})! This usually means that it didn't save its node.with the uuid being the old uuid (Full log 2022-02-22-2.log) - Cleanly shutting down and retrying
Investigation
We have investigated the NBT save files of the given world and could not find issues with the saved node, hence we assume that the save was done correctly. We have tried to figure out what might be causing the issue during loading but we could not find anything. The issue appears never when the user is in the chunk during joining the server (0 out of 30 times). However if the users spawns outside of the loaded chunk range and then flies towards the chunk with the controller in it it appears around 90% of the time (approx 9 of 10) times.
We would be thankful for any help mitigating this issue,
Cheers and thanks
~MrTroble
AFAIK this is a long standing bug in the mod that's been worked on but never really fixed.
@brisingraerowing Thank you for your response, we have been hunting this ghostly issue for a while on our side but we have not found the root cause. You don't happen to have additional information, do you? Like other instances with this happening?