Magirot

I retested it now. My cardinal error earlier was to not use a dedicated server, thinking it won't matter in this case. At least for me, the side does change if the player dies - however, the lag between the server and the player results in the BLUFOR AI taking a few seconds to realise this, enough to fire a volley or two. Terox's solution above would fix it (put the respawn far away, and setPos in the compound only after a while), or simply put the respawn in a building where they're out of sight of the AI at first. Making the player join the AI group might also work. The trigger is nicely thought, but its behaviour right now would be pretty annoying when you play it with more than one player: An OPFOR walks in the trigger, triggering it for all players. All players get switched to BLUFOR, regardless of where they are, because player always refers to the local player and the trigger was triggered to everybody. This should be fixed if you just change the trigger's Condition from "this" to "player in thisList". thisList is a special variable for triggers referring to all units which are in the trigger and fulfill the conditions (in this case being OPFOR). However, that won't change the fact that if someone wanders in the trigger when simply assaulting the compound as OPFOR, it'll change their side - I'd still try my hand with the onPlayerRespawn setup.

:Oo: When I tested it before it worked fine. Sorry, I'm not sure if I can re-check it today, but I'll take a look tomorrow if no-one else can help you in the meantime.

Here's an example mission containing what I described, which worked when I tested it, at least. dl (3kb)

It's easily explained: if a JIP player joins while the game is in progress, without isServer their init.sqf (or even a trigger) would throw the unit back to one of the starting positions, which, when badly timed, can be annoying. Another point is that every player gets a different result from BIS_fnc_selectRandom. Wouldn't be an issue in this case without JIP, since the final setPos in the beginning would set it up nicely anyway, but it's good to remember.

Hmm, how have you setup the trigger? I mean, if you use a trigger, the condition box would only have isServer (nothing else) and the onActivation box should contain the markerpos and setPos, without { } or anything. I'm unsure because you listed them like a script syntax, was that just for presentation? Local variables (signified by the underscore) don't work in triggers, and are mainly used in separate scripts like init.sqf, that's why the editor complained.

