Zone 351: Wall doesn't break

[chillywillysoft]

There's a walled off area with a crack in the wall that says, "The wall looks kind of weak here..." I used a Beamdrill on the wall and instead of opening the wall, it turned the Beamdrill into a Pile of Credits and also gave me a Power Terminal, even though I can still see a Power Terminal inside the walled off area.

[cyco]

Again, thanks for reporting. This is happening in zone 351.

[chillywillysoft]

Yes, that's the zone.

[chillywillysoft]

I don't really know my way around the codebase but I am looking around and I think the issue for the first two issues might be in lines 140-170 of file WebFun/src/engine/script/hotspot-processing-unit.ts which seems to simplify the logic of "trade" zones rather than follow the scripted actions. Let me know if I am overstepping and I will step out.

[cyco]

No no I think your spot on.

I tried to build a test case for this issue but I could not reproduce it on my end. The wall can be destroyed with all items and nothing drops. But I also have the issue that no item is placed in the walled-off area either. Maybe the simulator is a bit off here. I'll try to find a seed with this zone so I can test it in a real scenario.

I think the problem is in line

WebFun/src/engine/script/hotspot-processing-unit.ts

Line 163 in 59d3cf3

if (!unlockedHotspot) {

as you mentioned. During initialisation of the zone (src/engine/objects/zone.ts L115) one of the DropQuestItem hotspots is chosen and assigned the item you are supposed to receive. After that the item is placed on the zone and the hotspot is disabled. That's why

WebFun/src/engine/script/hotspot-processing-unit.ts

Line 160 in 59d3cf3

htsp => htsp.type === Hotspot.Type.DropQuestItem && htsp.enabled && htsp.arg === findItem.id

does not find any hotspots and the engine proceeds to drop the item right there where the lock is

WebFun/src/engine/script/hotspot-processing-unit.ts

Line 167 in 59d3cf3

engine.dropItem(findItem, point);

.

I don't know off the top of my head if the fallback in line 167 is actually needed. Maybe we can just remove that. If that does not work, we could add another check that looks for DropQuestItem hotspots that are on top of the provided item or something similar.

[chillywillysoft]

The hotspot processing is called from here

WebFun/src/engine/scenes/zone-scene.ts

Lines 381 to 392 in 59d3cf3

	const htspResult = this.engine.hpu.execute(HotspotExecutionMode.PlaceTile, location, tile);
	if (
	htspResult & HotspotExecutionResult.Speak ||
	htspResult & HotspotExecutionResult.ChangeZone ||
	htspResult & HotspotExecutionResult.Drop
	) {
	return ScriptResult.Void;
	}
	this.engine.spu.prepareExecution(EvaluationMode.PlaceItem, this.zone);
	return await this.engine.spu.run();

and depending on the result it may or may not run the PlaceItem action script. As you pointed out, the result depends on the presence and absence of certain hotspots.

I looked at several Trade Zones and although they all had correctly placed Lock Hotspots, they all had action scripts to handle a tile being place on the lock. This makes me think that not only should the action script be run before the hotspot processor, you might not need the hotspot processor at all for Lock Hotspots in Trade Zones.

But then it gets weirder. Although all the Trade Zones have at least one DropQuestItem Hotspot (either in the zone itself or its associated rooms) some of the zones manually drop item -1 in the scripts (like Zone 327) and some do not (like Zone 351). Perhaps when loading a room a scan of the actions could tell whether the item should be placed at a hotspot or will be done in script.

But to make it even weirder some have the DropQuestItem in an incorrect spot (like Room 4 part of Trade Zone 3), but I think you handle that correctly somehow because I think I remember the item dropping where I killed the monster behind the door. How are you handling that?