Bug 496455

Note that the segfault is while its cleaning up, the more interesting question
is why is it cleaning up, iow why did it fail to start.

Can you please run
doom-shareware -debug
And then when it has failed, get ~/.vavoom/debug.txt and attach it here?

Thanks.

With no arguments:
Init: Adding /usr/share/vavoom/basev/common/basepak.pk3
Sys_Error: Game mode indeterminate.
- ParseBase
- FL_Init
- Host_Init
Log: Doing C_Shutdown
Log: Doing CL_Shutdown
Log: Doing SV_Shutdown
signal: Segmentation Violation
- SV_ShutdownGame
- SV_Shutdown
Log: SV_Shutdown failed
Log: Doing V_Shutdown
Log: Doing T_Shutdown
Log: Doing Sys_Shutdown
Log: Doing R_ShutdownTexture
Log: Doing R_ShutdownData
Log: Doing VCommand::Shutdown
Log: Doing VCvar::Shutdown
Log: Doing ShutdownMapInfo
Log: Doing FL_Shutdown
Log: Doing W_Shutdown
Log: Doing GLanguage.FreeData
Log: Doing ShutdownDecorate
Log: Doing VObject::StaticExit
Log: Doing VName::StaticExit
Uninitialised: Doing Z_Shutdown
STACK TRACE:

stack 0 0x10252f58 frame 0 0xbf8a9110
stack 1 0xf6c015c frame 1 0xbf8a9150
stack 2 0xf6c0300 frame 2 0xbf8a9170
stack 3    (nil) frame 3 0xbf8a93a0

---

Adding "-iwad /usr/share/doom-shareware/DOOM1.WAD" to the command line, the debug log starts out:

Init: Adding /usr/share/vavoom/basev/common/basepak.pk3
Sys_Error: Required file  doesn't exist
- W_AddFile
- ParseBase
- FL_Init
- Host_Init
Log: Doing C_Shutdown

---

There should be a man file or atleast usage when I run 'vavoom --help' ... =/

Try this:

vavoom -iwaddir /usr/share/doom-shareware -doom

Note btw that the vavoom packages comes with a number of scripts (and application menu entries) to make life easier for you:

/usr/bin/doom-shareware
/usr/bin/heretic-shareware
/usr/bin/hexen-demo
/usr/bin/strife-demo

These will download (after asking) the necessary .wad files to your home dir (under .vavoom) and then launch vavoom with the correct cmdline options.

vavoom doesn't install those scripts:

$ ls /usr/bin/vav*
/usr/bin/vavoom  /usr/bin/vavoom-dedicated

vavoom -iwaddir /usr/share/doom-shareware -doom -debug gives:

Init: Adding /usr/share/vavoom/basev/common/basepak.pk3
Sys_Error: Main wad file not found.
...

rpmfusion's shareware-doom package installs:
/usr/share/doom-shareware/DOOM1.WAD

I had a hunch and renamed it lower case... and that worked.

So that's one part of the problem (check for files with caps), but the segfault should still not occur after a failed start... a graceful exit is preferred.

---

Now how about freedoom?

freedoom installs /usr/share/doom/freedoom.wad

I tried:
vavoom -iwaddir /usr/share/doom {-freedoom,-doom,-doom2,...}

none seemed to work.

it's too late at night here... I do have the /usr/bin/doom-shareware, etc scripts...

Still, it would be nice if vavoom:
1) didn't segfault when launched with no arguments
2) had a man page or at-least --help
3) accepted DOOM1.WAD, DOOM.WAD, DOOM2.WAD, etc as app-caps filenames are common when dealing with files that originated in the DOS era.
4) could work nicely with the freedoom.wad

