Recent Posts

Pages: [1] 2 3 ... 10
1
Quest Pack / Re: bug with revisited hell trials
« Last post by Wisp on August 24, 2019, 07:12:51 PM »
Is this a reproducible bug? The post-fight dialogue leads back to the same state ("The Tear of Bhaal is yours, Child.") which awards the tear on either of the vanilla paths, so I shouldn't think QP's path would behave any differently.
2
BG1 Unfinished Business / Readme Item Discrepancies
« Last post by RobinHood70 on August 21, 2019, 08:13:59 PM »
I've just been reviewing the readme vs. the actual Weidu files for new/changed items, and I've noted a couple of minor discrepancies in the documentation that should probably be updated:
  • Girdles are incompletely documented in the version history, and not at all in the items added/item locations sections.
  • Oddly, a Ghost Knight in Firewine Ruins has the Longbow of Marksmanship +2 replaced with a Longbow +1. Hakt has one which isn't replaced, so I assume the item works correctly. The change and the reason for it are not documented at all.
  • Bracers are documented as being in one of the many "General Store"s, but not which specific ones (Baldur's Gate SE and SW).
3
BG1 Unfinished Business / Charm dialogues
« Last post by RobinHood70 on August 21, 2019, 06:31:35 PM »
I'm noticing a few dialogue files in BGEE that check for a charmed state, but these lines are often precluded/rendered unlikely by checks above them (e.g., BEGGBA.DLG, MTBE7.DLG), or where the higher-ranked reactions aren't consistent with a lower-ranked charm check (e.g., MTOB5.DLG). Do you want these reported to you as I find them? Or have they already been noticed and it's been decided to leave them as is?
4
WeiDU / --list-components-json fails when there is no @xxx reference inside .tra file
« Last post by AL|EN on August 20, 2019, 01:29:54 PM »
Hi,

--list-components-json fails when there is no @xxx reference inside .tra file

Code: [Select]
RROR: No translation provided for @623
FATAL ERROR: Not_found
on the other hand, --list-components replace missing string with 'UNDEFINED STRING:   @xxx' and return the data.
5
WeiDU / Re: Bug in CREATE for ARE
« Last 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
6
WeiDU / Re: Bug in CREATE for ARE
« Last post by Wisp on August 16, 2019, 08:23:14 PM »
Quote from: DavidW on August 16, 2019, 05:32:10 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.
7
WeiDU / Re: Bug in CREATE for ARE
« Last 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.)
8
WeiDU / Re: error installing >256 kits
« Last post by Wisp on August 16, 2019, 01:05:01 PM »
My plan has been to implement the ADD_KIT portion of the process into fl#add_kit_ee, include that by some other name into WeiDU proper and effectively deprecate the ADD_KIT action. The function could then have an option for performing the safety-check or not, but maybe your option 2 is less likely to languish indefinitely.
9
WeiDU / Re: Bug in CREATE for ARE
« Last 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.
10
WeiDU / Bug in CREATE for ARE
« Last 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.
Pages: [1] 2 3 ... 10