mr.peanut

@HumDinger - not sure if your tone is deliberately pejorative or not. {edit:allusion to violence, 3M adhesives  and choo-choo posteriors deleted} You mean:{publicVariable "_x"} forEach [...] ? I did this. BTW, even with a small pause at the script start, it still failed most of the time I have also had problems with desync breaking unit init called scripts, scripts that are as simple as removing and adding weapons. I have also had locality problems with waypoint on activation fields.  Without a definitive MP guide from BIS, it is all trial and error. So, if no pauses exist in the init.sqs it definitely runs head to toe on all clients before the mission starts? Not all of us have unlimited access to ded servers to test every pinpoint detail, and some of us are old farts without the time to do so.

This thread is drifting quite far away from its topic, but I need to get my last 2 cents in. I was not PV'ing from the init.sqs but in a script called from there. If I understand correctly, all scripts called from the init.sqs will not execute until the mission starts and will in fact pause execution of the rest of the init.sqs until the mission starts. Â The thread I linked to earlier has the full details. Â The script almost never worked. When I moved this script to be called from a trigger that activated as soon as the mission started, it would work about 50% of the time. It was only sending about 5 values. When I made the script PV the same values 3 times with a 0.5 second pause in between it worked every time. Nobody expects a game to run 100%, but pings/bandwidths of 200/50 are still common. Â Triggers that have sensitive conditions (e.g. a side present trigger with a small area) are also susceptible to packet loss/desynch failures. Â Mission makers should not have to double trigger mission-critical conditions, nor multiply PV mission-critical variables. MP debugging is challenging enough without these difficulties.

How can it be guaranteed when we have all experienced situations where packet loss causes it to fail? Recently I have started double PV'ing critical variables (especially those sent near the mission start), with a tiny pause in-between, which seems to work reliably. One of the major uses of PV is to guarantee that eventhandlers, and triggers with sensitive conditions, synch properly. Â An option to set trigger/waypoint activation locality would be a good idea?

But I wanted to be a boogie-woogie bugle boy... (no innuendo please)

publicVariable is broken in the sense that it is not always reliable. Â Read through this thread to see what I mean by "broken". This is a far more serious problem to my mind than not being able to send (character) arrays. When I talk about querying a waypoint I mean being able to check which waypoint index is active for a group.

I think would be a neat bit of audio candy for sure to see players actually speaking ingame. It would be mission controlled setting, so you could have realistic voice/radio, or the default settings. It would really force squads to stick together. Also, enemy could detect and shoot players who talk too much or too loudly. lol. Â I guess for knowing who is who in vet mode players' names could be mapped onto a uniform patch....

A few interviews and media releases and this thread sinks like a stone. How typically superficial.

My two cents for a cool idea for the future. An option to set voice in game(VOIP) to be range dependant and lip-synched to the person speaking. You can only hear a person speak if you are close enough.

I was wondering about the locality of the following commands: play/switchMove setDir setPos setVelocity The fact that setDir is local was exploited in the ECP tail rotor failure script, but how can it be entirely local when the direction of an object determines whether or not it gets hits? Ditto for play/ switchMove. I understand these to also be local, but they would also affect collision detection.

Any word on whether the publicVariable command has been fixed? Also, to repeat myself, it seems like a serious oversight not to have a function to query what a group's present and past waypoint are.

Maybe <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">xx doWatch objNull  or <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">xx doWatch "" ?? Or maybe get them to watch you just before they are joined to you?

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">@((getdir DAC_StartDummy) > 170) {if(!(_x == _buildingA)) then {_x setpos [0,0];if(format["%1",typeof _x] == "fire") then {_x inflame false}}}foreach _camparray Is there any reason why the fire could not also be setPos to [0,0]?

Everyone has this problem. setPos a solid object just under the pier?

Everyone has this problem. setPos a solid object just under the pier?

