[BUG] Alter Hostile Rest Spawns chokes on BG:EE AR0608.ARE

[agris]

cdtweaks 16 win. when trying to install alter hostile rest spawns -> increase frequency by 50% (DESIGNATED 3196). Bug also occurs on double frequency, choking on same 2-byte read from the same .ARE

Maybe this belongs in Randomiser's forum, but I thought I'd start here.

ar0608.are SETUP-CDTWEAKS_debug.7z

[jmerry]

That's the upstairs area of the Flaming Fist HQ, and the issue is that it's completely missing the rest encounter element. The "rest encounters offset" is still there, but has an obvious invalid default value of 0.

And the mod already took that into account:

    READ_LONG rest_offr rest_off
	PATCH_IF rest_off BEGIN // in case area has no rest encounter section, skip attempted patching

That bit is there in the component's code; read the "rest encounters offset", and don't do anything if it's zero.

The version you've uploaded here is not the base version. It's still missing the rest encounter element and a couple others, but it has the offsets for those at "size of file" instead of 0. Trying to read at that location fails, producing the error you saw.

All right, what misguided mod edited this area before Tweaks got to it?

[agris]

@jmerry as you can see in the OP, a --change-log only shows randomizer touching it. should I be looking at the area's BCS or something else?

[jmerry]

... Ah. I think I see. Deleting and replacing items requires all the later offsets to be recalculated. The functions there must be recalculating the "rest encounters offset" to "after the items". Which is the end of the file. Oops.

This should be fixable on the cdtweaks end, by updating that sanity check I quoted above:

    READ_LONG rest_offr rest_off
	PATCH_IF (rest_off > 0) AND (rest_off < SOURCE_SIZE) BEGIN // in case area has no rest encounter section, skip attempted patching

 

[agris]

3 minutes ago, jmerry said:

... Ah. I think I see. Deleting and replacing items requires all the later offsets to be recalculated. The functions there must be recalculating the "rest encounters offset" to "after the items". Which is the end of the file. Oops.

This should be fixable on the cdtweaks end, by updating that sanity check I quoted above:

    READ_LONG rest_offr rest_off
	PATCH_IF (rest_off > 0) AND (rest_off < SOURCE_SIZE) BEGIN // in case area has no rest encounter section, skip attempted patching

 

 

42 minutes ago, jmerry said:

It's still missing the rest encounter element and a couple others, but it has the offsets for those at "size of file" instead of 0.

If I understand you correctly,

1) this fix you provided works around the .ARE being modified, but doesn't actually let cdtweaks impact the encounter rate? i.e. the component doesn't fall down, but for this one map it has no impact (which is fine).

2) from your most recent reply, it sounds like you *thought* the rest encounter element and "a couple others" were missing, but that was because you expected to find them at certain offsets and randomizer, by virtue of doing what it does, required the re-calculation of those offsets and thus the fields aren't where you (or cdtweaks) expects them.

[jmerry]

What encounter rate? That area has no rest encounters, hostile or otherwise. There's no probability to alter, so of course this component shouldn't do anything to it. All we need to do is stop it from choking by trying to read out of bounds.

The area file has fixed locations where it stores the offsets for area elements such as rest encounters. In the specific case of rest encounters, that location is at 0xc0 (in the v1.0 ARE format) and this area AR0608 has the value stored there equal to zero. The other "missing" elements I noted were automap notes and projectile traps, both of which don't exist on this map and have their offsets at zero. All three of these offset entries, stored at predictable places in the area file, get recalculated by the functions around adding/removing items and have their new values set to the file size.

That recalculation is something that could easily happen to other areas that get modified. The item randomiser didn't do anything wrong here. And that's why this needs to be fixed on the cdtweaks end. Areas that don't have rest encounters should be skipped, and that's indicated by either rest_off = 0 (in the base game files) or rest_off = SOURCE_SIZE (in some modified files). A simple update to the check for that, and we're set.

[agris]

For anyone else dealing with this, prior to Cam releasing an update, I've attached the fixed. tpa. Drop it in /lib/

 

 

rest_spawns.tpa

[jmerry]

I've just run into something similar with one of my own mod components breaking on a mod-added area that lacked a rest encounter table. A bad read, causing the component to error out.

It wasn't any of my own code that broke; it was when I used fj_are_structure to add stuff (spawn points). That function - built into WeiDU - has to recalculate offsets as part of its operation, and it apparently can't handle areas that lack the rest encounter table.

[agris]

@jmerry that sounds like an issue you should submit on weidu's github.

[jmerry]

On the subject of the broader issue involved - missing rest encounter tables causing errors - I've just posted a couple of macros to repair ARE files so it doesn't happen. https://www.gibberlings3.net/forums/topic/28835-toss-your-semi-useful-weidu-macros-here/?do=findComment&comment=322813

One patch macro to add an empty rest encounter table to an ARE file if it lacks that element, one action macro to add empty rest encounters to all ARE files that lack that element.