The sounds are secondary. Some of this is fundamental input design and we must get it right.

Quote from: Armani on January 23, 2025, 01:06:04 AMThe most recent example
used a jumper to cancel a basher
I overwrote the jumper assignment with a shimmier

This is a same-tick-same-lemming assignment. This overwriting will continue to be allowed. The design in the 2024 topic was:

• Prevent assignment on same tick to different lemming. Reason: This is the problematic accidental overwriting.
  
• Some feedback for the prevented different-lemming assignment will be nice. Sound is the easiest.
  
• Allow assignment on same tick to same lemming. This will first erase the old assignment, then write the new. I assume everybody wants this.
  
• Additionally, when we erase the old assignment, we should also erase all future assignments to the same lemming. (We keep the future of other lemmings.) Lix does this and it seems the best; reason: The future of that same lemming will desync otherwise anyway. namida/WillLem haven't outright said that this is the best, but I'll chalk that up to unfamiliarity with this detail in Lix. Happy to discuss this.
  

No need for hotkeys. Prevent only what is absolutely necessary: Same-tick-different-lemming.

-- Simon

Quote from: Armani on January 23, 2025, 01:06:04 AMyou have a pretty strong strong opinion on disallowing skill overwrite replay in insert mode.
I sometimes do overwrite skills with intention

Interesting that you want to overwrite. Thanks for bringing it up. Then it's not 100 % clear. See next post. I still believe that no accidental overwrite is better, but I've only read your post now, I haven't slept over it yet.

Older topics for reference:

2023 topic: Replay Insert Mode ("blue R") silently overwrites
2024 topic: Replay Insert Mode ("blue R") silently overwrites: Decision?

Quote from: WillLem on January 23, 2025, 03:01:55 AMmodifier key (Ctrl, Alt, Shift) to overwrite assignments

I've already bound fencer to Shift, and I've bound nuke to Ctrl.

-- Simon

Sure, newbies have turned off replay -- as a hack! Can't see how to cut it after rewinding? Turn the whole feature off! Please don't mistake this for a genuine wish to disable replay.

You'll fix that newbie confusion in a different way during play. Only after that, revisit this worry.

Newbies want to play a level ASAP, I agree.

-- Simon

Quote 'Replay After Backwards Frameskips' and uncheck it by default

Like Icho, I recommend to check it by default.

The default should be that rewinding preserves the assignments, and that you must cut the replay explicitly to erase the assignments. The newbie confusion doesn't come from this default; NL confuses the newbies because NL doesn't tell them how to cut the replay. You'll fix this confusion elsewhere.

Quoteevery effort will be made to preserve current user option, but it may need to be re-set following this change

Right. It's nice to heed the user's old setting when you reword the boolean option to positive. If you can't heed that, it's okay to fall back to this option's default on first run. The default will be that rewinding keeps the replay, which matches most people's settings.

Anyway, I'm happy that you brought this up in the first place. UI is important and negatively-worded checkboxes are surprisingly confusing.

-- Simon

Yes, autogenerating forum markup is a good choice. Like this, neither the forum nor the public listing has to depend on Excel. But you can still use Excel behind the scenes as a database and as tooling. Thanks for your work!

Would you like to become moderator for this board (NeoLemmix Levels) so you can update the first post?

Or do you want to create your own post? I'll then un-pin Wafflem's post, pin yours, and link to yours from Wafflem's? (You can still become board moderator.)

-- Simon

Quote from: namida on November 16, 2024, 06:14:14 AMNeoLemmix
checking for interactive objects along the entire path

That's a good approach, and Lix has tracked fire and water along the path for 10 years.

But I've never tracked exits or triggered traps like this. I omitted this 10 years ago because it was harder to design for exits/traps. We need know into which exact one of the many exits/traps the lix went.

The correct solution seems to be: If a lix moves several pixels per physics update, (e.g., the runner moves forward, then forward), and we reach an exit/fire/water/a hungry trap/... after one of the individual movements, we must stop short the entire movement for that frame.

In other words: Movement within each physics update should be written as a program in a domain-specific language. The engine interprets/executes that program. Touching exits stops further execution of that inner language for this lix in this physics update. Ideally, the domain-specific language will then consist of high-level verbs such as "walk forward", "fly forward", "fall down", ..., which have different conditions on surrounding ground, and they all require the physics update of this lix to have not encountered hungry traps yet.

This yet another ingredient for my planned Lemmings physics manifesto.

Added this bug to the 2025 roadmap.

-- Simon

2017 -- 2018 -- 2020 -- 2022 -- 2023 -- 2025

---

UI

#496: Add flying shovel/jackhammer for basher/digger who hits steel.

Upgrade Allegro DLLs in the Windows release to 5.2.10. I forgot why I wanted that. But it's the newest version, updating is good anyway even if I don't remember why.

