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

Figure out meaning of level chunk L45 (level variables) #10

Open
dertseha opened this issue May 14, 2015 · 7 comments
Open

Figure out meaning of level chunk L45 (level variables) #10

dertseha opened this issue May 14, 2015 · 7 comments

Comments

@dertseha
Copy link
Member

Determine the meaning of level chunk L45.

@dertseha
Copy link
Member Author

The chunks that I so far checked always contain 94 bytes and the content is similar between levels.
There seems to be some recurring information, though I couldn't pinpoint the proper lengths of the entries so far.

The chunk appears to start with an int32 value that has the same value as the length of the block (0x0000005E).

@dertseha
Copy link
Member Author

This chunk appears to contain what I call now "level variables". I first thought of "environmental variables" as I could identify the rad/bio hazard and gravity values. Since changing the remaining values did not show any immediate effect, I suspect these are some level/game values, to be handled by triggers.

dertseha added a commit that referenced this issue May 23, 2015
@dertseha dertseha changed the title Figure out meaning of level chunk L45 Figure out meaning of level chunk L45 (level variables) May 23, 2015
dertseha added a commit that referenced this issue May 6, 2017
@dertseha
Copy link
Member Author

dertseha commented May 6, 2017

There is indeed a repeating information; From offset 000D there are three 27 byte entries.

These three entries are almost identical across all levels. Only differences: level 1 has a few bytes different, as well as level 9. The second entry is always all bytes zero. The third entry always equals the first, with the exception of its second byte. (first is always 0x03, third is always 0x02)

Now I have even less of an idea what these entries could mean.

Some values "could" be tile coordinates, with the exception of level 1 pointing to the center (tile 31, fine 128) - no it's not the new-game-spawn-point. Other values appear to be common video resolutions (320x200), again with exception of level 1.

Since so far construct levels (which have all these bytes zero) work just as fine, I'll leave these as a curiosity.

@dertseha
Copy link
Member Author

dertseha commented May 6, 2017

Also: radiation and bio contamination register fields were mixed up. Fixed.

@dertseha
Copy link
Member Author

dertseha commented May 6, 2017

Another idea I had was that this level chunk is not about level variables in general, but only the hazards. And the three entries describe detail properties of the hazards (with a third hazard not realized). Crazy idea: describing the (visual) effects.
I tried a few modifications (including a rainbow test of setting all values to 0x7F or 0xFF) - with no difference.

@dertseha
Copy link
Member Author

dertseha commented Apr 8, 2018

This structure is based on LevelData (lvldata.h).

I'm inclined to keep the name "Level Variables" for this one - is a close synonym for it.

@dertseha
Copy link
Member Author

dertseha commented Apr 9, 2018

Ok, documented stuff out of the auto-mapper.
Though, I suspect the information is only a placeholder for current state data and it is always re-initialized with each level transition. It should be, because hacker can return to the same level with newer hardware...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant