Howdie, fellow post-apocalyptic sojourners. For the fortunate Gentoo-ites among us (…you know who you are), a series of unofficial but well-tested ebuilds compiling and installing Cataclysm: DDA from live GitHub sources have arisen! We currently support versions 0.4 and 9999 (i.e., the most recent GitHub commit), with planned support for 0.5 as soon as that erupts.
The wiki has complete instructions. If you’re too busy chopping up your bench into nailboards to thumb through them, however, it’s pretty simple:
We now return to your regularly scheduled bout of frostbite, moaning fear, and huddling despondently in unmarked graves dirt pits you dug by the last of firelight.
We’re migrating the license to CC-BY-SA 3.0, so once that’s done we can do “legit” distro releases, but while that’s happening by all means feel free to build and spread around packages.
We’re also taking a look at updating the makefiles to accomodate packaging more easily (allowing installing to /usr/local/whatever or whatever wacky paths various distros use).
Excellent. Given Gentoo’s somewhat “elongated” release schedule, this ebuild won’t be squirming its way into the official Portage tree anytime soon. Bah!
Badical! Err… excellent. Honestly, I found the Cataclysm: DDA “Makefile” to be remarkably helpful. So many roguelikes either distribute no makefiles or highly nonstandard makefiles. (premake4-based ToME4, I’m glaring at you.)
I did trip across a breaking bug, however. I should probably launch a new forum post for it, but… well, Spring is here. Doesn’t happen often in Canada. So here goes:
Under Linux (and possibly OS X), if the directory to which “cataclysm” is installed is not writable by the current user, running “cataclysm” results in 100% CPU load. And that’s it. No output. No error. No warning. Just 100% CPU load.
I’m afraid I haven’t grepped through the codebase, yet. Perhaps the function responsible for writing the “save” savefile silently spins until getting write access to such directory? Which, of course, it never gets.
Regardless, fantastic job. At the currently diabolic pace of development, I can well see DDA overtaking ToME4 as Roguelike of the Year. I guess what I’m trying to say is: “Thanks for all the rancid zombie fish.”
Bump. Version 0.5 is now supported. Enjoy, would-be biohazard survivors!
If upgrading from version 0.4, you’ll probably want to move the existing “save/” subdirectory aside. This avoids STL exceptions on game startup resembling:
terminate called after throwing an instance of 'std::out_of_range'
what(): basic_string::substr
Cataclysm: DDA 0.9 (also referred to as “Ma, it hurts so bad.”) Gentoo support has landed. Before upgrading, note that you must enable at least one of the following USE flags:
[ul][li]"[tt]ncurses[/tt]", installing the ncurses-based terminal executable [tt]cataclysm-dda-ncurses[/tt].[/li]
[li]"[tt]sdl[/tt]", installing the SDL-based tiles executable [tt]cataclysm-dda-sdl[/tt].[/li][/ul]
Ideally, enable both. (Queue skin-crawlingly overused “Why can’t we have both?” meme. Twitch. Twitch.) For your grisly edification, the following optional USE flags are also now supported:
[ul][li]"[tt]clang[/tt]", compiling Cataclysm: DDA with the LLVM-based clang++ compiler rather than the conventional g++ compiler. (Highly experimental. Guaranteed to explode your digital world in uncomfortable ways – but it’s there if you’re feeling frisky.)[/li]
[li]"[tt]lua[/tt]", embedding a Lua interpreter into Cataclysm: DDA. (Technically, this currently does nothing. Thanks, leycec. I know. But it will probably do something when Lua support goes live in the upcoming version 1.0. Hey, no harm in planning ahead… or is there?)[/li][/ul]
This updates comes courtesy the following Gentooers, whose thankless diligence on both this forum and github shamed me into patching my bit rot:
We know we’re bad people wrt non-configurable file paths, builld- and run-time configurability for that is being looked at. We have the gnarly “let’s add indirection to all the hard-coded file paths” done, now just need to hook it up to the makefile and stuff.
Btw, clang++ isn’t all that experimental, the official builds are on clang since that’s what our Jenkins instance is configured for. (yes we’ll be looking at whether g++ builds make faster code at some point)
You guys rock the post-apocalyptic Casbah. With bated (fetid) breath, we contemplate what lurks in the dark for 0.A. Here’s to even more weekends wrecked with Lua-enabled grappler zombie duels.
We know we're bad people wrt non-configurable file paths, builld- and run-time configurability for that is being looked at. We have the gnarly "let's add indirection to all the hard-coded file paths" done, now just need to hook it up to the makefile and stuff.
The “Makefile” is astonishingly serviceable with respect to Gentoo integration. A well-deserved kudos to the build team! That said, there are a few incidental hiccoughs:
[ul][li]The live “Makefile” assumes subdirectories [tt]“obj”[/tt] (when compiling the ncurses build) and [tt]“obj/tiles”[/tt] (when compiling the SDL build) to exist without actually creating such subdirectories. Since they don’t exist, [tt]“make”[/tt] immediately fails with fatal error. (Easily fixed on our end, of course, but there you are.)[/li]
[li]The live “Makefile” hardcodes [tt]“-werror”[/tt] into variable [tt]$(WARNINGS)[/tt] (when building with g++). This is a fairly dangerous option, guaranteeing build failure on the first otherwise ignorable compilation warning. You might want to omit such option from $(WARNINGS) by default – perhaps enabling such option only under developer-specific debug builds. (Easily fixed on our end, again.)[/li][/ul]
Aaaand… That’s it.
Btw, clang++ isn't all that experimental, the official builds are on clang since that's what our Jenkins instance is configured for. (yes we'll be looking at whether g++ builds make faster code at some point)
Fantastic. I should probably have actually tested that.
Live Cataclysm: DDA Gentoo support has landed. In blood-flecked anticipation for the official 0.A release, we now support building straight from the live repository. (Not for the wobbly of heart.)
This an inherently unstable and hence hard-masked ebuild. To unmask, just add the following line to “[tt]/etc/portage/package.unmask[/tt]”:
The same caveats as above also apply: namely, enable the “[tt]ncurses[/tt]” and/or “[tt]sdl[/tt]” USE flags.
Bump. For inscrutable reasons, the live ebuild has switched from a hard package mask to empty ebuild [tt]KEYWORDS[/tt]. Current users will probably want to add the following line to [tt]/etc/portage/package.accept_keywords[/tt]:
