Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FTB Omnia Crash #465

Closed
camcam95 opened this issue Apr 6, 2020 · 6 comments
Closed

FTB Omnia Crash #465

camcam95 opened this issue Apr 6, 2020 · 6 comments
Labels
1.15 This issue or pull request only pertains to MC 1.15 bug Something isn't working requires backport Anything that has been fixed but requires a backport to an older version
Milestone

Comments

@camcam95
Copy link

camcam95 commented Apr 6, 2020

Forge Version: 31.1.35
Building Gadgets Version: 3.3.4
Crash Report: Pastebin

While exploring the Nether, I fell into lava. Once dead, game crashed and world is no longer even loadable.

While I can't reproduce the error, my world is definitely borked.

@MajorTuvok
Copy link
Contributor

MajorTuvok commented Apr 6, 2020

Interesting, something that is supposedly impossible happened... Did Forge not re-instantiate the caps?

Also the problem here lies with the Buildingrender, try to spam some number key when entering the world, so that the Gadget is no longer selected (I hope you weren't holding it in the offhand, as that would be tricky to swap away... You could edit it out of the world file though).

@MichaelHillcox
Copy link
Collaborator

Hay, I know about this one! By any chance do you have the hardcore mod thing where it leaves a corps? @MajorTuvok This is why I've already said to try and fail softly instead of throwing as this is something I've now resolved in my latest 1.15 push. I haven't yet released it but it was a fun one to fix. Some mods delay death without invalidating the caps but at the same time, moving the caps / invalidating them in an hacky way. This is effectively what caused this.

@camcam95 https://s.mikey.pro/buildinggadgets-3.3.4.jar this is a custom build I've not released yet. Please see if this resolves your issue 👍

@MajorTuvok
Copy link
Contributor

MajorTuvok commented Apr 6, 2020

@MichaelHillcox in this case it is someone not properly initialising caps which is why in my opinion it's just the right thing to do... They don't init caps? Well then they shall fix it or live with it crashing stuff. I don't like your fix, as it fixes the Symptom and not the cause - though I understand why you do it.

As we've already had this discussion a few times and never seem to agree, I'll just leave it
:(

@MichaelHillcox
Copy link
Collaborator

MichaelHillcox commented Apr 6, 2020

When you're dealing with other modders and external factors there has to be a level of dealing with the symptoms instead of dealing with the cause. We don't have the time to go around fixing everyone elses mods but we do have the time to put minor things in place so when something fails because of another mod, it's not the end of the world. This specific issue is actually part of mutiple different issues, how MC handles death, how Forge handles the death events and where and when it blocks those specific code segments and how the specific mod in question doesn't do anything to avoid the caps being invalidated incorrectly. For us, this is causing an issue with our render continuing to run when the player is in a state of "fake death" which only really has two solutions, throw the game and give a crap user experience for something they otherwise wouldn't have noticed. Or two, fail lightly and just ignore it. If this was in a critical system like the mod starting up, sorting data on the player or something which the mod can not come back from then I'd agree that we throw but we shouldn't throw in an instance where we have no control over the existance of something. No player inventory, welp, return an empty cap. Mods config didn't load, time to throw the game, we can't run without this. For example.

Another good example of failing lightly instead of failing hard is when working with api's, web api's to be sepecific, a lot of the time, something minor will go wrong and throw something stupid back at the main application, you how two options, throw everything or try and recover, the best option is to always try and recover as 9 times out of 10 it's not a critical call issue and you can likely just retry the call and it'll be resolves. Programming is never a 1 solution fits all and you've got to allow for failing softly over failing hard in a lot of instances. It's a pain in the ass because it triples your work load 90% of the time but it greatly improves the useability of something.

@MajorTuvok
Copy link
Contributor

MajorTuvok commented Apr 6, 2020

^ As I said we can't get to a common ground here. Therefore no point discussing this.

@MichaelHillcox MichaelHillcox added stale This issue or pull request has become stale unresolved For any closed issues that have not been resolved. waiting on response Waiting for issue-opener to respond labels Jun 24, 2020
@MichaelHillcox MichaelHillcox added this to the 1.15.2-3.4.0 milestone Jul 17, 2020
@MichaelHillcox MichaelHillcox added 1.15 This issue or pull request only pertains to MC 1.15 bug Something isn't working pending release These changes have not yet been released in a build and removed stale This issue or pull request has become stale unresolved For any closed issues that have not been resolved. waiting on response Waiting for issue-opener to respond labels Jul 17, 2020
@MichaelHillcox MichaelHillcox added the requires backport Anything that has been fixed but requires a backport to an older version label Aug 21, 2020
@MichaelHillcox
Copy link
Collaborator

Fixed a while ago and will be released on older versions some time today 👍

@MichaelHillcox MichaelHillcox removed the pending release These changes have not yet been released in a build label Feb 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.15 This issue or pull request only pertains to MC 1.15 bug Something isn't working requires backport Anything that has been fixed but requires a backport to an older version
Projects
None yet
Development

No branches or pull requests

3 participants