Currently installed mission not staying installed after game exit

[PranQster]

A couple of the latest missions, by Jesps and Sotha for example, have not stayed installed after exiting the game (yes, I know that only one FM is installed at any one time). When launching TDM the next time, it is as if there is no mission currently installed. This requires me to choose to install it and allow TDM to restart itself so I can continue playing a previously saved mission.

Previous missions had stayed installed and I only had to choose install when changing FMs.

Does anybody know what causes this?

 

It normally would not be a very big deal except for a couple things.

First, TDM does not play (pun intended) well with ALSA/PulseAudio on my linux system and I get choppy audio. If I change the audio to OSS then the audio performs better, but after installing an FM the game immediately restarts with no delay and I lose all audio. ALSA supports multiple audio instances from different sources, but OSS can only handle one instance at a time.

I think OSS needs more time to stop and restart properly than occurs during a TDM restart.

So for now, I am using ALSA and tolerating the choppy audio. But we all know how vital the game audio is in TDM... I'd like to get the choppiness out.

 

Is there any way to modify the FMs in question so that the currently installed FM stays installed after exiting TDM?

[Tels]

I can't answer your original question, but there is a way to delay the restart (requested by me because I have the same issue, and implemented by greebo, horrah!), it is some option for tdm_launcher, however, I forgot which it is and where you need to add it. (That should probably covered in our FAQ somewhere).

[greebo]

It's configurable via the CVAR tdm_fm_restart_delay.

[PranQster]

Awesome, thanks guys!

[PranQster]

I have tried both 500 and 5000 as values for tdm_fm_restart_delay, but TDM still restarts immediately when installing/uninstalling an FM.

Any ideas why this had no effect?

If I type the CVAR in the console with nothing following it, it shows the current setting, which shows the value I had entered. So I know the value is being set.

[nbohr1more]

It looks like that CVAR is intended to be invoked in the launch string. (Alternatively you could create an autoexec.cfg with the CVAR).

 

If that fails... some sort of logging to track this down better?

[Aprilsister]

Maybe the best thing to do is figure out the original problem: why aren't some FM missions staying installed?

 

It seems you are 2-3 layers deep in convolution at the moment and delving-ever-deeper...

 

So, if you would, list a few missions that do work (stay installed) flawlessly and consistently; and then, again, if you would, re-verify that those other 2 are not staying installed.

[Fidcal]

Silly question but are you certain that you are always launching via tdmlauncher.exe? I have lots of different shortcuts for different things and only the other day I used one I didn't use very often and got this same effect - install and play an FM once then after that it is no longer installed. Then I realized I was using a shortcut direct to Doom3.exe with the darkmod game base set in the args.

[PranQster]

Silly question but are you certain that you are always launching via tdmlauncher.exe? I have lots of different shortcuts for different things and only the other day I used one I didn't use very often and got this same effect - install and play an FM once then after that it is no longer installed. Then I realized I was using a shortcut direct to Doom3.exe with the darkmod game base set in the args.

 

Ahh... thank you, I'll try the launcher instead. I have been using:

xrandr -s 3;cd /home/john/apps/games/doom3;./doom3 +set s_driver alsa +set fs_game darkmod +set tdm_fm_restart_delay 5000;xrandr -s 0

 

So instead I will try:

xrandr -s 3;cd /home/john/apps/games/doom3/darkmod;./tdmlauncher.linux +set s_driver alsa +set fs_game darkmod +set tdm_fm_restart_delay 5000;xrandr -s 0

In this code ^^^ there is not supposed to be a space between 'tdmlauncher.' and 'linux', but this forum always adds it no matter if I use code snippets or not.

 

 

Fingers crossed...

Edited December 17, 2010 by PranQster

[PranQster]

I get this as the last 2 lines:

 

Trying to launch /usr/local/games/doom3/doom.x86 +set fs_game_base darkmod +set fs_game flakebridge

Error while launching D3 executable: No such file or directory

 

Is the path /usr/local/games/doom3/doom.x86 hard coded into the launcher binary, or is there a place for me to change that path? Because that is not where I have doom3 installed.

 

I have doom3 installed in my /home/username/ path. That way I can reformat, reinstall linux, etc. including /usr without having to reinstall my games.

 

 

Ok, I copied my doom3 install to /usr/local/games/doom3. The launcher works now, and flakebridge was still installed when it launched. So it seems that my primary goal has been achieved. I still need to test sound, but it had been very choppy before and now it sounds flawless while in the main menu... have not tried in-game yet.

 

Thanks guys!

Edited December 17, 2010 by PranQster

[nbohr1more]

I'm pretty sure that I recall another thread where this was found to be hard-coded for Linux in v1.02...

[PranQster]

That's good to know... no problem. Whenever I end up doing a hard drive upgrade or another new install, I'll just remember to copy my doom3 directory to /usr/local/games... it only takes a few seconds and it cleared up multiple issues.

ALSA audio now works very nicely in addition to FMs staying installed after exiting the game.

 

I only wonder why some FMs would stay installed and others would not when launching the doom.x86 binary directly.

[greebo]

Trying to launch /usr/local/games/doom3/doom.x86 +set fs_game_base darkmod +set fs_game flakebridge

Error while launching D3 executable: No such file or directory

 

Is the path /usr/local/games/doom3/doom.x86 hard coded into the launcher binary, or is there a place for me to change that path? Because that is not where I have doom3 installed.

Just pass the path to the D3 executable as argument to tdmlauncher, it will use that after it can't find D3 at the default location.

 

xrandr -s 3;cd /home/john/apps/games/doom3/darkmod;./tdmlauncher.linux /home/john/apps/games/doom3/doom.x86 +set s_driver alsa +set fs_game darkmod +set tdm_fm_restart_delay 5000;xrandr -s 0

[PranQster]

Just pass the path to the D3 executable as argument to tdmlauncher, it will use that after it can't find D3 at the default location.

 

xrandr -s 3;cd /home/john/apps/games/doom3/darkmod;./tdmlauncher.linux /home/john/apps/games/doom3/doom.x86 +set s_driver alsa +set fs_game darkmod +set tdm_fm_restart_delay 5000;xrandr -s 0

 

Ahh, cool. Thanks.

I might give that a try, but for now the game is running so well that I think I'll just keep running it from the default path. After copying my doom3/ to /usr/local/games, ALSA problems went away. I assume that since my /home partition is on a separate hard drive than the rest of the system, I'm getting better performance with ALSA since doom3 is running from a different drive then where game data is being cached...?? Does that sound reasonable?