jshock

Sqf is a proprietary language made my BI, so video game coding books won't do you much good other than getting the basic coding ideas down. There are a lot of videos out there on sqf stuff and there are a number of threads of similar nature here on this forum. Check out this post for some extended info and some other intro stuff: https://forums.bistudio.com/topic/183993-scripting-introduction-for-new-scripters/

Look at this page: https://community.bistudio.com/wiki/addAction You have access to who called the action, the object the action is attached to and the ID of the action. You'll want to use the caller to find out which player executed the action. Side note: As far as pasting code, copy it from your text editor, go to the forums here, you should be able to see an icon that looks like this: < >, but the arrows are blue, click that, paste in, click ok, done is done.

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

I don't know the basis of your database or how it functions, nor do I know Alive that well either, but look at Mission Event Handler for EntityKilled for deaths/kills, a Fired EH for shots fired, etc. https://community.bistudio.com/wiki/Arma_3:_Event_Handlers

My thoughts are to just add user input for an area to allow for detectable distance from origin and deadly distance from the origin. But right now everything is based on using the "inArea" command and the damage system is relatively related and completely seperate all the same in the sense of if you don't meet "safety requirements" damage is applied to you over time until you are dead or until you meet those requirements. I'm not sure if allowing that user input would at least curb your needs or at least closely mirror them, but with the current setup of all the functions and such I would have to make a lot of changes/allowances to accomadate something like that. Or at least that's what I'm thinking right now, that could change...

This I do understand, I just wanted to see what we could get away with in sqf, cause I know with some things I've been surprised ;).

Only one way to test there barbolani . Optimizations threads are always exciting to me, learning new stuff and all, only reason I'm not throwing up timings is it's 4am and I'm on my phone trying to beat insomnia (at least to some extent). I would like to see the timings on something like barbolani posted but more like the following, just to fully test out some different script commands and possibly some future optimizations (doubtful on the following, just want to see the results :p): (playableUnits select {allConditions}) apply {_x call fnc_doStuff}; Will test this and others after college shit tomorrow :).

This page shares a lot of interesting info, with some timings for most instances: https://community.bistudio.com/wiki/Code_Optimisation

Count returns a number not an array for use, did you mean select?

As far as I remember sqf will evaluate all conditions no matter the order or outcome of one conditional compared to another. You will need to explicitly evaluate lazily: if (cond1 && {cond2} && {cond3}) then {stuff};Where if cond1 is false, it implictly falsifies the entire condition, whereas your original would evaluate all of them anyhow, but anyways, seems you understand that concept, just wanted to say sqf doesn't do that inherently.And never mind to it all, your're nesting the if statements, same damn thing as what I just put lol, long day. As far as nearEntites goes, I don't know what's under the hood there, but it's safe to assume it would probably iterate through all entities (AI or players) not just players. So I would recommend iterating through "allPlayers" command, doing the distance check last, and the other conditions in whatever order. And for another optimization that could help some, use count instead of forEach, no difference between the two other than forEach provides an indexing variable that increments for each element iterated through, which you aren't using. I would recommend coding it on the basis that the number of players could inherently be infinite, because when your're dealing with only a handful the performance requirement would be negilgible. Again, small but could help, the side of the player is unlikely to change, so instead of re-evaling every iteration, save that value outside the loop.

Your heaviest evaluation will be the distance, but the real question is how often this is evaluated?

A leading \ may be important: file = "\dnr_decals\scripts\script.sqf";

Sorry for the lack of updates guys, been busy and been taking a step back away from this for the past couple days. Hopefully will push some new stuff the next week or so....

{ if (side _x == east) then { holder = createVehicle ["GroundWeaponHolder", getPos _x, [], 0, "CAN_COLLIDE"]; _x action ["DropWeapon",holder,currentWeapon _x]; _x playMove 'AmovPercMstpSsurWnonDnon'; _x disableAI 'ANIM'; _x setCaptive true; holder = nil; }; } forEach thisList;

Your condition should be good try the following in onAct: {if (side _x == east) then { _x playMoveNow 'AmovPercMstpSsurWnonDnon'; _x disableAI 'ANIM'; _x setCaptive true; }; } forEach thisList;I don't know if there is a Vanilla surrender module available, but the playMoveNow above uses the surrender (hands on head) animation, so you should be fine :).

Yup my apologies, kinda threw that together quickly :p (the below should also work): if (!(getPlayerUID _x in _myWhiteList) && (_x inArea "zoneA")) then {blah};And just an FYI, the _myWhiteList variable needs to contain all the approved player ID strings for your area, not what I provided, those are just for example purposes :).

myUnit getVariable ["ACE_isUnconscious", false];

private _myWhiteList = ["id1","id2","id3"]; while {true} do { { if ((!getPlayerUID _x in _myWhiteList) && _x inArea "zoneA") then { _x setPos getMarkerPos "zoneB";// or getPos "zoneB", depending on what the zones are }; } count allPlayers; sleep 3; };

To the comment after waitUntil, yes.

I think black is fine, blue would make me think they're some sort of over protected doctor, lol.

I'm not too sure at this point either...lol.

I use the export functionality without any issues, but if your're getting an error saying a file is not there, then it isn't there, lol. Make sure your saving/exporting the right mission file.

That fucking thing still works, I haven't even looked at it in over a half-year or more. Glad to see it's still of use to people :D.@Ltf, those uniforms are fucking awesome. I'm thinking for an overall thing, there needs to be white/black/yellow/red/orange/green suits, that covers all the flourecents and your standard white/black. But that's up to you :).

Your understanding is correct (those commands are essentially built into the backend of those files), from a performance standpoint, there may be slight differences, the true upside being you know the absolute locality of the code executing.To tac onto what has already been presented by davidoss, the way he is checking the server ensures compatibility between SP and MP, as in SP the player is both a client and the server at the same time (at least in basic terms). Your original code would do the same, between SP and MP, but the isDedicated check is really just an unecessary conditional (again barely any difference in performance, just extra stuff to look at). Where an isDedicated check would come in handy is when you want code in the init.sqf to only run on the HC (headless client), in which case you'll want: if (!hasInterface && !isDedicated) then { call TAG_fnc_myHCFunction; };Lots of the locality condtional commands are more for certainty of where and when code/functions are executing over general purpose usage. They are also good for function security, in the sense that I can make a function only executable on the server or only a client or only the HC, no matter who/what calls it. And with the CfgRemoteExec now in play, it makes that even more secure.Anyways probably way more info than you probably wanted, since davidoss gave you a good short answer, but I can't go to sleep and saw the thread :). Also just noticed KKs note on that link covers most of what I just said, but it's typed anyhow lol.

Hm, I'm not seeing anything that stands out, though I'm currently on my phone so the formatting is a bit weird. Have you checked the rpts both client and server side to see if there are any errors that pop up? Just weird it works in editor preview, just not on a dedi. Only thing it may be that I can think of is that the initPlayerLocal isn't in the final mission pbo, therefore not executing once on the server.