killswitch

unittype = typeOf unit

Yes. Clean 1.94, no extra addons whatsoever. And by that I *really* mean no extra addons whatsoever since I keep my OFP/Addons and Res/Addons clean of third-party addons. Place a squad on the desert island, you as the leader. One variant of seeing the bug is to manually drop ammo from the AI via the map screen inventory, another to have them fire at enemies, thereby expending ammo. Have an ammo crate nearby. The 6 - Action radio menu won't let you tell the AI:s to rearm or pick up ammo. What they can do is pick up weapons off dead soldiers, but not ammo.

Yep, there's definitely something afoot here. Can't do ammo or weapons management on my AI squaddies anymore. Another AI management bug: One cannot order AI:s to disembark from vehicles that are non-local. (Examples: my troops in a truck driven by either another AI or another player. Same with helos.)

I hope you're not thinking of playing OFP on that? Or any other modern game for that matter... That's a motherboard with integrated graphics a.k.a. "POS". Granted, it will show colors, but thats about it... On the other hand, if this is for a computer that's just going to be used for surfing, word processing and other "light computing" tasks, I'm sure it will do just fine. Hardcore OFP gaming? Fugheddaboutit... That...thing...from Intel is a normal ATX board so just about any old ATX case would do fine. I could have told you that years ago You might find some comfort in the fact that at least, it isn't a Compaq... (shudders) Very often, brand-name computers have strange non-standard chassis solutions, so I cannot say wether an ATX board will fit in your old tower. However, another snag is the fact that the box in question only has a meager 200W PSU and that is too little these days. Tell us a bit more of what your intentions are - to build a new snazzy gaming rig for yourself or a surf box for a girlfriend, the latter often preferring design over actual function and usability.

A thread I found discussing the diff* settings in users/player/userinfo.cfg, the file you need to edit: server settings.

Heh, just when I was wishing for east, resistance and civvie versions of the divers, this comes along. Neat. Now, are there any of you talented model-makers out there that could pull it off? I'm thinking the civvie diver should be distinctly James Bond-60's style

Baz, a 1 GHz processor and "high terrain detail" dont mix. In fact, nowadays, 1 GHz processors and OFP dont mix very well, period. Keep the gfx card and the Audigy but its time to retire that old steam-driven processor. When purchasing hardware for OFP: #1 get more CPU. Then get even more. No, there is no such thing as fast enough CPU for OFP. Deal with it. #2 gfx card #3 more memory. (512 MB might be enough for your use, I regularly top that out here and need more) **EDIT: Try disabling the AA and AF. The GF4 isn't a Radeon 9800XT/ GF FX 5900, after all...

Definitely get a HT P4. They are "P4:s done right" so to speak. And it seems that OFP gets a small boost from having HT on (this from asking people with HT P4:s so its not that scientific). The "C" is for the "800" MHz FSB. There are 533 FSB P4:s with HT too. God I love that Lian-Li case, Shadow. And you bought that in Norway? Guess the tales are true - everyone in Norway has an oil well in their backyard.

A few suggestions: Chassis: Antec Sonata. Pros: mounts two 120 mm fans. The stock ones may not be silent enough, but there are silent ones out there. However, that AcoustiCase you found looks like a winner, too. CPU HSF: Zalman CPNS-7000A-Cu or the "flower" variant, the CPNS-6000Cu MB: something with a passive chipset heatsink on HD: Check StorageReview for HD tests and acoustics figures. Traditionally, the Seagate ATA Barracudas have been slower than others of their generation, but with a lower sound level. This may have changed nowadays. I believe the new Hitachi Deskstars are both fast and "silent". Add some sound dampening material to the case, and you should be set. However, for use as a DAW, I wouldn't build a single-CPU machine with the disk setup you mentioned. Granted, this depends on what needs and budgetary constraints your dad has for the computer in his business. *EDIT: Oops, the money's coming from your pocket. Ok, cheap and good will do just fine. Disregard that last paragraph above.

Ok, two mail sent to GM. One with a (begs and prays to the gods of OFP) working config, the other with a note of a syntax error in said "working" config Hope you get them, Goldie... Now, I want to kill..nay....nuke the debris objects... wonder why

