[GC4] KNOWN ISSUES with rendering and other minor issues

[radfast]

As we move closer to have a release-ready version for Galacticraft4, I am making this thread to put together all the minor issues which still need fixing.

(We don't want separate threads for each of these!)

UPDATED

Block Rendering

A. Some multiblocks with special renderers (for example AstroMinerBase) are rendered with the wrong block brightness

B. Fuel Loader, Launch Controller, Cargo Loader are missing their drawn "connection" to the Landing Pad

C. Vacuum Glass

• glass borders maybe don't line up perfectly if joining different shapes, e.g. 1 block high glass with 3 frame edges joining onto other glass
• some shapes missing the fill-in corners - e.g. make a cruciform shape, the centre pane needs 4 fill-in corners

D. Aluminium Wire

• the texture will sometimes seem to "rotate" by 90 degrees when connecting wires, if the connection causes a different blockstate model with a 90 degree rotation screenshots

E. Treasure chests: [1.10.2+ only] Item drawn with incorrect rotation, you can't see the golden latch

G. 1.8.9 only: mobspawners drawn in NEI cause all later items in NEI to have changing colours (probably not a GC issue, but check it isn't made worse by GC mobspawners or infinite battery, infinite oxygen, etc)

H. [Possible issue, can't reproduce?] Cryogenic Chamber inventory rendering (in hand) - strange missing block seen sometimes? See screenshot in #2548

HH. NASA workbench issue detailed here

Rocket Rendering

I. Tier 1 rocket in flight has a 4-5 degree tilt from vertical (wrong pitch) when rendered, although it flies straight - maybe the rumble is not symmetrical?

J. Player rendered inside rocket (in 3rd person view) has wrong yaw, for body and head

K. Rocket model briefly "flickering" / "ghosting" (not rendered) when crossing into new chunk above height y=256 - fly the rocket with tilt to see this. Also if you can make it fly vertically exactly on a chunk boundary, you can make this happen a lot from rumble. (Tracing shows the rocket is always added in the correct chunk on the client after world.updateEntity(). Therefore I think this is likely connected with the player entity and the rocket entity being temporarily in different chunks, and something related with the frustum check in RenderManager.)

L. Similar to K but worse - complete non-rendering of player and rocket - if you fly horizontally for a long time at high altitude, e.g. fly 500 blocks horizontally at an altitude of y==900

M. Some Z-fighting on Tier 1 rocket model, at the top

N. Some textures don't join properly on Tier 2 rocket model, at the top

T. We can lose the render of tall rockets, if the base of the rocket (and therefore the entity.posY) is in a lower sub-chunk (e.g. at y==63), and that lower sub-chunk is completely outside the frustum. see comment

• there may not be anything we can do about this, seems like this is in vanilla

Other

P. Display Screens - sometimes when a multi-screen display is broken, part of the on-screen image is still drawn outside the screen blocks (also an issue in 1.7.10?)

Q. NEI reports [Client thread/ERROR] [NotEnoughItems]: Missing container for galacticraftcore (and galacticraftplanets) - this is minor

R. Asteroids have no sky lighting (major long term issue!)

V. Vacuum Glass - 1.11.2 only - hitbox is wrong

Chunk update FPS problems

W. Chunk Update Flicker / FPS lag:

• severe when Painter used (updates all rendered chunks)
• minor when airlock opens or closes (updates around 1-4 chunks depending on size of airlock)

Other FPS issues (maybe only in development environment??)

Y. [1.10+] Severe drop in FPS when fighting the Creeper Boss

Z. [1.8.9] Place down a 3x3 Rocket Pad. Sometimes -> Massive fps decrease (e.g. 1-10fps instead of 60fps) whenever that Rocket Pad is inside the frustum. "Chunk updates" in F3 goes up to around 60 updates every tick instead of its normal average 0-3. Breaking the rocket pad fixes it. I've seen this a few times but can't figure out conditions to reproduce it. For example seen on Venus in an otherwise fairly clean rendering environment, only Venus rocks around, nothing not naturally spawning except the Rocket Pad. It's the full Rocket Pad which does it, placing individual Rocket Pad sections has no effect on FPS, the FPS problem starts immediately when 9 pads switch to being a full pad on the client. I also noticed that placing a rocket on the pad immediately improved it, though not fully.

[micdoodle8]

I'm not sure that (G) is fixable. After some investigation NEI spawners have OpenGL state problems which cause the world/items to render improperly. Since there is no active development of NEI for 1.8 this might have to be declared a "cantfix"

[EzerArch]

Since there is no active development of NEI for 1.8 this might have to be declared a "cantfix"

Needlessly to say, 1.8.9 is no longer the hotspot of the modding community -- it's now 1.10.2, where NEI is being maintained --, and was kinda "ew" for some developers (Carpenter's Blocks, MPS etc), especially concerning 3D model area.

As to (P), yes it's an issue in 1.7.10. Not much gamebreaking since I can just tear down the whole panel and reassemble it.

[radfast]

I'm not sure that (G) is fixable. After some investigation NEI spawners have OpenGL state problems which cause the world/items to render improperly. Since there is no active development of NEI for 1.8 this might have to be declared a "cantfix"

We have a powerful and flexible Class transformer :) Is it just a couple of OpenGL states which need fixing at the end of the NEI spawner renderer?

[SteveKunG]

(G) Lighting issue with spawner renderer should fix by replacing this code. But not 100% fixed. All of this OpenGL render are copied from GuiInventory#drawEntityOnScreen

https://pastebin.com/jFZD60ga

[radfast]

Is anyone else seeing the fps issues X, Y, Z ever?

I think it's possible they are threading or memory issues which occur only when I'm running Minecraft from inside my development environment, as there seems no good reason for them otherwise - Galacticraft is not doing any "heavy lifting" at these times. For example, I just got 2 fps when I spawned a vanilla spider in the Overworld. But then spawned 10 more spiders and had 60 fps?!

[SteveKunG]

Test with 1.8.9. Mod list (Dev workspace) : https://pastebin.com/HVy8YwEc @radfast Did you tested in 1.8 or 1.10+? Everything is work fine for me.

[radfast]

Yes it's working fine for me most of the time but sometimes spawning moving entities - rockets on launchpads, creeper boss, it can be anything really - makes an FPS problem. Seems worse in 1.10.2. Only noticed inside my IDE.

[EzerArch]

U. GuiSlimelingInventory causes brightening of the world and blocks seen in the background outside the GUI window, if viewed at night time. Guess it's an GLState issue... [edited: see video in #2662]

Wasn't it fixed? https://github.com/micdoodle8/Galacticraft/issues/2662#issuecomment-298414446

[radfast]

thank you :)

