1.09.4 talk:Red Volcano Zone Act 1
Unfinished...?
Er, what's missing in this article again? Nothing in here looks unfinished or short of info. ~ Blue Warrior 21:58, 21 September 2007 (PDT)
Read note 3, BZ.--Kaysakado 14:06, 24 September 2007 (PDT)
Question
Will RVZ be complete for SRB2 1.1? Thanks, WafflezHedgehog 15:04, 28 November 2007 (PST)
Yesh. ~Kaysakado • Talk 16:01, 28 November 2007 (PST)
Sweeeeeeeeeeeeet. WafflezHedgehog 17:26, 28 November 2007 (PST)
RVZ1 information
Just a bit of technical information that needs to be put out here to get rid of some misconceptions:
- Red Volcano's SECTORS and VERTEXES lumps are scrambled in soar.dta. (Contrary to what has been said in some other areas, none of the RVZ data is actually built in to the EXE.)
- There is an IF statement in P_SetupLevel that checks two things:
- That the current game map is 0x10 (Map 16, in other words)
- That "modifiedgame" is false.
- If both of those conditions pass, then the game proceeds to load two special functions to read the SECTORS and VERTEXES lumps in a different manner than usual (P_LoadDBGVertexes and P_LoadDBGSectors). If either one of them is not true, then it proceeds to load the map like any other map (P_LoadVertexes and P_LoadSectors).
- Because of the "modifiedgame" check, if cheat protection is enabled or a file is added in any way, the game will attempt to load MAP16 just like any other map, instead of unscrambling the data. This is why most people think that warping to MAP16 through console will crash the game. However, this isn't really true. Most people modify the game in some way so that they can use the command on the title screen, or in single player, or whatnot. Obviously, this makes the "modifiedgame" check fail, resulting in the game seeing a negative-height FOF from the scrambled SECTORS lump and crashing. Try starting a splitscreen coop game without adding any wads or using any cheats, and then type MAP MAP16. You should go straight to RVZ1, without any errors of any sort.
- Also, the "modifiedgame" check serves to prevent any maps added to MAP16 from getting un-scrambled when they're not scrambled to begin with (which would certainly screw things up). Therefore, the whole advice to avoid MAP16 when mapping is... kind of ironic.
- As for whether the crash is intentional... I can't honestly tell whether it is or not. It could go either way, really. (EDIT: AJ says it's unintentional.)
...phew, that's a lot of stuff. Anyways, I think that covers most things, so... MattW_CFItalk*contribs 19:26, 1 December 2008 (UTC)
Also, for the curious, this is what RVZ1 looks like if it's loaded up normally. Quite a mess, and quite hard to play (you die instantly on level start, you need GOD+NOCLIP to get anywhere). MattW_CFItalk*contribs 01:07, 2 December 2008 (UTC)
How did you get it to load like that?--Glaber 18:14, 18 March 2009 (UTC)
XSRB2 doesn't crash if it finds an upside-down FOF, it instead fixes it. Thus, RVZ1 as it is stored in soar.dta will actually load... albeit with a myriad of console errors and looking like it did above. This isn't really noticeable because XSRB2 has a "fixed" MAP16 included with it, but if you use addfile soar.dta to re-load the "unfixed" RVZ1 you can see it for yourself. MattW_CFItalk*contribs 19:19, 18 March 2009 (UTC)
To be a bit more specific, it's scrambled by saving the lumps as Short instead of Long. Or maybe the other way around. ~Kaysakado • Talk • 02:31, 1 April 2009 (UTC)
It's the other way around; what's supposed to be stored as a Short int is stored as a Long int. Close enough though. ;P MattW_CFItalk*contribs 03:26, 1 April 2009 (UTC)