Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
biggnome opened this issue Feb 13, 2023 · 8 comments
Open

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

biggnome opened this issue Feb 13, 2023 · 8 comments
Labels
alf bug Something isn't working

Comments

@biggnome
Copy link

biggnome commented Feb 13, 2023

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:

  • training

    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-og

  • training2

    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.

  • practicerun

    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

    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

    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
Copy link

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.

Screenshot 2023-02-25 at 4 22 17 PM

@biggnome
Copy link
Author

biggnome commented Feb 25, 2023

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
Copy link
Member

assertivist commented Mar 8, 2023

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
Copy link
Member

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.

@assertivist assertivist added bug Something isn't working alf labels May 9, 2023
@biggnome
Copy link
Author

biggnome commented Nov 3, 2023

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 biggnome closed this as completed Nov 3, 2023
@biggnome biggnome reopened this Nov 3, 2023
@biggnome
Copy link
Author

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
Copy link
Contributor

tra commented Jun 19, 2024

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
Copy link
Author

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
alf bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants