Thanks! No rush, I'll be busy for another week.

-- Simon

Do you think that this fix warrants a new release for CE? It has sat unreleased now for 7 weeks.

There will be Level of the Year 2024 and Design Contest 32 soon. CE has made it more interesting for me to livestream solving NL levels, and you'll get better feedback for newer versions.

-- Simon

Hi,

I apologize for promising a deeper explanation "at the weekend", and then taking 6 weeks. Life came in the way, no free weekends. I've only come back properly to Lemmings Forums this week.

Quote from: ∫tan x dx on March 04, 2025, 10:51:26 AM

Quote from: Simon on March 04, 2025, 12:41:17 AMhave you considered colliding only the foot?

Unfortunately, that is not going to be an option.

At least to preserve NL backward compatibility, you have options:

• You can import NL triggers as-is. Then you drown when your anchor (= 1 pixel under foot) is in the trigger.
  
• You can import NL triggers and shorten them vertically at the bottom by 1 pixel. Then you drown when your anchor is in the trigger or when your foot is in the trigger.
  
• You can import NL triggers, shorten them vertically at the bottom by 1 pixel, and expand them at the top by 1 pixel. Then you drown when your foot is in the trigger.
  
• You could import NL triggers, expand all 4 sides by 1, then move the expanded rectangle to the left by 19. Then you drown when the anchor and all of its 4 neighbors are 19 to the right of a trigger.

All these preserve the drowning behavior of NL. (The caveat is that #2 requires all water triggers to be at least 2 pixels high. Let's assume that all water indeed is at least 2 pixels high.)

Obviously #4 will turn out stupid as soon as you want to walk on the trigger. But walking on the trigger isn't relevant in this half of the argument yet; this part is only about NL backward compatibility. The claim is: To preserve NL physics, you have options with the trigger area import; all of these options lead to the same drowning/swimming/... (other NL activities) behavior for the existing water tiles, provided you scan for drowning/swimming/... at the compensating offset to the anchor.

Do you agree with this claim?

To minimize the risk for misunderstanding, I'd really like to be on the same page here first. This part is purely about NL back-compat and not yet about walking on the trigger areas.

---

Let me know when you have released binaries and need the space for more user feedback or user levels. Happy to make a board for NeoLemmixSharp.

Or do you prefer the feedback directly on Github?

I had a few first attempts at compiling the source; there are Linux C# environments. But it was 7 weeks ago and I'd have to dig for the exact errors. I'll let you know when I have a few free evenings to attempt it for good.

-- Simon

Quote from: WillLem on April 13, 2025, 05:29:39 PM"think first, do later" comes with experience

Motivation: It's more expensive/annoying/time-consuming to put the bugs in, test, and take them out, than it is to write the correct code in the first place.

With experience, you can anticipate the typical bugs that can arise.

It's better to design the bugs out of existence than to test for them. With experience and sense, you'll see more opportunities to design bugs out of existence. You can't always do it: The better design can be expensive to retrofit, or you must remain backward-compatible to the old design, or there isn't even a theoretical way to design the bugs away.

Quotecan this then prevent a more experienced dev from getting things done?

Yes.

Neutral Lix don't exist yet because I want the level format to express loose single lix (pre-placed lemmings) and player-assigned hatches/exits, and this cannot be backward-compatible. Roadmap for neutral lix. Physics changes in general are hard, everybody must update to netplay with each other. I like to bunch physics changes and have them at most once per year, but it makes public testing really hard; can't iterate naturally.

TripleA, a networked turn-based strategy game, is still on version 2.5 from 2020-2022. They didn't release 2.6 in 2022 and they've had trouble releasing 2.7 since October 2024, i.e., for half a year now. One problem is manpower, the other is getting everything to work with public netgame servers.

The stable 2.5 has at least one nasty bug that affects normal players. When you assign casualties to your aircraft, you usually want to kill your aircraft with the least fuel remaining. Instead, the engine kills a random aircraft (probably according to internal unit IDs), and you're stuck with surviving aircraft that can't land and will ditch into the ocean in addition to the assigned casualty. This was fixed in 2021, 4 years ago, but that fix hasn't made it into stable yet.

It's fundamentally the same problem as in Lix: Some backward compatibility concern in the ecosystem is blocking the release of perfectly good things. I don't need the server-side back-compat, I haven't played people from the internet. Instead, I'll host on my own machine and tell friends to grab the same TripleA nightly from github for netplay. Aircraft survive, and happy Simon.

-- Simon

Thanks! Sorry for asking again about software fullscreen. Yes, you wrote about it.

Lix doesn't react to external resizing of the Lix window, neither when windowed nor when in software fullscreen (= really a fullscreen-sized window without title bar).

Lix doesn't react to user moving the Lix window to a different monitor, neither when windowed (which shouldn't matter) nor when in software fullscreen (here, it matters, as you described).

