Numerous bugs in single-player levels + 2 minor graphical things

[biggnome]

I was revisiting Avara over the weekend (looking great, by the way!) but I've noticed with up-to-date compiles under Windows & Linux (also present in the Windows nightly binaries) that there are a number of bugs in the single-player level set. Many of these seem to be related to Field and/or WallDoor objects. The ones I've found are as follows:

• 

  All of the platforms in Training Grounds referencing the towerHeight variable are flat on the ground. Here's how they appear in the original game (excuse the change of perspective):

  

• 

  Training 2: In the yellow circled area, the light purple platform raises immediately, whereas in the original it raises only when the player steps on it. The relevant script from the OG level data seems to be

    object WallDoor
    open = @enterLift1
    close = @enterLift1
    deltaY = kFloor[0]
    openDelay = 5
    closeDelay = 100
    openSpeed = 4
    end
    
    object Area
    enter = @enterLift1
    end
  

  The pink block I think is a Field object that's rendering (incorrectly) as a block in the flyover, but is (correctly) not rendered in-game.

• 

  Practice Run: The big white "trampoline" circled here in yellow is another Field object. Like in Training 2, this behaves correctly in-game, but renders as a huge block in the flyover.

• 

  Bluewater Documents: The platform circled in yellow bottoms out halfway down its travel. The relevant script here is:

    object WallDoor
    open = @pLift
    close = @pDrop
    middle = closed
    midY = 5
    deltaY = 9
    didClose = @pLift
    didOpen = @pDrop
    openSound = 0
    closeSound = 0
    stopSound = 0
    end
  

• 

  Boake Maze: Same issue with Fields mis-rendering as blocks in the flyover, but not in-game. However, in the "north" part of the level (here, the circled bit on the left/center), a ramp object is being interpreted as a block which can soft-lock the level if the player gets trapped under it (a likely scenario the way this level is designed).

Additionally, I noticed a couple of graphical issues. One is a moire pattern on objects occupying the same plane. This mostly seems to affect Hologram objects; I wonder if these could/ought to be hard coded to be given precedence by the rendering engine?

The other thing I noticed was a notable 'jerkiness' to certain animations not present in the original game which I don't recall from older builds. This mostly seems to affect UFOs and Parasites revolving around the Z-axis, but it's a little hard to tell for sure. I'm completely guessing here, but could this be a frame rate dependent thing? (This definitely occurs on Windows; I haven't taken the time to confirm on Linux.)

[Iritscen]

I noticed the flying enemies moving in jerky steps too on macOS. Perhaps they're just not interpolated in 60fps?

Anyway, the single-player Desert Map gets to a point where I (seemingly) cannot advance. I'm not familiar enough with the maps and with mapping to say what the problem is, but it comes after you reach the pictured area partway through the level. There are destructible pillars which you can shoot to lower certain blocks and use them as a stairway, but it's not clear what I'm supposed to do here next. When attempting to walk to another part of the level, I simply get teleported back here.

[biggnome]

Good catch--I don't recall experiencing this in my own recent compiles, but I did check against the 2-25-23 Windows nightly and can confirm. What's supposed to happen is a platform raises and a teleporter appears when you climb up and walk to the end of the perimeter of the structure (the block pictured here in the hollow of the "V" reticle; but that is not happening here. The relevant level script seems to be--

object WallSolid
stepOnMsg = @extend
end

object WallDoor
open = @extend
deltaY = 0
deltaX = 5
didOpen = @teleSwitch2
end

object Teleporter
start = @teleSwitch2
y = 10
group = @Ogroup
end

Seems to me there may be an issue parsing WallDoors?

Edit: Just compiled fresh from source, and can confirm on Windows.

[assertivist]

These are all excellent finds, thank you for identifying even the specific level scripts, that is wildly friendly and helpful.

I first took a look at Bluewater Documents. For what it's worth, you can view the "ALF" translated version of the map in levels/single-player/alf/bluewater-documents.alf. I think both of the WallDoors are behaving incorrectly.

<WallDoor open="@pLift" close="@pDrop" middle="closed" midY="5" deltaY="9" didClose="@pLift" didOpen="@pDrop" openSound="0" closeSound="0" stopSound="0" fill="#7b23aa" frame="#000000" x="31.458333333333336" z="164.58333333333334" w="5" d="2.5" h="0.5" />

As you can see, and in your avarascript that you posted as well, the middle parameter is set to closed. The Avara Level Design Manual has this to say about the middle parameter:

This is the middle position. A useful setting would be something like 0.5, but if you keep it at closed, you can actually change the orientation of the door when it is in the closed state.

I'm not sure I fully understand what this parameter actually does (setting a different time T between 0 and 1 for the middle position??), but the problem in our case seems to be that closed default bit. I can't find where that would have been defined in the original either tbh.

HOWEVER, changing it to '0' makes both WallDoors move fully from the platform below to the platform above at the same time, which i believe is "correct". I'll be firing up the G4 later to confirm.

[assertivist]

Okay, that wasn't it, seems like the extents of the motion of the door are different for each door each time I load and run, regardless of what closed is... I now suspect the logic signals but I'll update if I figure anything out.

[biggnome]

Minor, unproductive follow up: for giggles, on single-player:training-grounds.alf, I replaced all the referenced towerHeight variables with the discrete value of 7.5 (or arithmetical equivalent, e.g., towerHeight + 2 -> 9.5). My knee-jerk assumption was that towerHeight was not being parsed, since those are the affected structures; but didn't see any change from the bugged platform arrangement I posted originally. Back to the drawing board...

[biggnome]

Found & fixed a bunch of problems with misaligned elements (presumably bugged conversion of the original PICT files?), which correct most of the aforementioned issues. The line numbers & relevant changes to the ALF files are as follows--

Boake Maze:
Ln. 45: <Wall color="#ffffff" color.1="#000000" x="53.958333333333336" z="86.45833333333334" w="2.5" d="2.5" h="2.625" y="1.875" />

Bomb Deposit:
Ln. 18: <Door shape="bspGrid7.5" canGlow="1" isTarget="1" shield="2" killMsg="@rFire" color="#8b0f00" color.1="#000000" cx="91.45833333333334" cz="83.64583333333334" angle="270" />

Rescue:
Ln. 25: <Dome y="6" color="#0080ff" color.1="#000000" cx="58.75" cz="85" r="2.5" angle="156" quarters="0" />
Ln. 7: There's a typo (present in the original data)--destorying should be destroying

Training Grounds 2:
Ln. 8: <Area enter="@enterLift1" cx="24.23611111111111" cz="17.36111111111111" r="2.5" />

Also, something in the interim has seemed to fix the lift issue in Bluewater Documents.

Training Grounds [1] & Desert Base are still borked though. I'll see if I can find anything "off" with these, time permitting.

[tra]

Thanks, this is helpful. Generally we will use this to fix the converter and re-run the converter on all the levels if it uncovers a bug there.

[biggnome]

The Desert Base teleporter bug appears to be related to overlapping objects (in this particular case, I think it's the WallDoor & WallSolid @ lines 30 & 31 which both occupy identical spaces, precluding stepOnMessage="@extend" and thereby didOpen="@teleSwitch2" from triggering). My cheap-o, hacky proof of concept was as simple as decreasing the y value of the WallDoor @ ln. 30 infinitesimally; although I imagine that sorting this out "for real" in a non-destructive way in the game engine might fix some of the graphical moire issues with holograms and stuff as well. More food for thought anyway...