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.


Messages - Simon

Pages: 1 2 [3] 4 5 ... 274
31
Found another case on Lemmings Forums and added it to OP:

Example from 2023-06:
Join development team

yoyoz files the automatic replay as a bug. He had already changed the NL code to fix it, and writes:

Quote from: yoyoz
There is a problem when you click on restart button: Same actions are replay. I have fixed it. But for the moment, i havent found where fix when you restart the level with the menu screen.

-- Simon

32
Lix Main / Re: Rewind as Undo: Still Preserve a Loaded Replay
« on: March 08, 2024, 05:38:00 AM »
We had Forestidia and mobius play with rewind-as-undo. I.e., rewinding (and restarting, which is the ultimate rewind) drops the rewound assignments from the replay flat-out.

Rewind-as-undo was also saxdude26's way of playing NeoLemmix: He likes saving/loading replays, and he likes rewinding mistakes, but he doesn't want replay after restarting.

Still hard to say: Did saxdude26 play like this because it's his objectively preferred way? Or is it merely the only bearable way of playing NL that he found? I.e., was it merely better than { playing with rewind-as-browse and not seeing that air clicks cut the replay }, which of course sucks?

-- Simon

33
Yeah, sounds important.

Workaround: Run Lix with the replay filename as single argument. On Windows: Drag-and-drop the replay onto the Lix executable.



I'll have to see how hard this is to fit onto the existing architecture. Internally, for the file browsers, Lix uses a virtual file system that merges the user's writeable tree (./local/share/lix/ or equivalent Windows) with the Lix installation's read-only tree. But on self-contained Lix, there's only one tree (in the working directory) and you'll never notice any such tree merging. On Windows, Lix is always self-contained because I don't support Windows package managers.

Filenames (Lix's internal filename handling) are already either pointing into that virtual filesystem (they look up from the few fixed roots) or absolute (lookup ignores the roots and hopes that the OS fetches something useful). Virtual filesystem filenames come from the browsers. Absolute filenames come from the command-line arguments.

What we want for this bug: Somehow browsing with absolute filenames in a way that doesn't break too much existing browser UI.

-- Simon

34
Thanks to both of you for pushing this!

I'll be busy until Monday. During that next week, I'll stream more contest levels with that experimental version 4, and I'll test offline in addition. Thus, expect detailed feedback in roughly a week.

-- Simon

35
NeoLemmix Main / Re: Future of NeoLemmix development
« on: March 04, 2024, 11:52:23 PM »
namida is happy to merge end-of-game improvements (unless we screw that up), and I'm sure he'll  merge more good contributions. No need to fork.

You can still have a public repository for experimental NL work, for code review, ...

-- Simon

36
NeoLemmix Levels / Re: [NeoLemmix] PoPiPack
« on: March 04, 2024, 08:55:35 PM »
Good job to tie the loose ends together and release your half of the project!

It's a surprisingly hard decision even when one forsees no imminent progress. It's much better than letting it sit unreleased forever -- 50 levels is considerable! -- and you can always re-release if Dodochacalo reappears in a few years.

-- Simon

37
Minutes from the Mumble session.

Nobody has wished to continue into the dead state explicitly. Still, some people might want to do it (e.g., watch zombies walk?), but a prominent possibility to continue into dead state is confusing on its own. The freeze avoids this particular confusion, let's try it. If somebody really wants to continue into the dead state, we'll implement an option to neither freeze nor quit when no lemmings remain. The freeze is too useful to weaken it for the presumably rare wish to continue.

That means we choose the freeze over the pause to make a first PR against NL. That's because the pause would fiddle with too many assumptions of other speed controls. Nonetheless, neither of us wants to hammer any decision in stone here. NL can get additional solutions or improve on the freeze should the freeze suck.

Nuke will always prevent the freeze. Nuke will lead to quitting to postview. If you nuke with zombies, you'll see the zombies explode before exiting to postview. If you've already reached the freeze, the nuke will either exit to postview if no zombies exist, or unfreeze to show the zombies exploding, then exit to postview. (Technically: Activating the nuke forces NL to start another physics update despite the freeze. Without zombies, that extra frame of water/exit animation isn't shown then, not even during fade-out, nice.)

This design accepts that precise nuke solutions need manual pausing to prevent exiting to postview. It sounds practical because nuke levels are rare, and it doesn't worsen the user experience in nuke levels compared to 2023 NL. The fireworks take a few seconds, you have plenty of time to pause.

It would be nice if the freeze can work even if NL fails to load the graphic for the message on the minimap, e.g., when people update by putting only the NL executable into an existing NL tree. Our main worry is that the freeze will then look buggy. We have some ideas, possibly a once-per-NL-session dialog box, but no solution seems perfect. WillLem will ask namida what namida prefers for a PR here. Do others have a suggestion?

-- Simon

38
Do you (or others) have time to hop on Mumble tomorrow, Monday, 19:00 UTC?
Potentially, yes. I'll move a few things around and see you then.

All right, cool. If 19:00 UTC is hard, I can make 18:00 UTC or 20:00 UTC or 21:00 UTC. Let me know by the afternoon what's best, or hop on IRC tomorrow.

Everything else, I'll come back to it later, but it all sounds excellent and promising!

-- Simon

39
No worries with the poll; thanks for it, it helped me second-guess all this.

The poll said 4:1 in favor of the pause. I can't blame every single one of the 4 pause answers on the framing, and you preferred the pause before the poll.

My worry is now: If we make the freeze, but don't nail it perfectly, yes, we'll still be better than quitting, but we aren't as good as pausing (for a reason that I don't see yet). Are the pause wanters worried about a concrete reason? Are the pause wanters worried about a possible reason that might exist? Are you worried about this? What are the reasons?

Do you (or others) have time to hop on Mumble tomorrow, Monday, 19:00 UTC?

Quote from: WillLem
Quote from: Simon
Ah, a nuked level in general freezes now (when everybody has exploded and even if no zombies exist), and doesn't exit.]
I can't seem to reproduce this. Nuked levels exit as usual...

You are right, I can't reproduce this either. Sorry, I don't remember why I wrote this, either. Consider it fine, and If I ever find anything like it, I'll post full instructions to reproduce it in the future.

Quote from: Simon
There is more to write about zombies and nuke.

Regardless of freeze or pause, there is the decision if there is something of interest still happening. For this, we don't treat zombies as interesting.

Now I believe: Zombies become interesting once we are nuking. As a result, the nuke prevents the pause/freeze when only zombies remain. When everybody (regular, neutral, zombies) is dead, we quit. Reworded: In the decision if there is something of interest still happening, we test for regular lemmings alive, or neutrals alive, or traps eating, or nuke.

The fun part will then be: During the freeze with only zombies left alive, can we nuke? We won't advance to the tick in which the nuke is actively preventing the freeze. >_>;; In Lix, during the freeze, the nuke becomes a button to exit.

-- Simon

40
people seem to prefer pause, according to the poll results so far.

Because you've framed the question.

"Pause - that way, I can decide" -- you can decide even if we implement the freeze, because the freeze is optional anyway. Also, tasty swizzle: Who wouldn't want to decide.

"Also, it looks less like a bug/crash" -- we've both realized today that the current designs (of freeze and pause) have bug-lookingness the other way around. Feels like you're straw-manning the current (2024-02-23) freeze implementation with an early idea of the freeze that had no message.

"Freeze - [...] I'll only ever need to" -- that's a powerful nudge away from this option. Who has had the time to try both experimental variants? If you haven't played both, why should you waive your rights (by picking this option) to instead of being allowed to "I can decide"?

Even I am not sure if I ever need to bypass! E.g., nuke and zombies.



There is more to write about zombies and nuke. Either later tonight or these days. Exciting design ahead!

There is more to write about false dichotomies. Across both experimentals, you already have a 7-way option here (3 radio buttons + 1 freeze radio button, and 3 out of those 4 listen to the checkmark), with at most 2-3 of the 7 useful in practice, and now you're making such polls based on two unfinished designs. Put them both into git as two branches and see.

There is more to drill out of you here because you like the pause even after all of this. Again, later.

-- Simon

41
Advantages for pause: it doesn't look like a bug
all advantages into one feature :)

