Hello,

as soon as I sit in any vehicle, my console gets spammed with OpenGL errors:
[11:08:48] [Client thread/ERROR] [net.optifine.shaders.SMCLog]: [Shaders] OpenGL error: 1283 (Stack overflow), program: shadow, at: pre-useProgram
Roughly 150 errors per second are getting generated. Besides of this, there are no mechanical or visual interferences that I could notice. I want to explicitly state that I'm using this mod together with a bunch of other mods, but I more likely expect it to be an interference with Optifine or my shaderpack. Turning the shader off solves the issue.

Here are some informations:

• Minecraft 12.2.2
• Forge 2814
• Latest Immersive Vehicles release from 05/02/19 (v13)
• Latest Official Vehicle Set release from 05/02/19 (v09)
• Optifine 1.12.2 HD_U_E3
• Continuum shader 2.0.2

Perhaps I'm doing something Optifine doesn't like. To narrow down where the issue might be:

Does this issue occur in both first-person and third-person modes?
Does it occur if you have F1 pressed to disable the HUD?
Does it happen in a vehicle with no instruments?

I did some more testing, here are my results:

• It's independant of the shaderpack that I'm using. I tested it with SEUS and have the same issue
• It also seems to be independant from the instruments or HUD. Disabling any of them or both does not help
• It occurs in first- and third-person mode

The only other thing I can ask you to try is fly a plane to about Y=300, or at least above the world height. Some special code runs there that might narrow-down the issue.

Once you do that, here's a test build. It basically cycles through the entire rendering sequence, cutting out each step one by one. I would assume that at first you won't have anything rendered, but you also won't have the error. Eventually, something should snag and give you fits and GL should start spamming your console.
Immersive Vehicles-1.12.2-13.1.0.zip

I did your testing suggestions, now here you have a huge log file with a bunch of entries - have fun analysing it ;-) First thing I noticed was that the textures of the plane are missing, opping up occasionally. That made it hard to enter the plane, but I guess this was for you're testing purposes. I climbed to above 300 and flew there for a bit. To find the right time period in the log file, you can search for "height reached", which I typed into the chat.
Thanks for your effort. I really appreciate your fast actions.

log_file.zip

That's.... a lot of log. Yes, I did make the textures go away. The idea was to skip parts of the rendering to figure out which render bit is causing issues. Your text dump there showed me something odd, however. Mainly that if I skip nearly everything in the rendering, I still see the GL error that Optifine is throwing. It appears the height does not affect this either, so that's something interesting.

Let's try this: I'm going to send another test unit that will cycle the rendering off after 10 seconds. If you could, set yourself next to a seat, but don't enter the seat until the vehicle disappears (you might have to create the vehicle without this version, and then load the world). Once it does, enter the seat (it'll just be invisible). If at this point we see the same issue, I can rule out the rendering of vehicles while seated, which is a HUGE section of code to avoid.

Immersive Vehicles-1.12.2-13.1.0.zip

Indeed, the same issue even without any textures. Again independant from the HUD or panel beeing visible or not.
Funny side note: Once I entered the world (prior created a fresh map in the regular version and spawned a plane), I encountered #93. So I hopped into the plane after it disappeared to test the OpenGL error and slowely slided away with it... Definitely no parking brake was engaged in this scenario and this time I slided lateral to the right.

Well, that rules out vehicle rendering there. I can also rule out the custom zoom camera, as that's only active in third-person, which would mean you wouldn't have the issue in first-person. As well as the roll operations that make the screen roll in first-person, as those aren't active in third-person. Plus I can rule out the HUD due to F1 not making a difference.

The only other thing I can think of is the player rendering tweaks I do to make the player pitch and yaw in their seat. To test this, I'm posting a version with this code disabled. Hopefully we get it pegged down in this one.
Immersive Vehicles-1.12.2-13.1.0.zip

Well, I can only say you that it seems that we achieved at least a partial success. The error does not occur in your test build.

Just had an idea today about what might be the source of the issue. Got another test build for logs, but be warned that it's rather log-heavy, so I wouldn't recommend playing a long time. Should be enough to start getting the OpenGL errors once you get in a vehicle, however.
Immersive Vehicles-1.12.2-13.1.0.zip

I didn't had time to test it until now. Here is a small log file of a quick flight.
log_file.zip

AHA! Now this tells me something! Looked in your log and found that the code for the pre-render is being called twice, and the post-render is only being called once. That explains why you're getting an overflow and there's lingering rotations: the rotation code is being started twice, but only being ended once.

