Sometimes the wrong cube map texture is used for the skybox for a moment

[smcameron]

It corrects quickly, but sometimes you'll see, say a planet texture used for the skybox texture.

I think it happens immediately after transiting a warp gate.

You can trigger it pretty reliably by the following procedure:

Start up snis_client, and choose the wrong star system (say, DEFAULT, when the correct one is ZOLON). It will dump you into DEFAULT, but then right away slam you into ZOLON, and there's a good chance the skybox will be the wrong texture for a moment.

What I think is happening is it loads all the textures for DEFAULT, texture_finished_loading[] is 1 for all the textures, then you slam into ZOLON, and it re-uses the textures, but there are only 4 threads to load them, maybe the skybox isn't among the first 4, but rather say, 4 big planet textures, so they take a moment to load, meanwhile the skybox is over there using the wrong texture, an old planet texture left over from DEFAULT.

Maybe the fix is to mark "expired" textures as not loaded.

Edit: marking expired textures as not loaded did not fix the problem, and introduced some other problems.

Maybe when you start off in the wrong solar system, it starts slamming you into the correct solar system before it has even finished loading the textures for the first one, but they are already queued up to be loaded, so they get loaded, but queued up behind them are requests to load the correct textures for the new solarsystem, so the wrong textures don't stick around very long.

[smcameron]

I tried the following (obviously wrong) experimental patch to snis_multiverse.c:

diff --git a/snis_multiverse.c b/snis_multiverse.c
index a15ae360..594208b0 100644
--- a/snis_multiverse.c
+++ b/snis_multiverse.c
@@ -995,6 +995,7 @@ static int verify_existence(struct starsystem_info *ss, int should_already_exist
                        if (strcmp(ship[i].starsystem_name, ss->starsystem_name) != 0 &&
                                verify_solarsystem) {
                                pass = SNISMV_VERIFICATION_RESPONSE_WRONG_SOLARSYSTEM;
+                               sleep(10); // allow client to finish loading textures
                        } else {
                                pass = SNISMV_VERIFICATION_RESPONSE_PASS;
                                bd = &ship[i].persistent_bridge_data;

which introduces a 10 second delay before multiverse sends notification to snis_server that the user is in the wrong solarsystem. This gives the client plenty of time to finish loading textures before switching to the new solarsystem.

The problem still persisted, so my theory that this problem is due to the client switching solarsystems before it was finished loading textures is disproven, or at least proven insufficient to completely account for the symptoms.

[Stigmate-Fr]

After about two hours without any problems, this bug appeared after a ticket-authorized warp jump to Karado. The “Main” station (SNIS client on the same device as the server and multiverse server) is affected by the bug. Turret, on a client connected to Wi-Fi, is not affected. But the skybox did not refresh, and after about 10 to 15 minutes, we simply jumped to another system. This isn't a real problem for us, but out of curiosity, do you know of a way to reload the skybox without disconnecting the client? (I vaguely remember a command to trigger the reloading of shaders. Will that help us next time?)

[smcameron]

There isn't a way to reload the textures other than disconnecting/reconnecting the client. Reloading shaders won't help with this problem either.

[Stigmate-Fr]

Ok, not a real problem. Thanks !