Game seems to play itself and triggers GNOME Shell's "is not responding" dialog

[HebaruSan]

Problem

I just stumbled on this game while browsing apps randomly in my Ubuntu system menus. I'm quite interested in Haskell and Roguelikes, so this seems like a really neat project. But so far this is what I get:

It looks like the numerals are the player's squad members (I browsed the documentation a bit but not a lot), based on the cursor movements hovering on them, but they're moving around by themselves rather than waiting for player input. It looks like an AI autoplay mode has been triggered automatically.

I eventually noticed the prompt at the top and tried pressing a key, but nothing happened. All I can seem to do is Force Quit.

Suggestions

• I'd find this a lot more approachable if the default view was of the game paused waiting for player input rather than an AI autoplay, as in other Roguelikes.
• It would help tremendously if the "not responding" popup did not appear. I tried running it in a terminal to bypass whatever problems the custom window has, but it still opened the custom window, so that would be another nice solution.

[Mikolaj]

Hi! Thank you for the report. That's most likely a bug, probably of the SDL graphics library, that blocks any key and mouse input. Which Ubuntu version is this?

Could you experiment a bit with commandline options? Run Allure --help in the terminal and try a few combination. E.g., --frontendANSI would run entirely in the terminal and so rule out the problem with SDL. Or --gameMode crawl would not start one of the AIvsAI modes but the crawl mode, so the player should be in control from the start. Once you start in such a mode once, you should be in control until you cede it intentionally or until the game ends.

[HebaruSan]

Sorry, I realized belatedly that you'd want system info and was in the process of grabbing it:

I'll experiment with those options and report back...

[HebaruSan]

--frontendANSI doesn't exist, so I might have an older version than expected.