Gaah *Lots of edits Ok. I now have what I believe is a working config with gmr_crater integrated into gmr.pbo. No floating debris so far. Another mail sent to goldmember... PS. A fall-back solution is to add GMR_crater to the preloaded addons in PreloadAddons of the big config.bin EDIT2: it seems that having <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> // type scope #define private 0 #define protected 1 #define public 2 these in the config makes the floating debris phenomenon appear. Examining the issue further... to be continued. EDIT3: Breaking news. Issue probably solved. It had to do with GMR_debris* and GMR_stone* being declared "scope=public". Now, without the #defines for scope above, "public" will evaluate to 0 by default instead of 2. This had the effect of "floating debris" if I added those #defines to the config.cpp. A real nasty one to find. However, declaring GMR_debris* to "scope=private;" will make the floating debris go away. Putting either protected or public scope on them will make the debris hang mid air again. (And, to further confuse, setting the simulation type of these debris to "thingeffect" instead of the default "thing" they inherit from class Thing will allow any scope type) Again, with scope=private (or scope=0), all is well again, as far as I can tell.

Thank you very much! You frozen my PC again! Still not working. BTW how long you tested, because crater object is come to under destroyed vehicle appr. 2 minutes after explosion. Untill the problem not arises. Please mail me your config.cpp if it is really woorking. [email protected] thanks Heh... sorry to hear about your freezing problems. I have mailed you the config I made, based on the 1.49 GMR.pbo/GMR_crater configs. Hope it will work on your side too. I can run missions for a long time with no problems using that. Regards

Strange... I dont get any of that. Here's what I did to the config.cpp of GMR.pbo: 1. Added GMR_crater to CfgPatches/class GMR : <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> #define TEast 0 #define TWest 1 #define TGuerrila 2 #define TCivilian 3 #define TSideUnknown 4 #define TEnemy 5 #define TFriendly 6 #define TLogic 7 #define true 1 #define false 0 // type scope #define private 0 #define protected 1 #define public 2 class CfgPatches { class GMR { units[] = {GMR_debris1,GMR_crater}; weapons[] = {}; requiredVersion = 1.90; }; }; 2. Added a GMR_crater to the CfgVehicles part <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ... ... class NonStrategic : Building {}; class GMR_crater: NonStrategic { scope=public; hideUnitInfo=1; vehicleClass="Camera"; side=TSideUnknown; mapSize=1; destrType=destructno; displayName="GMR_crater"; model=\data3d\krater; }; ... ... 3. Moved the gmr_crater.pbo out of the mod addon folder so as to not disturb And so far it seems to work just splendidly. Unrelated (?) to this (tested both with a clean 1.49 and the non-gmr_crater.pbo version), I do however see debris hanging mid-air close to wrecks. Really "Matrixy" feeling

On the GMR_crater issue:<ul> [*] The problem with dialogs mid-game yelling for a missing addon gmr_crater comes from the creation of these craters on the fly, not from the gmr_crater addon having a dependency deficiency. [*] Why have the gmr_crater in a separate addon of itself? It could very easily be integrated into the gmr.pbo under the umbrella of class GMR [*]With gmr_crater inside gmr.pbo, it will be preloaded due to gmr.pbo being in class PreloadAddons within the config. Tadaa! Problem solved. Again, to emphasize: move the GMR_crater "vehicle" into the GMR.pbo addon and retire the separate GMR_crater.pbo addon.

Should I take that as one copy of moviezombie.sqs running on each machine for each zombie or one copy running only on the machine where the zombie is local? Agree. Not much, but every bit helps. Couple of notes/possible tweaks: <ul> [*] Dont do things globally that need only be done where the zombie is local. (setUnitpos, disableAI, allowFleeing, removeAllMagazines, addMagazine, doMove, setPos) [*] Move the player cries for help to a "Hit" event handler? [*] Likewise I suspect the playSound needs to be done on all player machines but not on a dedicated server. [*] If this script is run on spawn, make it sleep for a random amount of time in the beginning. This will alleviate some of the spawn-time stutterfests that are so common in zombie missions. (Nogova Virus being a good example) Basically, I'd think about what needs to be done on the server and what needs to be done on the clients and in that way cut down on unnecessary stuff. <ul> [*]I'm not entirely sure what happens for you there, but I would move the "list AllWestSoldiers" out of the loop as quick as possible. [*]Assign a variable the value of "count list AllWestSoldiers" for loop efficiency. [*] Concatenate the two arrays of players - the AllResSoldiers and AllWestSoldiers. No need to do two travels through them separately, I believe [*] Add a slight delay in the loop. It chews CPU as it is. [*] No, OFP scripting does not have the ++ increment operator Is suspect both CPU load issues and local/remote clashes leading to desync and all that loveliness... I believe its the former. BIS has hinted to the possibility of some sort of JIT pre-compiling, but if that was/is for functions loaded by preload/preprocessFile only or separate scripts, I dont know. Perhaps... I'd need more info on how the whole system is set up and intended to work. Don't suppose one could get a preview under the table

