Immersive Petroleum

Immersive Petroleum

47M Downloads

Projector doesn't working

MrMorgan0 opened this issue · 15 comments

commented

Minecraft Version

1.18.2

Immersive Engineering Version

8.4.0-161

Immersive Petroleum Version

4.1.0-19

Current Behaviour

I'm selecting a building that i want to show in the world (for example "Fluid Tank"), GUI closing (it's ok), but i can't see it when I'm trying to put schematic(shell) in the world.

Expected Behaviour

I expect that projector's functions work correctly.

Reproduction Steps

How did i get this case?

  1. I've updated Immersive Petroleum mod to newest version of it, and run Minecraft,

  2. It bring me that the Immersive Engineering mod also needs to be updated, I did it, and run Minecraft,

After that the Projector did not work.

What I've tried?

  1. Tried to remove any performance mods(Didn't help),

  2. Tried to play with config files from both mods/Immersive Engineering & Immersive Petroleum/(Didn't help),

  3. Tried to generate new world(Didn't help),

By the way, when I've selected building that i want to project in the world and clicking(RMB) in the world, in latest.log file I see that Error code

[Render thread/ERROR]: ########## GL ERROR ##########
[Render thread/ERROR]: @ Render
[Render thread/ERROR]: 65539: Invalid key -1

Here's the screen where you can see that.
Here's the video demonstration of issue https://tinyurl.com/5cswv644

Снимок экрана (4)

How we can Fix that?

Debug Crash Log

https://pastebin.com/NFrkwmQU

Information for the reader.

Sorry for my English, I'm not good on it :)

commented

I'm having the same issue. I'm away from my computer right now, so I don't have access to much diagnostics info - but I think it's related to PR #134.

@MrMorgan0, try downgrading Immersive Petroleum to v4.0.0-17 - that's the latest published version that doesn't include the above PR.

EDIT: Indeed, downgrading to that version fixed the issue for me.

commented

What about a clean instance with just IE and IP? If it works there, then some other mod likely is causing issues.

commented

What about a clean instance with just IE and IP? If it works there, then some other mod likely is causing issues.

Yeah, it works well without another mods.. and I just tried to find which mod causing that issue by removing suspected mods, and I've already find it. Also I have read IE issues page on GitHub. Rubidium mod causing that issue. Rubidium 0.5.4 is not working with IE 8.4.0-161 new PR(Projector Shader).
But I found how we can fix that. Follow that steps to fix it out:

  1. Download Rubidium 0.5.5,
  2. Download latest versions of IE and IP,
  3. Install and run Minecraft
  4. Close your Minecraft and go to Config folder, find the file named rubidium-mixins.properties,
  5. Change the value of mixin.features.chunk_rendering to false.

It's should look like this mixin.features.chunk_rendering=false

After that the Projector should work correctly, but there is another issue coming from that :( Animations of Fire, Liquids, Portal and some another tile entities with animated block state WILL NOT WORK CORRECTLY such as IE Metal press, Stone cutter and other.

So, if u want Projector work correct u should try this, but u will break animations of blocks. Anyway if you want to play without any issues, just delete Rubidium and addon mods(Oculus, Rubidium Extra e.t.c) and play with OptiFine

P.S. The IE wires sometimes visually invisible, it's also caused by Rubidium

Thanks a lot for respond :) @unilock Try it also if u want to play with some new features in updated IE and IP

commented

I don't think this should be closed; downgrading a mod and entirely sacrificing animated textures isn't too good a solution imo. But it sounds like an upstream problem, and the IE developer has already deemed Rubidium support a "won't fix", so... :(
(note that using OptiFine isn't an option for me, due to it causing more issues than it would solve, in my case)

commented

Although this has been closed, I believe the issue has to do with Rubidium replacing the code that fires RenderLevelStageEvent events. You can see Immersive Petroleum relies on those events in the following locations:

public void renderLevelStage(RenderLevelStageEvent event){


public static void renderLevelStage(RenderLevelStageEvent event){

I had a similar issue with a mod I created which I solved by using mixins to call my render code directly (I didn't fire the events myself, because of possible compatibility issues) in lieu of the events and I have not noticed any particular issues. This would necessitate that Immersive Petroleum start using mixins however, something I'm not sure the devs want.

On the off chance that the devs want to use mixins for compatibilities sake, or even petition Rubidium to add Forge event calls, I found that Rubidium still calls chunk drawing in different passes similarly to the code that Forge fires events from as you can see in the following links:
Forge render passes

Rubidium render passes

Where I determined the correct place for a mixin was after this line:
Rubidium chunk render pass

In this situation, the BlockRenderPass parameter would need to be checked to see if it is equal to BlockRenderPass.TRIPWIRE for the sake of equivalency and then call the Immersive Petroleum functions I linked above in whatever way is deemed best.

commented

just to prevent further misconception, optifine currently shares the same fate as rubidium regarding compatibility and support

commented

I've bashed in my own mixin fix from own mod, and everything seems to work fine, so I would say what I mentioned above is indeed the issue. I'm using an extensive mod list that includes Rubidium and I still get a working projection. I've pushed the changes to a branch in a fork linked below.

https://github.com/littlej541/ImmersivePetroleum/tree/1.18.2-rubidium-projector-mixin-compat

Again, I don't know if the Immersive Petroleum team want mixins in the project, but I can submit a pull request if wanted.

commented

Sorry, I did not see the discussion on this issue until I had the Rubidium PR ready. Incompatibilities caused by Rubidium (and similar) not properly replicating Forge's API without good reason should be fixed in Rubidium. Mixins modifying other mods are nearly always a bad idea since they are very likely to break on any mod update.

commented

just to prevent further misconception, optifine currently shares the same fate as rubidium regarding compatibility and support

Optifine also working not good as expected, IE Engineers Workbench crashing game, when you trying to insert blueprint to it (OptiFine issue).
IMO Rubidium devs should look at this issue, but idk when it gonna be happen.

commented

@littlej541 Thanks a lot, I'm glad to see that the people using they programming skills to help other people. I'll check it soon and give you response. Thanks

commented

@littlej541 Thanks a lot, I'm glad to see that the people using they programming skills to help other people. I'll check it soon and give you response. Thanks

I am however not gonna accept that PR for the reason malte already mentioned.
Mixins modifying other mods are nearly always a bad idea since they are very likely to break on any mod update.

commented

Also just saying but this is only ever used by the debugger (and nobody should use it anyway)

commented

It's no biggie, I figured it wouldn't be. It was more of a proof of concept/personal fix. That's why I shared it here rather than making a pull request, on the off chance it was helpful somehow.

Hopefully the Rubidium PR gets merged since I also had the same issue in my own project. I even asked about it in the Reforged Hub discord about 4 months ago, but just impatiently hacked up my own fix several hours later since I wanted to add my mod to my own game as soon as possible lol.

commented

stale

commented

I think it's worth mentioning that this issue is not present with Embeddium, an alternative (better?) fork of Sodium for Forge. :)