Xygos 0.0.2 "Chuckie Egg" released

[Mike]

You remove a Cloak of Stealth (+3).
You put on a Space Suit.

Xygos is a new variant of Angband, forked from 4.2.1 in early January with most of 4.2.2 folded in.
This is 0.0.2, the first announced release.

It's aiming towards conversion from V's fantasy milieu to an eclectic sci-fi / futuristic / post-apocalyptic theme, in the same way that Steamband did.

It's a long way away yet - this is an early pre-alpha release with a weird mix of dragons and androids, and probably some fearsome bugs.

Playtesters are very welcome, especially if you report bugs, suggest ideas or send patches (on Github, or here on this thread)!

Right now, you will need to build it yourself. I use autogen.sh / configure --with-no-install --enable-stats --enable-test / make, but the cmake method is also maintained and used by automatic builds, so that should be fine as well. I normally run the X interface (although SDL2 and Curses should at least build). Tiles won't work - not that I have anything against them, but most of the monster and item lists are due to be replaced so existing tilesets won't be usable. It should work out of the box on Linux, and hopefully on any modern Unixy system as well.

If you use Windows or MacOS, you'll also need to make some changes to the build scripts - probably not much is needed, but I don't have an easy way to test these builds.

New (from Vanilla) top level files include:
BUGS (what it says - but most of them are marked as fixed)
BRANCHES (list of branches, with brief descriptions)
CHANGES (summary of changes made - the equivalent of changes.txt)


The github repository is here:

https://github.com/msearle5/xygos

[wobbly]

psst... you didn't provide a link to it.

[Mike]

Link this way

https://github.com/msearle5/xygos

[fiery_mews]

Oh wow I really like the sound of this! Totally here for post-apocalyptic genre mashups.

[Nick]

Very good

I haven't played (or even downloaded), but looking at the datafiles it looks very intriguing.

The github build process is broken in some interesting way I don't fully understand. If you can get that fixed, you will have working Mac and Windows builds. I suspect it's not too hard.

[Mike]

The broken Mac and Windows builds are at least partly caused by the renaming from Angband. It's not so easy to fix for me without having a local Windows or Mac dev environment, though.

[HugoVirtuoso]

Mike, what Linux distro have you been using while developing this variant?

[backwardsEric]

The broken Mac and Windows builds are at least partly caused by the renaming from Angband. It's not so easy to fix for me without having a local Windows or Mac dev environment, though.

Nick is referring to the GitHub Actions that your project inherited from Angband; within the repository, they're stored in .github/workflows. Those are set to trigger on pushes to certain branches and run on GitHub's servers. You can see the results of those actions and disable them from the 'Actions' tab on the GitHub page for the project: https://github.com/msearle5/xygos/actions

There's one workflow, release.yaml, that will automatically add a new release to the release part of your project on a push to the master branch. That release will include builds for Windows and Mac. The xygos project has acquired some very long tag names ("4.2.1-407-...."), perhaps because of the past runs from release.yaml, that are breaking that workflow. Deleting those tags from the release tab for the project, could get that workflow to run properly again.

The code builds fine, with some clang warnings, on macOS. I didn't play much with the resulting executable, but it certainly got as far as the birth screen without trouble.

[Mike]

I've been using Gentoo. (Has it failed to build for you on some other distro?)

[Mike]

Windows and Mac builds are up

Good to know that the Mac build is working - thanks. I've got both Mac and Windows building from the Action now, and you can download them from Releases.

[backwardsEric]

Not sure if this is the appropriate thread for a bug report about Xygos, but here's one

OS: macOS 10.15.7; Xcode 12.4 for the compiler; built from source (commit number 49cbe9eff8e17b20fe1bd8912f73675233b1bc62, "An easter egg ....", was HEAD) using

./autogen.sh
cd src; make -f Makefile.osx

Problem: Crashes on a segmentation fault immediately after character creation. The new character was a human, no mutations or implants, engineer, default point buy for the stats, and a randomly selected name. Took the Foraging talent from the talent selection screen. Recompiling with debugging enabled and rerunning crashed at the same point. The top of the call stack at the point of the crash for that was

cave_monster_max(c=0) at cave.c:595
monster_list_new at mon-list.c:33
monster_list_shared_instance at mon-list.c:94
monster_list_show_subwindow(height=16, width=42) at ui-mon-list.c:354
update_monlist_subwindow(type=EVENT_MONSTERLIST, data=0, user=0x000000010054c3a8) at ui-display.c:1766
game_event_dispatch(type=EVENT_MONSTERLIST, data=0) at game-event.c:43
event_signal(type=EVENT_MONSTERLIST) at game-event.c:142
redraw_stuff(p=0x00000001028eba08) at player-calcs.c:2364
ui_enter_world(type=EVENT_ENTER_WORLD, data=0, user=0) at ui-display.c:2617
game_event_dispatch(type=EVENT_ENTER_WORLD, data=0) at game-event.c:43
event_signal(type=EVENT_ENTER_WORLD) at game-event.c:142
start_game(new_game=true) at ui-game.c:420
play_game(new_game=true) at ui-game.c:440

It looks like it may be using my existing subwindow setup from Angband, and that may explain why the monster list window is being updated at the point of the crash.

[Pete Mack]

To fix this problem, edit the make file version number and executable name.

[Mike]

This is definitely the appropriate place to report Xygos bugs. This doesn't look Mac specific, and at first glance I thought that all extra windows could be affected - I don't normally play with them and so haven't really tested them. But I have been unable to reproduce it - and the flip side of not playing with extra windows is that I haven't meddled with them. So although sharing window positions etc. with V would be unintended behaviour it still seems unlikely that doing so would cause problems. It looks as if the window is trying to be displayed too early - when there is no level generated (the null cave pointer). Simply ignoring that case would probably be effective, but I would prefer to know why it happens and how to see it on Linux.



So, please could you post your .prf? The Linux equivalent is ~/.angband/Xygos/x11-settings.prf. I don't know where they are kept on MacOS.

[Mike]

Make file version number, name

While I did say that I didn't think that this was the cause of the segfault - it's still a bug, whether or not it is the same bug that caused that crash. If there's a duff version or exe name I would like to fix it. But at my first look there isn't - could you point me at the file/line you mean?

[backwardsEric]

So, please could you post your .prf? The Linux equivalent is ~/.angband/Xygos/x11-settings.prf. I don't know where they are kept on MacOS.

The contents of ~/Documents/Angband/window.prf are attached as window.txt . The ~/Documents/Xygos directory (where the Mac front end would tell Xygos to place user files) doesn't have a window.prf. For Angband, the size and placement for the active subwindows are stored by the Mac front end in ~/Library/Preferences/rephial.org.angband.plist . The human-readable form of that (generated with "plutil -p file") is attached as angband-pref.txt. It says I've got subwindows 1, 2, 3, 4, and 5 open by default.

src/Makefile.osx in Xygos uses the same setting for BUNDLE_IDENTIFIER as Angband does (i.e. org.rephial.angband). That is why the Mac front-end preferences are shared. Changing that would keep them separate.