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

Quote from: Moderation LogMoved "[SUG] Sound Schemes" from "Community Edition" to "Bugs & Suggestions"   
Moved "[SUG] Welcome Screen enhancements" from "Community Edition" to "Bugs & Suggestions"   
Moved "[SUG] Assign Fail Sound" from "Community Edition" to "Bugs & Suggestions"   
Moved "[SUG] Multiple player profiles" from "Community Edition" to "Bugs & Suggestions"   
Moved "[BUG][FIXED] Remove Update Message Box (points to NL site)" from "Community Edition" to "Bugs & Suggestions"   
Moved "[SUG] Replay Insert Mode / Replay Editor updates" from "Community Edition" to "Bugs & Suggestions"   
Moved "[SUG] Non-Windows-dialog alternatives to the level select etc screens" from "Community Edition" to "Bugs & Suggestions"   
Moved "[BUG] Crash after quit: Press ESC twice during level preview" from "Community Edition" to "Bugs & Suggestions"   
Unlocked "[Potential Bug] Fencers no longer turn around when hitting steel"   
Moved "[Potential Bug] Fencers no longer turn around when hitting steel" from "Closed" to "NeoLemmix Main"   
Moved "[No Bug][Player] Sliders Exiting in Midair If Still Dehoisting" from "Closed" to "Closed"   
Moved "[BUG][PLAYER] Slider lemmings can shimmy across the bottom boundary of the level" from "Closed" to "Closed"   
Moved "[SUG][PLAYER] Display Neutral Lemming Count" from "Closed" to "Bugs & Suggestions"   
Moved "NeoLemmix Bugs & Suggestions Subforum Rules" from "Bugs & Suggestions" to "Closed"

This is all of my uprooting from tonight.

In hindsight, I should have moved all of them with those self-deleting redirections. The clutter in the list of recent topics on the homepage would have been acceptable at 5-6 moves.

-- Simon

I've moved all the NL engine bugs to either NL closed or to CE bugs. This emptied the NL engine bug board.

What's with the NL editor bug board? Shall people file new bugs against the editor there? Which editor is that? Is it Will's editor that covers SuperLemmix and NL? I'll keep the editor bug board open until somebody complains. :-)

CE has two sub-boards now, one for open bugs and one for closed bugs. (The closed bugs contains some moved-topic redirects that will delete themselves a week.)

-- Simon

I've moved this from the NL bug board into the CE bug board. The alternative was to move this into the NL closed bugs.

WillLem, move it as you see fit.

-- Simon

Quote from: namida on October 19, 2024, 11:17:02 PMthis will need to be tested more thoroughly.

I assume that at least one of these is correct:

• People have tested this and are sliently happy with it.
  
• People aren't annoyed with whatever negligible bugs this may have left.
  
• NL physics won't update even if this still has odd physics.
  

Therefore, I'll move this into the closed NL bugs unless people object within 1-2 weeks.

-- Simon

Quote from: namida on December 21, 2015, 02:47:05 PMThis board [NL bugs] remains open so that in the event a third-party fork (or editor) is developed, people's suggestions will be here.

This means that the NL bug board should become the CE bug board.

I'll reopen the NL bug board and rename it to CE bugs. WillLem is a moderator already.

The alternative is to file the CE bugs on the CE main board, but WillLem prefers a separate bug board.

-- Simon

NL CE 1.0 in Wine 10.2 on Arch Linux.

• Start CE.
  
• Click in the main menu to go to a level preview.
  
• Wait for the fade-in to finish or not, it makes no difference.
  
• Press Esc to start the level preview's fade-out.
  
• Press Esc a second time, either before the level preview has finished fading out, or before the main menu has finished fading in.
  
• Watch the main menu fading out.
  
• See NL crash. Screenshot of the error box is in the attachment.
  

20-second video of the crash

Expected instead: No crash. I should get the same result regardless of how often I mash Esc during the fade-outs.

The program quits cleanly when I wait until the main menu has finished fading in before I press Esc the second time.

No data is lost. The program has already saved all user options and level results before it ever tries to quit from the main menu.

-- Simon

Quote from: Simonuse only the foot (and never the ground under the foot) for both terrain and gadgets

Ah, yes, my wording was unnecessarily wide. I don't want to focus on the terrain collision here.

Let me retract the quote and ask instead: When you collide gadgets with lemmings, instead of colliding two pixels (the foot, and one-below-foot), have you considered colliding only the foot?

The conversion work stays similar: On importing NL tilesets, you'll have to change trigger areas either way. Either you shorten their height, or you raise them. And you collide at one new position (where NL didn't collide), at the foot.

But it improves UX. All three of tile designers, level designers, and players will profit, as in my paragraph "The cyan outline is fairer UX-wise [...]". Isolated from any programming/redesigning work/bugs, do you see value in the cyan box, compared to the pink area?

-- Simon

You raise the trigger rectangle by 1 pixel at tile-import time.

I'll argue: The cyan outline is fairer UX-wise than the pink rectangle. It's now obvious that walking across the grey surface is deadly. And it's obvious for tile creators (who must define the pink/cyan rectangles) to avoid the typical mistake of making the bottom row harmless. Tile creators can now match the visible rectangle to the visible water, and get correct physics.

You already give no guarantees that trigger areas rotate as in NL. And different gravities have no precedence in NL. You can also do anything you like with different gravities without breaking back-compat.

namida, what exactly do you fear for climbers? I imagine that tan x will keep the climber foot inside the wall (what I consider strange, but necessary for NL compatibility)? All collisions will happen a pixel higher, against trigger rectangles that also moved higher. I don't see a problem. What is it?

-- Simon