The buggiest-looking behavior is now after unpausing in the dead state. During dead state, you're gimping the frameskips because that's the only way you can bring the pause to support real-life patterns (extrapolate current state to end of time and see by how many lemmings we come short).

There is a nasty long-term issue here: 5-10 years down the road, NL's maintainer X (neither you nor namida) gets a bug report from player Y: The frameskip after the pause is broken. This will be a perfectly nice bug report against what you've considered to look less like a bug. It's easy for X to fix, breaking the guarantees that you've added.

The pause itself looks well-defined. The freeze also looks correct with the message.

I'd even bet that anything with a message (pause or freeze) will look more intended than anything else without such a message (pause or freeze).

-- Simon

42
was anything else happening besides the lemmings falling offscreen? Any trap animations it needed to wait for?

The level was your end-of-game test (some Crystal bars, 1 neutral, 1 zombie). No traps. The zombie was alive. The last dying lemming was regular (not the neutral; the neutral was already dead).

Quote
I'll need to add a check for the nuke specifically here.

Okay, cool, happy to re-test then.

-- Simon

43
First test results of your experimental NL 12.13 freeze version:

Out of habit, I placed only the executable in my existing NL dir and forgot the images (for the in-game messages during the freeze). NL works well until it finally wants to show the message. This produces many exceptions as one popup each, and the level continues to run and produce more exception popups even before I close the earlier popups. NL was hard to kill from the command line (impossible to type xkill or killall -s 9) because the popups stole focus (many times per second). Mouse worked, but NL has no X button to close the window. It managed to write a total of 7,000 lines into the log until I managed to close NL.

To close NL, eventually I thought of Alt+F4, and that worked. I believe that another solution would have been: Ctrl+Shift+F2 to switch to non-GUI Linux command line, kill NL from there, Ctrl+Shift+F1 to switch back to desktop.