I was just thinking that it'd be better if it was under the "official" customisation options, since people afraid of scripting might not want to venture past the "do not edit beyond this line" point. Just a percentage applied at the end of the _civilians checkup would likely work fine. Thanks for fixing the blacklist, it works fine now. However, whitelistmarkers doesn't... whiteListMkrs=["civsmarker"]; gives if (_name #== "") then {}else{ Error Generic error in expression on line 55 of cosInit.sqf. Doesn't == "" work with structured text or something?

Make sure it's run only on the server and you're all set for MP and JIP in this case, since setPos is global. if isServer then { _randompos and setPos stuff here };

According to Killzone_Kid in the wiki, setObjectTextureGlobal isn't synced with JIP players, so probably it's still smarter to use BIS_fnc_MP or some other setup? Edit: Oh, I should've checked the link to the feedback tracker. It seems to be fixed, so you don't need BIS_fnc_MP for this at all. Rest of this post isn't relevant. In this situation it would probably be best to use a function called BIS_fnc_spawn. It will allow you to pass code directly with BIS_fnc_MP: // all this should be executed only on one client, presumably the server _object = createVehicle ["Sign_Sphere25cm_F", _pos, [], 0, "CAN_COLLIDE"]; _object attachTo [_target, [0,-2,1.329]]; _object setVectorDirAndUp [[0,0,-1],[0,1,0]]; [[_object], { (_this select 0) setObjectTexture [0, "textures\NATO V2.PAA"]; }], "BIS_fnc_spawn", TRUE, TRUE] spawn BIS_fnc_MP; The last two parameters (target and isPersistent) are best read from in the wiki.

Probably due to every marker name having to be unique. You have to generate a new name each time: [b]_markercount = 0;[/b] while {true} do { { if ((_x isKindOf "Man") and (isPlayer _x)) then { _markerstr = createMarker [[b][url="https://community.bistudio.com/wiki/format"]format[/url] ["markername%1", _markercount][/b], getpos _x]; _markerstr setMarkerShape "ICON"; _markerstr setMarkerType "mil_dot"; [b]_markercount = _markercount + 1;[/b] }; } forEach Allunits; sleep 10; };

You don't actually need to execute the script anywhere, the default is (or at least was) that onPlayerRespawn.sqf is called when any respawn is run. From the wiki link: "When you create files called onPlayerKilled.sqf and onPlayerRespawn.sqf in your mission directory, they will be automatically executed on player's computer when he dies and respawns."

Really? :Oo: I'd have thought that the increase in mass at the beginning would sink any other ship like a rock right away. ...actually I guess that's an appropriate sinking speed for any other vessel the game has. However, that addAction script attaches the explosive based on the size of the trawler, so there's a floating explosive somewhere nearby. You could maybe put the location setup of the latter under an if so it'll attach to the default [0, 0, 0] when it's not a trawler: Edit: Maybe it was because of it attaching a long way off the boat in the way I mentioned above? If not, you could just put _target setDamage 1; after the last sleep.

Killing members of your own side doesn't switch you to the opposing side, it sets you as hostile to all and everyone. But just changing the side is very simple, basically put if isServer then { bluforgroup = createGroup blufor; publicVariable "bluforgroup" }; in init.sqf and [player] joinSilent bluforgroup; in onPlayerRespawn.sqf in your mission directory. Group determines the side of the unit, so that'll make respawning units blufor. If your respawn position for OPFOR is in the BLUFOR compound, and you setup the loadout after that, it should be all you need. Unless onPlayerRespawn runs at the start of the game too for missions with respawn enabled? In that case it should be // Player's old unit is the second parameter passed to the script. _oldunit = _this select 1; // If the old unit is null, then the player hasn't died yet. If it isn't null, switch to blufor. if (!isNull _oldunit) then { [player] joinSilent bluforgroup; // Loadout stuff here }; Edit: More info on the respawn scripts at the wiki Edit 2: Realised that the server probably has to publicVariable the created group so the players can access it; added.

this addAction ["Place Explosive Charge", "attach_charge.sqf"]; on the trawler object's init.

Is there a reason why cos\addScript_Unit.sqf has _unit addAction ["Hello", ""]; in it on default? It would be nice if the default customisation options had a way for decreasing the number of civilians the system spawns. Other than that, this is a great system, thanks a lot. Edit: Hmm, I also don't seem to get blackListTowns to work. Or at least when I put blackListTowns = ["Kavala", "CityC_Kavala", "Neri", "CityC_Neri", "Aggelochori", "Panochori"]; in there, civilians still spawn in all of them.

You can use { _x hideObject FALSE; _x enableAI "MOVE"; _x setCaptive FALSE; } forEach units group this; in the init field of one of the group members to apply it to the whole group, or forEach [soldier1, soldier2, soldier3] to list exact units. _x is a special variable referring to the object it's going through at the moment with forEach. I'd rather go with disabling the simulation, though. While enableAI disables even the unit's capability to turn (or did in Arma 2 at least), it'll still fire if someone gets in front of it. I also realised that you DO have to run hideObject separately for everyone instead of it working right through the init line. So I'd go with handling most of it through init.sqf. If you want to go with what I described in post 2, leave this in the init field of the group leaders: ambushgroup1 = group this; (changing the number with each if there is more than one group) This assigns the variable ambushgroup1 to refer to the group of this unit. Then in your init.sqf (if you don't have an init.sqf, create one in your mission directory): // set a variable to determine if still to hide the units for join-in-progress players // on the server and then broadcast with publicVariable, again to account for join-in-progress players if isServer then { ambush_activated = FALSE; publicVariable "ambush_activated" }; // use if there's only one group: if (!ambush_activated) then { { _x enableSimulation FALSE; _x hideObject TRUE; } forEach units ambushgroup1; }; // if there's more than one: if (!ambush_activated) then { { _x enableSimulation FALSE; _x hideObject TRUE; } forEach units ambushgroup1 + units ambushgroup2 + units ambushgroup3; }; Then, in the trigger where you want to activate the ambush: // use if there's only one group: { _x enableSimulation TRUE; _x hideObject FALSE; } forEach units ambushgroup1; ambush_activated = TRUE; publicVariable "ambush_activated"; // if there's more than one: { _x enableSimulation TRUE; _x hideObject FALSE; } forEach units ambushgroup1 + units ambushgroup2 + units ambushgroup3; ambush_activated = TRUE; publicVariable "ambush_activated"; JIP, as always, makes it a bit more complicated than it should be. If someone knows a simpler method, I'd be happy to know of it as well.

