Bots Are Stupid is a puzzle programming game, in which you to guide your bot via a set of commands to the exit. Despite the differences it reminds me of Lemmings since e.g. move right lets your bot just continue to run right and sometimes to its doom if you don't interfere with other commands. It can be sometimes finnicky with the timings and I haven't played far yet. As extra goals the number of lines and the time needed for the bot to get to the exit are shown.

Due to issue #488 some errors aren't logged into log.txt, although the error would show on console/shell.

On Win the console is suppressed, so that it can happen that no error feedback is given (in case no error window appears). As a workaround piping with e.g. lix.exe 2>a.txt produces the error message in a.txt.

Edit: First option - building with debugging libraries

Only a first draft:

Options to get the Allegro debugging libs and dlls are nuget package or (mingw) release from the github page of Allegro 5.
From my experience: Running after building with the nuget release ones would need as extra dependencies Microsoft building tools (debugging variants of standard dlls, not tested since no access to these tools). Whereas the github release needs mingw libraries (which have a better availability).

For the dlls just choose the ones with 'debug' in the name.
For libs I know no other way than to rename them. (This means you can't have non-debug and debug libs at the same time in your toolchain.)
For nuget you already have lib-files and you have to choose the ones with 'debug' in the name. But for using them I had to remove the '-debug' part of the name, so that they look like the non-debug ones.
For the github release there are no libs. (For build with optlink you can use implib to create some.) As one way to get files that work like libs, you can rename the liballegro_....dll.a to lib files. Again you have to choose the ones with debug in their name but rename them without the '-debug' so that they look like the regular lib files, e.g. 'liballegro-debug.dll.a' to 'allegro.lib' or 'liballegro_acodec-debug.dll.a' to 'allegro_acodec.lib'.
There are maybe/probably more elegant ways to achieve this but this is how it worked for me.

Building is as usual.

If building with Allegro debug libraries was successful there should be an allegro.log (gets huge fast) created after starting the game.

The color for Global Moderators is hardly readable with default forum style. Example is attached.

It might be more convenient to have a fixed choice of common resolutions for hardware fullscreen and windowed instead of having to type it oneself.
I would suggest: 640x480, 800x600, 1024x768, 1280x720, 1280x1024, 1600x900, 1680x1050, 1920x1080 (and maybe 1366x768)

1366x768 is a common resolution for old non-hd laptops. Windowed is fine for me but it doesn't work in hardware fullscreen (defaults to 640x480 window). My standard resolution is 1920x1080.

The option to put in custom values could be left to editing the options.sdl.

Maybe add a confirmation window for changing the resolution, that you have to confirm within x secs or it resets to the previous value and add an information when it defaults to 640x480 window for nonviable resolutions.

Edit Simon 2024-02-05: Split off Simon streams Lix, 2023-11-26

Quote from: SimonI solved mobius's Eye of the Needle -- two lovely ideas, excellent puzzle!

Quote from: geoo on November 27, 2023, 09:57:38 AM
For Eye of the Needle, your solution differs from the intended one quite significantly. Removing the feature that Simon exploited on the left, or bumping up the requirement to 8/10 (at the cost of slightly trickier execution) could work here.

Removing the terrain piece wouldn't prevent the core of Simon's solution.

Spoiler

You can instead just platform in the miner tunnel.

I have attached a solution which saves 8/10 and is very well doable timingwise. It has a variation to the replay of the collection though.

At the moment there is only a button to flip tiles horizontally in the editor. There is a feature wish issue 115 to add a button to flip tiles vertically to the editor as well.
You can at the moment have the result of flipping vertically by turning two times and flipping horizontally.
The question is if nevertheless a button to directly flip tiles vertically would be helpful.

Edit Simon: This is now github issue #429: Search dialog, implement scrollbar and up/down nav.

---

At the moment the search list only shows 18 of the matching results.
Imho all matching results should be shown though.

Nepster Lix has 3 Outtakes levels that have time requirements in the title. The question is how to make them viable.
There is an option meant for debugging to turn on phyus and FPS. phyus (physics units) count like a clock, currently start in singleplayer at 45 phyus and first lix spawn is at 60 phyus, 15 phyus are 1 second. So as a rather hidden option there is already a clock in the game to give some legacy support.

This question was topic of an IRC (#lix) discussion, which is included at the end of the post.

The spirit of the game is to have no skill external requirements like a clock. Nevertheless is it not fully against this spirit to have a counting up clock, especially since there is already a phyu counter. Having a proper clock option would only make it more accessible but could lead to time limit desires. I think it is worth the risk.

In my view if it is introduced there should be the option between no clock, normal clock and phyus.
Normal clock should start at first spawn for overarching compatibility. (Though maybe there are reasons to do it otherwise.)

(If it is implemented there could be a need to adjust the time requirements in Nepster Lix levels according to the start of the normal clock.)

Full discussion w/ further details of possibilities and problems:
[14:18] <F_> Nepster has 3 levels in outtakes with time requirements in the title, question is if the phyu count is added to the title to help tracking if it was successful.
[14:20] <F_> Problem is that phuys are not shown by default.
[14:21] <F_> Further problem is if it is wanted to discourage such possibilities of external challenges like beat levels in such and such a time.
[14:27] <@SimonN> Hi
[14:28] <@SimonN> Yeah, time limits in titles are in seconds, and the engine measures in phyus that are nowhere shown.
[14:29] <@SimonN> My hunch is not to support this further. But Proxima likes a general clock (counting up) in seconds. Thus there is weak argument to support this kind of level.
[14:30] <@SimonN> The fear is: When clock is too prominent, people will make time challenges, and then the engine should support those.
[14:30] <@SimonN> The absence of the clock is really a nudge away from making time challenges.
[14:31] <F_> I understand, yeah that's a legitimate concern. On the other hand it would show the desire for such chanllenges.
[14:31] <@SimonN> Hmm
[14:32] <F_> It is a deliberate decision which had it's reasons I can understand. Time limits can be used in some cases very detrimentally.
[14:33] <@SimonN> It's hard. I cut it in one go with cutting variable spawn interval, and the focus was always on cutting VSI.
[14:34] <@SimonN> No clock means less things to worry about.
[14:34] <@SimonN> Frees space in the panel.
[14:34] <F_> yeah by default
[14:35] <@SimonN> Well, technically, there is a clock whenever you have the tweaker open, it shows the current phyu.
[14:35] <F_> The phyu counter on the other hand is in some sense a clock though it's mainly meant for debugging.
[14:35] <@SimonN> And that, yes
[14:35] <@SimonN> We have to reel Proxima into the discussion.
[14:36] <F_> yeah, it's generally the question if there should be a forum post for broader discussion or not
[14:36] <@SimonN> Time in seconds is also ill-defined. In 2009, time ran from 4 seconds before first spawn. Then later, it ran from 2 seconds before first spawn.
[14:37] <@SimonN> Makes sense to warm it up again, yeah
[14:37] <F_> Well that's not different for the phyus either?
[14:37] <@SimonN> Phyus always have first spawn at 60.
[14:37] <@SimonN> Singleplayer merely starts at phyu 45 and multiplayer starts at phyu 0. It's all smoke and mirrors
[14:38] <F_> ah I see
[14:38] <@SimonN> Reason for this: I didn't want to break replays that count in phyus and assume first spawn at phyu 60.
[14:38] <F_> okay
[14:38] <F_> You could start the clock with spawn.
[14:39] <@SimonN> Pre-placed lix are interesting feature and need a decision for how long before first spawn they start walking.
[14:40] <@SimonN> It's possible to nail it all onto first spawn. Everything before is just eye candy.
[14:40] <F_> I see yeah.
[14:41] <@SimonN> In NL, pre-placed lemmings walk from start of time, which is ~4-5 seconds before hatches open.
[14:41] <F_> In that case it would just have to move to when that happens.
[14:42] <@SimonN> Yeah, difference between stragglers walking and first spawn is not so big in NL either. We may as well remove all difference and have stragglers start on first spawn.
[14:43] <F_> one possibility
[14:44] <F_> This depends in the end what the feature is ought to offer. But it is not implemented yet.
[14:46] <F_> If a clock is reintroduced then I would want the option to decide if phyu or time or no clock is shown. If you have to feature to disable clock then it would be an argument against supported timed levels.
[14:56] <@SimonN> Hmm. No clock by default, and you can choose to see phyus (with first spawn at 60) or seconds (with first spawn at ?, probably 0.00)
[14:57] <@SimonN> And trophies will always save with phyus, but display nothing/phyus/seconds according to clock on end-of-singleplayer.
[14:57] <@SimonN> * according to clock option.
[14:58] <@SimonN> I have a soft spot for no clock, because it clearly shows what the game is about.
[14:59] <F_> hmm
[15:01] <F_> That sounds like a good compromise. My perspective comes from level maintainance, how to make them viable.
[15:01] -__:#lix- lemmingsforums.net: Re: Different Types of Levels [Proxima] <https://www.lemmingsforums.net/index.php?topic=5787.msg93908#msg93908>
[15:02] <@SimonN> Level archaeology >_>;;
[15:02] <F_> yeah
[15:05] <@SimonN> Brushing and polishing them.
[15:06] <@SimonN> It's sensible and supports the general idea that Proxima wants the clock even for normal play.
[15:07] <F_> In a hidden way it's in already with phyu count, it just makes it more accessible. (Which can on the other hand in turn wake up desires.)
[15:08] <F_> I think it's worth the risk, but it's your decision and of the community.


The experimental next level feature offers going to the next level even after Escaping or Nuke when you haven't won the level.
I'm curious how others think about it.

The issue #208 'Editor: re-click window-opening button closes modal window' is I think an important quality of life feature wish. I think I'm quite used to the mechanism that reclicking closes the opened window in games or that one can click on another button to go to another window.

Lix should build 32bit binaries with the compiler LDC as well. (--compiler=ldc2 --arch=x86)

I ran into the problem that the linker didn't want to accept the provided 32bit libs and win32.res. No clue why, but with newly build win32.res and fresh nuget libs it worked.

Issue#421
There is technically no error since if you download ldc2-1.26.0-windows-x64.7z as said in the build notes there is only one lib folder.
Dullstar probably downloaded the multilib version to which there is the installer as well, so it is nevertherless right to add the instructions for multilib as well.

(The build notes state explicitly: "Download the D compiler LDC, version 1.21.0 or newer;
choose the download that ends in "-windows-x64.7z":"
Nevertheless multilib should become standard since that's what the installer installs, Win 7 and Wine have only at the moment the known problem with LLVM. lib64 is as well the name for the 64-bit folder with dmd as well, so this would benefit from a rename as well.)

The Lix dependency optional has at least since v1.2.0 itself a new dependency, vibe.d.
The questions is whether this is needed since it bloats the Lix build.
To get that clear there should be filed an issue with optional.

Nasty compiler bug as a reminder:
Class with unimplemented interface method compiles, links, then segfaults, if inherited through abstract base class -  Bugzilla 21321

"DMD 2.094.0 on 64-bit Linux.

    interface I {
        int f();
    }

    abstract class A : I {
    }

    class B : A {
    }

    void main()
    {
        I i = new B();
        i.f();
    }

This program compiles, links, and then segfaults at runtime once i.f() is called. The call to i.f() is necessary to trigger the segfault.

Expected instead: This program fails to compile.

The compiler should recognize class B as wrongly implemented because B doesn't implement int f(). This definition of class B shouldn't compile. (Or, if you disagree whether the definition of class B should compile, then, at the very least, the compiler should recognize B as abstract and the line "I i = new B();" should error. But I encourage that this empty definition of B itself be an error.)

The impact of this bug is that programs will compile even though their types do not satisfy their interfaces. This breaks a basic promise of the type system: We shouldn't have to call all possible methods in all possible derived classes at runtime merely to find what we should implement.

Workaround: Write "class B : A, I" instead of "class B : A", then we get the correct compiler error already for the definition of the class, even when we delete all code in main().

Related but different bug: "Unimplemented methods of interface are not reported as errors during compilation."
https://issues.dlang.org/show_bug.cgi?id=21184
In that bug, the program compiles, but fails to link."

It is possible that "6 Gaps, 5 Builders" got easier due to a physics change from 0.6 to 0.7 ("Builder creates brick further ahead, like in NL. No builder backstep."). So the question is if it should be downranked or fixed?

Lix went through multiple physics changes. This affected levels and lead to adjustments. Although most levels is cared for it could be good to have an acessible documentation of physics changes across versions (from C++- to D-Lix and across major D-Lix versions).

For the change from C++- to D-Lix there are some aspects documented in a thread about singleplayer migration e.g.

Since I don't want to create a github account, some suggestions here to the (probably Allegro) bug (#419)

1) Filing an issue to Allegro, they should know best to find a fix if viable
2) Playing around with the values in the example, e.g. divide through 4, multiply with negative values etc.
3) Looking what values are shown if the cursor is within the window (maybe even create a video for that)
4) Using debug libraries to create log, which can be maybe helpful for issue at Allegro
5) Offering the workaround to switch off the mouse warping, maybe it's viable for Dominator

Out of interest how Lix is started by others.

This issue (#234) can really get grating when tailoring the map (zoomed out) to the wished size. It can take mutiple tries to get the proper map size and because of this issue one has to zoom out every time again to see if it fits.
The zoomed in map actually tells you very few about the full size of the map.

(I can see the use of automatically readjusting zoom when it is the default zoom.)