Okay, in hindsight, the popups are practically unrelated to the freeze feature; if we want to do anything at all about this, we should first file those repeated exception popups (1 popup is enough) as a bug against the general resource loading. By the way, I'm happy that NL loads the things lazily, to start up more quickly. Nice.

I took the lo-res and the hi-res image from the zip into the NL tree, and that fixed the exceptions.



Now back to the freeze.

Yes, it prevents any physics advances consistently.

It appears impossible to bypass the freeze. I tried to fast-forward, to unpause, and to framestep forward. Nothing bypasses, nice. Not even when I rewound ~3 frames to before the freeze, then tapped or held the 10-second skip, NL would ever advance beyond the freeze.

The freeze appears to happen 1 tick too late. Example: I see the lemming in tick n. Then it falls out of the level, dies, and is not visibile anymore in tick n + 1. The lemming count in tick n + 1 is red and shows 0, correct. Nonetheless, I can now still advance to tick n + 2 before your message appears. The late freeze is mostly cosmetical, it doesn't break my play patterns. It merely makes me wonder why it overshoots.

Nuking brings an interesting design problem. The nuke generates 5-second countdowns, and you might run into the freeze (because you lost all normal lemmings and all neutrals), but there are still unnuked zombies (with countdowns from your nuke). This freezes, but it doesn't exit. Is this intended? Do I want this myself? (Haven't made up my mind w.r.t. nuke solutions.) Would others want this?

Ah, a nuked level in general freezes now (when everybody has exploded and even if no zombies exist), and doesn't exit. I believe it should exit, as it did in your pause experimental. Or do you have a new reason to freeze here?

-- Simon

44
Dialogs: Let's try other ideas than dialogs first ... Don't put important info only in a one-shot dialog.
OK, agreed. But, I'd personally be happy if that's what we end up falling back on: it gets the job done well enough, and if people choose not to read it that's up to them.

Right, let's do other things first, and see if that improves it for newbies.

More Coding Horror articles about the problems of dialog boxes and written instructions:

Quote from: WillLem
Quote
Cursor: ... on Lix: Scissors mouse cursor while replaying
This is a brilliant idea! I'd also suggest turning the cursor red for standard Replay mode, and blue for Replay Insert mode.

Do you mean red scissors and blue scissors? In insert mode, NL doesn't allow cutting the replay by clicking.

And as usual, I caution against signalling different meanings only by color. The blue R feels subobtimal already, but it's already much better than no feedback.

You can put an icon next to the cursor when you're about to insert. There is no good, simple, universal icon for inserting. comes to mind, which is complex.

-- Simon

45
General Discussion / Re: Simon blogs
« on: March 02, 2024, 02:15:38 AM »
No hidden hotkeys.
  • Every function gets a GUI button with the hotkey printed on it.
  • If it can't be a GUI button, e.g., directional select or priority invert, the function gets a tooltip as soon as it's useful.
  • Can you automate the function to reduce mental burden?
  • Esc is special. It's a common hidden key in games, and it's like the home button on smartphones.
Still, in singleplayer Lix, you don't even need Esc; you can nuke. The nuke has a GUI button with a printed hotkey.

No dialogs.
  • If you must display a message, display it without interrupting the control flow.
  • The classic essay on this rule is Death to the Dialog Box on Coding Horror, 2004.
  • Example: Level loading errors show in the Lix level preview screen. You can keep clicking levels.
  • Five years ago, I followed this to an extreme, removed the end-of-singleplayer dialog, and printed game outcomes into the level browser. Only when people wanted a next-level button, the browser would have become too crowded.
  • Dialogs break flow the most after you perform action/command X and usually get no dialog after X.
On hard-to-remove dialogs:
  • Menus (that we implement as dialogs) are okay when we consciously summon them for their unique content, e.g., the options menu.
  • The menu, if it is a modal dialog (i.e., you must finish dealing with it before you may continue your normal work), must still pull its weight. If we only have 1-2 small options, can we stick those into another existing screen?
  • I believe that dialogs are less annoying (but still annoying) when you expect a drastic context switch anyway and have no clear next goal.
Example: You return from game to the menu. I still want to avoid dialogs here, but they're less nasty here than elsewhere.

Example: You start a time-consuming computation with nontrivial results that you rarely need, e.g., mass replay verification from inside the GUI.

Counterexample: When you need the replay verification often, dialogs will get annoying. E.g., you maintain Lix and want to test all packs before each release. Run the replay verification from the command line:
$ lix --coverage replays/path/to/your/pack

Counterexample: After you save a level in the editor, you usually want to playtest it. This is a clear goal; you don't want strange dialogs to get in the way despite the drastic context switch between editing and playing. Thinking about this, this leads us to more design insight: The context switch between editing and playing a level shouldn't be drastic in the first place. You're working on a single level throughout, after all. IIRC, back in the day, GigaLem suggested a button in the editor to playtest immediately.

-- Simon

Pages: 1 2 [3] 4 5 ... 274