killswitch

Hi Winters. First of all a great big thanks to you for making missions for OFP! Greatly appreciated. I have tested and problem-shot two of the missions. Here are the things I noted Convoy Security It has lots of old cruft left in the addOns and addonsAuto parts of the mission.sqm. Here's how to clear it out and do it properly: 1 - get the latest version of the updated JJR Generic ME Rebels (1.1). There were references to weapons used by that <span style='color:red'>utterly broken</span> first release in the mission before. 2 - open the mission.sqm in a text editor and clear the list of addons in addOns and addonsAuto. Make them read <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> addOns[]= { }; addOnsAuto[]= { }; and save it. Now hop back into OFP and load the mission editor. 3 - reload the mission in the (SP,not MP) editor, preview it once and save it again. Open the mission.sqm again and make sure it looks like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">addOns[]= { "JJR_Rebels", "HYK_USsoldiers", "CBT_misc", "CBT_M977", "CBT_HMMWV", "bis_resistance", "cocmine", "BAS_RUSOPFOR", "CBT_m113a", "CBT_M2IFV", "lsr_uswp", "jam_magazines", "bis_weaponpack" }; addOnsAuto[]= { "JJR_Rebels", "HYK_USsoldiers", "CBT_misc", "CBT_M977", "CBT_HMMWV", "bis_resistance", "cocmine", "BAS_RUSOPFOR", "CBT_m113a" }; As you can see, there's no need for the marine assault pack at all. If you see any other names in there, you have one or more broken addons loaded. If you have any names missing, then that also indicates broken addons somewhere. Isn't life swell? Now, mission gameplay logic...in playing the coop/A&D version I noticed a way to win the mission quickly playing as west: borrow one of the empty A10:s on the airfield, fly north to Camp Liberty and eject just above the camp. When you land - bling - mission complete. I noticed this when having one of my AI:s fly CAS above Quandahar and he was shot down. I had him drag himself into C. Liberty for medical attention and suddenly the mission ended while I was busy in the city. Oops! Village Patrol This one suffers from the same "dirty" mission.sqm. Do the clear it out-preview-save bit here too. Furthermore, the mission is still titled "convoy security" and has traces of things from that mission still in it (parked A10:s at the airport for example) Also, this mission doesn't require the MAP either...

What CrashDome said, ie yes. No In the case exemplified by you above, no Again, no, for the case at hand. Take care to note and understand the generalisation: if a script runs on only one machine and calls another script, the second script will also only run on that machine, be it a server or client. No doubt... getting to grips with OFP:s MP idioms without a proper test setup is an exercise in futility.

Slight correction so as to not get everyone's hopes up too high: Now actually ECP compatible - yes MP friendly - well, it still works as good or bad as the first one, meaning that "Rebel dude A" will have a different face on every machine in a MP game. Regards

I don't know if it's better, but I have a variant of the APAM fuzer that's less heavy on the CPU. "Only" problem is that instead of a nice burst of bullets it's more of a 10-15 second rain of bullets at the impact point. Real nice on the framerate though but don't zoom in on the target ("Dance, cowboy") Try it by adding a small delay in the current bullet creation loop (say ~0.00001) and you'll see what I mean. If that's an acceptable gameplay/realism compromise I can follow up with the rest (the current solution I have here depends on other changes "upstream" from the APAM fuzer, so it's not a matter of sending one script only). Cheers!

What rating ("wattage") is the computer's power supply unit? Brand and model might be important here, because these days PSU:s seem to be more about useless coloured LED fans and other trinkets than, well, quality. It might be that it's not up to the task of powering the new computer parts. Sagging voltages are really bad for stability...