Ok, more stuff: All of them They ought to have requiredVersion=1.85 instead of 1.75 since requiredAddons was introduced in OFP version 1.85. GAZ_pack The three weapons GAZ_ak103Base, GAZ_ak103gl and GAZ_ak104Base have a magazine "KEGak104mag" that isn't defined in any of the addons this pack depends on. (There exists a LSR_ak104mag, but that's beside the point) uce_jam_weapons_pack Some weapons only take JAM mags whereas others can take both JAM magazines and normal BIS magazines. As an example, compare uce_ak74gl with uce_ak74mgl. Also, the GL-equipped weapons only take JAM rifle grenades, not the standard BIS ones. uce_jam_est_pack and uce_jam_res_pack They need to have this requiredAddons to be complete: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> requiredAddons[] = {BIS_Resistance, JAM_Magazines, UCE_JAM_weapons_pack, GAZ_PACK, ak101soldier, KEGak103, KEGak107, KEGrpg7, KEGrpk47, KEGrpk74, LSR_rfwp }; This is because GAZ_pack depends on all those weapons addons, so since the est and res packs depend on gaz_pack, they too need to specify them. File sizes revisited Ok, I see you have split the download into separate archives for the addons. Thats also a good idea but not really what I meant by the earlier post. This is what I meant, taking the east pack as an example: 1 - make an addon, perhaps called just "uce_jam_est.pbo" and move the config.cpp into it. 2 - this config will still reference models and textures from "\uce_jam_est_pack\blah\bluh..." and so on 3 - whenever you update the config, we only need to download the very small "uce_jam_est.pbo" instead of a 10+ MB archive 4 - do the same for the res pack or any other huge addon. In fact, I just tried this and the resulting "uce_jam_est.pbo" is 112 kB in size (compressed config.cpp). That is a lot smaller than the near 27 MB big uce_jam_est_pack.pbo And again, I strongly suggest you include the config.cpp in the addons so that others can take a look at it and comment on it. This way, testing will be much faster. (You can have both a .bin and a .cpp in an addon and I believe OFP will still load the optimized config.bin if it can) Cheers!

Sweet! It may hurt the many old missions, but for the future, I feel that making correct addons is better. (So yes, remove it) I just mentioned the SD mags as something that was available and I thought you had made a typo. Ok, if the 10SAmag will be available in JAM3, what are people going to do in the mean time if they want to use your addon? *EDIT: yeah, what Evis says right here below... don't count on it.

I concur. Here's two scenarios: 1: Idiot Boy is a weekend addon maker and has just made yet another M4 or a snazzy quad-barrelled handgun with laser range finder, 48x scope and a satellite dish to boot. Belt-fed, of course. He will proceed to base the config on some old addon from 2001 making it lack proper addon dependency declarations and also name it something clever like "M4.pbo" or "Gun.pbo" or something equally nondescript. He knows people will need to read about how to install it, so he proceeds to make a "readme.txt", since that's what everyone else is doing, right? Without further testing, he sends it off to some of the big OFP news sites and is happy since he has his SnazzGun published. 2: Thinking Dude is making a yet unseen addon that has nifty, working features and has tested it to work in both MP and SP and on dedicated servers. The config is air tight since he took the time to learn about the pitfalls of addon making. He has registered his tag over at OFPEC and gotten "TDUDE". The addon is named TDUDE_NiftyThing.pbo and the provided text file showing how to install it in a mod folder in addition to the fallback solutions of Res/Addons or Addons is mentioned as a matter of completeness is named "TDUDE_NiftyThing-readme.txt" I'll take #2, thankyouverymuch.

