beno_83au

I think it'd only wrap it AFTER either hitting "OK" on the trigger or saving the mission (or some other event, been a little while). Either way, code works, but doesn't like going into a trigger. So maybe it is a scripted trigger like you mentioned (which means we need the trigger code.....)

Ok, in that case let's start with: _players = players; You've declared players as a group (in the leaders init) - https://community.bistudio.com/wiki/group. So _players is a group. Keep that in mind. toWhom is the first parameter, which here is _x. The group of a1, a2, etc, is considered, and in this case you are just revealing the player to the group of a1, then a2, then a3 and so on, because of how you've written it. But even in your original example you've just using a group (_players) instead of an object, so it was failing at that point. So........ toWhom reveal target toWhom: Object or Group which receives revealing information target: Object which is revealed You need to write it so that an object or group has an object revealed to them: { _aiGroup reveal _x; } forEach (units _playerGroup); With _aiGroup and _playerGroup defined correctly, that will reveal each unit in the player's group to the AI group.

Wait, which one is it? Do you want to reveal the players to the AI?

Perhaps you need to read sarogahtyp's reply a little more closely: Looking at the command reveal would explain his reply in detail.

If it's account theft then wouldn't it affect your entire catalogue of games?

I'm thinking maybe a visible button in a corner, where it might not be in the way?

Yeah, that'll work fine. But the initial problem was your use of _wpHeli1. When you create the waypoint it generates an array of the group and waypoint index. So _wpHeli1 is actually [_group,_index], not just the group. Food for thought at this point really.

Maybe start with the trigger: https://community.bistudio.com/wiki/setTriggerStatements. But your StopFollowing variable has no purpose in the above script. StopFollowing is immediately declared as 1 straight after the trigger is created. But the trigger statement is written wrong (== not =). But the script is a bit confusing, so I'm not sure if that's actually meant to be your condition. You could just cut the trigger away altogether and use a distance2D check in the loop: while {(_unit distance2D _position) > 10} do { //code }; Where _unit is the unit that the camera is following, and _position is where it's going to. So you could adjust that condition to end at a different time. Depends on what you're actually trying to do though.

Well, https://community.bistudio.com/wiki/addWaypoint returns an array. So _wpHeli1 is an array, and that's what you're using with setCurrentWaypoint. But also, no units are actually assigned to your group. You create the group, then create the vehicle crew, but you never add the crew/units to the group. https://community.bistudio.com/wiki/createVehicleCrew returns it's own group anyway, which means you don't need to create a group at the start: _vehLiftHeli = createVehicle ["O_Heli_Transport_04_F", getMarkerPos "wpHeli_1", [], 0, "FLY"]; _grpLiftHeli = createVehicleCrew _vehLiftHeli; _vehLiftHeli setDir 240; _grpLiftHeli addVehicle _vehLiftHeli;

Sounds alright. Leaves room to scale the size/length of the game too.

You're already referencing the spawned object, just add the action to it, or add inventories, or whatever else you need to do with it. Example: _spwnveh addAction [//code]; You'll only need remoteExec if you're trying to script for multiplayer. But as Harzach said, setVehicleInit and it's related commands were disabled (as the linked wiki description states).

At a guess, that's probably a config entry for the ammunition, not the aircraft.

https://community.bistudio.com/wiki/setObjectTexture will allow you to change an objects texture, and https://community.bistudio.com/wiki/getObjectTextures get you the textures available to that object.

That's definitely what it sounded like 👍

Doesn't work like that.

I think they all have compatibility versions on the workshop.

Did you get A2 from Steam?

At some point, likely regularly, you're going to have to do a restart to maintain performance.

@LazyLukeGaming This has, unfortunately, been one of the biggest issues with Life servers. Ripping content and asking for payment has not only left a sour taste in many mouths around here, but also forced some community contributors to cease contributing. It sucks, but the best thing you can do would be to report the servers to BI or report any ripped content on the Steam Workshop to Steam (and perhaps the original creator). Also, yes. Necroing a post is frowned upon, but this is at least not as bad as asking a dead thread for updates.

Well, at a guess I'd say you need to check your key bindings to make sure nothing is duplicated. That's all I can think of really, as the command menu doesn't randomly show up like that (unless there's some broken mod that's doing it). If it is a mod, you need to test them each to see which one is causing it. It could end up taking a while, so maybe start with the most likely mods to be causing it.

Are you using mods? And maybe post a screen of the "command action combat box", I'm not even sure what that is but it doesn't sound like the vanilla action menu. The action menu doesn't prevent you from controlling a vehicle anyway.

It sounds like the dirt strip might not actually be configured as a runway. If that's the case, you can configure your own runway and include it as a mod, but it's not a simple thing to do.

So, kind of in line with what Sarogahtyp has linked, except that in your case it may be fine to use limitSpeed even if they do ignore the limit once they are in contact, as you'd expect from any counter-ambush drill. But then, if they aren't going to be in contact then limitSpeed would be fine. In Sarogahtyp's example the vehicle is being prevented from going over the limit even if they are in contact, which is a pretty handy thing if that's what your aim is, and that example works well. It all kind of depends on what you are doing with the convoy. Like, are they just going from A to B to look cool? Or are they going to get ambushed? If they're getting ambushed, are they stopping to fight, or continuing through? That sort of info helps a lot, and it sounds like you're ambushing the convoy, but it's good practice to be specific about it. But you can definitely set a vehicle's speed in km/h (forceSpeed actually uses metres/second, so is an easy conversion).

Have you tried it?

Perhaps with support groups like mortars, and maybe AT teams, it could show the amount of ammo or fire missions still available if it doesn't start to get too cluttered.