Print

Please login or register.

1 Hour 1 Day 1 Week 1 Month Forever

Login with username, password and session length

[theduck101]

Hi Guys,

I've slapped together an Ubuntu package for doomrl. It will (hopefully) install site wide so each user gets their own saves/config settings (by the use of duct tape and hacks aka the Linux Way(tm)). For some unfathomable reason I threw in a horribly designed gui interface for changing config settings as well (complete with a gimmicky option to use random names off a user defined list).

I don't know how many of you run Ubuntu - if you want this for Fedora or other distros I can probably whip something up. Actually a generic linux installer wouldn't be too hard to do...

You can get it here:
doomrl_0994-2.deb

You should be able to just double click on the file to install. I haven't tested it extensively, let me know if there are issues. All source code is included (if you know how to unzip debian packages - otherwise take a look in /usr/local/share/doomrl after install). If it worked you should find DoomRL in your Games menu :-)

I tested this on 10.04 and 11.10 (32bit but 64bit should work fine).
Also note: the package doesn't include the doomrl executable - it'll download it during the install process, that way the stats on the chaosforge downloads page will still be correct.

Anyway, hope this might be useful to someone out there...

[Simon-v]

You weren't kidding about duct tape.

[theduck101]

You weren't kidding about duct tape.

lol

Yep - I just wanted something I could get off the ground quickly so I wasn't really applying brain power. This does what I need it to - although I'll be the first to admit the config stuff is an abomination unto man... Still I don't think it's too bad for a couple hours work and, who knows, someone out there might even find it useful :-)

[Kornel Kisielewicz]

If I'd get help from a linux person in knowledge of the proper configuration schemes I could prepare a multi-user friendly and well behaved version of DoomRL... *hint, hint*

[theduck101]

I'd be happy to help - (with any linux stuff - I'm not an expert but I know my way around) :-)

I'll explain how the package works currently: DoomRL is installed in a central location and every user gets a (hidden) folder for the config/player/score files. The DoomRL executable is symlinked into the user folder and when DoomRL is run we change directory to make sure everything works. I realised that after installation a user wouldn't know where the config files would end up so I wrote a little gui to enable them to edit settings. Most of the duct tape is because of the gui editor - I used a rather convoluted implementation and I added the extended names 'feature' (which, given a moments thought, makes far more sense as a proper Feature Request... Sigh...).
I can take out the extended names bit and clean up the settings editor - that alone would get rid of most of the ugliness.

The symlink method I've used is a hack but a fairly typical one for linux - while it would be nice for DoomRL to support multiple users explicitly I would, in my professional opinion, first see if there's any interest in the Ubuntu package/installer at all and, if so, add explicit multi-user support to 0.9.9.6.

BTW: I tested some more  - the package isn't checking for 64bit machines correctly and Ubuntu Software Centre is complaining because I left out a field (it's just the Install-Size field - you can ignore the error) - I'll try to have a fix up by tomorrow...

EDIT: 64bit and Software Centre should be fine now...

[Simon-v]

From what i've seen, the typical Linux game packaging scheme is fairly straightforward.

The executables are placed in /usr/games/ (example: "/usr/games/doomrl")
The data files are placed in their own subdirectory under /usr/share/games/ (example: "/usr/share/games/doomrl/doomrl.wad" or  or "/usr/share/games/doomrl/music/e1m1.mp3")
Per-user configuration, save and log files are placed a hidden directory in the user's home directory (example: "$HOME/.doomrl/player.wad")

The game needs to check for these locations and be able to regenerate a new set of the per-user configuration files when they are removed in order to work in a multi-user environment. The rest (library dependencies, splitting the game distro between required and optional parts, menu entries, desktop launchers, man files etc.) is normally the job of the packager.

[theduck101]

Yep - that's about it. My current setup is just to get around the fact that DoomRL doesn't support this yet. An alternative scheme if you'd rather keep everything together is to install to /opt i.e. /opt/doomrl/ - that way the devs don't need to change any paths to get to the data files (this is what google does for chrome). Then all that would be necessary is to cater for $HOME/.doomrl config files...