#400: Scissors mouse cursor: Change the mouse cursor to scissors when a click will cut the replay.

Add an icon near the mouse cursor that means insert mode. There is no obvious icon for inserting. See: Old post with icon ideas, even though these ideas were for a panel button, not for something at the mouse.

#494: Explain gadgets on mouseover (catapult, steam, trap). This is good newbie onboarding. Newbie onboarding is important; bad UX confuses newbies and they never play again.

---

Physics

Fix several of these bugs:

• #47 The ❤-Bug for Basher/Miner. When a basher or a miner turns at a blocker, the basher/miner won't consider the new terrain that now blocks his path. The basher/miner can clip through walls. Miners can clip through floors.
  
• #491: Jumper clips upward through terrain
  
• Basher (after lowering) clips forward through terrain. This is the same underlying bug as the ❤-Bug. Again, we put unexpected terrain in front of the basher, and the basher clips through that terrain. Here, we didn't use a blocker; we used the basher's down-stepping.
  
• Miner hovers in mid-air when he mines along a builder staircase. You can assign blocker to cancel in mid-air. The lix will then fall and revert to walker.
  
• #471: Platformer is inside his first brick. When you assign jumper at a specific time, the lix will be stuck and not jump.
  
• Remove unglitching out of wall: Ascenders travel inside the vertical wall. This requires extra code in tumbler.d to move the ascender out of terrain when something is about to fling an ascender. The ascender should take a better path outside the wall.
  
• Runners Bypass Exit, Walkers Exit: A moving lix looks for exits or triggered traps only at the end of her entire physics update, not during her path. We want to look during her entire path instead.
  

