Doctor Who - Regeneration

Doctor Who - Regeneration

318k Downloads

[BUG] Big crash in proximity of "potential" sync shell with regeneration.

Darkmega18 opened this issue ยท 13 comments

commented

Describe the bug
I am using a pack that I made that has both sync and Regeneration, and the dalek mod (since that also has it's own regenerations, but we didn't know this before we started using it). We have reason to believe that a friend has probably made a secret lab in our base area that causes us to crash due to an incompatibility with sync shell storage printing the player's skin onto the stored bodies, as this crash seems to related to a block and it's capability to get the skin vs your power to switch peoples skin at will with regenerations.

https://paste.dimdev.org/uxujumeyeg.mccrash

crash is above. as given by vanilla fixes mod.

To Reproduce
If this is simply an error between the two mods, simply get regeneration, get sync, then build a sync storage, and let it build a clone. once it's finished and it tries to print the skin onto the clone, the game will proceed to always blow up when you're within visible distance of the clone storage/builder.

Expected behavior
We'll be fine. and friend can have his clones, and others can be time lords. but instead, game blows up when we get close to base.

I was hoping that Sync can be used as a "failsafe death save" in the case of overpowered mobs killing us mid regen or as a choice of just not regenning and dieing but instead using a disposable clone body to sync to instead of using the regeneration.

Screenshots
None available, i crash before getting proof. he's not around at the minute. :V

Additional context
EDIT: This seems to be server side. My friend and I just did some science related to shells in single player. with a regen changed skin, without, and with shells made and stored. no such crash. but we still crash when trying to get on the server in the proximity to the storage in question made by the friend who chooses not to use regeneration.

commented

I suspect that this is caused by the sync bodies not being real players and Regeneration is trying to obtain the data required from them that only a player would ever have

This makes the game return null, as this data is not obtained and causes a crash, I will have a fix out this evening for this hopefully

commented

Thank you so much. I guess we'll just wait a while then. or ask the friend to take his clone facility down temporarily and just be careful for a bit. :)

commented

Could you try with this jar?

commented

Uh. which jar? where jar? I see not a jar. D:

commented

Well, that's my end of things fixed chief, Dalek Mod is closed source so I can't help you at all there

commented

I know. I've let them know of it, and pointed them here to see how you fixed it. now, I guess friend is cloneless for a bit longer. :V thank you again for the swift fix. :)

commented

In terms of this releasing officially, it will either be on twitch tonight or by the end of the week. I have a few things I wish to add to the mod, such as the Chameleon Arch and some more regeneration stuff based on the Watcher entity. If you use twitch for your modpack though, I do not mind putting this out as a small patch for convenience

commented

it should be fine if you've got other stuff to add. it's just made as a private pack for myself and friends. we can just sit on this version until you've made the update and i'll grab it then. :) I send it to them manually with the export function anyways.

commented

O.o 2.0.8? when the one on curse is 2.1.0? :V but ok, we'll give it a shot. updating my server and letting friends know.

commented

No no, just that specific jar, the versioning wasn't updated correctly, don't use the twitch version, download from here and attempt

commented

yeah, I am. just ribbing you, figured it was just some auto versioning/slip.

commented

well, different crash this time. from dalek mod. so I think you've fixed it. but dalek mod now has to also.

https://paste.dimdev.org/ayaxoyufel.mccrash

if it's any consolation, atleast you're not the only one to make the same mistake. ;) I'll reference them here so to have them implement the same fix. cause seems to be very similar if not the same bug.