Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - namida

Pages: [1] 2 3 ... 56
Bugs & Suggestions / DECISION: Cutoff dates for bug reports.
« on: November 04, 2022, 08:56:08 AM »
Earlier, I already set a cutoff for new suggestions, as part of the efforts to finalize NL. I am now going to start the next step of planning a cutoff for bug reports.

I did earlier say that I would delay this decision until V12.13.0 was released, but I was not expecting such a huge window between 12.12.X and 12.13.X, so I have decided to bring this forward.

Similar to the cutoffs for suggestions, I will do this in a few phases. Dates may change, but there will not be a sudden cutoff out of nowhere - should any decision be made to move these forward, a window of at least a couple of weeks will be given before it takes effect.

Phase 1 - This will take effect from the 1st January 2023, or from two weeks after V12.13.0 goes stable, whichever comes first. When this comes into effect, no new reports of any physics bugs will be accepted, unless the bug is newly introduced in the latest major stable version at the time - either because the bug relates to a new feature (eg. the new object types), or because the bug is a side effect of another change or bugfix. UI bugs may continue to be reported as normal.

Phase 2 - This will take effect from the 1st July 2023, or from two weeks after V12.14.0 goes stable, whichever comes first. When this comes into effect, no new bug reports (whether physics or otherwise) will be accepted unless either (a) the bug was introduced, either as a side effect of another bug fix or in relation to a new feature, in the latest major stable version at the time, or (b) the bug causes a crash or hang, or causes data loss.

Phase 3 - This will take effect from four weeks after the major version after the one that introduces the new object types, goes stable (eg. if the new object types are introduced in 12.14.0 as is currently expected, this phase will take effect four weeks after V12.15.0 goes stable). When this comes into effect, no new bug reports will be accepted unless the bug causes a crash or hang, or causes data loss.

Phase 4 - I am not going to set a time for this phase to take effect yet. When this comes into effect, no new bug reports will be accepted whatsoever.

Much like with the phasing out of accepting suggestions, this applies ONLY to the player; bugs with the editor may continue to be reported. Also, like with suggestions, this only applies to new reports; any reports that already have been made, but not yet fixed, at the time, will remain open.

When mass saving images, if styles are missing, the output images simply contain the placeholder graphics rather than any error and/or failure.

Closed / [BUG][PLAYER] Auto-generated rank graphics broken?
« on: November 03, 2022, 09:18:30 AM »
Haven't looked into the cause at all, so not sure if it's a bug, an edge case, or just something weird in the particular setup, but in this screenshot posted on Discord by GigaLem, the rank graphic has a "Rank graphic not found" image instead of generating a placeholder.

New Objects / [DISC][PLAYER] Behavior of horizontally-flipped portals
« on: November 03, 2022, 05:35:11 AM »
For teleporters/receivers we have a defined behavior: Either both objects must be flipped, or else neither is flipped. If they are flipped, the lemming comes out the receiver facing the opposite direction they entered the teleporter.

For portals, currently, flipping doesn't do anything (aside from adjusting the graphic / repositioning the trigger area in the same way it would do for any object). The question that arises is - what should happen?

I see three possibilities here:
1. Flipped portals have no special effect and behave the same as ordinary portals. Not keen on this one (unless flipping portals is prohibited altogether, rather than being allowed but having no physics effect), in particular due to it being inconsistent with what teleporters do.
2. Paired portals can be flipped individually. If either the sending or receiving portal is flipped, the lemming reverses direction when exiting the receiving portal. If both are flipped, this cancels out and the lemming's direction does not change.
3. Paired portals must either be both flipped, or neither flipped, much like teleporter/receiver pairs. If the pair is flipped, the lemming reverses direction when exiting the receiving portal. This is my preferred approach.


Closed / [BUG][PLAYER] Error when starting LPV Unruly 15
« on: August 30, 2022, 07:01:28 AM »
Reported by kaywhyn on Discord. This error happens if Unruly 15 is the first level played when starting NL, but not if another level is played first.

Have not investigated at all yet; simply making a topic so that it's recorded here. Please let me know if you're aware of any other levels with this issue.

From memory, the only "unusual" feature this level contains is locked exits / unlock buttons.

Loap / Rendering issues - some help?
« on: August 28, 2022, 10:36:39 PM »
I'm wondering if anyone more experienced with 3D graphics (or perhaps just geometry / maths in general is enough) can help with ideas on how to improve the rendering.