Do you have Karrilions RTS3 addons in there somewhere? Remove them and see what happens. Guess I should investigate it further and tell Karr about it... (RTS3CoreAddon.pbo and RTS3VehicleAddon.pbo, both dated 2003-11-07)

Some quick findings (more to follow, still trying to get a grip of the sheer amount of stuff in the addons). NB: I havent been able to download the 0.88 archive you link to, so I just took the configs you mailed and put them into the 0.86 addons.<ul> [*]GAZ_pack and uce_jam_est_pack has "JAM_E762_10SAmag" in lots of places. That magazine doesn't exist, at least in my JAM2 addon. "JAM_E762_10SDmag", however, exists. [*] Some officers use a "GAZ_ak104" that has an ammo type "KEGak104mag" that does not exist in either the ak101.pbo or any of the weapons in Kegetys Weapons pack 1.1. If there's a AK104 by Kegetys out there, please tell me. Also, you might want to consider splitting the configs from all the models and textures into two separate configs, at least for the east pack. That way, we won't need to download a 21+ MB file every time you make small hasty changes and present it to us for the actual testing. Take a look at how BAS did with their OPFOR pack, for example - its split into "bas_opfor.pbo", a huge 50+ MB file with models and graphics and "bas_opcpp.pbo" a tiny 177 kB file with basically just the config.cpp in it. On to the "Groups issue": take a look at the thread joltan posted. In it I describe how I fixed uce_kuffiya in that and other (dependency) regards. Also note how its not possible to both make a correct addon and fix the fact that missions made with the old broken addon have a rogue "groups" added to their mission.sqm:s.

Actually, doing a search in this forum (Multiplayer) will give you 11 threads in which "MaxMsgSend" is mentioned and discussed and where suggestions for settings are mentioned. Do try again.

And I speak swedish but would still name my addons in english instead of, say, "uce_jam_öst_pack.bpo". Then, I'd add language-specific strings to the config via stringtable.cvs techniques. Anyways, that leaves us with the question of the config.cpp:s unanswered.

Interesting initiative, Gaz. One thing: for beta testing and peer review, un-binarized versions of the config.cpp:s would be most helpful. Also, is "uce_jam_est_pack.pbo" meant to be "uce_jam_east_pack.pbo"?

Hey Jackal. Took a quick look at the handgun configs (from the addons in "SJB_HandgunPack_1.1") and they all suffer from the same addon dependency bug that plagues so many addons out there. But the fix is easy! Take the SJB_Ber92F for example. Here's how it looks now: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class SJB_Ber92F { units[] = {SJB_Ber92F_Man}; weapons[] = {"SJB_Ber92F"}; requiredVersion = 1.75; }; The same goes for all other weapons in that addon and the other addons in the weapon pack. However, since that weapon uses both resources and class definitions from O.pbo (i.e "BIS_Resistance") it needs to be <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class SJB_Ber92F { units[] = {SJB_Ber92F_Man}; weapons[] = {"SJB_Ber92F"}; requiredVersion = 1.85; requiredAddons[]={bis_resistance}; }; (requiredAddons came with 1.85). These fixes will make your addons work correctly when used in mod folders and on dedicated servers. Nothing less, nothing more but very important.

Tested locally, i.e. in SP in the editor. Worked just fine. However, I might have an idea... this is for MP, right? Remember this: <ul> [*] action and animate should only be executed where the affected unit is local [*] setObjectTexture otoh, has to be done on all machines. (IIRC) The script snippet above doesn't take that into consideration. This one does: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _chopper = _this select 0 _VISORDTEX = {\BAS_SOAR\cmn\visord.paa} _VISORTEX = {\BAS_SOAR\cmn\visor.paa} ?(daytime > 19) || (daytime < 5): goto "NV" #Visor { if (local _x) then {_x animate ["goggles", 1]}; _x setObjectTexture [0, _VISORDTEX]; _x setObjectTexture [2,_VISORTEX] } forEach crew _chopper goto "end" #NV {if (local _x) then {_x animate ["ngoggles", 1]; _x action ["NVGoggles"] }} forEach crew _chopper #end exit It would have to be run on all machines, possibly by a trigger. *EDIT: Tested that script, activated by a trigger, in MP on a dedicated server with an AI helo (i.e its not local to my client machine). Works just fine.