jshock
-
Content Count
3059 -
Joined
-
Last visited
-
Medals
-
Medals
-
Posts posted by jshock
-
-
Anyways, this is just my two cents, might help op with deciding which method is preferable
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...
-
2
-
-
Having all other things being equal, it should not be better.
At first, select creates (returns) an array which is not there in initial variant. Here we have some slight memory and execution overhead.
At second, additional iteration loop is having place because of forEach; in case of apply there will also be overhead caused by calls and storing their results back into array.
At third, there will be no gains in terms of reducing initial operations count: no new corners to be cut, etc. select is still O(N) where N is number of elements in input (playableUnits).
Having O(N) both ways, what matters is amount of operations performed on every iteration, e.g. you can win a (very tiny) bit in some places: like not creating _forEachIndex in select; and lose using extra calls, and extra memory.
Consider measuring for different orders of magnitude of input's size to have a full and clear picture (esp. if not sure algorithm complexity is linear).
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 :).-
1
-
-
This page shares a lot of interesting info, with some timings for most instances:
-
What about something like this?
{ //Your if stuff false; } count ({player distance _x } count playableUnits)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....
-
2
-
-
{
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;
};
-
2
-
-
if(hasInterface) then { //run on all player clients incl. player host [] spawn { waitUntil {sleep 0.1; !isNull player}; //this code will executed locally when player joins mission ? }; };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.using your redress script so... general thanks :)
@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 :).
-
2
-
-
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.or what Killzone Kid posted. link in name
Im always editing inits looking for better performance .
my understanding is if you use initserver.sqf then you don't need if isserver in a script and same with initPlayerLocal.sqf.
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.
-
Can you post what your file looks like? Cause I've done the same in a mission of mine and it works fine.
-
ps:..config then...that's another story. That's a NO NO for me...
I can work the configs if necessary, I just need the textures :p.
Man, setObjectTexture could be truly powerfull - if it didn't cause issues with LoDs and foggy weather. :/
Yea, it would be nice to have that work fully, completely script in new textures on the fly.
-
2
-
-
I used setobjecttextureglobal, on OPFOR fatigue, with Cunico's gas mask and black shemag..... just for the fun of it.
I bet if I learn how to retexture uniform I can come pretty close to Riten units.... :P :P :P
Yea if I had and/or could afford Photoshop, I would have learned at least some basics a long time ago. But since I also refuse to pirate it like most people do.....
Questions, looking for a few functions
in ARMA 3 - MISSION EDITING & SCRIPTING
Posted
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