Ooh, that's why the function in the bomb planting script was returning weird stuff, I used BIS_fnc_dirTo by accident. D: Fixed it now. Thanks, everyone.

You can use spawn to sleep past the randomisation. In the init field: handle = this spawn { sleep 0.1; _this setObjectTexture [0, "\A3\soft_F\Offroad\Data\Offroad_ext_BASE02_CO.paa"]; _this setObjectTexture [1, "\A3\soft_F\Offroad\Data\Offroad_ext_BASE02_CO.paa"]; }; http://forums.bistudio.com/showthread.php?156120-Setting-Color-of-Offroad&p=2408318&viewfull=1#post2408318

Huh. A day of scratching my head with setVectorDirAndUp loops, and now I learn from the video that all you need in Arma 3 to sink the trawler is something on these lines: trawler1 [url=https://community.bistudio.com/wiki/setCenterOfMass]setCenterOfMass[/url] [[-1.8, -6.5, -4.5], 60]; trawler1 [url=https://community.bistudio.com/wiki/setMass]setMass[/url] [5000000, 60]; That's pretty handy. I made a more complicated script which tries to account for faster sinking after the water reaches the deck. Also has some options for customisation. I'm not perfectly happy with it, but maybe someone finds it useful, or can suggest improvements / tweak it: Here's it in action: I used this as the addAction script:

That's a smart thing to do actually, because "vehicle player" refers to the player infantry unit if the player isn't in a vehicle. So if the waitUntil manages to run before the player is in the helicopter, it checks if the player is standing on the ground, and queues the eject action. The issue was that you checked for the vehicle of "_wgroup", which is a group instead of an object. Like with the lock command, isTouchingGround _wtaxi (or isTouchingGround vehicle leader _wgroup) would be functional. Glad that you got it working! :)

There's nothing wrong with your use of waitUntil, at least. I just tested it in the editor and it worked fine. Maybe it's something before that? Can you post the full script? Here's all of what I tested:

Yes, it certainly does. D: If only it was mentioned in the wiki. What about wreckLimit, though?

You have to specify the vehicle to eject in the player action as well, as in Ignaeous01's example above: player action ["Eject", vehicle player];

I'd say this, but I'm not sure if it'll get to 1/10 of a second, in my experience it usually takes somewhere between 0.2-0.5s (at least when you count the time it takes for triggers / waitUntil to catch up - I don't know if addPublicVariableEventHandler is better in that regard). It might also be worse on servers under heavy load. Maybe someone else knows more. I doubt serverTime is any more reliable than time.

How did it break it? Did it give any error message? But apparently the problem is that the land command wants the helicopter object itself instead of the group leader or pilot. Geh. This works for me, at least: _veh = [_eastposition, 0, "O_Heli_Light_02_unarmed_F", opfor] call BIS_fnc_spawnVehicle; heli1 = _veh select 0; _heligroup = _veh select 2; _heligroup setBehaviour "SAFE"; player moveInCargo heli1; _wp = _heligroup addWaypoint [getMarkerPos "opf_air_land", 0]; _wp setWaypointType "MOVE"; _wp setWaypointStatements ["TRUE", "heli1 land 'LAND'"]; // or 'GET OUT' for keeping engine on // if the heli should leave afterwards waitUntil { vehicle player != heli1 }; heli1 setVehicleLock "LOCKED"; _wp = _heligroup addWaypoint [getMarkerPos "somewhere_far_away", 0]; _wp setWaypointType "MOVE";

Oops, you're right. :) *"this land 'LAND'"]