Quote from: Silken Healer on April 12, 2025, 02:04:09 PM

QuoteThen there is the problem that "turns Lix window into entirely black square" for hardware fullscreen. Instead, you want the Windows hotkey (Winkey + Shift + Left/Right).

I think this is correct. Apologies, but I'm struggling to comprehend the meaning of what you were trying to convey here. I think this may be due to English being your second language. Just to clarify, the black square is only for hardware fullscreen if you try Windows Key + Shift + Left/Right arrow

Sorry for the ambiguous terseness. I meant: For Lix in hardware fullscreen, you describe the following problem: You want to move Lix (in hardware fullscreen) to a different monitor, and to do that, you press Winkey + Shift + Left/Right.

You observe: Lix turns into a black square and moves to the target monitor. Graphical relics of Lix remain on the source monitor.

You expected instead the result of Winkey + Shift + Left/Right that you know from other games, which is: Lix moves to the target monitor fully visible (not as a black square). Lix leaves no relics on the source monitor. Lix remains fully playable.

Quoterecord some footage later if that's helpful, I think it will be a lot easier to show

Thanks for the offer, yes, such a video will eventually be helpful.

Don't rush it. The first part of the investigation into these bugs must be: I'll have to read the Allegro documentation. It's well possible that Allegro expects me to do something with the monitors in the Lix code. I'll have to see when I find time for that. I'm still busy.

I had never expected people to move fullscreened Lix (either mode) to a different montior. There is no code in Lix whatsoever about this. And I had hoped that Allgero would somehow put hardware-fullscreened Lix on the right monitor. Again, no code in Lix about this.

-- Simon

Sorry, no time to investigate yet, but I'd like to understand what bugs remain.

You want Lix to open on the primary monitor when you use hardware fullscreen, not on monitor 1. Okay, I can look into the Allegro 5 API, maybe I can solve this in Lix itself.

Where does Lix open when you choose software fullscreen?

Then there is the problem that "turns Lix window into entirely black square" for hardware fullscreen. Instead, you want the Windows hotkey (Winkey + Shift + Left/Right).

Do need hardware fullscreen? Is the point to make Lix pixellated, or are you working around technical problems of software fullscreen? This investigation will be a lot of work. Is some of this stuff broken for software fullscreen, too? E.g., what happens when you run Lix in software fullscreen, then press (Winkey + Shift + Left/Right)?

-- Simon

Quote from: Simon on March 19, 2025, 12:31:38 AMWithout the warning, this isn't ripe for a stable release

No, Simon, I've put it as-is into Lix 0.10.31, which I've released.

I haven't had time yet to make the nonintrusive warning. I still want small red warning text to appear next/above/below to your long typed title.

-- Simon

Lix 0.10.31 released.

Download for Windows 64-bit -- recommended
Download for Windows 32-bit -- fallback for ancient machines
Download for Linux 64-bit
Source code
Changelog
Issue tracker

How to update

Quick and dirty: Extract over your old installation. Level moves will then result in duplicate levels that remain in your level tree.

