killswitch

Yes, this is indeed possible. One public server I know of that does this is Zeus. I would venture to guess there are other OFP server(s) running on MP processor machines. However, if they (or others) specifically assigns one OFP instance to one processor and the other to the second by way of processor affinity settings, I don't know. Nor do I know if that is neccessary or beneficial.

What you want is to organize your addons in what in the world of OFP goes by the name of "mod folders". Have a look at the Avon Lady's excellent FAQ Either do a search there for "mod folders" or look at this

Gielovic15, do you have the following things installed? * Win 2000 SP3 or even SP4 (get it via Windows Update) ? * DirectX 9.x (Also via Win Update)? * The Microsoft W2k patch for AGP apps: .Link is down on the right side * The correct chipset drivers from SiS for your ECS motherboard? Â (Specifically, the SiS AGP driver, 1.16a is the latest, i think) * Same thing for the sound chip on the motherboard, also on the ECS web site. Note: I'm not sure which of the many K7S5A variants you have, so maybe you don't have onboard sound. Or, if you do, you may not be using it but a separate card in stead. If so, like the good placebo said, tell us what card that is. When all that is installed, get the latest drivers for the GF4 (44.03, officially, when I write this) from www.nvidia.com/ Hope it helps! Oh, you may also want to flash the latest bios for your motherboard. Sometimes that fixes odd problems

I think I have found a rather serious bug in the current 1.91c Linux server: A 1.91 linux server won't load any addons that have "requiredVersion=1.91" in its config.cpp. Weird, huh! It was the same thing back with 1.90: a 1.90 linux deddy wouldn't load 1.90-requiring addons. I didn't realise it back then but remembered it now that I saw it again and did some research. What you will see in the shell from where you start the server is that one of the class names of those 1.91-addons will be silently printed. Lately we have gotten the marvellous BAS Chinook. Adding that addon to my linux server wont work: one of two names are printed out by the server: BAS_Cargo or BAS_MH47185 on startup. Result: missions containing 1.91 addons wont load. I have verified this by unpacking the addons and removing the "requiredVersion=1.91" line. Without them, the linux deddy loads the addon just fine and missions are go again. I have added the offending line to other addons (who dont actually need 1.91) and they also stop being loaded. So, Suma, I hope you will see this. Can you verify this? Note: I don't think that removing the requiredVersion from all addons that actually need 1.91 is a very good idea. Note 2: the 1.91 linux server loads addons with requiredVersion=1.90 and lower version numbers just fine. The 1.90 linux version loads 1.89 addons and lower. See the pattern?

From your flashpoint.rpt: </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">Exception code: C0000005 ACCESS_VIOLATION at 004F1A65<span id='postcolor'> Hmm... $004F1A65 rings a bell... I have had those crashes, too, and can recreate them if I want to. If I have the view distance set too high, that crash will show up sooner or later. Try lowering the view distance in your settings to, say, 900, and try.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">I have ca 2.15 Gb addons<span id='postcolor'> >BLING BLING< There we have it, I believe. You have too many addons for the amount of system memory you have (512 MB). I can recreate your problem on my machine by also having too many addons activated at the same time. Try organizing your addons into "mod folders". Go to The FAQ, search for "mod folder" and you should see it. Make up your own folder naming convention and sort your addons into those folders. Then edit the shortcut to Flashpoint to only include some of them and see if it helps. </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">I have the latest Video-drivers<span id='postcolor'> Means nothing in these days of drivers being updated all the time. Specify the version number, please. But I suspect a low memory problem, though...

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">-mod=@Invasion44;@Modern  <span id='postcolor'> What are those "@" signs for? I know they are in Avon's FAQ, too, but I have never used them and it works fine. Taking the example above, I would have </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">-mod=Invasion44;Modern<span id='postcolor'> Just curious if I have missed something that those at-signs correspond to...

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">not for Duplicats IP´s ! This command is to autokick Duplicat ID´s ! <span id='postcolor'> I know. Just like I wrote in my posting, using slightly different words.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE"> Users\PFC Voorhees\missions\SCUDS.Noe\description.ext/CfgMusic: 'S' encountered instead of '{'<span id='postcolor'> The problem is the line "class William Stromberg - Russian Monster Bomb" in the description.ext. Reason: the track name(s) in tracks[] and the class name(s) defining the track(s) have to be one word with no spaces - the "description.ext interpreter" (if I may call it that) choked on the 'S' in "Stromberg" since it expects an opening curly brace there instead. Try this one: </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class CfgMusic { Â tracks[]= {wsrmbomb}; Â class wsrmbomb { Â Â Â name = "William Stromberg - Russian Monster Bomb"; Â Â Â sound[] = {\music\William Stromberg - Russian Monster bomb.ogg, db+0, 1.0}; Â }; }; <span id='postcolor'> And then use </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">playMusic "wsrmbomb"<span id='postcolor'> To play it. Note how the parameter to playMusic is the "track class name", not the file name of the .ogg file, nor what you have in the name= property. Note: it may be possible to have a long-winded track class name like William_Stromberg_Russan_Monster_Bomb. Haven't tried it, though.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">our addons are in the addons and res addons folder so what would the linux command be for that also what  benifit would i see from it?<span id='postcolor'> You don't have to specify anything special for that - OFP and the linux server always loads its addons from the Res/Addons and Addons folders. Indeed - you don't have to use a lot of extra folders to put your addons into. I do, however, and find it a good way to split up what after a while becomes a huge normal Addons (or Res/Addons) folder with zillions of files. Then, by just making different windows shortcuts to your game, you can load a different set of extra addons depending on what you're playing. This also cuts down on OFP:s memory usage and if more people would do it, we would probably get a lot less postings abot "cannot load addon O.pbo" and the likes. So: mod folders for good housekeeping, basically.