[11:10:04] [Client thread/ERROR] [mts]: RENDER PRE
[11:10:04] [Client thread/ERROR] [mts]: RENDER PRE
[11:10:04] [Client thread/ERROR] [mts]: RENDER POST
[11:10:04] [Client thread/ERROR] [net.optifine.shaders.SMCLog]: [Shaders] OpenGL error: 1283 (Stack overflow), program: shadow, at: pre-useProgram

This is good data. I should be able to track down the source of the issue with this.

Went to check the stock pre-post cycle and can confirm that I get one PRE and one POST each render. Not sure why Optifine is calling two PREs. I was going to check their source code to see if I could find out why and allow for it, but Optifine is closed-source.

However, it could very well be a shaders issue. Could you try another shader or two and see if this issue still happens? While debugging a closed-source mod like Optifine is hard, debugging a possibly open-source shaders bolt-on is far easier.

Besides the Continuum 2.0.2 shader that I'm normally using, I've also tested SEUS Renewed 1.0.0 and Sildurs Vibrant Shaders v1.18 High and every single one creates the issue with OpenGL, so I guess it's more related to the way Optifine integrates the shader mechanics than to the shaders themselve. It is only not happening with Optifine's "internal shader", if that can be considered a shader at all...

So I myself went and tried using the exact same version of Optifine and Continuum shaders and could not re-produce this issue. That being said, my version of Forge was a bit different, but I fail to see how Forge would affect shaders.

Could you try running your instance without any other mods installed besides MTS and Optifine? Starting to wonder if one of those is causing the issue.

Also talked with the people on Discord. None of them have had the same error with any shaders, which also makes me think that this might be related to another mod not calling events correctly.

I understand. At a minimum, if the issue persists with only Optifine, MTS, and Shaders then we at least know it has to be in that set. If it doesn't, then for sure that could be a longer process. Still, I'd rather fix this or at least note the incompatibility than ignore it.

Interesting, I'll test that soon, but this may end up in a lot of work to subsequently add mods and start minecraft to check for the error. I have a lot to do currently so it might take a few more days.

First of all, the issue does not occur with just Optifine, your mod and a shader, as you discovered already. So I tried to subsequently add mods to the directory and I started with the ones I assume to add or modify some sort of animation. It ended up to be related to "Mo' Bends Mod", which makes a lot of sense. This mod replaces player and animal animations to make them more "realistic" and I guess this messes up with your modification of the player animation as long as you sit in a plane.
To make it a bit more confusing, I was able to get the OpenGL errors with no shaders active, even though less frequently than with shaders. Also, the relation to #103 confuses me a lot, because as you assessed it definitely seems to be related to the OpenGL errors, but it is not solely related to Mo' Bends mod. While I get the OpenGL errors (less frequent) without the shader, I don't see creatures roll and pitch. That behavior first starts in combination with a shader active.
This bug report took an interesting turn and I want to say sorry for pointing into the wrong direction in a first place. But it was so likely to be related with the shader because of the way and frequency the issue occured and also because it was an OpenGL error. Testing without a shader takes more time to generate an OpenGL error on the ingame console as you will see if you test it, so I might just cancelled the tests without the shader active too fast.

Went and submitted a bug report on the Mo Bends mod GitHub. Hopefully we can get together and get this resolved. For the moment, however, I'm going to apply the notmyproblem label as it's a single mod that causes the issue, and doesn't appear to be related to the normal operation of MTS. More than willing to re-evaluate this once I get in contact with the Mo Bends team.

@Einsiedler98 Just got a response from the MoBends author. He suspects it might be due to how MoBends does rendering in his latest release. He has a test build on his Discord, so if you have the chance to test it out on your build and see if the problem persists that would give us both some good feedback. Here's a link to the issue: mobends/MoBends#55

I got in contact with the author of Mo' Bends and he gave me his latest test version where he implemented the changes to the he stated at the bug report on his page. With this new version, I'm not able to reproduce the issue again! I don't know what you would suggest to do now but I guess you can either add an incompatability hint to your mod as long as the new Mo'Bends release isn't out or you - and that would be a quick fix - add a config file setting to disable your rendering as you did it in the test version you gave me a few days ago.

Great to hear that we've got the issue figured out. I suspect that the development time won't be too long for MoBends, so I'd hesitate to add a config that will need to be removed in short order. Not to mention I'm in the middle of a major feature addition, so I can't really do changes right now. I think I'll just leave this issue open and re-direct users here for the test build if they really want it, and once the new MoBends drops I'll close this issue out.

So it appears that MoBends has finally dropped a new version. Last I checked, this was fixed in the test version, so can anyone confirm if this is fixed in the latest release?

Confirmed closed with newest version of MoBends. Closing my ticket, even if they haven't closed theirs.