[radfast]

For the record, the previous listed issues which are now fixed were:

A. "Missing model" loading error for around 6 blocks or items - I think these are the DoubleSlabs

B. Missing breaking particle textures for many GC blocks

C. AstroMiner base (? and other multiblock models) sometimes drawn much too dark

D. Arc Lamp model does not rotate with a Standard Wrench

E. Arc Lamp lit section not drawn bright enough when dimension is dark (e.g. Venus underground)

G1. Aluminum Wire texture is 1024x1024 and some uv values are off by 1-2 pixels

I. Player doesn't always switch to 3P view when mount rocket [Tested thoroughly in SSP and SMP and Sponge server, I can't now reproduce this - radfast]

J. When rocket in flight, player's head is drawn in the wrong position in the HUD (left hand side)

K. Lunar lander - the model is not well lit, lander looks very dark when first arrive on the Moon (in 1.8.9 it stays unlit until it descends below y==256)

L. Player position inside lunar lander is sometimes incorrect (half body comes out of the top)

L1. Lunar lander flame drawn too high, overlaps with the lander [confirmed in 1.10+, not sure about 1.8]

M1. Playing on a server, noticeable lag / catch-up between rocket position server->client, worst right after launch. (I think this is the issue reported at #2523)

N. NASA workbench fake blocks can be broken by the player, and destroying a NASA workbench fails to remove all fake blocks (probably the same for other multiblock models)

O. Display Screen mapping is sometimes not generating a local map on server start [Probably fixed from build 64, needs testing] [Fixed from build 86]

U. GuiSlimelingInventory causes brightening of the world and blocks seen in the background outside the GUI window, if viewed at night time. Guess it's an GLState issue... [edited: see video in #2662]

X. Severe FPS drop / client TPS drop when ignite rocket on launchpad, due to smoke fx particle updates and a large number of smoke particles - worst for Tier 3 Rocket

[rashdanml]

In the interest of keeping things in one place: I can't seem to be able to craft an arc lamp at all. Using empty battery, desh, and glowstone, the arc lamp shows up in the crafting output, but can't retrieve it (shift click doesn't work either, it returns the items to me).

GalacticraftCore-1.10.2-4.0.0.111 Galacticraft-Planets-1.10.2-4.0.0.111 MicdoodleCore-1.10.2-4.0.0.111

Forge: 12.18.3.2297

[radfast]

Hey @rashdanml, thanks for reporting.

The Arc Lamp recipe needs a full battery.

In build 112 and before there's a bug where, if you look at the Arc Lamp recipe in JEI and move your mouse over the battery to get the item information, it changes the battery from full to empty and then the recipe is "stuck" with an empty battery, until you restart your game.

The bug is fixed in latest build 114.

[rashdanml]

I see. Thanks!

The arc lamp showed up as invisible when using a full battery, so I thought it wouldn't work. I'll have the server updated regardless.

[SteveKunG]

1.10+ Missing sound for Deconstructor. [21:58:23] [Client thread/WARN]: Missing sound for event: galacticraftcore:block.deconstructor

[radfast]

The Deconstructor sound is fixed by https://github.com/micdoodle8/Galacticraft/commit/cac2fbe44aaeb2d8871819df1f412ce4f79746ae

[SteveKunG]

Issue E. have been fixed.

[MJRLegends]

Issue R: Fixed by https://github.com/micdoodle8/Galacticraft/commit/a154c7ada82fcf1ae85a8a5b8d8d1e8254779cdb ? maybe?

[radfast]

Issue R - no, sadly not fixed by that!!! That is a sky background fix.

The Asteroids problem is that the vanilla Minecraft lighting engine has huge problems (is super slow and laggy) in the Asteroids dimension because of the large areas of empty space below each asteroid. The vanilla game lighting engine -

• involves a full re-check of both Block Light and Sky Light when any block changes (for example "maybe" that was the block which opened up a light shaft so the sun can shine into an underground cavern)
• is not optimised for performance
• has never been good for areas below "overhangs"
• becomes very slow for underground caverns.

Unfortunately, for the vanilla lighting engine, the Asteroids dimension is basically a dimension filled with caverns and overhangs - the underside of each asteroid is like an overhang, and all the space below each Asteroid seems like a large cavern.

To overcome these problems we currently have switched off all Skylighting in the Asteroids dimension. Instead, the asteroids are lit from the "sunny" side by Blocklighting. This is achieved by the worldgen generating some fake illumination blocks on the sunny side - they are similar to the blocks which the Arc Lamp generates. So if you build a huge structure on the sunny side of an asteroid, then destroy the structure, you will have lost all the sunlight on that particular asteroid. There are also other small issues - an asteroid lighting is incomplete (it may not be fully lit) until the player goes there and starts doing stuff, that's connected with the way that the game re-checks block light for blocks close to the player at random tick intervals.

A proper solution needs a re-write of the vanilla lighting engine. That's possible, but it's not a small task ... A really good solution would involve: different lighting for the Moon and other airless dimensions (it would be great to have sharp shadows); respect for the astronomical position of the sun. Maybe also a fix for the bugs in the vanilla lighting engine, just to show off :)

Example of what we can do. Arc Lamps impose a huge demand on the block lighting in the vanilla game engine when they switch on or off, because it's like placing or destroying 100+ glowstone blocks simultaneously. To overcome the lag issues, I rewrote the vanilla block lighting engine optimised for performance. In my timed tests, performance of my code is 2x vanilla for single block lighting changes, and 10x vanilla for a massed group of block lighting changes all in the same tick. So it's great for the Arc Lamps.

This optimised code is only for the Arc Lamp. I have not attempted to reverse-engineer it into the vanilla lighting engine overall, because that would potentially cause incompatibility with any other mod which interacts with the vanilla lighting engine, and I don't feel like spending a month dealing with issues caused by that. Although it would be somewhat cool to have a situation where installing Galacticraft improves your server performance.

[radfast]

New one: NASA workbench has some texture uv errors (coordinates reversed giving diagonals?)

(The right hand step on Moon Buggy also has this.)

[SteveKunG]

Good news! Entity rendering outside the world have been fixed by https://github.com/MinecraftForge/MinecraftForge/pull/4823

[radfast]

Thanks @SteveKunG it will be interesting to see whether this fixes all the small rendering issues.

[Romsik788]

The news is very pleasing. Now there is no longer a problem that was in #3232

[radfast]

@Romsik788 the Forge update affects entities above y=256 only, I think. I had already mostly compensated for that vanilla bug, but with some flickering as in issues K and L here.

[Romsik788]

Issue - T it's vanilla bug. MC-88176