geqqo

A mission I made (in-pbo credit is for my in-game name :)) There isn't really a particularly plausible story or such; the east-ies have set up all their units in defence of Kavala, where-as west tries to take them on at a significant numerical disadvantage for some surely serious reason, etc. 😛 Personally I've played and tested it on Veteran, so I'd suggest that but other difficulty-levels should work fine. Some things it does and doesn't have It was primarily made to be used for play with a private group of people rather than hosting on a public server but do as you please 😛 (It doesn't really try to do anything on the security front) It supports being run on a dedicated server. It doesn't support JIP. It can technically be played solo (if you can be bothered to team-switch for 6 hours 😄 Unless you're a wizard with AI-management maybe). It has a fairly comprehensive parameter list (there may be a couple that probably look mysterious, that's on purpose 😜). It doesn't really support translation (it does have a stringtable but there's some lacking dev as far as I remember, for that to "just work"). It doesn't rely on any add-ons (vanilla). Editing You'd need to regex the following in mission.sqm before editing it in the game's editor (otherwise the game would remove any such entries altogether, once saving): Search: (\$STR)(\w+)(;) Replace: "@STR$2"$3 (including quotes) Because I'm using the $STR_... way to reference the stringtable in mission.sqm ("@STR_..." has been fine for editing and running as server-player but had issues at least when the clients first acquired the mission from server in testing). Asset use Feel free to use any code or asset in there (the musical elements I cannot speak for though, since they're parts or modifications of pre-existing work (sfx are fine though)). Or use/re-release the mission itself in modified ways, etc. It's not all the neatest code though :] Bugs I most likely won't personally bug-fix the remaining things that are broken in there. The core features and actual gameplay shouldn't really have significant issues though. Some examples: The vehicle group "Tiger" can spawn stuck or in a dangerous location despite a light attempt to counter that, if placed to a custom location. The mission-provided UAV stuff doesn't necessarily sync with the UAV-terminal UI. The parameter-driven teamswitch/respawn/death handling can look a little "obvious"/rough. Revival parameters are entirely untested; might work, might not. Download [Updated: 22:28 24.08.2020: v1-03] https://drive.google.com/file/d/1IlY1AVf1WZvjJ4hXOtlBKRZ38ychZ_Ub/view?usp=sharing Hopefully somebody will get some fun out of that 🙂

