kylania

waitUntil { isnull ( uinamespace getvariable "RSCDisplayArsenal" ) }; There's another way of checking too, but that code isn't at my fingertips at the moment. I suppose if you limit arsenal item availability and block loading and check that would be good too, but free-for-all arsenal + checking seems excessive. Code from this post.

Why do you have arsenal active in a mission where you want to limit weapons? Just use respawn templates and delete bodies/weapons on death. Or just have a crate with only the weapons you want available, track who gets one and when they die/lose the weapon replace it in the box.

That's thermal while the goggles use infrared.

Did these commands you found not work?

Neat, didn't realize that about compile. Nice!

https://community.bistudio.com/wiki/splitString

The author thing is up to the community to fix their configs, haven't seen that error in vanilla content at all. I'm seeing the placement radius on the map view in Eden Editor using 1.63.136817 Not sure I understand what you mean with unit placement. I'm able to move or place groups by their group icon or leader or any selected and dragged unit in the group. Got an example? I saw that in a friends mission, but what was odd is that only one speaker had it happen. I'll check the codes to see if it was using the same format for both.

https://community.bistudio.com/wiki/Category:Scripting_Commands_Arma_3 https://community.bistudio.com/wiki/Category:Arma_3:_Functions https://community.bistudio.com/wiki/Description.ext https://community.bistudio.com/wiki/Arma_3_Tasks_Overhaul Those are the big biki links I use all the time.

This doesn't appear to be working any more. Running ArmA3Sync as administrator and have write permissions to the profiles directory. I've reinstalled from Armaholic using v1.5u6 Build 1.5.80. I've freshly installed onto the E drive so that it's no longer under Program Files to avoid write permission errors with that folder. I've tried by duplicating a profile and starting from scratch and it just doesn't keep the executable location per profile. Any ideas? A3S-DEBUG shows no errors.

You don't, you virtualize it for the sake of gameplay over realism. Click the radio trigger and they disappear into "hiding" as you delete them. If for some reason you need them again, your other trigger would spawn them wherever you want them. Or if they really must be there on the battlefield, doStop them and make them invulnerable or setCaptive so they are ignored. Or just accept that War is Hell and allow them to be killed and the mission failed because your players didn't protect them properly. :)

It's a McGuffin.

Glad to hear it's working for you. :)

From my minor testing the only benefit of the current implementation of ViV over what the community has already scripted is that if you get loaded into a vehicle while in a vehicle and Get Out you exit the parent vehicle nicely rather than get stuck between models.

You need the "EmptyDetector" in your createTrigger. That's not the name of the trigger, it's the type of trigger. _captrig = createTrigger ["EmptyDetector", position _x]; // Are you running this inside a loop on multiple hostages? _x is a special variable _captrig setTriggerArea [markerX, markerY, 0, true]; // Are markerX and markerY global variables with numbers in them? _captrig setTriggerActivation ["ANY", "PRESENT", true]; _myStatements = format[["player in thislist", "script = [%1] execVM 'capture.sqf';", "hint 'bye']", _x]; // Assuming this is looped _captrig setTriggerStatements _myStatements; // Changed this to feed just the current hostage to the script. To be honest I'd skip the triggers and just go with addActions on each hostage instead. A lot less pain and code.

Today's dev build change log lists it as a feature added (bold and everything!), but it also includes a bunch of stuff that was added yesterday, so not sure what's going on. :) Did they maybe add the preview stuff + ViV to the normal dev build and now we have to switch back to that?

Sync the trigger with a taskSetState module set to Created which in turn is synched to the second task. Or just create it on the fly using functions in the onAct field of the trigger: [civilian,["task1"],["Do this and you get a cookie","Earn Cookie","cookiemarker"],[0,0,0],1,2,true] call BIS_fnc_taskCreate;

The Apex expansion preview has been released which includes the Tanoa island and equipment and vehicles from the upcoming expansion. If you haven't pre-purchased that product and also switched over to the Apex Preview Development Build in Steam you won't be able to access the content.

They announced on twitter the other day that feature isn't in game yet.

Yeah, I saw a fish swim up the beach and head into the jungle yesterday. I just backed away slowly. Aren't those CBA messages from CBA's mod itself? Wouldn't disabling that would be removing UI abilities from all modders? Seems like a bad thing to do just to get rid of a few lines of text you'll see for a split second before opening the editor or game to me. Personally I like the little video panels, but don't like that they totally block the background.

Yeah, I imagine CSAT special forces looking more like this or this than this. :)

Yeah, seems they really should go much faster.

In my opinion waypoints for players (not destinations, but the go here, then here, then here waypoints) are not welcome. Just tell the player where they need to go and let them find their own way there. If you want them to walk a certain path either make that a cutscene or physically block off all the other options (which is equally as bad heh). If you insist on that however you can use the function BIS_fnc_taskSetDestination to move your task destination. Have just the single destination module at the location of your first trigger. Then have your little triggers in each spot and give them names like yellowBrickRoad_1 through yellowBrickRoad_5 and in each onAct field have: ["whateverTaskName", yellowBrickRoad_2] call BIS_fnc_taskSetDestination; And then change the _2 to _3 and so on, so each trigger will move the destination to the next trigger location.

Right click on the trigger, choose Sync then Trigger Owner. Drag over and drop onto the vehicle in question to connect the two with a dark blue line. Now when you look at the trigger the Activation will read VEHICLE or OWNER or something similar (away from game at the moment) and only that vehicle will activate that trigger (when set to PRESENT). Then right click and Sync and Connect the trigger to the setTaskState module.

Just tried that and you can still "pick up" the weapon but it just drops on the ground, off the table.

Hi Campbell, welcome to the forums. You can use the code from this page for that. You'd want to use the optional delete option, so the addAction would be: this addAction ["Grab Camera", "grabCamera.sqf", ["tskGrabCamera", true]]; Here's a rather glorious demo mission showing this in action.