[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: plans for doom packages



On 06/28/2013 05:42 AM, Jonathan Dowland wrote:
> On Thu, Jun 27, 2013 at 05:37:13PM -0300, gustavo panizzo <gfa> wrote:
>> right now, data packages call prboom (mostly) with parameters,
>> i would like to change that so data packages call an executable named
>> after the engine (doom, doom2, etc). that executable would be
>> managed through alternatives system.
> 
> I'm a little confused, because that's how things work right now:
> 
>> /usr/share/applications/doom2-wad.desktop:
>> Exec=doom -iwad /usr/share/games/doom/doom2.wad
that is exactly what i would like to change

to


/usr/share/applications/doom2-wad.desktop:
Exec=doom2


being /usr/games/doom2 a wrapper generated by the engine and managed
through alternatives

>>
>> $ readlink -f $(which doom)
>> /usr/games/chocolate-doom
>>
>> $ update-alternatives --list doom
>> /usr/games/chocolate-doom
>> /usr/games/prboom
>> /usr/games/prboom-plus
>> /usr/games/winmbf
> 
>> for that change, i've done some work on game-data-packager (is not
>> finished yet), i'm willing to do the same for deng if needed
>> vavoom is ready too
> 
> deng does not accept the same command-line options as doom.exe did, so I don't
> think it should provide /usr/games/doom (or doom2) as an alternative. When
> we cooked up the alternatives scheme I didn't anticipate engines breaking
> the command-line conventions of the original engine, which has proven to
> be a problem (specifically -iwad, but other switches might be assumed by
> a future launcher we write or package or both)
> 
> vavoom does provide alternatives for /usr/games/doom (and boom) despite
> breaking some of the command line conventions.
> 
> 


Reply to: