Airplanes of GAP don't show in the replay
Kepler-17c opened this issue ยท 8 comments
Airplanes added by https://www.curseforge.com/minecraft/mc-mods/golden-airport-pack-immersive-vehicles-content while playing, but don't show in the replay-viewer.
I don't know whether this is an issue with ReplayMod or GAP, so this is just to keep track of the issue.
Note for testing, that GAP requires ImmersiveVehicles and UNUParts (both linked on the CurseForge page linked above).
As the person who originally reported this issue, this is my exact issue. If you have any questions feel free to ask me
Potentially an Immersive Vehicle problem: DonBruce64/MinecraftTransportSimulator#990
They seem to have an idea (which I don't understand) of what causes it. so I'll wait until that's gone somewhere.
Duplicate of DonBruce64/MinecraftTransportSimulator#990
It's not a duplicate if it's on a different repo.. both issues should be kept open until it's fixed (or declared as wontfix), so people can find information about the current state by searching on either repo.
Agreed, and also this is likely my fault. In order to ensure that vehicles render outside of the camera fustrum I have an invisible entity that follows the player around and is always in their FOV. I'm assuming that ReplayMod uses a not-player for their camera, so the vehicles are invisible. That being said, the Forge-base RenderWorldLast event should still be firing and should still call my render code? Or does ReplayMod inhibit that event call during the replay?
The camera is actually a relatively normal player. The only special thing about it relevant to this issue is the fact that it doesn't have the same UUID as the recording player (cause the recording player is already there, the camera is meant to be a third party) and that it was not present on the server during recording (obviously).
From a quick look, it seems to me that MTS is spawning the follower entity on the server and attaches it to a specific player, and given the camera isn't present on the server, no follower entity is ever spawned for it, so this check (which is done right before rendering, so it applies to the RenderWorldLast path as well) can never pass in a replay:
if(Minecraft.getMinecraft().player.equals(builder.playerFollowing) && ...){My reply wasn't directed at you, it was directed at Don, who's the author of IM (btw, I've been wondering, Don, should I abbreviate the mod as IM or as MTS?).
And that means it should be fixable on BOTH SIDES either the replay mod detects GAP/IM and creates that follower for those mods or IM detects the replay mod and generates it a follower
Technically, I guess so, but one of those is clearly the more sane option. If you can't tell which one, then maybe don't comment on it.
IM wouldn't need to detect the RM, it would just need to detect the lack of an applicable follower, or spawn the follower on the client, or skip that check for the fallback path.
RM would need to detect IM, detect that it's implementation is still dependent on the follower system (cause that's not a standard Minecraft thing), detect that the issue is still present (otherwise stuff may render twice if it happens to be fixed in a future IM version), then somehow invoke a specific part of IM's code, and finally hope that that doesn't change in a future IM version because then we'll crash.
Can you remove the third-party-issue tag, this can be fixed by both mods, i think so anyway!
No, just because something is technically possible doesn't mean it should be done.
My reply wasn't directed at you, it was directed at Don, who's the author of IM (btw, I've been wondering, Don, should I abbreviate the mod as IM or as MTS?).
Heh, that's a fun one there. Code-wise it's still MTS as I never changed the mod ID. It's IV to the new folks. Mainly did that due to branding since Immersive Railroading hopped on that "Immersive" bandwagon and I didn't wanna eat the dust. Either or works for me.
Technically, I guess so, but one of those is clearly the more sane option. If you can't tell which one, then maybe don't comment on it. IM wouldn't need to detect the RM, it would just need to detect the lack of an applicable follower, or spawn the follower on the client, or skip that check for the fallback path. RM would need to detect IM, detect that it's implementation is still dependent on the follower system (cause that's not a standard Minecraft thing), detect that the issue is still present (otherwise stuff may render twice if it happens to be fixed in a future IM version), then somehow invoke a specific part of IM's code, and finally hope that that doesn't change in a future IM version because then we'll crash.
Ideally, I'd always spawn the follower on the client and never the server. But for some reason I've never had luck spawning entities on the client only, with the exception of particles, of course. Seems MC auto-culls things it knows shouldn't be there as there's an internal tracker or something that's seeing the fake-client-followers without a server entity and nips em. Lemme see what I can do though, as I don't particularly want render-making entities on the server. Will keep you posted.