Clean method: Extract to new directory, then copy these directories from old Lix into new Lix:
user/
replays/
...and any levels that you've built yourself or added manually.

It's a boring release -- you only get features that I've already described elsewhere:

Unlimited text-entry for level title and author: The editor's text-entry fields for level title and for author don't prevent typing anymore when you've filled the field. Text length is now unlimited.

Don't put longer titles than before. If you enter too long a text, the level browser will abbreviate it as before.

The unlimited title length is not yet how I want it to be. In the editor, I'd like to warn about too long a level title. But I haven't had time to implement that warning yet.



Allow a livestream note in singleplayer. Create the text file ./user/streamnote.txt and enter lines, e.g., "Help solve!" or "No spoilers!" Lines will appear in big font until the first empty line; remaining lines will appear in small font. The livestream note replaces the buttons next to the skill panel; use their hotkeys instead. If you don't create a livestream note, the buttons appear as before.

---

The main point of this release is to react to the recent development of the D compiler, DMD 2.111.0. It's been a long time since they released a new compiler, and the newest version has a new bug or two, and it reacts differently to some speed hacks in my code. I've adapted Lix to not crash even when you build with the most recent compiler:

• Fix a crash during play after building with the recently released DMD 2.111.0. The crash was: The copying method in struct for a lix crashed on return.
  
• Fix a crash during play in LDC debug builds. The crash was: Emplacing classes into the Debris struct triggered the assertion "chunk is not aligned".
  
• Improve compile times. On my Intel i5-6600 (4x 3.3 GHz), it takes 3.5 seconds to build Lix in debug mode now, 34 % faster than the 4.7 seconds from before. Dependency build times and link times are as before.
  
• Bump dub package optional from 1.3.0 to 1.3.1 to fix deprecation warnings.
  

I'm proud of the improved compile times. For me, that's the real excitement of this release. DMD 2.111.0 has a feature to show me where the compiler spends its the time in the Lix source. I've found and replaced some slow parts (some metaprogramming magic, and a recursive template with 380 arguments) with a down-to-earth solution, and it's still expressive.



-- Simon

Here is a 64-bit Windows executable that, in the editor, removes the length cap for title and author. It doesn't show any warnings yet: https://www.lixgame.com/etc/lix-0.10.30-unlimited-title.exe

My unstable repo has this too, in the branch master.

Without the warning, this isn't ripe for a stable release yet. It merely gets around Silken's silent data loss, the truncation of the title when he saves in the editor.

-- Simon

Quote from: Silken Healer on March 18, 2025, 02:35:43 AMlonger title myself in a text editor and then edit the level in Lix it doesn't save over it with a truncated title

Ah, yeah, that truncating is awkward.

Idea: The editor fields (title, author) should never cap. Instead, whenever the text is too long, the fields should warn you. Here, we define text to be too long when the level browser would truncate it in a few different standard-sounding resolutions. And warnings will be red text that appear next to the field, never a new clickbox.

Quote from: WillLem on December 05, 2024, 01:28:41 AMIdea: allow unlimited characters, but warn the user if they go over the amount that will play nicely with Lix UI. [...] showing a label below the title field that says "title is longer than the UI's limit"

Yeah, in hindsight, you had the right idea first. Silken has now given me yet another reason why it's better.

-- Simon

Sorry, with "counterintuitivity", I wasn't talking about reactions to solidity. I'm aware of your desired level of back-compat. I mean, I was already not prodding for, e.g., climber outside terrain.

I'll try at the weekend to make my concern clear enough. Not much time today.

-- Simon

Never name a function "check".

Check incoming messages ... and then what? Check time, check hotkeys, check terrain, what does it mean?

Example 1: You examine the terrain, and you want to fall when you're not standing on terrain. Then name the function "fall", "maybeFall", or (worse) "reactToGround". These names are all better than "checkTerrain" or "checkFall" because they imply a consequence/side effect.

