Immersive Engineering

Immersive Engineering

134M Downloads

[1.16.1] Crash on Forge 0.90+

archonsd opened this issue ยท 5 comments

commented

Description of the issue:

Running forge >= 0.90 with immersive engineering v109 results in crash complaining of immersive engineering failing to load correctly, specifying "method public void".

Crashlog:

https://pastebin.com/eX2q6tEe

Versions & Modlist

IE 0.16-109
Breaks on Forge 32.0.98 and Forge 32.0.106. Works fine with Forge 32.0.88
Mod List: https://pastebin.com/g4xy9UyJ

Also, please try testing an issue in a minimal instance, with just IE, Forge and maybe JEI. That makes elminating compat issues easier.

Thank you for reporting issues, without people reporting them, they wouldn't get fixed. You're helping contribute to this mod and that is much appreciated <3

commented

This is already known. It's been reported multiple times. Check recent issues before opening.

commented

This is already known. It's been reported multiple times. Check recent issues before opening.

I did check.. (used search with "1.16" only, only one issue showed, used "public void main", no issue showed) I might not know some trick to using search more effectively, but I did search. I also visually scanned the open issue front page, all the way to the bottom. Nothing resembled this one.

I didn't remove "open" from the search, given it's still an ongoing issue.. so maybe someone reported it and it was closed already.. but it wouldn't be obvious to me to search closed issues explicitly for an ongoing issue.

commented

Yeah, that caused some confusion for me early on as well. You have to remove "open" and scan through the recent fixes. Either that or monitor the GitHub commits. From the contribution guidelines referenced in the new issue template:

Please always search for both open and closed issues as issues are closed when the fix has been written, not when a release containing a fix is published.

But yes, it has been fixed and will be in the next release. Releases are done at a much slower rate than issues are fixed and no estimates are provided as to when the next release will be available for download.

commented

Yeah, that caused some confusion for me early on as well. You have to remove "open" and scan through the recent fixes. Either that or monitor the GitHub commits. From the contribution guidelines referenced in the new issue template:

Please always search for both open and closed issues as issues are closed when the fix has been written, not when a release containing a fix is published.

But yes, it has been fixed and will be in the next release. Releases are done at a much slower rate than issues are fixed and no estimates are provided as to when the next release will be available for download.

When I remove 'is:open', I do see a few reports. I'll 'close and comment' since this isn't useful anymore. Thanks for the clarification.

commented

Thinking about it, you might want to re-open one of them, to avoid situations like this in the future.. but that's just a suggestion. Good intentioned people that want to use the mod are likely to repeat.

Secondary thought: a mechanism to mark issues 'fixed', without closing them, to make them easy to see.. and then closing them once the binary is pushed, might be a good process improvement.