Neat! It would be interesting to hear what you (or anybody) make(s) of it, even if you find it trash 😄 I just updated the file -- a parameter (experimental preloading availability for commander's live-feeds) didn't apply.

Thus the != in the given expression. You may want to take a look at the following page, in case this is confusing - Operators on Biki. The parenthesizing in the provided expression was to be used inside the if condition-delimiting parentheses (possibly along with other conditions) not in place of them, thus your initial failure. The parentheses in the provided sample aren't actually necessary (provided you encase the whole expression in parentheses), it's more of a style/readability matter (in this particular case).

Sorry, that's what I get for being lazy and not testing my suggestions... That's what you must be looking for - (!isPlayer _x && behaviour _x != "COMBAT")||(_x==_ldr) Which effectively means "If unit is AI with non-combat behaviour OR unit is the triggering player..." (... then teleport the unit). This is still expecting the inline if solution (that determines the forEach input; which is either just the triggering player (if not squad leader) or all units in the group (both AI and players)).

Well, that's what the ||isPlayer _x part does - if you use it, it will teleport the players as well (it doesn't take into account the behaviour for players though; if you wanted to apply the behaviour check to both players and AI alike, you'd simply remove all the isPlayer checks altogether (leaving just behaviour!="COMBAT")).

Indeed, it should be if((!isPlayer _x && behaviour _x != "COMBAT")||isPlayer _x) then { (lacked the ||isPlayer _x part before as well as checked the opposite of intended behaviour; also fixed in above post)

You're missing the # in front of the USER in the case the error is referring to.

These reference materials might help - BIS_fnc_createmenu, showCommandingMenu

So what you want is - - squad leader can teleport with all units (players and AI) in the team - non-leader player members can teleport on their own (without taking the AI) ? That could be done as follows (if you want to write the position setting part only once; "..." stands for the regular position setting part in your code) - {...}forEach (if(_ldr == leader group _ldr)then{units group _ldr}else{[_ldr]}); What this effectively does, is returning either the full group (if it's the leader) or only the player that triggered the action (if player is not the leader) for iteration by forEach. It's just using if inline to avoid typing the position setting code twice. This alone doesn't deal with behaviour limiting though. As for the behaviour checking. What I meant was, that you would need another forEach before the one you already have that would go through the units in the group (if the player's a leader in the first place) but instead of setting the position would check for the behaviour. To avoid the inline if altogether you could use another variable to store the unit array so the script would end up like - scopeName "actionscript"; _unitstoteleport = []; //... your usual definitions here if(_ldr == leader group _ldr){ {if(behaviour _x == "COMBAT")then{breakOut "actionscript"}} forEach units group _ldr; _unitstoteleport = units group _ldr; }else{ _unitstoteleport = [_ldr]; }; {/* set position here */}forEach _unitstoteleport; This will cancel the teleport altogether if any AI unit is in "COMBAT" behaviour. To leave behind only the specific AI units with the "COMBAT" behaviour you could still instead use the other forEach code-sample (the one with the inline if) but add inside the forEach a check - {if(isPlayer _x||(!isPlayer _x && behaviour _x != "COMBAT"))then{/*set position here*/}}forEach ...

Sorry, I must have been too ambiguous. The syntax for behaviour will allow to work as following - if(behaviour _yourunit=="COMBAT"){... You could use the check in either the same forEach to only teleport the specific AI units that aren't (or are) in "COMBAT" behaviour mode or you could use it in a preceding forEach (still for the same group, but to preliminarily check if any AI is (or is not) in "COMBAT" mode to judge whether the script should proceed to the teleporting forEach). The part in the forEach I meant as - {if(!isPlayer _x||_x == leader group _x)then{_x SetPos [(getMarkerPos _dest select 0)-10*sin(_dir),(getMarkerPos _dest select 1)-10*cos(_dir)]}} forEach units group _ldr; Also, as a little sidenote, _dir = random 359;, will in fact leave out a degree between 359-360, so 360 is probably what you mean to use there (random does not include the last integer itself but generates floating point (decimal) numbers up to that point).

If the action wasn't shown only to the leader, then right after _ldr definition - if(_ldr!=leader group _ldr)exitWith{} Whether the player activating the script is his group's leader In the forEach - if(!isPlayer _x||(_x == leader group _x))then{... As for detection of combat mode for the AI; there isn't a specific check for "whether AI is in a firefight" (as far as I know), if that's what you meant, but you can take a look at AI Combat Modes on Biki

As to why they would disappear on server restart, can't really tell as I would expect none of the previous info to carry over. Server restart shouldn't be any different from the first start, if it's a full mission restart from the lobby. Probably unrelated but if that's the full file in its literal form then the if(true) checks and using a _this variable wouldn't seem to be necessary.

if (100 > random 100[color=RED][b])[/b][/color] then [color=RED][b]{[/b][/color]['Donut',2] call INV_AddInventoryItem[color=RED][b]}[/b][/color] Also, the 100 > effectively means 100% chance, so it's not really random in the given code (but of course works for testing if the code works at all).

What kind of exact code/solution are you currently using? It happens only on restart (so it's okay the first time the server's started)? Where/how are you calling this?

Replacing _this setDir _dir; with group _this setFormDir _dir; made the unit do the move correctly unless he was in a group. Otherwise I needed to add doStop _this; right after the setFormDir line. However, this will change the direction of the group, which may be unwanted; you could temporarily make the unit leave the group ([_this] joinSilent grpNull;) and later return him if it won't break anything in the particular situation. In my tests the unit did the move at an offset though, so I needed to adjust the dir accordingly (in my particular case +20 degrees when not in a group and -30 degrees with the doStop; regardless of initial group direction, possibly dependent on the used formation (he was doing the move towards a unit in the same group)). EDIT: Didn't notice your edit before posting.

You can try getting the relative direction manually (with atan2), here's a simple test-case that works ok for me - Just place a player-unit and a second unit, name the second unit unit2. Put in the player unit's init: 0 = this spawn { _pos1=position _this; _pos2=position unit2; _dir=((_pos2 select 0) - (_pos1 select 0)) atan2 ((_pos2 select 1) - (_pos1 select 1)); _this setDir _dir; sleep 1; _this playMoveNow "ActsPercMrunSlowWrflDf_FlipFlopPara"; };

You don't happen to be using createVehicle instead of createUnit, do you? Also, you will need to have the side "center" present (is automatically present if you have placed at least one unit on the side in editor) which can be created using createCenter (as the notes on the page suggest, you may also need to apply side-relations, using setFriend).

Well, yes, it will start acting as a global variable, once assigned. While naturally any keywords/commands shouldn't be used as variable names, I just expected for some reason for it to have special handling as a "data sink" (can't quite tell where I picked this up). Quite coincidentally, I had just recently started using nil to undefine variables and started getting "anomalous" results that I hadn't yet looked into very specifically, so when Burdy mentioned the warning, the problem became clear.

That's right (in my quick test case it looked quite ok), or you can go a step further and use worldToModel and modelToWorld _vehicle_23094 attachTo [_this,_this worldToModel (_vehicle_23094 modelToWorld [0,0,0])];//Not using the modelToWorld/worldToModel in either case caused some inconsistencies If I look really close, it actually still seems a little off ground (good enough though). EDIT: Viba's solution below is naturally much simpler :D

According to createMarker biki page additional notes, you would need to define shape as well in addition to type for it to be shown. As for the trigger; it's working as written, if there's no enemies in the area and you're flying above 10 meters - there's "any" unit "present" and the number of units below 10 meters is not greater than 0, thus triggering the "false case" script that shows the red marker.

Here's some references - select, init.sqf (and others), general script command reference for Arma 2 (&OA). Hope that clears things up a little :)

You are referring to the VBS wiki, this functionality doesn't appear in createVehicle_array (the Arma 2 version). attachTo applied to your code (preserving usage of the two different variables that you are using for the vehicle) would look something like the following: _vehicle_23094 = objNull; _this = createVehicle ["HeliHEmpty",[4057.35, 11662.7, 0.000128174],[],0,"CAN_COLLIDE"]; _this setDir 207.046; _vehicle_23094 = createVehicle ["Infostand_2_EP1", [4057.35, 11662.7, 0.000128174], [], 0, "CAN_COLLIDE"]; _vehicle_23094 attachTo [_this,[0,0,0.9]]; _this = _vehicle_23094;

forcePos doesn't appear here, google doesn't give anything related either, what exactly are you referring to? You might be able to use attachTo with a "HeliHEmpty" (invisible object) vehicle to achieve what you want (I thought initially that it would've disabled clipping altogether but apparently not (quite; try for yourself)). Or set the position in OnEachFrame or a regular loop.

Should be just - "colorCorrections" ppEffectAdjust [1, 1, 0, [0,0,0,0], [0,0,0,0], [0,0,0,0]]; "colorCorrections" ppEffectCommit 3; In other words, reseting the value and recommiting.

Wow... must be the nil = 0 spawn { that I've been using in editor for testing (it doesn't like any value returned so I've been returning into nil but I guess it doesn't work like void in C or similar (got to fix some codes on my end now that I'm aware of this; never encountered this warning before, curiously, probably due to my singleplayer background)). Just replace it with 0 = 0 spawn{ .... Sorry about that :|