About the -mod command line parameter...my mistake. I did some tests and found the correct way to express a list of mod folders in linux As you may know, in windows you list them like this: </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE"> OperationFlashpoint.exe -nosplash -mod=mods/misc;mods/BAS;mods/sebnam2 <span id='postcolor'> And it will load any addons in mods/misc/addons, mods/BAS/addons and mods/sebnam2/addons just the way it should be. In linux (or more exactly, in a unix bash shell), however, the semicolon is interpreted differently, so a little trick is neccessary. To do something similar to the above on linux, one would write </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE"> server -config=server.cfg -mod="mods/misc;mods/bas;mods/sebnam2"<span id='postcolor'> The difference: on linux, if you have more than one mod folder, list them in a string enclosed by quotation marks. This might be a thing to add to the linux server readme, by the way.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">I think we have the problems identified. There seems to be some rounding error when doing version comparison on Linux. We hope to have a fix available within a week or so.<span id='postcolor'> Good news! Many thanks, Suma! Â Sneaky-wish: Â A -mod= command line option just like the windows version, to organize the addons on the server. Â

Oops - sorry to have caused all this...should have thought a bit more before I wrote this: </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">(Note: going to the video settings and back to the game again will reset the view distance to whatever your prefs are)<span id='postcolor'> Indeed, in a MP game that statement is not true, thankfully. In a SP game, however, you can do that - i.e. re-set the view distance to your own preferences. ...goes and stands in the corner for a while...

>Has anyone been able to get the "init.sqs" file to do the same as someone called KeyCat explains in thisTREAD (Raises hand) I have. Adding a line like, say </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">setViewDistance 1500;<span id='postcolor'> to a/the init.sqs file will give all players a 1500 m view distance, regardless of what they have specified in the game settings. (Note: going to the video settings and back to the game again will reset the view distance to whatever your prefs are)

I found out what the problem is with the linux server and the addon. There's nothing wrong with the addon - its looks like a bug in the server. Here's the deal: A 1.91 linux server won't load any addons that have "requiredVersion=1.91" in its config.cpp. Weird, huh! It was the same thing back with 1.90: a 1.90 linux deddy wont load 1.90-requiring addons. I didn't realise it back then but remembered it now that I saw it again and did some research. What you will see in the shell from where you start the server is that one of the class names of those 1.91-addons will be silently printed. For the Chinook, one of the two names are printed out by the server: BAS_Cargo or BAS_MH47185. I have verified this by unpacking the addons and removing the "requiredVersion=1.91" line. With that line removed from the config.cpp of both the bas_cargo.pbo and the bas_mh47e_185.pbo the linux deddy loads them just fine and missions are go again. Sadly, this *IS* a showstopper bug... I'll go make a posting in the Troubleshooting forum right away and hope that Suma sees it and we can have a bugfixed server. (And no, I don't think that removing the requiredVersion from all addons that actually need 1.91 is a very good idea. Its a server bug, plain and simple and it needs to be fixed) PS. I have added the offending line to other addons (who dont actually need 1.91) and they also stop being loaded. PS2: The 1.91 linux server has no problem with addons that have requiredVersion=1.90 or lower version numbers in it.

>But when I use server.cfg it just hangs there at the WAIT FOR SERVER screen. That's actually the way it works. Without a "class Missions {...};" in the config file, the server will just show you that black, unfriendly "wait for server" screen. There are two things you can do now: Login in as admin and select a mission: Type the following command in the global chat channel: </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">#login 18005551212<span id='postcolor'> Now you should be logged in as admin. Naturally, you should change this admin password before you go public with the server... Next, lets show the list of missions: </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">#missions<span id='postcolor'> Now you can select what mission you want to run. Remember to set Cadet/Veteran to your preference. Next you get to the familiar roles setup window and, well, you probably know how to take it from there... No admin - vote for a mission: Without an admin present, sitting at the "waiting for server" screen, type this in the global chat channel: </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">#vote missions<span id='postcolor'> (Note the plural, "missions", not "mission", that's a slightly different cmd) Browse the missions and select the one you want to play. When you do that, the screen goes black again and a short chat msg should appear that you voted for a mission. Everyone else on the server also has to do a "#vote missions" and choose the mission of their liking. Note: you can of course vote in an admin and let him do the mission selection per the instructions above. Yes, the dedicated server part of OFP is hideously badly documented... One last thing: if it won't work, try adding this to the server.cfg: </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Missions { //nothing here };<span id='postcolor'> Good luck!