Example 2: You examine the terrain, then report to your caller whether there was terrain, and you don't react to the terrain yourself. Then name the function: "isSolid", "hasTerrain". Again, these names are all better than "checkTerrain" or "checkFall". They imply that the function has no side effects.

Example 3: You examine your motion, not the terrain, and you report some aspect of the motion to your caller. Again, don't name it "checkFall" nor "checkFalling", because that can be taken to mean a function as in example 1, where you react to the terrain and decide to fall. Name it "isFalling".

Example 4: You take at a directory name, look at the filesystem, and create the directory unless that directory already exists. Don't name it "checkDirectory" nor "checkDirExists", neither implies creation. Name it "ensureDirectoryExists" or "mkdirp".

With the name "checkX", you're not outright lying, but you triple the possible meanings:

• The function does X if Y.
  
• The function does Y if X.
  
• The function reports if you are already X-ing.
  

Instead of "checkX", consider "X" or "Y" or "reactToX" or "maybeX" or "isX" or "ensureX" or "warnAboutX" or ...

If you have a side effect, name the function after the side effect, not after the condition that triggers the side effect. "openBrolly" or "maybeOpenBrolly" is better than "reactToFallDistance". Can you inline the condition into the calling function so that "openBrolly" always opens the brolly, and doesn't examine the fall distance anymore? You can refactor the caller, too, if he gets too long.

Faller.perform():
    moveDuringFall;
    if grounded:
        land;
        return;
    if fallDistance > limit:
        openBrolly;

Inlining the condition is sometimes good, sometimes it's bad. Expressing both X and Y at the call site is only one possible alternative to naming the called function "checkX" with silent dependency on Y.

In rare cases, you really want to hammer it home that the function only X-s if Y, or only Y-s if X. Again, "checkX" won't satisfy your need. Consider a stupidly long name, e.g., respondToAllMessages_ExitIfWeReceivedShutdownMessage. It's honest, and it can reveal a refactoring opportunity.

-- Simon

Thanks for looking at this so quickly! Happy to test it when you release binaries for the next time. I don't have a Delphi build toolchain here.

-- Simon

Quote from: ∫tan x dx on March 04, 2025, 10:51:26 AM

Quote from: Simon on March 04, 2025, 12:41:17 AMhave you considered colliding only the foot?

gadgets can now act as solid terrain.
hitbox of such a gadget will have to be treated identically to terrain.
Hence, anchor pixel checks for terrain/gadget collision (solid gadgets), foot pixel checks for other gadget collisions (non-solid gadgets).

Right, I had seen gadgets-as-solid in your document, and I don't see how it is a counter-argument to colliding only the foot (never the anchor) for drowning, and only the anchor for walking on water. Neither from a conceptual standpoint, nor from a technical standpoint, nor from performance.

I'll write a proper argument to this on the weekend.

Quote from: namida on March 06, 2025, 12:50:02 AM"pin inside the wall" setup, the climber passes by this flamethrower safely. With the pin outside the wall, he gets burninated.

Horizontal change vs. NL, hmm. It's more intuitive to collide with gadgets on the outside, but that will break compatibility more than tan x wants to break.

You're right with the flamethrower for out-of-wall pins. And your oh-noers would fall when you bomb mid-climb.

Quote"pin inside terrain", although perhaps counterintuitive from a visual point of view

This visual counterintuitivity is the heart of the matter.

The visualization of the trigger area shouldn't rely on implementation choices. Tileset designers and level designers don't write physics code. Compared to what NL 12.14 shows, you should show the area one higher, regardless of implementation. It should look like it collides with the lemming when it does collide.

Tileset designers and level designers have fallen for the misdesign in the past. Now tan x is finally fixing the bottom (tileset designers won't accidentally allow walking across the bottom of water anymore), good. But then it's painful to see more complicated physics rather than a fixed top, too.

-- Simon

Removed the read-only setting from editor bug board.

-- Simon