geqqo

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.

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 🙂

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.