In OFP: make yourself an East unit, and place an empty BAS addon KLR250 motorcycle beside you. Place a full West infantry patrol nearby. Make it night time. Now get on the KLR and drive all over the enemy killing them. It doesn't matter if they have NVG, or you do this in a well lit town, they will not detect you as enemy until you get off the KLR.

Do DAC groups follow the WP in the same order each time? Or is the route randomised for each circuit? I was just suggesting that the route WP be sorted in a way that minimises it net length. No matter to me. Easier not to bother with it!

Silola, If you can hold off releasing your patch, I might have something to offer as well. Â It would be a function suite that takes an array of 2D positions, and returns an array that indexes the positions to make the shortest round trip, measured by straight line distance. Right now, I only have the algorithm coded for one way trips, not for a circular route, but I think I could hack it up quickly. Missus PNut is away for a couple weeks and I need a few little projects to keep me out of trouble. I have a demo of the one way trip. If you would like PM me your email and I will send it to you.

That type of lockup results from having the same resolution and refresh rate i.e. set to same resolution but different refresh works. Â It is not a lock up per se but simply a blackout of the screen. My lockup is a true lockup i.e. keyboard and mouse buffer overflow beeps etc.

I installed the latest Catalyst drivers 6.6 on my computer recently, and since doing so an Alt-Tab from within OFP often leads to a complete system lockup. GPU is ATI Radeon x850XT. Â Anybody else experiencing this problem?

I do not see a command to query which waypoint is active for a given group. But check out the surfaceType and surfaceIsWater!

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">forceMap true

This sounds like a lot of fun, but I would need a month to scrounge the time together to participate. Are the units to be completely script controlled i.e. no waypoints or triggers? The only problem I foresee is that given the mission template, it would be possible to script for the specific location. i.e. a huge array of map locations and instructions. I would only take part if only inf units are used to keep it simple. I have the following suggestions: 1) Contestants should have to compete on each side of the conflict, for a few different mission templates.(or randomised start locations within a given distance of each other, where one group must advance west and the other east). 2) The same island (one of the BIS islands) be used for all conflicts. 3) The camcreate/createvehicle command should be allowed for emptysensors and gamelogics only to allow calculation of above sea level elevation. 4) No respawns. 5) No triggers. 6) No knowsAbout command. 7) A time limit after which losses are counted. 8) The code have some serious constraints on size, perhaps total size and/or number of lines.

Thanks Silola for the patch. Excellent to see these issues resolved so easily. Can anyone out there answer my unanswered question from above: As for a Wiki: far too much work for a small audience. I am sure Silola would not mind if you set one up though Those of us who are old farts, and still suffer from time-management disorders, know how hard it is to do that one extra thing, especially if it involves new learning. Since I started testing coop mission for LOL, I have almost no time left for mission making or even just playing OFP.

I would liked ArmedAss to have multiple controller(gamepad,joystick,etc) configs for different vehicle classes, including separate horizontal-vertical sensitivity and deadzone settings. An aircraft's throttle should not be as sensitive as a helicopter's collective. The POV control should have a lock and release. A dual gamepad should use the second controller for targeting(turret) control in manual fire modes. The list goes on...

Okay. Here is my first untested attempt: In DAC_Waiting_for_End.sqs (in both KI_0 and KI_1) add the following lines just before #checkid: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_i = 0 #checkdist if (({((_rCamp select _i) distance _x) < (DAC_KI_Spawn select 4)} count DAC_Players) > 0) then {_temparray1 = _temparray1 - [_i];_temparray2 = _temparray2 - [_i]} _i = _i + 1 if (_i < count _rCamp) then {goto {checkdist}} You must assign a fifth variable to DAC_KI_Spawn that is the minimum distance from player units enemy can spawn. If the players are too close to all possible spawn points, then no spawn takes place and that group will never again respawn. Having a second option that forces a respawn at the furthest spawnpoint would require a double loop over all players and spawnpoints, which would be slower. I would be obliged if someone could test this change... Edit: on second thought, it would be easy to adapt so that if spawn attempt fails, script waits and then tries again...