Quote from: WillLem on January 27, 2025, 01:07:55 AM

Quote from: Simon on January 26, 2025, 05:34:30 PMRight, release what you have

Yes, let's do it! Here's the first RC build.

Also, let's agree on one (or a combination) of these going forward, to help steady the pace of CE development:

Option 1: We agree as a community on a development schedule, which I can then aim to stick to. I'd be happy to work to something that someone else draws up if that makes everyone feel a bit better about the rate of updates/progress, and then people know in advance how long they have to catch up with what's going on and provide the necessary feedback, should they wish to do so.

Option 2: We agree as a community on a feature limit per-version, which again gives me something to aim for and helps to keep the new feature set less overwhelming with each version.

Option 3: We agree as a community on feedback waiting time at the very least; I need to know how long I should wait before proceeding with anything.

Option 3 should be considered regardless - at least in the form of a minimum expected timespan between RC and stable. You don't have to meet that timespan exactly; just no shorter than it. (In fact, it's probably a good idea to wait at least a couple of days longer. There's always people who leave it until the last minute.)

Option 1 isn't an awful idea, but will you stick to it? Will you have new features to justify each one? Of course, it could also be a minimum.

Option 2 is one I'd be cautious of. Certianly, consider one or two major ideas per release, but don't limit the minor stuff - I wouldn't consider counting something like "option to display the title screen panels in a single line" towards such a limit, for example. (I also wouldn't implement this option at all, but it came to mind as something that's reasonably fitting as an example here.) Rather than an arbitrary number limit, I'd suggest instead just going off feel - try to stick to just a small number of major things per update, with perhaps a few more minor ones.

If you aren't getting much feedback in the discussion topics, or if it's hard to explain / for people to understand, don't forget that experimental releases are an option too. Use these sparingly, of course, but they can be useful. (They also need not always be publicly released, for that matter. It may be worthwhile making a branch for them similar to the release / RC branches in NL's repo, so that anyone who really wants to can build it from source - and also so you can track down exactly what commit the experimental was based on if this becomes useful for investigating a bug.) There's also the option of going ahead with it in the RC and seeing how people respond to that. When all else fails, there is also always the option of revert it (or make it a setting) later.

I don't see any harm in it existing.

One slight suggested change to your "how" though - instead of having multiple "userdata_XXXXX" folders, have subfolders of "userdata" for each user.

Quote from: WillLem on January 26, 2025, 05:10:59 PMI can't really do much about my natural workflow speed. What I can do, however, is put CE lower down on my priority list so that I get around to it less; this will obviously help to temper the out-rolling of features. I could also take more frequent breaks during sessions (which is something I'm aiming to do anyway for health reasons).

You can also keep various developments in side branches, if you feel like working on them now, and then work towards rolling them out later. You could even consider making topics about them so people who do want to give the input can, while applying a unique tag to them (maybe something like [LONGTERM]) to indicate they're not under consideration for the immediate upcoming releases.

Yeah, I'm also a bit iffy about the idea of erasing all future assignments for the same reasons. Additionally, it might be useful for the player to refer to the future assignments when correcting them - this could especially be the case if a user is attempting to repair a broken replay.

Quote from: WillLem on January 21, 2025, 11:04:27 PMBeyond this though, what would you suggest in terms of accounting for unmodified sets?

I'm on the fence between "fall back on the frozen-exiter behavior" vs "use the default style Sleeper sprite to fill the gap". I don't think this is significant enough to implement an option for; just pick one or the other and go with it.

Quote from: WillLem on January 21, 2025, 11:04:27 PMThis could be accounted for by specifically allowing Shimmier assignments to be queued. Saying that, I had a quick look and couldn't see anything specifically linking Shimmiers to queued assigments. I'll have a closer look when I get around to this specific feature, but if you happen to know whereabouts it is in the meantime I definitely think this one is worthwhile, given how aggressively it interprets user input.

It's not that any special behavior is explicitly coded, but rather that there's a lot of scenarios where there is only a one frame window to assign a shimmier (eg. slider->shimmier transition), and skill queueing is relied on to make this practical - even with framestepping, it's not the most convenient assignment to make otherwise.

Quote from: WillLem on January 21, 2025, 01:51:12 PM Sleeper lemming state - this state is entered when time runs out and the lemming reaches the exit. It's a mostly aesthetic state to replace the buggy-looking cluster of exiting lems, but it's also useful for simulating exit behaviour as these lems cannot be assigned to.