[Simon-v]

Placing in /opt would would still require you to symlink the doomrl executable to one of the standard places in $PATH in order for it to be found when running "doomrl" from the command line.

For documentation: In addition to man files, the executable (or its wrapper script, if used) should catch "-h|--help" and print out brief usage notes, even if there aren't any at the moment.

Finally, proper multi-user installation packages and such might not be obviously necessary right now, but they have the potential of increasing the game's spread. It is my understanding that this kind of thing is considered desirable by this community.

[theduck101]

Placing in /opt would would still require you to symlink the doomrl executable to one of the standard places in $PATH in order for it to be found when running "doomrl" from the command line.

Good point, didn't think of that :-/

Finally, proper multi-user installation packages and such might not be obviously necessary right now, but they have the potential of increasing the game's spread. It is my understanding that this kind of thing is considered desirable by this community.

I'm still pretty new here so I don't know what the conventions are for this type of thing. I'll be more than happy to put a proper standards compliant package together.

[Kornel Kisielewicz]

Ok, so gather up the requests from my side, and somebody please post it to the tracker with a 0.9.9.6 target.

What do you mean by "extended names" feature?

[theduck101]

What do you mean by "extended names" feature?

It was really silly - I tend to use the random names feature but I wanted a bigger pool of names - so I hacked together a script to modify the AlwaysName config variable every time doomrl started. If you combine that with the MenuReturn option it works pretty well. One of those little things that made me smile. I guess the proper way to implement something like that would be to have a RandomNames array in config.lua. In hindsight I shouldn't have included it in the package but I went with what was working for me at the time...

I'll commit to maintaining packages for both major Linux package types: rpm and deb. That way we'll cater for the majority of linux distributions. I'll also put some effort into the settings editor - keybinding support and maybe an option to automatically download the doomrl mp3's might be nice.

I'll post a cleaned up version of the current package when I can as a preview/alpha - more feedback along the lines of Simon-v's will be appreciated.

[Kornel Kisielewicz]

It was really silly - I tend to use the random names feature but I wanted a bigger pool of names - so I hacked together a script to modify the AlwaysName config variable every time doomrl started. If you combine that with the MenuReturn option it works pretty well. One of those little things that made me smile. I guess the proper way to implement something like that would be to have a RandomNames array in config.lua. In hindsight I shouldn't have included it in the package but I went with what was working for me at the time...

Oh come on, that is really silly, because... the feature you want is already there ;)

You just have to realize the truth... there is no config format. It is a Lua file. So....

Code: [Select]