$ Allure --frontendANSI
Invalid option `--frontendANSI'

Usage: Allure [--newGame N] [--knowMap] [--knowEvents] [--knowItems] 
              [--showItemSamples] [--exposePlaces] [--exposeItems] 
              [--exposeActors] [--sniff] [--allClear] [--boostRandomItem] 
              [--gameMode MODE] [--automateAll] [--keepAutomated] 
              [--stopAfterSeconds N] [--stopAfterFrames N] [--printEachScreen] 
              [--benchmark] [--setDungeonRng RNG_SEED] [--setMainRng RNG_SEED] 
              [--dumpInitRngs] [--dbgMsgSer] [--gtkFontFamily FONT_FAMILY] 
              [--sdlFontFile FONT_FILE] [--sdlScalableSizeAdd N] 
              [--sdlBitmapSizeAdd N] [--scalableFontSize N] [--fontDir FILEPATH]
              [--logPriority N] [--maxFps N] [--disableAutoYes] [--noAnim] 
              [--savePrefix PREFIX] [--frontendTeletype] [--frontendNull] 
              [--frontendLazy] [--dbgMsgCli] [--version]
  Configure debug options here, gameplay options in configuration file.

$ Allure --version
0.9.5.0

I see the repo is up to v0.11.0.0, so my apologies if this was already fixed. I'll try compiling the repo next...

--gameMode crawl seems to wait for user input but still triggers "is not responding":

[Mikolaj]

Oh, right, I forgot how ancient the version in Ubuntu is. It even has a known error for which the fix is still not applied in Ubuntu (but it's not the one).

It would be great if you tried compiling, feel free to ask questions here if there are any snags.

Another option is to download a linux binary, which may or may not work on your new Ubuntu. See the Releases github subsection.

In this Allure version --frontendTeletype is the (very ugly) terminal-only option. You may require Enter after each keystroke. Please let me know if this one accepts input.

I'd love to work around the SDL bug (it's not present in my old Ubuntu, but I've had reports about it), so any experiments would be very useful. E.g., perhaps newer Haskell SDL bindings (the ones you'd use when compiling yourself) eliminate the problem. Or perhaps upgrading SDL fixes it (downgrading certainly does, but that's hard to do). Or perhaps I can tweak something.

[HebaruSan]

The github build instructions from the README didn't work for me:

$ cabal run --project-file=cabal.project.LH.dir 
Resolving dependencies...
cabal: The run command is for running a single executable at once. The target
'' refers to the package Allure-0.11.0.0 which includes the executable
'Allure' and the test suite 'test'.

Adding Allure to the end seemed to get past that.

In a separate terminal I started the cabal install instructions, and that has been stuck on Building LambdaHack-0.11.0.0 (lib) for several minutes now. How long does it usually take? Never mind, that finished without problems. I guess the answer is "several minutes plus a bit more" 😉 .

[HebaruSan]

(Deleted the previous comment about running the custom compile. It hadn't actually finished, and I was running make play from the other terminal where I ran cabal install. It was in the Allure project folder, though.)

[Mikolaj]

Yes, cabal 3.0 is ancient. I could fix instructions for cabal run to be more portable, as you suggested, but I can't replace list-bin. Oh, I even say "version 3.4 or later is required" in the README.

[HebaruSan]

My custom compile of the code from GitHub is worse; it still says "not responding", but now I can't even move the window.

[Mikolaj]

Thank you for the experiment. I guess I mixed up too different methods in the README. One for official version from Hackage, using cabal install and the other, for unofficial version straight from the repo using cabal run. Which you did you end up experimenting with?

[HebaruSan]

I'm trying both in parallel, which admittedly is causing some confusion, but primarily focusing on the unofficial version from the repo right now.

[Mikolaj]

I just tried and this works cabal run --project-file=cabal.project.LH.dir Allure -- --frontendANSI. However, make play would find the binary for you and so you wouldn't need cabal run, which tries to compile again. If cabal is too old, you can find the binary manually inside the repo. It's called Allure and has executable bit set. You can run it directly.

[Mikolaj]

cabal: installdir is not defined probably comes from your ~/.cabal/config being even older than your cabal. Perhaps remove ~/.cabal/config so that it gets regenerated?

[HebaruSan]

I just tried and this works cabal run --project-file=cabal.project.LH.dir Allure -- --frontendANSI

Thanks! That worked for me as well, and spacebar took me to the menu where I could turn off autoplay. My replies may slow down now that I'm trying out the gameplay...

[Mikolaj]

My custom compile of the code from GitHub is worse; it still says "not responding", but now I can't even move the window.

Still sounds like a broken SDL and, given that your GHC is probably ancient, it prevents the use of the new Haskell SDL bindings that have some workarounds for SDL bugs. If, at some point, you'd like to to experiment more, please consider installing new cabal and new GHC using https://www.haskell.org/ghcup/.

No rush, however, have fun playing (some people prefer the terminal interface, though it has some features turned off and the map aspect ratio is far from 1:1).

[HebaruSan]

Still sounds like a broken SDL and, given that your GHC is probably ancient,

In case the details would be useful:

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.8.4

Latest seems to be 9.2.4, so maybe not as bad as some of the others?

it prevents the use of the new Haskell SDL bindings that have some workarounds for SDL bugs. If, at some point, you'd like to to experiment more, please consider installing new cabal and new GHC using https://www.haskell.org/ghcup/.

OK, I'll try that, thanks.

cabal: installdir is not defined probably comes from your ~/.cabal/config being even older than your cabal. Perhaps remove ~/.cabal/config so that it gets regenerated?

That successfully installed ~/.cabal/bin/Allure, but it still does the "not responding" thing. I assume for the same SDL related reasons.

No rush, however, have fun playing (some people prefer the terminal interface, though it has some features turned off and the map aspect ratio is far from 1:1).

Heh, fortunately I'm very comfortable playing Roguelikes in a non-1:1 aspect ratio. When I started with Nethack it was the only option available.

I guess ultimately this amounts to an FYI that Ubuntu users will be having a poor user experience at the moment. Thanks for all the help in solving what would have taken me days if ever.

[Mikolaj]

I guess ultimately this amounts to an FYI that Ubuntu users will be having a poor user experience at the moment. Thanks for all the help in solving what would have taken me days if ever.

My pleasure. I await any other feedback you may feel like sharing in the future. When I get any news of the SDL situation, I will update this ticket.

[HebaruSan]

I GHCup'd my system, but ~/.ghcup/env put its new paths at the end of $PATH 🤦, so I was still running the older cabal until I flipped it.

I deleted dist-newstyle to force a rebuild, but it still seems to have some kind of problem with the event loop:

These are the APT packages that I have with sdl in them:

I don't know which of those is important or out of date, but they're all whatever is current in Ubuntu 22.04.

[Mikolaj]

Thank you for checking. If your cabal --version and ghc --version show what we expect, I'm almost sure your new setup doesn't use the Haskell packages from Ubuntu, in particular the old bindings from libghc-sdl2-dev. If so, only the libsdl2-* packages from your list are relevant. The fact you still have the problem probably means the workarounds in the newest Haskell bindings to SDL don't help. The newest SDL is 2.0.22

https://www.libsdl.org/download-2.0.php

which is available for Ubuntu (but this may break your system) here

https://launchpad.net/ubuntu/+source/libsdl2

It is possible they fixed it, but far from guaranteed (I haven't read the changelogs).

[Mikolaj]

The cheapest workaround in Allure we could try is change the line

ghc-options: "-with-rtsopts=-A99m -I5"

in Allure.cabal to

ghc-options: -threaded "-with-rtsopts=-A99m -I5"

Low chance of success, but hey, it's only one line. :)

I can't check easily, because in my ancient Ubuntu with its old libsdl2, I have no problems of that kind (and I never had any for a decade). And I can't install a newer libsdl2, I'm already using a version years ahead of my distribution precisely to debug the errors libsdl, libfreetype and OpenGL did introduce in the past.

P.S. It won't rebuild anything, just re-link, so the experiment should be fast.

[HebaruSan]

Here's what GHCup gave me:

$ cabal --version
cabal-install version 3.6.2.0
compiled using version 3.6.2.0 of the Cabal library 
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.10.7

Oddly I still can't drop the target name from the run command:

$ cabal run --project-file=cabal.project.LH.dir 
Resolving dependencies...
cabal: The run command is for running a single executable at once. The target
'' refers to the package Allure-0.11.0.0 which includes the executable
'Allure' and the test suite 'test'.

Click to expand the part where I edited the file wrong

Cabal doesn't seem to like the -threaded flag:

$ cabal run --project-file=cabal.project.LH.dir Allure
Build profile: -w ghc-8.10.7 -O1
In order, the following will be built (use -v for more details):
 - Allure-0.11.0.0 (lib:this-game-content) (configuration changed)
 - Allure-0.11.0.0 (lib:this-game-src) (configuration changed)
 - Allure-0.11.0.0 (exe:Allure) (configuration changed)
Configuring library 'this-game-content' for Allure-0.11.0.0..

Preprocessing library 'this-game-content' for Allure-0.11.0.0..
Building library 'this-game-content' for Allure-0.11.0.0..

on the commandline: warning:
    unrecognised warning flag: -Winvalid-haddock

<no location info>: warning: [-Wunused-packages]
    The following packages were specified via -package or -package-id flags,
    but were not needed for compilation:
      - LambdaHack-0.11.0.0
Configuring library 'this-game-src' for Allure-0.11.0.0..
Preprocessing library 'this-game-src' for Allure-0.11.0.0..
Building library 'this-game-src' for Allure-0.11.0.0..

on the commandline: warning:
    unrecognised warning flag: -Winvalid-haddock
Configuring executable 'Allure' for Allure-0.11.0.0..
Preprocessing executable 'Allure' for Allure-0.11.0.0..
Building executable 'Allure' for Allure-0.11.0.0..

on the commandline: warning:
    unrecognised warning flag: -Winvalid-haddock
ghc: unrecognised flag: -threaded -with-rtsopts=-A99m -I5

Usage: For basic information, try the `--help' option.

I think I'm going to draw the line at updating SDL manually, since that might risk breaking other software.

[HebaruSan]

Oh, I did the quotes wrong. Hold on, will retry.

... same:

[Mikolaj]

Thanks a lot for verifying. Oh well.

Oddly I still can't drop the target name from the run command

OK, that must have changed in the pre-release cabal I'm running. In that case, README needs to be fixed by adding that "Allure" target at the end, just as you suggested.

8.10.7

I'd recommend 9.2.*, which ghcup gives you if you insist in ghcup tui. There's a slight chance this may help via transitive version dependencies.

I think I'm going to draw the line at updating SDL manually, since that might risk breaking other software.

It may indeed and recovering is a frantic mix of apt, dpkg, etc.

[HebaruSan]

I'd recommend 9.2.*, which ghcup gives you if you insist in ghcup tui. There's a slight chance this may help via transitive version dependencies.

Cool (and that tui is a surprisingly nice app), but Allure is still "not responding".

[Mikolaj]

Thank you again. I appreciate it.

[Mikolaj]

Note to self: I'm going to leave cabal run --project-file=cabal.project.LH.dir in, because it works in cabal 3.8.1.0, 3.6.2.0 and 3.4.1.0 and only fails in older versions.

[Ark74]

Hello!
I have reached here by having the same issue with MATE and X11 on Trisquel 11.0 which is Jammy 22.04 based.

I've fixed the issue by backporting libsdl2_2.26.5+dfsg-1 from bookworm.

On the other hand, backporting allure from bookworm version: 0.11.0.0

It required to also add the following dependencies in order to build allure_0.11.0.0-1;

1. lambdahack_0.11.0.0-2
2. libghc-call-stack-dev_0.4.0-1
3. libghc-call-stack-doc_0.4.0-1
4. libghc-call-stack-prof_0.4.0-1
5. libghc-hunit-dev_1.6.2.0-1
6. libghc-hunit-doc_1.6.2.0-1
7. libghc-hunit-prof_1.6.2.0-1
8. libghc-lambdahack-dev_0.11.0.0-2
9. libghc-lambdahack-doc_0.11.0.0-2
10. libghc-lambdahack-prof_0.11.0.0-2
11. libghc-witch-dev_1.0.2.0-1
12. libghc-witch-doc_1.0.2.0-1
13. libghc-witch-prof_1.0.2.0-1

It takes a bit of work, but at the end, you can get the latest on a jammy based distro.

[Mikolaj]

Yay, congrats. Any idea where the root cause of the problems lies? A bug in SDL2 or the libsdl2 bindings or an incompatibility between versions of things or something else entirely?

[Ark74]

Well, seems like there is a bug in the jammy sdl2 version that may be causing the issue as even the bullseye one is working. So something there is weird. 🤨