Egor

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Lt_Dan_Sweden @ Oct. 15 2002,22:57)</td></tr><tr><td id="QUOTE">OK Now we run on Linux. How do I get :start start /W ofp_server.exe goto start to work in Linux Shell? Probably BASH, not sure. Lt_Dan_Sweden<span id='postcolor'> This does the trick in Linux: #!/bin/bash while (1); do ./ofp_server done I'd suggest running servers within a 'screen' session under Linux. Make two scripts, one with the above (call it loop.sh) and one with commands to open a screen (call it start.sh): #!/bin/bash name=opflash screen -c ./screenrc -S $name su -c -- games ./loop.sh Now make another file called screenrc with some suggested screen config info in it: scrollback  2000 bindkey \003 detach bindkey \033 detach detach Now run ./start.sh. This creates a screen session called 'opflash' and runs the server as the 'games' user, then detaches the session. You can log out and the server will continue running. Typing: screen -r opflash ...will reattach the screen. You can push Esc to detach again. You'll need the 'screen' package installed on your system of course for this to work.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (BigQEd @ April 04 2002,01:19)</td></tr><tr><td id="QUOTE">You are correct Keg... I am sure those that log on to their servers might like the Batch file idea. I simply prefer to run as a Service because all our Servers are in our NOC and not systems we utilize as Desktop systems.<span id='postcolor'> BigQEd, you're right that most FTP, Web, etc. server applications for Windows run as services, and they work best that way because that's how they're designed to run. The problem with running a game server like OFP as a service, is it has *not* been designed to run that way. If any errors occur while the server is running, there's no way you'll know about them, because it has no logging; only on-screen visual alerts. If you're running as a service then you can't see the console and you can't see these alerts. By contrast, something like IIS which is designed to run as a service will log all errors to the system Event Log (or a separate log file), so you can read them. Pop-up alerts are unfortunately quite common with the OFP server if you're not careful (I consider this something of a design flaw on BIS's part); all you need is a mission file with an error (missing resource, addon etc.) and you get a popup alert box. The alert prevents the server from running, but doesn't end the process, so it won't be auto-restarted. If you're running as a service, you presumably just have to guess at the problem. Background processes are not "more efficient" than foreground processes. The only difference would be if you have Win2K Server set to optimize for background services, they might get some kind of higher priority (not sure exactly what that switch does, actually). If you set that to optimize for foreground applications, then it will be the other way around. There is nothing inherently better about background processes, as far as I know. It's more of an application design issue; if you just force a foreground application to pretend to be a background service, you gain few or none of the actual advantages of having a background service (only good thing I can think of is the program can be set to start up at reboot automatically--but servers shouldn't be rebooting often enough for that to matter). I have a few custom programs for restarting and monitoring our various game servers, but for OFP we're actually just using the freeware ServerDoc. It's simple and works well enough. Effectively the same as the batch file, but with a few extra features.

The player list would not be used by the master servers. The player list functionality already exists, as browsers like ASE and GameSpy are already able to display the player list. All it needs is for the implementation of this in the in-game browser GUI.

Hmm yes you're right. I was thinking of the troubles that Tribes 2 had when they initially used a voice codec that was not supported under Linux, but I think that was actually in reference to the Linux client version of Tribes 2, so no worries.

I'd like to see an option in the server.cfg for disabling the Lock Server function. I can see that this button is going to cause nothing but trouble for those of us running public dedicated servers. It will allow a few bad guys to join the server (and get auto-adminned) and basically take it over for their own use (a squad match or whatever) without permission. This is not at all acceptable for a public Internet server.

If they have any plans for a Linux server version of OFP anytime in the future, they will want to be careful to use a voice technology which also has Linux support.

Hmm, I see what you're saying. That string normally reads "Dedicated server" (in English), so if I change that to "Gameplanet NZ OFP server" and set the hostname in server.cfg to "opflash.gameplanet.co.nz" then in full it will come out as "Gameplanet NZ OFP server on opflash.gameplanet.co.nz" (instead of just "Dedicated server on opflash.gameplanet.co.nz"). It's doesn't seem to be possible to get rid of the "on" part however. And I still think this is a bit cruddy; I should be able to simply set the full hostname from server.cfg.

Also, I am pleased to see the new "gstate" server rule. What are the possible values of this rule? I presume the numbers equate to "briefing", "role assignment", and "in game" or suchlike.

Would it be possible to remove the "Dedicated server on ..." prefix from the hostname for dedicated servers. This would seem to be unnecessary and it clutters up the server list. Instead I would suggest returning whether the server is dedicated as a separate server rule (e.g. "dedicated = 1"). Then server browsers like GameSpy and ASE can actually use that rule for filtering. In OFP's new in-game browser, dedicated servers could perhaps be indicated with an icon next to the server name.

Mirror for New Zealand/Australia users: OFP v1.60 MP Test http://downloads.gameplanet.co.nz/dl.dyn/Files/3061.html OFP v1.60 MP Test Standalone Server http://downloads.gameplanet.co.nz/dl.dyn/Files/3062.html

Fixed it! Woohoo. Turns out it was the sound card. I found a new SBLiveXPDrvUpdate.exe than what I had installed. There's no version numbers on those files, but that one is listed as "Revision 2" and mine was dated about a month older, so I presume I had "Revision 1". I installed the new one and now OFPMPTest.exe v1.59 starts up fine. Something must have changed in v1.58 with OFP's audio features which has caused an incompatibility with the SB Live Revision 1 XP drivers.

It's been suggested to me that information about my disk devices could be relevant if this a SafeDisc issue. I have the following configuration: </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">- Onboard Promise UltraATA-100 IDE controller - Primary Master: Maxtor 20GB hard drive - C: (NTFS "Basic" disk) - Secondary Master: IBM 30 GB hard drive - E: (NTFS "Dynamic" disk) - Onboard ATA-66 IDE controller - Primary Master: Creative CD-ROM drive - D: - Secondary Master: Asus CD-RW drive - F:<span id='postcolor'>

Here's new screenshots and a new context.bin for 1.59: http://www.gameplanet.co.nz/~sgarner/opflash159/context.bin

Just a note I'm still getting this *exact* same problem under 1.59. I've tried upgrading video drivers to the latest official Detonators, v28.32, with no effect. (I've gone back to my old 27.20 drivers now though since the Nvidia Refresh Rate Fix doesn't work with any of the newer drivers.) I forgot to state my sound card in the original post; perhaps that could be related. I have a SB Live! Value (one of the older ones), running LiveWare3 with the LiveXP update. I've sent this report to support@bistudio.com now too.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (PfhorKen @ May 22 2002,10:51)</td></tr><tr><td id="QUOTE">This error and displayed dialogs are completery same as I've experienced. http://www.flashpoint1985.com/cgi-bin....t=12488 Hope it would help.<span id='postcolor'> I don't think this is related, as my problem never occurred before 1.58. And I'm in New Zealand, running the EU version of OFP. My language setting in XP is "English (New Zealand)". I've just tried changing it to "English (United States)" and it made no difference. Thanks anyway.