Ah...good old OFP. Every day a new oddity in store. I stand corrected on how setPos behaves. (And I wasn't hinking about camCreated things, which are indeed local to the machine where they were created).

I suppose it's time for the usual list of things to check. Let's do it again: <ul>[*] Have you installed the latest chipset drivers (VIA Hyperion 4-in-1 4.55vp1, http://www.viaarena.com/ ) [*] Try disabling AGP Fast Writes (BIOS) [*] Try different settings for the AGP Aperture value (32/64/128) (BIOS) [*] Relax the RAM timings (BIOS) [*] Is it heat? Check the airflow. Try running the machine with the hood off. [*] Do you have a flaky and/or insufficient PSU? [*] Once there was a AGP fix for W2k and older AMD processors. This might have been resolved with SP4 and/or the A64 platform (1) [*] Feel daring? Try the latest BIOS (beta 1010.003 when I write this, it seems) [*] Trawl other hardware/game forums looking for similar issues. Perhaps someone somewhere has stumbled upon something interesting. (eg nForcersHQ.com forum) (1) AMD site - Utilities, Drivers & Updates See "Microsoft® Windows® 2000 Patch for AGP Applications"

Veeeery nice finding there. There's another radar tower in the Mapfact Baracks Addon (Baracken.pbo, currently in version 1.5), "AIR\Military Radar Tower"/JOF_Radar003. Here's how to do the same trick to it by adding a class UserActions part to it: NB: The "..." just means "things here I haven't quoted", so don't go adding those to the config. <span style='color:red'>EDIT: set radius to 5 km based on Unnamed's tip in the post just below</span>

Another quirk report: the way the APAM handling currently works, it might as well be renamed "Desync Ammo" You see, the APAM fuzer (INQ_M1_Apam.sqs) in it's current state will create 300(301?) small bullets per participating computer in a MP game. Example: if there are 9 players and one dedicated server in a game, and someone fires off an APAM round, there will be no less than <span style='color:red'>three thousand (3000)</span> wee "INQ_ApamBullet":s createVehicle:d. Now, imagine all nine players having one tank each and they all fire off one APAM round each. The number of objects created is left as an exercise for the reader... That, my friends, is what we call a desync storm The two possible solutions: 1 - limit the APAM fuzer to the machine where the firer is local 2 - let the APAM fuzer do the following: * On non-firing machines, have new 0-damage "INQ_ApamBulletSpoof" bullets camCreate:d ("For show") * On the firer-local machine, have the real thing be camCreated. ("For effect") Result - less traffic, happier MP players

Yes, but that's the Question i have: how many triggers will be created?If you place N triggers in the mission, there will be N triggers created, regardless of the number of players. Moving triggers around is fine, but as InqWiper said, don't move the same trigger around on more than one machine, since they will "fight" over where it's located. Actually, that might not be true, since, IIRC, setPos only has an effect if issued on the machine where the object to be moved is local (There it is again - the local/remote bit).That means the only place where the moving around of triggers will actually do anything is on the server, to which the triggers are local.

Most likely because the mission itself (the mission.sqm) hasn't got the proper addons listed. You see, after an addon has been fixed for dependencies, one needs to re-preview the mission in the OFP mission editor. Do this in the normal, single-player mission editor mode (reached with "Mission Editor" from the OFP main menu, not the "MP mode" mission editor one can get to from the Multiplayer menu). After that re-preview, save the mission again. That should add the proper stuff to the mission.sqm and you will be rid of the annoying error message dialogs.

Yep. The addon is farked in the usual regard - incomplete addon dependency declaration. Here's how a correct CfgPatches part of the config looks: <ul>[*]requiredAddons was added in 1.85 [*] CBT_Crew depends on JAM which depends on BIS_Resistance and BIS_Weaponpack. Therefore, this addon needs to list them all. Another possible improvement is in the sound department - currently, all the sounds within the addon are in .ogg format. A cheap way to gain in-game performance is to convert them to .wss.

First: asking oneself if something is "local or server-side" shows a bit of a misunderstanding of the concepts. Let's sort them out:<ul>[*] On one hand, there's the concept of an object being local or remote [*] OTOH, things can be viewed as being server-side or client-side Make sure to understand the difference between these two. An example: object A can be local to a server and therefore regarded as server-side. Another object, B, can be local to a client and therefore client-side. To the client, object A is remote whereas B is local. The opposite goes for the server's view of things - A is local and B is remote. I'm not sure locality is a relevant aspect to think about when dealing with triggers. You could call them somewhat "global" in that <span style='color:red'>trigger conditions are evaluated on all machines</span>. Have a look at my reply in this OFPEC thread: "Scripts activated by triggers in MP are not local?" and see if that helps. Before I answer the questions, I need to mention that the variable you're trying to broadcast in that pV call will make OFP complain - you are trying to broadcast a local scope variable (i e one prefixed by an underscore). <span style='color:red'>Important: don NOT confuse local and global variable scope with locality of objects(local-remote)</span> Nope, publicVariable is a one time thing and you need to reissue that every time you need to broadcast a variable. Yep I hope that clears up things more than it confuses

That should read "commonly associated with botched configs from the dark ages of OFP" . The addon is promising but needs at lot of work in the config department. The config.cpp is based on some old 2001-2002 era config and does just about everything wrong: <ul>[*] Declares a class Groups -> screws up missions [*] Puts every single unit in its own CfgPatches class -> is just bad form, clutters up mission.sqm:s [*] Doesn't properly declare its dependencies -> addon is all but useless for actual mission making and MP compatibility [*] Lacks a CfgModels section Also, it seems the models themselves need handgun proxies added. (Symptom of lack of that: if you equip a guy with a pistol and wield it - the pistol is invisible but you can still fire it). Does JJR visit these forums? If so, can anyone help him get those handgun proxies onto the models? To illustrate the three top issues listed above, here's how the CfgPatches part of the config.cpp <span style='color:red'>could</span> look. (The "BIS_Resistance" is listed there in anticipation of models with handgun proxies) Let's help JJR get these babies fixed up and then perhaps move on to getting JAM and MAAM variants out. I actually have that config:ed already, but I'll await handgun-able models before proceeding.

Where can this editorupdate102.pbo file be found? Get it from OFPEC There are actually three entries there that will give you a file named "editorupdate102.pbo". Gunslinger's is the original, but noone should use that one anymore. Choose one of these two, in order of preference: 1 - "Editor Upgrade (Editors Edition" by General Barron, v 2.2) 2 - "Kegetys Editor Addon" (Kegetys, 1.11) The second one is the most common one, but the first one is a reconfigured version that organises things a lot better in the mission editor. Again, they are all named "editorupdate102.pbo" and are cross-compatible with eachother. GenB's is the latest and most pleasant to use when mission editing, so I prefer it to the older ones. Actually, the only reason to use Keg's one would be that there might be MP servers out there that run filechecks on the editor update and assume it's Keg's version (the most spread one) that's used. If you show up with GenB's, you might experience an unpleasant line of verbal garbage from whatever snotty-nosed Sherlock Holmses that are logged onto the server at that time and think they've caught a "ch34tz0r" red-handed. If that happens, don't be angry at them. Just revert to Keg's variant and be happeh!

Do you have a "hosts.txt" with your favourite OFP servers listed? If so, are any of them in the form of DNS names, not IP numbers? If so the freezes you're seeing could be OFP trying to resolve those names and while waiting for that to be done, OFP essentially freezes. Solution: either remove the hosts.txt or make sure it only contains lines of the form "IP:port" and not "cool.ofpserver.com".

Like Avon said - If overclocking makes your computer unstable, there's only one thing to do: The good Captain says "Clock down, mister! That will help"

Yep. I needed to colour code parts of it though, for clarity - hence the use of the quote environment.

Very nice units, ORCS! Small bug report: <ul>[*]They wiill not work properly in MP on dedicated servers. [*] config.cpp has unbalanced {}:s in CfgGroups MP problem Reason: they lack a proper addon dependency declaration. The fix: Add this requiredAddons[] line in CfgPatches: Unbalanced {}:s The config lacks one last closing "};" for the CfgGroups part at the very end of the file. Keep it up guys!

Nope, the ECP soldier features will not be seen with the HYK units since the addon isn't (yet?) ECP compatible. The "fix" is as follows: Currently, the 1.53 HYK US soldiers have the following EventHandlers definition in the config.cpp, in class HYK_USSolBase: In order to make them ECP compatible, one has to do two things: 1 - Add an empty ECP_EventHandlers declaration outside CfgVehicles: Just before class CfgVehicles add this: (The "..." just means "lots of text I haven't quoted". Don't type that into the file. 2 - Extend the EventHandlers definition for the base soldier class Edit the EventHandlers definition in HYK_USSolBase to look like this: Note that the forum system here breaks up the line for the fired EH into two - this should be only one line in the editor. There's also a space between the "4" and the "in" near the end.

Try<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">; anchor_obj.sqs ; ; Usage: [object] exec "anchor_obj.sqs" ; ; Example: [pc] exec "anchor_obj.sqs" ; _obj=_this select 0 _p=position _obj ; Position on table - 1.14 m above ground _pos=[_p select 0, _p select 1, 1.14] _delay=1 + random 1 #loop ~_delay _obj setPos _pos ?!isNull _obj:goto"loop" exit...or something similar...

You better believe it. And use of these broken addons (the majority of addons are, indeed, broken in this regard) will lead to one or more of the following typical symptoms:<ul>[*] Missions you know doesn't use addon X will get you the "missing addon X" error dialog. [*] "X" sneaking itself into the addons[] and/or addonsAuto[] parts of the mission.sqm of a mission that doesn't use it. [*] Dedicated servers silently refusing to load certain missions [*] Island intros (the ones playing behind the main menu) getting "missing addons X" error dialogs [*] Cutscenes/intros are interrupted, preventing you from seeing it [*] Missions you make using addon Y that depends on Z won't list Z , again resulting in the aforementioned symptoms. Above, Hudson gave a very typical example of one source of addon dependency - new vehicles inheriting properties of a vehicle (Jawa) that's defined in another addon (In this case Res/Addons/O.pbo, ie "BIS_Resistance"). Another common reason for a dependency is a soldier addon using rifles from a separate weapon pack. If addon A depends on B and addon B in turn depends on C, A must declare it's dependency on both B and C. So, to conclude: it's not your fault and there's nothing wrong with your setup. Out of curiosity, what does your error messages say? What addon class is it complaining about? Perhaps we can help the author(s) of that addon getting it fixed.

Fallout 2 intro - very well done and set the mood of the game just perfectly.

And the root of that problem isn't the mission makers - it's the addon makers. It's now 2005 and they still haven't gotten their act together with regards to the One Bane of Addons in MP, old man Addon Dependencies. Of course, actually making working addons seems second to making them glitzy so they can get all those nice "OMFGz0rz I wanna have your babies!" accolades. Fanboi beta testing failing as usual. As a server admin I know this first-hand since 90% of everything that's released it useless in MP without first doing time-consuming fixes. And what are those "fixes", pray tell? Why, making sure the addons have a proper <span style='color:red'>requiredAddons</span> declaration. "Proper" here means "complete", not "yeah, I have one in there". By now, one would have thought the community would have picked up a clue or two, but that seems to remain the last frontier. MP would be so much more seamless and easy if that one small thing would be done properly and always. Want to know why poor qUill gets messages about a missing rucksack addon? Yep, you guessed it... most likely a botched dependency declaration somewhere. Good luck qUiLL and don't give up just yet!

Try