Talk:L
S'orlok Reaves: Can someone please explain to me what "walking frame * 2" means? I thought that all NPCs just used a walkabout (first two frames for up, second two for right, etc.) If you can't be bothered to help me understand, can you at least tell me the range of this value (e.g., 0 to 4). Thanks for the help!
Bob the Hamster: That walking frame data does not really belong in the .L file at all. It is an artifact of the way walking frame state used to stored in memory at run-time. Much of my early code did dumb stuff like saving run-time-only data to disk.
The Mad Cacti: Well, it is used, isn't it? If you had a .L lump with random integers in that field, it might muck up when loaded. Anyway, temporary mapstate .L files use that field. But you can ignore it, set to 0.
Bob the Hamster 20:36, 8 February 2007 (PST): Are you certain that temporary mapstate uses that field? I enabled mapstate saving on a Wandering Hamster map, then added some debug statements to notify me when a non-zero NPC frame was found, and then I danced back and forth through a door over and over again. I never saw it being used.
S'orlok Reaves: Certainly, this discussion tells me exactly what I needed to know. It'll get nixed from the XRPG format, making maps load that much faster. Thanks for the help!
The Mad Cacti: Strange, the frame looks like its loaded and saved in loading.bas (maybe it's being zeroed out somewhere else), but if it's not being saved and loaded, then I would call that a bug.
Mike C.: If it's being saved and loaded in loading.bas, then it's because it was saved and loaded wherever that code was before I moved/rewrote it.
However, keep in mind that while Game may save and load those fields, it'll never persist past the game session, as the working folder gets wiped afterwards. Custom doesn't even use that loading routine, and probably just writes 0s.
The Mad Cacti: Replying to a long dead mystery, I'd like to point out that .L is not used to save temporary map state, so I'm guessing that James' frame checking code was probably placed so that it was never being run.
NeoTA (talk) : currently, I'd like to note the dubiousness of the following information:
INT * 300 x co-ordinate in tiles
INT * 300 y co-ordinate in tiles + 1
I presume X is supposed to match Y -- ie. be +1?
For now, I'll update it based on that idea.
The Mad Cacti (talk): The reason that the Y coordinate is off by one is that the file stores the position of the bottom left of the NPCs (ie. where they are standing) rather than the top left (not much of a reason, I don't know more than that). I wish James had as much counter-sense when adding the FOR lump (where it would have avoided a bug with spawning enemies)!
Bob the Hamster (talk): The real reason that Y values are +1 is even more embarrasing than you imagine. In the map editor, the top 20 pixels of the screen is for showing the currently selected map tile in tilemapping mode. This space is still blank in other modes like NPC placement. The map is displayed starting 1 tile lower on screen than it does when the map displays in game. This confused my young mind enough to cause the off-by-one error that persists in the npc location storage format.
The Mad Cacti (talk): Ah yes. Looking at the map editor code (a while back) I had actually suspected that that was the reason! There were other things which seemed to have been just editor quirks that were fossilised into the file format. BSAVE/BLOAD cause you to end up with file formats which you've not even thought about.