Menu

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.

Show posts Menu

Messages - Simon

#46
General Discussion / Re: :(
May 04, 2025, 10:39:30 PM
Hi! Please keep the fanart safe for work. Don't add genitalia.

-- Simon
#47
Hi,

I will livestream the candidates for Level of the Year 2024. The stream will be Saturday, May 10th, starting 16:00 UTC.

Help solve the levels in chat! (Unless you had already known the solution by heart before the stream.)

Stream will be at: https://www.twitch.tv/simonnaar

-- Simon
#48
Reviews / Re: kaywhyn's L2 Playthrough, Full Gold
May 01, 2025, 12:29:30 AM
Well done!

Full gold is already finnicky.

Quote from: kaywhyn on April 30, 2025, 08:11:08 PMplatformer
backroute power the skill has as a result of it adding height AND the fact you can platform anywhere

Yes, platforming anywhere is powerful, and the bricks are thick, they gain 2 pixels of height. I'm still undecided if the NL platformer or the L2 platformer is better. If the L2 platformer is better for its versatility, Lix's platformer should really have been as thick as the L2 platformer.

Even more powerful is that the platformer enables geoo's crawling setup. Bash into a wall, cancel. Seal off the top of the basher hole with 1 or 2 platformers in such a way to leave a 1x1 hole that the lemmings can enter. When lemmings enter such a 1x1 hole, they crawl vertically through the terrain. Or make a wider hole, let the lemmings enter, then narrow/fill the hole with a platformer brick. Again, the lemmings will crawl.

The only skill that's even better for crawling is the roper.

Quote from: kaywhyn on April 30, 2025, 08:11:08 PMkieran millars' and Ste Woz Ere's L2 packs

I'm sure you'll enjoy Kieran's and Ste's levels. Out of the two, I've only played Kieran's pack, and it shows previously unrealized puzzle potential in the 51 skills. It's harder than vanilla L2, but that's expected, and the full gold playthrough is ample preparation.

-- Simon
#49
Lix Main / Re: Lix title character length limit
April 30, 2025, 11:58:57 PM
I had forgotten about the filename limit in the save dialog.

0.10.31 (and everything before) does: Filename gets truncated at the end of the box.

I want instead: People should be able to put long filenames. I should make the box unlimited, and there should be no warning for long filenames.

There will be a small worry about filesystem-imposed max lengths for filenames. I don't know how Windows Lix will behave for absurdly long filenames. I assume: If I unlimit the filename entry box do add nothing else, and user puts absurdly long filename, Lix crashes and writes an exception to the logfile, and the level gets lost.

Unsure how much work I want to invest here, i.e., if I should ship the unlimited entry box without catching the exception. If I catch the exception, I'll have to write new GUI feedback to tell people that the level wasn't saved. Data loss avoidance dictates that I should invest the time if I unlimit the box. Otherwise, people won't trust Lix.

-- Simon
#50
Sure, release what you have, under what name you like best.

Please don't delete the thread! Your ideas behind the project are worth preserving, and there is no shame in releasing only a part. You can always edit your posts with the [s][/s] strikethrough tag, e.g., to cross out "that's what I set out to do".

-- Simon
#51
Hi, welcome to the forums!

Quoteconsistently assign a digger to a basher (both scenarios in a crowd of lemmings)?

L2's mouse-hovering prefers existing workers over existing walkers. But the selection box of an existing worker is substantially enlarged to the right, and I believe that this is independent of the existing worker's facing.

Therefore: Select digger, and click to the right of the basher. This should assign digger to the basher.

Bashers in particular have a visual/positional oddity: Their location (invisible, the game tracks it internally) lags behind their visible sprite. During his swing, the basher looks more forward than he really is. (To see this, assign exploder to a basher; the countdown will lag behind.) Assuming your basher faces left, it's another reason to click further right of where the basher appears to be.

Quoteassign a skill to a left facing walker/ lemming

Directional select a.k.a. directional force isn't in L2. Yeah, it would help.

-- Simon
#52
Quote from: WillLem on April 26, 2025, 08:12:11 PMFixed the link

The link in the OP still fails. The wrong link ends in .../NLXCE101 with an X. After a few hours, I took the liberty to edit OP and put the correct link.

The correct link is: https://tinyurl.com/NLCE101

I've confirmed that CE 1.0.1 fixes the crash after doubletapping Esc. Thanks! Looking forward to playing Level of the Year 2024 with CE 1.0.1.

-- Simon
#53
Thanks! No rush, I'll be busy for another week.



Edit: WillLem has released 1.0.1. I confirm: The crash after double-tapping Esc is now fixed.

-- Simon
#54
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
#55
Other Projects / Re: NeoLemmixSharp
April 14, 2025, 10:46:35 PM
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
#56
General Discussion / Re: Will's Blog: Dev 101
April 14, 2025, 09:45:44 PM
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
#57
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
#58
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
#59
Lix Main / Re: Lix title character length limit
April 11, 2025, 09:29:41 PM
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
#60
Lix Main / Re: Lix 0.10.30 released
April 11, 2025, 09:16:56 PM
Lix 0.10.31 released.

:lix-cool: Download for Windows 64-bit -- recommended
:lix: Download for Windows 32-bit -- fallback for ancient machines
:lix: Download for Linux 64-bit
:lix-evil: Source code
:8(): Changelog
:8:()[: 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. :lix-evil: 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