2 and 4 are fairly related.  Solving 2 would satisfy 4.  I needed to 'strings /usr/bin/vavoom' to figure out these command line arguments (yes, I probably could've googled, but /shrug).  I finally figured out how to play freedoom:

vavoom -iwaddir /usr/share/doom -iwad freedoom.wad -doom2

(In reply to comment #4)

<snip>

> So that's one part of the problem (check for files with caps), but the segfault
> should still not occur after a failed start... a graceful exit is preferred.
> 

Ack the segfault is nasty,

<snip>

>  I finally figured out how to play freedoom:
> 
> vavoom -iwaddir /usr/share/doom -iwad freedoom.wad -doom2  

freedoom only supports using it with prboom according to the freedoom devs,
so if you got it to work with vavoom, you are lucky, this is an unsupported configuration. Also notice freedoom is packaged in Fedora, an again comes with
an application menu entry to launch it.

I do not understand your problem, you are trying to do things the hard way and even trying to do completely unsupported problems and then complains things
are hard to do the way you are doing them ???

No, I don't think I'm doing things "the hard way".  I did:

$ sudo yum install doom-shareware
$ sudo yum install vavoom
$ vavoom

I expected at best it to run doom shareware... at worst to display some usage information.  I got a crash.

I then tried

$ vavoom --help

crash

$ man vavoom

no such man page

$ vavoom -iwaddir /usr/share/doom

crash

This is certainly not good behavior.

Further, you state that this is "the hard way" ... but there exists no documentation to tell the user how to do it ANY way, so *THAT* is the main problem.  You need to create --help usage or a man page to let the user know how to do things.

(In reply to comment #8)
> Further, you state that this is "the hard way" ... but there exists no
> documentation to tell the user how to do it ANY way, so *THAT* is the main
> problem.  You need to create --help usage or a man page to let the user know
> how to do things.  

Well, doom-shareware (which drags in prboom btw), has a .desktop file
creating an entry in your applications menu click on it and play, how easy do
you want it to be ?

Also vavoom installs a number of scripts with which you can easily install
and play a number of shareware / demo games its supports (and also
adds application menu entries for them). You really should try clicking on
applications and then under games after installing games, I cannot make this
any easier.

vavoom supports a multitude of doom based games, there are wrapper scripts
to help you run them from the command line utility, but you insist in running
the vavoom binary itself, which unsurprisingly, turns out to need options.

As for --help not being good enough, and no man page that is an upstream
issue, also one could argue that as this is not a cmdline utility a manpage
is not needed.

The crash when not run with the proper options is a real issue, as I've already acknowledged (but a very low priority one at that).

(In reply to comment #9)
> (In reply to comment #8)
> > Further, you state that this is "the hard way" ... but there exists no
> > documentation to tell the user how to do it ANY way, so *THAT* is the main
> > problem.  You need to create --help usage or a man page to let the user know
> > how to do things.  
> 
> Well, doom-shareware (which drags in prboom btw), has a .desktop file
> creating an entry in your applications menu click on it and play, how easy do
> you want it to be ?

Well, it would be nice it it "just worked" with the doom-shareware rpm for one thing (such as accepting uppercase named WADs).

> Also vavoom installs a number of scripts with which you can easily install
> and play a number of shareware / demo games its supports (and also
> adds application menu entries for them). You really should try clicking on
> applications and then under games after installing games, I cannot make this
> any easier.

Not everyone enjoys the added time it requires to use the mouse.  The vavoom binary should at very least provide useful usage information when run with '--help' and as a next step up provide a man page.  documentation is critical.  I'm sure I'm not the only user who has tried running vavoom from the command line after installing it.  That *is* the most obvious case.  Users expect that if they install a certain package and run the installed binary they should get *something* useful (at worst usage spew).

> vavoom supports a multitude of doom based games, there are wrapper scripts
> to help you run them from the command line utility, but you insist in running
> the vavoom binary itself, which unsurprisingly, turns out to need options.

Yes, I'm not saying needing options is bad.  I'm saying that you should report what those options are.  Using 'strings /usr/bin/vavoom' is NOT how one should be expected to discover what those command line options are...

You do provide a number of scripts in /usr/bin for shareware games, but none of those scripts are setup for the retail versions.  How do you expect a user to figure out that -doom2 or -heretic or -hexen are the correct command line arguments for those games?  Guessing?  While I believe most people examining the *-shareware scripts would make that guess, providing a good man page or --help usage is a far better user experience.

> 
> As for --help not being good enough

"not good enough"??? It DOESN'T exist.  Running 'vavoom --help' causes a segfault.

, and no man page that is an upstream
> issue, also one could argue that as this is not a cmdline utility a manpage
> is not needed.

There is a man page for prboom.  Other gui applications support '--help'

> The crash when not run with the proper options is a real issue, as I've already
> acknowledged (but a very low priority one at that).  

Well I purport that not providing any documentation on proper usage is a serious issue.

(In reply to comment #10)
> 
> Well I purport that not providing any documentation on proper usage is a
> serious issue.  

I'm not saying that it wouldn't be good to have better docs, but this is
an upstream issue, if we (the Fedora project) would need to write docs
for all upstream project where the docs suck, we would be doing nothing
but writing docs.

With that said if you were to write a manpage, I would be more then happy to
include it and push it upstream.

Same for a patch for adding --help, I must admit that now that I've tried it
the fact that it is completely missing is indeed rather lame, at first I
thought your complaint was that its output wasn't very helpful.

http://vavoom-engine.com/forums/viewtopic.php?t=1535
http://vavoom-engine.com/forums/viewtopic.php?t=1536
http://vavoom-engine.com/forums/viewtopic.php?t=1537

Feel free to close this as 'WONTFIX UPSTREAM' or whatever is appropriate.

Thanks for taking this upstream!