Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Research the changes made in RSW version 2.2 #22

Closed
Duckwhale opened this issue Jan 26, 2021 · 4 comments
Closed

Research the changes made in RSW version 2.2 #22

Duckwhale opened this issue Jan 26, 2021 · 4 comments

Comments

@Duckwhale
Copy link
Collaborator

Duckwhale commented Jan 26, 2021

Example: gefenia01.rsw (kRO latest)
GRF editor also fails to load it. Clearly something other than the as yet unknown water property must have changed.

Update: A more recent version of GRF Editor exists that does display them AFAIK, but I don't think it actually uses them.

@Duckwhale
Copy link
Collaborator Author

Duckwhale commented Jul 12, 2021

Multiple sources and my own investigation indicate they simply added two bytes in the file header, before the file paths (more details in my notes, need to review them). The real question is, what the hell are they used for? I read about one being a renderFlag of some sort, and the other appears to be unused/always zero.

Does anyone have more info on this? I wonder...

Edit: There's only one additional byte, so where does this info even come from?

@Duckwhale
Copy link
Collaborator Author

Duckwhale commented Jan 24, 2022

I've looked into this more as I was investigating the latest kRO changes, and the main difference I've seen in 2.2 maps compared to the old ones is that they all seem to use a fog effect of sorts. This is clearly something that would fit what information is otherwise stored in the RSW.
AFAIK this was hardcoded for maps like einbroch, so maybe they finally decided to move it to the RSW (where it arguably makes more sense and is easier to maintain)? The mention of a "render flag" would play into that theory.

Another piece of evidence that matches this theory is the fact that most maps seem to have set it to zero, meaning "no cloud/fog effect"? Need to compare the individual maps to see if this is true for all of them.

Edit: And it's present in many new maps, many more than previously used a similar effect... so maybe they wanted to use it extensively now and have therefore decided to put it here?

Another idea: If true, it should be possible to prompt the client to render this by changing the map files and test it with an emulator. Unlike the latest kRO changes, this is a faily old version and should already be supported by emulators, no?

@Duckwhale
Copy link
Collaborator Author

Duckwhale commented Jan 24, 2022

Example map: tur_d03_i.rsw

Like most maps, it seems to have a "render flag" of zero. If the above assumptions are correct, this would translate to a standard cloud effect (one can be seen in this video) that is also present on other maps, and not "no effect" - I've seen some kRO videos that feature it but I don't have the link. So if that is the "default" value, I guess many maps would share this effect, with others using different presets... But in that case, how does one disable the effect? Seems rather odd.

Looking at some other maps with a nonzero flag, things get more strange still:

  • bl_grass.rsw doesn't have a cloud effect at all (see this video), though it does have a "flag" of 22
  • bl_death.rsw uses a flag of 46 but it doesn't look like there's any cloudy effects (later in the same video)
  • bl_lava.rsw sets it to 76 and yet there is no visible effect (earlier in the same video)

Well, seems like a dead end. What else could it be?

Edit: Never mind, these aren't even 2.1. I checked again and I used the wrong offset, but even so the results are similarly inconclusive.

@Duckwhale
Copy link
Collaborator Author

Duckwhale commented Jan 28, 2022

All of the above was clearly nonsense. In reality, they added a "build number", as one byte directly after the version number, which appears to be used to interpret the GND water plane configuration... and possibly for other features, as well?

According to Balfear (in the BrowEdit Discord) changing it messes up the "water level" (Y-offset of the water plane), so I'm guessing they could be using it to swap between different features, similar to the version number... but why not just rely on the GND version?

We also know that changing it to a version that is too high will make the client raise an error, similar to the version itself.

Edit: That's why we even know it's called "build number":

image

Source: Balfear

@Duckwhale Duckwhale closed this as not planned Won't fix, can't repro, duplicate, stale Sep 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Timeline
Vague and distand future (Backlog)
Development

No branches or pull requests

1 participant