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 ... 57
Loap / [BUG] Something going wrong when rewinding
« on: October 16, 2023, 09:01:42 PM »
Was making a solution replay for Mayhem 20 of LP3D, encountered some cases where the alive lemming count went down after backwards framestepping (then come right after further steps). I suspect some of the "checkpoint" save states aren't being erased correctly but haven't looked into it yet.

Using the latest source at the time, which has a few changes from

Not sure when this happened, but it's not meant to. Haven't looked into it beyond noticing it happens yet.

Closed Loap Bugs / Suggestions / Stereoscopic 3D?
« on: October 14, 2023, 09:44:41 PM »
So while I've ruled out any possibility of a full VR mode for Loap due to the complexity that'd be involved, I am open to the idea of supporting stereoscopic 3D - basically, the kind of thing you'd get from a 3D TV or a Nintendo 3DS. I'm wondering how many people with interest in Loap would (a) be interested in such a feature, and (b) actually have a means of using it (a 3D TV / monitor or a VR headset).

This should be relatively simple to implement - a slight caveat being I don't have a 3D TV, so I can't actually test that option of using it; I do have a VR headset so can test that.

If a miner mines into a 45 degree slope (going downwards from the miner's point of view), the miner should stop if during his walking phase, he walks down the slope. This does not happen; he keeps mining once he reaches the next block edge.

EDIT: Confirmed this happens for bashers too... although I do need to double check if that actually happens in DOS L3D. With that being said, it kinda feels like something I should fix either way.

EDIT: I have now confirmed this does happen in DOS L3D. I still feel like it should be fixed though; especially for miners (bashers are a bit more ambiguous; we allow them to move down slopes and continue bashing in 2D, but a miner must always follow his tunnel exactly; on the other hand, the exact workings in 3D differ in other ways too, in particular the use of a walker state between the equivalent of strokes).

EDIT: A video to show what I'm meaning:

Loap / [EDITOR] Creating a Loap version of L3DEdit
« on: September 22, 2023, 08:45:48 PM »
I've been thinking about this as an idea - instead of making a new editor for Loap, making a fork of L3DEdit that edits Loap levels rather than DOS L3D ones.

Many of the things Loap would need, would be fairly trivial to add to L3DEdit. (Many. Not all.)

Downside is this would mean having only an isometric view while level editing. There are a few things that would be hard to visualize in this view, in particular default camera angles. There's also the issue of what happens if Loap in the future supports 3D models for interactive / decorative objects; supporting these in L3DEdit would not be easy.

A bigger downside also is that L3DEdit is not as easily cross-platform. Although it can be (and has been) built for non-Windows OSes, it doesn't perform nearly as well on these platforms, due to using Lazarus rather than Delphi to compile on them. (The worse performance also occurs in Lazarus-built Windows builds, but on Windows the option of using Delphi is there.) I believe L3DEdit runs fine under WINE so this isn't too bad for Linux, but it will leave Mac out.

One reason for this is effort - there hasn't been much interest in making L3D custom content so far, so I'm not sure if it's worth the effort of a full new editor for Loap. Using L3DEdit as a base removes a lot of the required effort.

Loap / [SUG] Clear physics mode
« on: September 21, 2023, 05:47:50 AM »
The suggestion of a clear physics mode similar to what NL has, has come up a few times. I'm wondering what people think - is it necessary? L3D doesn't have the same proliferation of different styles, graphics, etc that NeoLemmix has to deal with, and realistically, it probably never will. On the other hand, there are things that are inconsistent especially in the official levels - are static objects solid, are they climbable, what's steel and what isn't, exactly how many blocks/slabs tall is a fall - so perhaps it's still a good idea to have this.

If it does happen, it probably won't be as thorough as NL's, but at least a basic form of CPM should be viable.

Loap / [SUG] Replay insert / suspend modes
« on: September 21, 2023, 05:45:40 AM »
DireKrow mentioned a while back on Discord that a replay insert mode and a replay editor, similar to what NL has, would be good features.

A replay editor probably won't happen. Implementing this while in-game, without Windows forms as an option (due to Loap being at least theoretically cross-platform - I intend to make Linux builds once it goes stable, and it should also be possible to build for Mac), is going to be trickier than I think is worthwhile.

Replay insert mode is definitely something that can and should happen. To cover the main important functionality of the replay editor (removing actions without erasing later actions), I was considering a "replay suspend" mode - where you can press, or perhaps hold, a hotkey to ignore any replay actions temporarily (and thus remove them from the replay), while any actions that come after you switch back out of this mode would still replay as normal, at least to the extent they can.

Closed Loap Bugs / Suggestions / [MISSING] Hotkey configuration menu
« on: September 21, 2023, 05:42:47 AM »
Loap supports configurable hotkeys, but at present these must be manually edited via the INI file. It would be good to implement a menu where these can be configured.

One complication is modifier keys (ie: like holding Shift + pressing a key, instead of just pressing the key). Loap supports designating keys as modifier keys, and any key can be designated as such. This needs to be factored into the hotkey configuation menu - including that a hotkey may ignore modifier keys, or specifically require no modifier keys are pressed, or require a combination of them rather than just one.

Another, likely much less troublesome issue, is that Loap does not prevent having multiple functions for the same key. It will generally just do both things if a key configured this way is pressed, if possible.

NeoLemmix Main / Future of NeoLemmix development
« on: August 30, 2023, 04:11:59 AM »
So, I haven't really been getting much work done on NeoLemmix in the past year and a half or so. A bit here and there, but not nearly enough to really keep the project going.

NeoLemmix is, overall, in a good state. Sure, there are some UI bugs that would be nice to get rid of, some room for better QOL features, etc, but overall, it's the most popular engine for a reason - because it's in good shape, it does what's needed, it isn't overly bloated with features, etc.

I had already decided to work towards a final version as a vague goal, but I have made the decision that I'm going to move very quickly towards that now. Most proposed features / suggestions are not going to happen, and likewise for minor fixes.

I do intend to do one more major update in the traditional sense (ie: an update that brings significant new features), with possibly one more "major" version after that for bugfixing purposes, in particular for any bugs that are introduced in the next update. This is because of the new objects - they are very close to ready, and it doesn't make sense to throw that work away at this point when not much further effort is needed to get it ready for release.

However, other proposed features - such as an improved replay editor - are going to be discarded, so that things can be wrapped up. I am also going to discontinue any further work on the editor, except for what is necessary to properly support the new objects (most of which is already implemented in the codebase and released in experimental form alongside the new objects experimental player).

I realise this might not be the news some people wanted to hear, but it had pretty much de-facto become the situation anyway - all I'm really doing here is making it official.

To address this before anyone suggests it - no, I do not want to hand further development of the game over to someone else. With that being said, NeoLemmix is open source, and anyone who wants to do so is welcome to fork it to create a new engine - SuperLemmix is already a case of this, though it may be that someone wants to create a fork that retains the NeoLemmix philosophies but continues to add / improve new features within that. It would then be for content creators and players to decide whether to adopt the fork or stick with NL's final version. Likewise, anyone who wants to create their own editor (either using the existing one as a basis, or an entirely new one) is of course free to do so. NeoLemmix and its tools will remain open source and free for anyone who wishes to fork, to do so.

Closed Loap Bugs / Suggestions / [SUG] Camera reset button
« on: August 05, 2023, 12:37:51 AM »
While watching Ryemanni play through LP3D in Loap, he ran into a case where in an enclosed level he moved a camera into a tunnel created by a basher, then rewound gameplay. The result was that this camera was stuck in the tunnel, which caused issues that I can't go into detail without spoiling the level.

Loap does have a means of moving the camera through walls, but this may feel a bit cheaty for some players. A way to reset the cameras to their original positions seems worthwhile.

Important context: Much like how NL doesn't treat the scrolling as part of the replay, Loap doesn't treat camera movements as part of it, so rewinding does not undo camera movement.

New Objects / [DISC][PLAYER] Visual designs of new objects
« on: July 19, 2023, 11:28:29 PM »
So yeah, it's probably time to start thinking about the visual side of things.

Normally, I'd come up with something, use it in one of my new styles, and see where things go from there. But, I don't have anything ready to release any time soon. I could add them to some existing styles, I guess... either way though, some discussion needs to be had about what these will look like.

Portals - the idea of swirling vortices seems popular. This could be in some kind of frame similar to teleporter designs, but with a constant vortex animation in the "doorway"; or could simply be a portal sitting out in the open.

Assigners, Deassigners - first I'll note, Assigners are capable of (and should be) using the same functionality as pickup skills do, in order to show the skill they assign. The rest of the design needs to be clearly different, though. Clear physics mode can reveal the skill in the case that a graphic doesn't, but this is a failsafe, not the intended way of telling the player the skill they give. Following on from this, I feel the standard for deassigners should be similar to the same style's assigner (same shape, possibly different colors or minor details), perhaps with a red X where the skill icon would go on an assigner?

Neutralizers, Deneutralizers - I don't really have any good starting points on these ones, aside from that again they should look similar to each other, and we should probably settle on some universal indication of which is which (similar to the "In" and "Out" on teleporters and receivers).

NeoLemmix Main / NeoLemmix will reintroduce timed bombers.
« on: April 01, 2023, 09:33:57 AM »
Well, timed bombers have been a constant request from new players in particular. Even some experienced players have occasionally had a very strong desire for them.

Bomber timing was removed from NeoLemmix because all it does is add execution difficulty that becomes almost meaningless in the face of NeoLemmix's framestepping and other advanced features. The bomber is actually a very versatile skill when the ability to use it precisely is there, but bomber timing made this very frustrating in practice.

However, NeoLemmix has indeed changed even further since then. In particular, we now have skill shadows, which would serve as an alternative means of assisting precise bombing. In light of this, I feel timed bombers could be reintroduced.

I know this will cause issues for existing content that relies on bombers in the first 5 seconds; this will break some of my levels too. But like many physics changes before, content will be able to adapt to this.

I guess it really came to this because the frequent requests, and the existence of a fork that originated with a goal of reading timed bombers, makes it clear. When it comes to timed bombers, there are people who are quite simply never gonna give it up, never gonna let it down, never gonna run around and desert it, never gonna make it cry, never gonna say goodbye, never gonna tell a lie and hurt it. April fools, y'all. Nothing is changing.

NeoLemmix Main / Performance During Fast-Forward
« on: February 13, 2023, 01:08:14 AM »
Edit Simon: I've split this off Fork: SuperLemmix.

I'd probably want to try and find a way to make it so it's the same speed regardless of what computer you run it on, and at this point I have no clue how this would even be approached. "if Superlemming=true, enable fast-forward" is relatively simple, whereas dealing with frame rates directly I can imagine will be much more difficult.

NeoLemmix sets a frame rate cap and runs as fast as it can subject to that cap. If the hardware can't manage the full fast forward speed, it'll just run as fast as it can. In extreme cases (slow hardware and/or large levels or with a lot of objects), it might not even manage the 17FPS of normal playback - again, in such a case it'll just run as fast as it can. Superlemming mode, back when it existed, just altered the frame rate caps.

Unless you can find a way to replicate the exact physics (or something you deem close enough and bug-free enough, if you're okay with breaking exact physics) with more efficient code, the only way you're getting around that is by frameskipping (ie: not actually rendering every frame if the hardware can't keep up).

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 is already in effect. 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 (or an experimental / RC that is more recent than the latest stable version) - 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 is already in effect. 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 (or an experimental / RC that is more recent than the latest stable version) at the time, or (b) the bug causes a crash or hang, or causes data loss.

Phase 3 - This will come into effect three months after V12.13.0 goes stable. 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.

Pages: [1] 2 3 ... 57