A wild guess: could this be an unwanted side-effect of having set </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">kickDuplicate="true";<span id='postcolor'> in the server config? The kickDuplicate property is used to kick off players that try to connect with the same playerId as someone already on the server. Not that it *should* have the effect you're describing, but, hey, the OFP server code *is* rather shaky, still... Â

First of all a big virtual hug to all you BAS guys and thanks for your excellent addons! In using the Kiowas, I stumbled over a bug/quirk and also, a solution: Problem: getting "missing addons"-messages when having the addon in a mod folder. Description: putting the BAS_kiowapack.pbo in a "mod folder" (separate from the AddOns and/or Res/AddOns folder) will get you a missing addons-message in every mission that uses the normal BIS OH58 helo. Also, adding a BIS OH58 to a mission will also add an entry for "bas_kiowapack" in the Addons (or maybe the AddonsAuto) part of the mission.sqm, even though no BAS Kiowa is in that mission. Reason: lack of a requiredAddons[] specification in the config.cpp Solution: add </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">requiredAddons[] = {oh58};<span id='postcolor'> to the CfgPatches part of the config.cpp, since the Kiowapack uses resources from the BIS OH58 addon. References: Suma's note on requiredAddons Avon's FAQ item on mod folders

Size-wize, it goes something like this, IIRC: division -> brigade/regiment -> battallion/squadron -> company/troop -> platoon -> section -> squad I believe this to be right for US Army elements, at least. I think I have seen references to British/Aussie units where a "squadron" is of company size and troop is of platoon size. Now, this is off the top of my head, so I may be totally wrong there. Now, about the hiearchy levels with two different designations - the US Marine Corps, for example, I believe, calls their "just below division" units regiments whereas the Army (or parts of it) calls units of the comparably same size brigades. Also, the naming convetion has changed through the course of history - we don't see many "cohorts" of infantry these days... That should set you in the right direction. Corrections/additions from more knowledgeable forum-goers are welcome.

Hi Rep! Â Ok, lets have a look at this... CPU/memory: ========== You said you felt you were getting "XP2000+ performance" and that had me thinking... Have you set your computer/motherboard to run your XP2600+ as an actual XP2600+, ie at 16x133 MHz = 2.13 GHz. It could be that the CPU/motherboard is set to a 100 MHz FSB (Front side bus). This would make your CPU be clocked at 16x100 = 1600 MHz which makes it run like a "slow XP1900+" (I say slow since the real 1900+ runs on 12x133). Also, the memory would then work like PC1600 DDR memory and not PC2100. AGP === Fiddle with the BIOS settings and set the AGP to 4x (it may be set to 2x or even 1x). Might give a bit better perf. Also, you may want to try enabling Fast Writes if that option is available. FW can be tricky though, needing a good, stable power supply to work without causing crashes. Try it, and be glad if it works. Sound card ======== I too have a Fortissimo III. You wrote "(latest drivers)"... drivers being a "moving target", the statement "latest drivers" means nothing. I have the 6.09 driver package which have the Hercules v.4101 drivers, and they "work" (Well, EAX in OFP is FUBAR on all non-Creative cards, but thats a subject for a whole separate thread, I believe... ;-) On UT 2003: The FIII, sadly, has no hardware accelerated OpenAL driver, so UT2k3 and other OpenAL using games lose performance there. (AFAIK, only Creative Labs cards and nVidias nForce-sound chips have HW OpenAL drivers at this time.) OFP itself ======= Well, the usual tweaking tips apply, such as lowering the terrain detail a notch or two (from Normal to Low or even Very Low), lowering the view distance. Shadows eat fps - try disabling them. Keep cloudlets, though, for the explosions. Keep using HW T&L. That should work best. That and what Avon has in her FAQ should help you get OFP working better. Regards!

I'll just bump this by saying that I have seen this, too. Happened last night during a MP Co-op game using the BAS Deltas on the Zeus Addon server. Animalmother (you lurking here ?) was going to toast a menacing BMP when he suddenly no longer was able to shoulder and use the AT4 launcher. So... it seems to happen from time to time. Wasn't monitoring the server (with #monitor) at the time, so I cant tell if the server was overloaded, nor was anyone lagged out, to my knowlegde. Beats me what it is...