DRL > Discussion

Ubuntu Package

<< < (3/3)

theduck101:

--- Quote ---What do you mean by "extended names" feature?
--- End quote ---

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:

--- Quote from: theduck101 on December 15, 2011, 08:37 ---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...

--- End quote ---

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: ---local names = { "John Doe", "Jack Black", "John Don" }
AlwaysName       = names[ math.random(#names) ]

--- End code ---

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.


--- Quote from: theduck101 on December 15, 2011, 08:37 ---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.

--- End quote ---
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.


--- Quote from: theduck101 on December 15, 2011, 08:37 ---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.

--- End quote ---

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.


--- Quote from: theduck101 on December 15, 2011, 08:37 ---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.

--- End quote ---

theduck101:

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

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


--- Quote ---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.
--- End quote ---

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: ---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

--- End code ---

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: ----- 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,,,


--- End code ---

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...



Navigation

[0] Message Index

[*] Previous page

Go to full version