local names = { "John Doe", "Jack Black", "John Don" }
AlwaysName       = names[ math.random(#names) ]

And this works since quite a few versions :P. And yeah, you could even auto-generate the names with any algorithm you can code in Lua. Or read them from a file using dofile... possibilities are endless, and already there since a looong time :P.

I'll commit to maintaining packages for both major Linux package types: rpm and deb. That way we'll cater for the majority of linux distributions.

Excellent, I really needed that :D. Now just prepare the requested list of things that I should do, and I'll do them once work on 0.9.9.6 starts.

I'll also put some effort into the settings editor - keybinding support and maybe an option to automatically download the doomrl mp3's might be nice.

The current version of DoomRL has already a downloader built in, it's just not active yet. Although it was designed for downloading modules, it might as well work with MP3s. An ingame settings editor is planned for a long time, but probably will appear after the graphics release.

I'll post a cleaned up version of the current package when I can as a preview/alpha - more feedback along the lines of Simon-v's will be appreciated.

[theduck101]

Oh come on, that is really silly, because... the feature you want is already there ;)

Bwahaha! I'm a moron :-) Need to learn me some of this 'lua' of which you speak :-)

Excellent, I really needed that :D. Now just prepare the requested list of things that I should do, and I'll do them once work on 0.9.9.6 starts.

Awesome. It'll be pretty much what Simon-v suggested but I'll do some more research to make sure we cover all the edge cases. I'll be busy this weekend but should get back to you next week sometime...

[theduck101]

Alrighty, I've checked it out and the changes required for enabling a site-wide install on Linux/FreeBSD for 0.9.9.6 are minimal.

As usual with Linux there's always more than one way to do this. Some apps have convoluted configuration schemes that may/may not be applicable to DoomRL. I've gone with the simplest scheme.

The basic rundown:

- When DoomRL starts it should check it's current path for the lua files and doomrl.wad. If all these files exist run DoomRL as normal i.e. using the current path for all files.
- If doomrl.wad is not in the current path then use the path /usr/local/share/games/doomrl/doomrl.wad. If this file doesn't exist exit with an error saying DoomRL has not been installed correctly.
- Check that the directory $HOME/.doomrl exists. If it doesn't exist create it. The config.lua file will be in this directory - if it doesn't exist it should be copied in from /usr/local/share/games/doomrl/config/config.lua
- The player.wad and score.wad files and backups will now be stored and accessed from this directory ($HOME/.doomrl).

Pseudo-code for clarity:

Code: [Select]

if pathExists(currentWorkingDirectory + "doomrl.wad") and pathExists(currentWorkingDirectory + "config.lua") then
   -- use current working directory - DoomRL runs like it did pre-multiuser.
   wad = open(currentWorkingDirectory + "doomrl.wad")
   config_lua = open(currentWorkingDirectory + "config.lua")
   -- etc...
else
    -- We're running with the multi-user site-wide configuration:
    doomDataDirectory = "/usr/local/share/games/doomrl/"

    if pathExists(doomDataDirectory + "doomrl.wad") then
        wad = open(doomDataDirectory + "doomrl.wad")
    else
        print("DoomRL has not been installed correctly - cannot find doomrl.wad")
        exit(1)
    end

    homePath = getFromEnvironmentVariable("HOME")

    if not pathExists(homePath + ".doomrl") then
        -- 755 is the default unix permission for a user directory
        create_directory(homePath + ".doomrl", 0755)
    end

    if not pathExists(homePath + ".doomrl/config.lua") then
       copyFile(doomDataDirectory + "config/config.lua", homePath + ".doomrl/config.lua")
    end
   
    -- Set the current working directory to the user profile path. From here on we create/read the player.wad/score.wad from this path.
    setCurrentWorkingDirectory(homePath + ".doomrl")
end

Aaaannd that's it.

One potential gotcha regards upgrades. Suppose a user upgrades from 0996 to 0997 and a new lua variable AwesomeFeature was added in 0997. We would need to change the users profile but this is difficult to do on package installation (we don't know which users to update). One possible solution to this problem is this: the config.lua file that is copied will be:

Code: [Select]

-- Config.lua for Linux packages
dofile "/usr/local/share/games/doorml/config/masterconfig.lua"

- User overides for settings here: uncomment variables to set

-- Whether to allow high-ASCII signs. Set to false if you see weird signs
-- on the screen.
--AllowHighAscii   = false

-- Setting to true will skip name entry procedure and choose a random name
-- instead
--AlwaysRandomName = false

-- Specifies how the DoomRL inventory and equipment menus should be handled.
-- Can be set to CHOICE, HYBRID or LETTER
--InvMenuStyle     = "HYBRID"

--etc,,,


This would read a master config file and allow a user to override individual settings. When DoomRL is updated any new variables will be automatically picked up by the user profile script via the updated master config file without affecting their old settings. I can think of other solutions but I think this one might work (although I realise it may complicate the up and coming settings editor - an alternative might just be to have an upgrade-config command that will update a users config.lua when appropriate...) 

Sorry I took so long (got *ahem* sidetracked by my first UV win/Diamond :-) ) Let me know what you guys think...