Make sure this plays nicely with custom lemming sprites, including those that have not been modified to account for it. EDIT: And also that the time might run out while lemmings are mid-exiting.

Quote from: WillLem on January 21, 2025, 01:51:12 PM Add option to deactivate skill queuing - another one that should definitely be optional as it's input-related.

Keep in mind that the assignment windows for some skills have been set under the assumption that skill queueing exists, in particular, niche transitions to Shimmier. Even though it's technically UI, I would argue this one leans a bit too much into physics to be messing with.

Quote from: WillLem on January 21, 2025, 01:51:12 PM Hotkey Config - Add Reset, Cancel and Save & Close buttons

There's already reset at least (or rather, three resets - one for each default layout option).

Quote from: WillLem on January 14, 2025, 11:13:34 PMMost other engines post-WinLemm have smoothed out the flickering cursor behaviour because it's no longer necessary with direction select (using the arrow keys to select a lemming fcaing a particular way) being a thing.

The reason this doesn't happen in NeoLemmix is not because it directly was fixed, but rather due to the underlying physics bug/detail that caused it being fixed. This happens because in DOS physics, a walker always moves one pixel ahead, and if he's inside a wall at this point, he then turns around but remains inside the wall. Thus - the behavior is simply a result of the lemming being inside the cursor region for exactly one frame. Likewise, he's only there for one frame because the pixel right inside the wall is under the cursor, but the pixel outside the wall is not - and because he turns around on this frame, he'll always be facing the desired direction. You just extend this to multiple lemmings coming into the cursor, each for one frame at a time, and there - the cursor itself is actually behaving 100% bug-free, but a physics bug (or at least a weird detail of physics) results in behavior that looks like a cursor bug.

I would be willing to bet that Lix is the same - it would happen there too if Lix replicated DOS's turn-around-at-wall physics, but it doesn't.

About two decades, I'd say - Lemmix made them both pretty much irrelevant. CustLemm especially, due to Lemmix being able to almost perfectly play CustLemm content (aside from early Lemmix missing some obscure glitches, as well as triggered traps in Lemmix resetting one frame faster than DOS/CustLemm - but this didn't get noticed even during the height of challenge runs (and I suspect that if we re-tried it on a fixed version of Lemmix, some replays might break but all the solutions would be reproducible) let alone when custom content began moving to Lemmix).

It's a standard MediaWiki feature I think. Check how Wikipedia or any other major wiki does it.

Infoboxes I believe are usually done via templates / transclusion. The templates themself have to be created.

I've fixed the image upload issue, as well as an intermittent login issue.

Alright, I've set up a wiki at: https://wiki.neolemmix.com/

Registration is required to edit pages, but not to simply view them.

It needs a logo - feel free to send me any suggestions. Otherwise - for all technical issues (including if there are additional addons / etc that people think should be installed, or if we get spam problems), let me know. For content, it's up to you guys.

Yeah, if we want to have the AI debate in general, let's make a seperate topic for that and keep this one more to the wiki idea (with any discussion of AI being solely about whether its use is allowed in writing the wiki - which really, for the reasons Icho explained, is going to be a defacto "yes" anyway; we aren't even going to know if an otherwise-good entry had assistance from AI).

(Also, FWIW, I didn't feel Silken's post was overly rude. The first line maybe a little bit, but the rest was all very much in the correct "attack the idea, not the poster" spirit.)

Anyway, it does indeed seem like there's at least some interest in the wiki so... yeah, sure, I'll spin one up at some point and we'll see where it goes. If it doesn't really go anywhere, we can always nuke it later.

Provide a couple of tunnel lengths, critically, including a single stroke. Make sure it has a marker for where the lemming will be when he starts the next stroke. Users can then chain these together as needed to create any length.

So... was there much interest in actually making this happen, or was it more just a case of "fun to discuss the idea"? As mentioned, I am happy to handle the hosting / setup / technical maintenance for this if there's interest. (I would want to see at least a few people who want to contribute to it (rather than just want it to exist) who are interested.)

Quote from: WillLem on January 11, 2025, 12:09:13 AMHow much work would it be to make NL 64 bit now that GR32 has been updated? Or, is it still not feasible?

Probably very easy, if GR32 is indeed compatible (and performs as well - or better than - 32 bit).