The main problem here is around determining the order to draw block faces and other 3D-space elements in. Due to how L3D levels can have multiple block faces in the same position, a Z buffer is not an option - this leads to an awful level of Z-fighting, and can also lead to lemmings' graphics disappearing inside blocks when they're close to a block face (especially deflectors). Instead, we need to determine what order to draw the block faces in. (Optionally, we can also work out which ones don't need to be drawn at all, due to being outside the viewing area. However, not doing this only results in a performance penalty, not glitches, so this is not critical.)

The current build, orders these elements purely by the distance from the camera to a "key point". The key point is usually, but not always, the middle of the element's position in 3D space. In the case of a tie, it's broken by a defined priority order based on the element type (so for example, if a block face and a lemming have exactly the same key point - or different points that are the same distance from the camera - the block face will be drawn first, then the lemming).

Source code in a side branch (wip/rendering-fix-20220828) implements a different algorithm, which looks at every vertex of each element, and finds the one that when transformed into screen coordinates is furthest from the camera (including the depth) then uses this as the "key point". The other difference is that instead of determining position based on the entire key point at once, it determines it based only on the depth at first, using the other two axes as a tiebreaker only (if it's still a tie after this, it uses the same priority order as the existing algorithm to break the tie). This algorithm seems to have slightly fewer glitches, but those it does have tend to be more noticable.

I'm wondering if anyone has any better ideas here? I've taken several shots at it throughout Loap's development, and these two algorithms (the former of which has been the one used in virtually all released builds; the latter is a recent development and hasn't been included in any build yet) are the only ones that even come close to getting it right - most other things I've tried have felt like they should work, but  produce awful results when I actually implement and try them out. To be clear - what I really need is thoughts on the algorithm itself; once I have the right idea, I shouldn't have any difficulty coding it.

Also, just to avoid miscommunications - note that in Loap, the X axis is left to right, the Y axis is front to back, and the Z axis is bottom to top. (ie: the coordinates (1, 2, 3) would be 1 space to the right, 2 spaces "into" the screen, and 3 spaces upwards from the origin).

EDIT: Also, with regards to freedom of movement of the camera - the camera in Loap can move in any 3D direction, has a full 360 degree freedom of movement for the yaw, a -45 degrees to +45 degrees range of movement for the pitch, and no ability at all to roll.

Loap / [SUG] Spawn direction indicator
« on: August 20, 2022, 11:12:54 AM »
Although the hatch flaps can rule out two possible directions, it's still ambiguous between the other two. Should add an indicator.

Loap / [BUG] Poles near end of level broken on "Hole In One, Two, Three"
« on: August 20, 2022, 10:42:26 AM »
Haven't noticed similar outcomes in any other level. In particular, I checked several other levels with similar poles - "Stilt Walkers", "Final Maze" (official) and "Deep Dash", "Breaking The Routine" (my pack) - and all of them dispalyed fine.

Presumably this is an edge case in L3D's behavior that Loap is not replicating correctly. The only research I've done into the why is quickly checking if L3DEdit has the same issue - it does not. Also presumably, this is purely a graphical issue.

Loap / [BUG] "Fun 8 effect" broken in V0.0.22.0
« on: August 14, 2022, 08:21:39 AM »
Tracked this down to commit 906a2d1 being responsible. As this commit was just some refactoring in preparation for (unsuccessful) attempts at improving rendering issues, I've fixed this simply by reverting it, and the fix will be included in the next build. Making this post just so people are aware it's a known issue.

This probably also applies to other cases where "wall" graphics (or in Loap terms, overlays) are used, rather than being specific to the Fun 8 effect, but that's the most noticable case of it.

Loap / [BUG] Level select menu bugs
« on: August 14, 2022, 05:53:44 AM »
Two bugs, probably related:

1. Scrolling option will not appear when subfolders (rather than levels) push the list past the maximum on-screen capacity.
2. Loap may crash when the maximum capacity is exceeded in a folder that contains both levels and subfolders.

Loap / To investigate: Bashing towards a slope
« on: August 09, 2022, 10:32:53 AM »
In L3D, if a lemming bashes through a wall then encounters the start of a slope, he stops bashing and walks up the slope, even though a basher assigned at the start of the slope will bash the slope itself. Need to investigate the result under Loap.

A related behavior occurs when instead of a slope, the lemming encounters a deflector. This situation is already handled correctly in Loap.

Loap / To investigate: Lemming hitting head while trampolining
« on: August 09, 2022, 10:21:30 AM »
Based on seeing it in a LP video, it seems lemmings in this situation continue their forward trajectory but immediately start moving downwards in DOS L3D. Haven't tested in Loap yet.

Loap / Options menu - what options are needed?
« on: August 08, 2022, 04:44:48 AM »
The options Loap currently supports (via editing the INI file) are:

Exists in current build (V0.0.21.0)
- Fullscreen mode
- Changing the window size
- Enabling / disabling VSync
- Changing the rendering resolution
- Toggling whether the mouse cursor locks in one place while rotating / panning the camera with the mouse
- Enabling or disabling replay auto-saving
- Hiding / showing the minimap (this one can be toggled in-game too via hotkey or clicking the red button in the minimap's corner)
- Changing the minimap size
- Changing the minimap resolution

Implemented for next build (V0.0.22.0)
- Sound / music volume
- Invert mouse camera movements on all axes of panning / rotation (seperate settings for each axis and for pan vs rotate)
- Mouse camera movement sensitivity
- Frame limiter (already exists but in a more-debuggy fashion rather than a proper setting)
- Display FPS (already exists but in a more-debuggy fashion rather than a proper setting)
- Trap mouse in window
- Disabling the background moving in menu screens

Planned but not yet implemented

Additionally, hotkeys can also be customized.

Is there anything else that should be configurable?

Loap / To investigate: Bashing on slopes at 90 degree angle
« on: July 30, 2022, 10:44:23 AM »
Need to look into what happens in both L3D and Loap (and adjust the latter if necessary) when a basher is walking along a slope (not up / down it, but along the slope sideways) and bashes through a wall at the end of it. Not exactly a common setup, but worth checking. Currently I'm not sure what happens in either engine.

Loap / [BUG] Hatch flaps missing on "Follow The Yellow Brick Road"
« on: July 24, 2022, 04:36:25 AM »
This appears to ultimately be an error in the level's design - the metablock for the entrance uses the textures that lack the flaps, and this is slightly visible in DOS L3D as well (the upper half of the hinge is missing) - which simply isn't as noticable in DOS L3D as it uses hardcoded indexes from the texture file for flap graphics, unlike Loap which determines them based on the actual textures used by the entrance block. Just needs an adjustment to the level to fix, but also need to look into whether any other levels are affected.

Pages: [1] 2 3 ... 56