So I was just running through what I hope is going to be Eternal X 1.1b5 and soon thereafter final, and I got to level 13 (counting from zero), "Unlucky For Some"... and what's supposed to be a term pict appeared like it was a chapter screen, before the level loaded. This was using Aleph One 1.2, which is the first version I've playtested thoroughly on since the #STATIC bug in AO 1.1 prevented playing past the first level of Eternal versions past 1.1b3.
I tried stock EX 1.1b4 on AO 1.2 and got the same behavior. I checked back in AO 1.1 skipping to that level in particular and got the same behavior. It went away when I went all the way back to AO 1.0.2.
I checked a suspicion and sure enough, the terminal pict ID ends with "1513", but it's NOT the usual 11513 that one would use for a chapter screen for level 13. It's just 01513. That's the only 015xx numbered terminal pict I've got in there, as (some of) my term picts are numbered 01XXY (where XX is level on which that pict appears and Y is just a sequential number), and 01513 is the only remaining pict from the last level (51), though there used to to be others (hence the 3). (Term picts that get reused across many levels are instead numbered 00XXY, where XX is an arbitrary number assigned to the character associated with those picts, and Y is just a sequential number).
I suspect that this was an accidental change in behavior that happened somewhere between 1.0.2. and 1.1. I'm not sure if any other scenarios happen to have term picts numbered 015xx that aren't intended to be chapter screens, but Eternal always has and the engine's never treated them like chapter screens, so this probably constitutes a bug in AO? Can anyone reproduce?
Change in chapter screen behavior?
Historically, the chapter PICT numbers have been 015xx for 8-bit, 115xx for 16-bit, 215xx for 32-bit. Take a look at Infinity, for example: it has 015xx and 115xx copies. The terminal picts follow the same pattern, with a three- or four-digit base ID, and base+10000 or base+20000 for higher-quality versions.
The PICT lookup got rewritten in 1.1 to handle Marathon 1 images, so it's reasonable something changed then, but I'm pretty sure the current behavior was always the intended one: it tries the number for the current screen depth and then falls back until it finds a picture or exhausts the possibilities.
The PICT lookup got rewritten in 1.1 to handle Marathon 1 images, so it's reasonable something changed then, but I'm pretty sure the current behavior was always the intended one: it tries the number for the current screen depth and then falls back until it finds a picture or exhausts the possibilities.
For reference, here are the special numbers, straight from the M2 source code. 15xx and 16xx are used in the Map file, the rest are used in the Images file.
Code: Select all
/* -------- this contains the ids for the 8 bit picts */
/* the 16 bit versions are these ids + 10000 */
/* the 32 bit versions are these ids + 20000 */
enum {
INTRO_SCREEN_BASE= 1000,
MAIN_MENU_BASE= 1100,
PROLOGUE_SCREEN_BASE= 1200,
EPILOGUE_SCREEN_BASE= 1300,
CREDIT_SCREEN_BASE= 1400,
CHAPTER_SCREEN_BASE= 1500,
COMPUTER_INTERFACE_BASE= 1600,
INTERFACE_PANEL_BASE= 1700,
FINAL_SCREEN_BASE= 1800
};
Ok, thanks for checkinig that. So I guess it was old versions of AO that were incorrectly not displaying that term pict as a chapter screen. I'll change it on my end for the upcoming EX1.1 release.
Can you please confirm that, if I understand correctly, changing my term pict numbering scheme to "10XXY" instead of "01XXY" should avoid any collision with special numbers? Or in general, so long as the thousands place is a zero, that should avoid collision?
EDIT: As it turns out, that term pict isn't even used anymore, so I'll just get rid of it instead of changing the numbering of every term pict in the entire scenario...
Can you please confirm that, if I understand correctly, changing my term pict numbering scheme to "10XXY" instead of "01XXY" should avoid any collision with special numbers? Or in general, so long as the thousands place is a zero, that should avoid collision?
EDIT: As it turns out, that term pict isn't even used anymore, so I'll just get rid of it instead of changing the numbering of every term pict in the entire scenario...
Yeah, the old versions must have been buggy. I took a glance at the 1.0.2 code, but it wasn't immediately obvious where it was going wrong. It certainly had code to do the fall-back.
To the best of my understanding, you should be safe with a thousands digit of 0 or 2-9 (unless you do something really strange, like making a map with hundreds of levels). In normal usage, only x15xx and x16xx need to be avoided. Of course, there may be other bugs lurking, but I don't see any intended behavior outside those ranges.
The ten-thousands digit can be 0 or 1 with no practical difference. 8-bit mode is no longer supported, so Aleph One will always start looking at either 2 or 1, and count down to 0.
To the best of my understanding, you should be safe with a thousands digit of 0 or 2-9 (unless you do something really strange, like making a map with hundreds of levels). In normal usage, only x15xx and x16xx need to be avoided. Of course, there may be other bugs lurking, but I don't see any intended behavior outside those ranges.
The ten-thousands digit can be 0 or 1 with no practical difference. 8-bit mode is no longer supported, so Aleph One will always start looking at either 2 or 1, and count down to 0.