Write a manifesto on Lemmings physics. Never should a lix willfully enter terrain, unless we override it explicitly, e.g., for ascender. Never should a lix hover, unless we override it explicitly, e.g., for builder. Replace some physics primitives, e.g., scan at (x in front | y up), e.g., move ahead unconditionally, ... with higher-level commands: "walk ahead" should mean { move ahead iff you're standing on floor and there is air ahead }. Rewrite some physics in these higher-level terms. See how much of the physics will break. We can still decide if all this is too aggressive.

-- Simon

Nice digging!

Quote from: GigaLem on January 17, 2025, 11:59:47 PMgithub right here
it doesn't have a program file to run it or the level editor.

One way is to build WinLems from source. Warren (the author) says that you needs Visual Basic 6 to build. VB6 is ancient, I have no experience with that.

Another way: Ask Warren directly to release executables. It's a long shot after all these years. And in 2020, he has marked the WinLems github project as archived, which means that he doesn't want to be involved with it anymore. But who knows what will happen if you ask nicely ...

-- Simon

Indeed, it's plausible that the image-editing problem and the lemming-controlling problem come from the same underlying problem. It sounds as if the cursor moves more than one pixel per minimum physical mouse movement, and you want to move one pixel at a time.

Try to lower the mouse speed of the operating system. (E.g., in Windows 10: Settings -> Mouse -> Cursor Speed, drag the slider leftward.) Does that help?

Does your mouse have physical buttons that control its sensitivity? Lower the sensitivity on the mouse then, too.

-- Simon

I'll play on Sunday, January 26th.

Thanks for organizing!

-- Simon

Quote from: Dominator_101 on January 07, 2025, 06:54:01 PMThe program does (not spellcheck),' 'The programmer implemented (not spellcheck),' 'The user wants (spellcheck), not (not spellcheck)' but that seems...a bit clunky?

Correct, that's exactly what I have in mind.

The nuance is: I don't want to inflict the choice between bug or feature on the user. If you're the designer or implementor, and such a classification helps you, by all means, classify. I've noticed that it hasn't helped me much.

Lix miners throw the pickaxe, but bashers/diggers won't throw the shovel/jackhammer. I call this a bug. Is this a missing feature or a bug in your view? Is it both?

In the graphics files, all three flying tools have sprites. In the physics, all three skills notify the effect sink (= the eye candy subsystem) to throw the tool. The difference is: The effect sink's method for pickaxe adds an animated pickaxe and rolls for initial speed, but the effect sinks's two methods for shovels and for jackhammers are still empty. Do you need the information in this paragraph to decide between bug/feature/both?

You can argue that the program does something very similar already, and therefore "attempts to do X" for X = throwing the ground-removing tool. But we can imagine requests à la: Please add a flying backpack when a builder has run out of bricks.

I'd even call it a bug report if a deranged user complained that Lix cannot understand chess notation. I'd reject this bug report as out of scope.

Quote from: Dominator_101 on January 07, 2025, 06:54:01 PMprotect the extreme edge-case user without becoming overly cumbersome for the general use

Right, irrevocable commands aren't the best example for a source of UX bugs that you and I, but not everybody else, would classify as UX bug. They entice those cumbersome safety measures that get in the way, and it's hard to say how much safety is best.

It's better to make the command easy-to-access and revocable, e.g., offer undo. This is hard in the physical world, and it's hard when files are involved, e.g., other processes may react to the database deletion.

A better example is a misleadingly named button/command/..., where the user doesn't classify his mistake as a typo or a mouse slip. E.g., there is a nontrivial difference between these two:

git rebase A B
git rebase --onto A B

-- Simon

Bug or Feature?

It's a bug if:

• The program does X.
  
• The programmer implemened X.
  
• The programmer wanted Y, not X.
  
• The user wants Y, not X.
  

It's a feature request if:

• The program does X.
  
• The programmer implemented X.
  
• The programmer wanted X.
  
• The user wants Y, not X.
  

The only difference is in line #3. When you force your users to classify requests as bug or as feature wish, you're forcing your users to read your mind. Yes, the user can eventually guess what you wanted if he's been around in the culture for a while. But why force him?

If we remove the need for the user to classify, we get:

• The program does X.
  
• The user wants Y, not X.
  

Indeed, feature requests are, at heart, bug reports. The program doesn't already do what the user expected. You can change the program or reject the request, regardless classification into bug report or feature request. Prioritize the requests by urgency, e.g., by average impact. A missing feature may well be annoying and urgent -- and I'll call that a bug with a straight face.

Another fun case:

• The program does X.
  
• The user wanted Y, not X, but has triggered X.
  
• The programmer got the implementation of X right, according to the design of X.
  
• The programmer disagrees with the user that X or Y or the program as a whole is buggy.
  

This is often a genuine bug, too: The bug is in the UI, or in the higher-level design of the program.

There is a grey area here. It's one thing if two buttons are too close to each other, enticing mouse slips. (Edit: Following example is bad; see next 2 posts for clarification.) Its another if you must, to delete the database, click Delete Database, type YES, DELETE DATABASE into the big red box and click and hold OK for 5 seconds. You can mouse-slip onto the Delete button, your cat might then run across the keyboard and accidentally push caps-lock and enter those 20 tokens, ...

-- Simon

Quote from: WillLem on January 01, 2025, 09:47:23 PMNL/SLX
jumps back to (the tick before (the tick before (the tick before seeing the effect of the assignment))).

We mean the same, but either we count ticks differently, or you didn't see the "before" inside the innermost parentheses.

We see the red builder bag for the first time after tick 100. The red bag is the visible effect of the assignment for tick 100. I -- and the Lix UI -- call this earliest sight of the red bag "the world at tick 100", but it's technically in-between ticks 100 and 101, not during tick 100. I would understand if somebody called this "at tick 101"; I don't.

The Lix feature rewinds to tick 99. This is before you see the effect of the assignment. In your gif, the walker is straddling, both of his feet touch the ground. At tick 99, we see the effects of all assignments for ticks ..., 96, 97, 98, 99. There are no such assignments this early in the gif. You're contemplating to change SLX to rewind to tick 99.

NL/SLX rewind to tick 98. This is the tick before (the tick before you see the effect of the assignment). The walker's frontal foot is in the air. kaywhyn wants Lix to rewind to 98 instead of to 99.

-- Simon

Quote from: WillLemIs having to step over a single frame desirable?

Desirable for whom? For kaywhyn? For me?

I cannot give you first-hand UI findings because I never use the feature (rewind to previous assignment). My playstyle doesn't need it.

All I can give you directly: Implementation-/design-wise, it felt more natural to rewind to (the tick before the assignment is visible). It felt unnatural (as in: I never thought of it before kaywhyn tested) to rewind to (the tick before (the tick before the assignment is visible)), which kaywhyn wants.

I'm waiting for kaywhyn to record and show his NL usage as a video. Are you (WillLem) prodding for such a video?

---

I'll guess why kaywhyn wants to rewind to (the tick before (the tick before seeing the effect of the assignment)). Consider the following 4-step sequence of actions.

• Rewind to before the assignment's effect is visible. I.e., use rewind-previous-assignment in the current Lix 0.10.28.
  
• Rewind one more tick.
  
• Assign the same skill (which you've rewound in step 1) to the same lemming.
  
• Fast-forward to view the result.
  

This 4-step sequence pulls the assignment earlier by one tick. Step 3 cuts the replay and reassigns the single cut assignment a tick earlier than from where it was cut.

When the rewind-to-skill behaves how kaywhyn wants it, he can omit step 2 because rewind-to-skill will then perform step 1 and step 2 together, not only step 1.

The minus button in the tweaker does all of this in one shot, including viewing the future result. You'll always view the result at the same future tick because you're tweaking an assignment in the past. The minus button is also easier to spam multiple times than it is to repeat that 4-step sequence by hand multiple times.

-- Simon

This is still open, and I consider this an important newbie-onboarding feature.

-- Simon