Pocket Plane Group

Friends and Neighbors => Weimer Republic (WeiDU.org) => WeiDU => Topic started by: DavidW on August 15, 2019, 02:41:40 AM

Title: Bug in CREATE for ARE
Post by: DavidW on August 15, 2019, 02:41:40 AM
The CREATE function, used to create an area, doesn't set the mapnote offset: it's set to 0.
Title: Re: Bug in CREATE for ARE
Post by: Wisp on August 16, 2019, 12:51:17 PM
This is actually "correct", in the sense it's what you find in the wild. As recently as Beamdog-created AREs, if some feature exists, the offset is non-zero, otherwise it's zero (at least those that are not dangerously bugged, with offsets that point into other structures). Automap notes is one which behaves this way, projectile traps, rest encounters and songs are others.

However, I recognise it's a fun time when patching files and perhaps it should be reconsidered. But this is something one would need to be aware of when working with vanilla files, as well, so perhaps it's also something patching code should account for. I can find at least one ARE with zero features but a valid non-zero feature offset. I'll have CREATE emit something similar.
Title: Re: Bug in CREATE for ARE
Post by: DavidW on August 16, 2019, 05:32:10 PM
That's something I didn't know.

Looking at vanilla BG2, you're dead right: there are 309 areas with a zero value of map offset, and no areas with a nonzero value but no map notes.

On BG2EE, on the other hand, there are only 40 areas with a zero value of map offset, 21 of which are OHxxxx areas. Conversely, there are 286 ARxxxx areas with zero features but valid offsets. At a guess, Cam or someone ran general patching code but forgot to tell Beamdog's own area designers! (I assume the other 2 areas in vanilla BG2 with zero map notes had some added in the EE.)

Since both conventions are present in game, and since the zero-value one is much less helpful, I agree that it would be good for CREATE to go with the valid-value convention. In general I 100% support your approach to backwards compatibility, but in this case, CREATE are is a sufficiently niche thing to do, and the scenario where bugs could be introduced is so baroque in any case, that you might as well just change it.

(Speaking of niche things to do, I worked up the WEIDU code to create a blank wed file, which CREATE can't do natively. You're welcome to it if you want it - though realistically the use case is so tiny that it might not be worth your time.)
Title: Re: Bug in CREATE for ARE
Post by: Wisp on August 16, 2019, 08:23:14 PM
(Speaking of niche things to do, I worked up the WEIDU code to create a blank wed file, which CREATE can't do natively. You're welcome to it if you want it - though realistically the use case is so tiny that it might not be worth your time.)
I'd be happy to take a look.
Title: Re: Bug in CREATE for ARE
Post by: DavidW on August 19, 2019, 12:02:32 PM
I suppose that come to think of it, a WED file arguably isn't well-defined unless it has specified nonzero width/height, so this doesn't really fit the CREATE paradigm; still, fwiw:

Code: [Select]
DEFINE_ACTION_FUNCTION build_wed
    INT_VAR width=0
            height=0
    STR_VAR tis=""
            wed=""
BEGIN
    COPY ".../stratagems-inline/blank" "override/%wed%.wed"
       // make sure it starts empty
       DELETE_BYTES 0x0 BUFFER_LENGTH
       INSERT_BYTES 0x0 0x20 // header
       WRITE_ASCII 0x0 "WED V1.3"
       WRITE_LONG 0x8 5 // # overlays
       WRITE_LONG 0x10 0x20 // overlay offset
       // insert first overlay
       INSERT_BYTES 0x20 0x18
       WRITE_SHORT 0x20 width
       WRITE_SHORT 0x22 height
       WRITE_ASCII 0x24 "%tis%" (8)
       INSERT_BYTES 0x38 0x60 // other overlays
       SET sec_header_off=0x98
       WRITE_LONG 0x14 sec_header_off
       INSERT_BYTES sec_header_off 0x14
       SET door_off=sec_header_off+0x14
       WRITE_LONG 0x18 door_off
       SET main_tilemap_off=door_off
       WRITE_LONG 0x30 main_tilemap_off
       FOR (i=0;i<width*height;i+=1) BEGIN
          SET this_tile_off=main_tilemap_off + 0xa * i
          INSERT_BYTES this_tile_off 0xa
          WRITE_SHORT this_tile_off i
          WRITE_SHORT (this_tile_off + 2) 1
          WRITE_SHORT (this_tile_off + 4) "-1"
       END
       SET other_tilemap_off=main_tilemap_off + width*height*0xa
       WRITE_LONG 0x48 other_tilemap_off
       WRITE_LONG 0x60 other_tilemap_off
       WRITE_LONG 0x78 other_tilemap_off
       WRITE_LONG 0x90 other_tilemap_off
       SET door_tile_ind_off=other_tilemap_off
       WRITE_LONG 0x1c door_tile_ind_off
       SET tile_lookup_off=door_tile_ind_off
       WRITE_LONG 0x34 tile_lookup_off
       FOR (i=0;i<width*height;i+=1) BEGIN
          SET this_off=tile_lookup_off + 0x2*i
          INSERT_BYTES this_off 2
          WRITE_SHORT this_off i
       END
       SET sec_tile_lookup_off=tile_lookup_off + 2 * width * height
       WRITE_LONG 0x4c other_tilemap_off
       WRITE_LONG 0x64 other_tilemap_off
       WRITE_LONG 0x7c other_tilemap_off
       WRITE_LONG 0x94 other_tilemap_off
       // find # wallgroups
       SET num_wallgroups = (width / 10) * ( (2* height) / 15)
       SET wallgroup_off=sec_tile_lookup_off
       WRITE_LONG 0xa4 wallgroup_off
       INSERT_BYTES wallgroup_off (0x4 * num_wallgroups)
       SET polygon_off = wallgroup_off + (0x4 * num_wallgroups)
       WRITE_LONG 0x9c polygon_off
       SET polygon_ind_off=polygon_off
       WRITE_LONG 0xa8 polygon_ind_off
       SET vertex_off=polygon_ind_off
       WRITE_LONG 0xa0 vertex_off
END
Title: Re: Bug in CREATE for ARE
Post by: Wisp on August 30, 2019, 02:13:32 PM
No, it does not look like a good fit for CREATE as it currently works.