Stanhope

@Foxtrot39 since this thread was created, almost exactly 2 years ago now, a lot has changed in the development of I&A3. I suggest making a new thread in the ideas box, I think it's more likely you'll get an answer there.

Where did you put the readme, what did you call it, what's in it and did it work on a locally hosted server?

Nope, term is just short for terminal.

Yes, yes you defined them in the mainAOs.hpp but they aren't put down on the map. How is it supposed to know where you want those vehicles to spawn if you don't put down a marker with aac_jet3 and aac_veh10 as names down on the map?

Yes, term_veh10 and term_jet3 are there but not aac_jet3 and aac_veh10

Could you send me your RPT?

Well yea, the relevant settings for your custom difficult to show the names and the hexagons The aac_jet3 and aac_veh10 markers don't exist so it's not gonna be able to spawn anything on those markers. Which it probably already told you in your RPT.

Put the server on rookie difficulty, or a custom difficulty, whatever works for you.

It never actually worked as intended and it's not in the mission file anymore, I've just not gotten rid of all of the references to it yet.

I'm pretty sure there is yea, I just don't know it.

You can just ask in one big thread, you don't have to make new threads for every single issue. Side mission rewards: \Functions\Vehicle\fn_smhintsuccess.sqf FOB buildings: on the map itself, keep it within 250 meters of the FOB marker you see in the editor. FOB vehicles: \Defines\MainAos.hpp search for FOB Other FOB mechanics: \Functions\Base\fn_BaseManager.sqf and fn_baseTeleport (in the same folder) to a certain degree

Are you sure that VON is enabled on your server? Because there is nothing else in the mission that messes with von

You have some inconsistencies in the files. In description.ext you fully disable global, side and command channel while allowing both text and voice in group, vehicle and local. But in onplayerrespawn you disable global, enable side and only allow chat on command. I suggest getting rid of the disableChannels in description.ext (lines 35-43) and using the code in onplayerrespawn (lines 85-87) to enable and disable channels. With maybe the exception of systemchat, I believe you have to use the one in description.ext for that

Yup

Send me the mission file, I'll have a look

Nothing new about it, it's been in the rules for several years now. Last time I played there were 2 3-man armour squads, the typical driver, gunner, commander. @GazMazk are you asking for armour roles in I&A3 or in I&A4?

That file, arma3_readme.txt is located at C:\Program Files (x86)\Steam\steamapps\common\Arma 3 for me, where my arma is installed. Put the code you find in that other thread in there and put the UIDs of the people you want to have zeus access in the appropriate array.

I can't remember but there might be something in description.ext as well

Between 16/5 and today I've made 182 commits to I&A3 across all 15 version. That's an average of 2,5 commits per day and an average of a version every 5 days. Around me I have 3 papers filled front to back with bugs that have been reported to me via some way, only a handful remain unfixed at this moment in time. Half of which don't even affect anything a regular player can see. Tell me again that I choose not to fix things.

Have a look at I&A4, then come back and tell me that I'm putting to much in that shared functions file again. Now that you mention perception. How I read your original post: "Stan, your code is not good enough, here's a way to fix it. I didn't look at it because it took me some time to find it but I'm sure it's bad." You then proceed to give me code that, except for a few minor things, does the exact same, in a very similar way. And about your steps, I know perfectly well how to implement a function, no need to spoon feed me that.

Have a look at this topic:

Check in the onplayerrespawn file, there's 3 lines with enableChannel, those disable VON in certain channels.

Bold assumption Could you remind me what the technical difference is? Because defining a function is, as far as I remember, just an easy way to put your code in a variable. The only benefit of doing it with a function is that you can whitelist it for remote execution if remote execution is locked down pretty strictly. Which it is not in I&A3, so I don't know why I should put it in a function. You only had to check 2 files seeing how you were looking for an addaction. It could either be assigned to the vehicle or to the player. So it'd either be in onPlayerRespawn or in vSetup. And seeing how I've chosen to assign the action to the vehicle, not the player, it's in vSetup. Line 260 to be exact. There you find this code: [_vehicle, ["LMG_Minigun_Transport", [1]]] remoteExecCall ["removeWeaponTurret", 0, false]; [_vehicle, ["LMG_Minigun_Transport2", [2]]] remoteExecCall ["removeWeaponTurret", 0, false]; _vehicle setVariable ['turretStatus', false, true]; [_vehicle, ["Toggle turrets", {_this spawn turretFunction}, [], -20, false, true, "", "(_this == (driver _target))", -1, false]] remoteExecCall ["addAction", 0, true]; Let's quickly look at what this script does. It starts by removing both guns from the ghosthawk, then it sets a variable and finally we assign the actual action to the vehicle. This because a member of staff had specifically requested I make something that would lock the guns by default. You now also have the variable name of the thing that contains the code: "turretFunction". All you have to do now is do a global search with any decent IDE and you'll find the file that function lives in in seconds. No need to be looking around for 10 minutes. So let's take a look at this function: turretFunction = { params ["_heli", "", ""]; if ( isNil "_heli" ) exitWith {}; if !( _heli isKindOf "Heli_Transport_01_base_F" ) exitWith {}; _turretStatus = _heli getVariable ['turretStatus', true]; if ( _turretStatus ) then{ [_heli, ["LMG_Minigun_Transport", [1]]] remoteExecCall ["removeWeaponTurret", 0, false]; [_heli, ["LMG_Minigun_Transport2", [2]]] remoteExecCall ["removeWeaponTurret", 0, false]; systemChat "Turrets disabled. Use this action again to enable turrets."; _heli setVariable ['turretStatus', false, true]; } else { [_heli, ["LMG_Minigun_Transport", [1]]] remoteExecCall ["addWeaponTurret", 0, false]; [_heli, ["LMG_Minigun_Transport2", [2]]] remoteExecCall ["addWeaponTurret", 0, false]; systemChat "Turrets enabled. Use this action again to disable turrets."; _heli setVariable ['turretStatus', true, true]; }; }; So, what do we do here? We get the heli from the params, do some routine checks, and get the variable we set earlier. Next we check if said variable is true, if so we remove the guns, if not we add the guns. Take particular note that there is no addaction command in this code. Now for your complaint about the text not changing: why should I add 2 actions to the player when I can do it with one on the vehicle? Why not just use setUserActionText to change the title of the action? That means only one condition has to be checked. Because let's look at the documentation of addAction: I only read reasons to keep the amount of actions limited. Now let's look at the code you wrote: To be honest, this could be written much shorter while still maintaining readability. First, why check for the 3 classnames of the ghosthawks? What if BI decided to make a new ghosthawk next update? You're going to have to manually add that to both of those lines. Why not use _heli isKindOf "Heli_Transport_01_base_F" instead? As for the variable, why put string in there? Why not just a boolean? Heck, rename it to gunsLocked or something along those lines so it's more clear what true and what false means. That also gets rid of your switch statement and you can use a simple if then else, less code, smaller filesize. That always makes people happy. I do this for free, in my free time. I'm not trying to make the code pretty, or easy to read. I&A3 is not going to be around much longer so I don't see the point in starting to make clear, easy to read, well documented code. If it works it works. If it does what it's supposed to in a performance friendly way, even better. If I was paid for this or was planning on showing future employers this code I'd make it look pretty, would follow all the conventions, ... But I'm not, so I don't. And I don't want to be paid for any of this. On a closing note: the code that you're complaining about has been tested, extensively. It was originally written for I&A4 by me and has been modified by Ryko. I've then taken this modified version, modified it a tiny bit more and put it back into I&A3. It was then tested by me, on a dedicated server, with someone else, to make sure it works. It's been in the mission since version 3.3.27, we're currently on 3.3.31. It's been in I&A3 for over a month and has been in I&A4 for a while as well. You've just given me the 2nd report that the action duplicates itself, I've got it written down on my todo list actually. In case you don't believe me. Yes I have ugly handwriting. Oh one last thing I forgot to mention: I have no intention of putting your code in. Not because it's bad code, it looks pretty decent except for the things I pointed out previously. But because it's not needed. I'll use setUserActionText to change the title of it in the next version. As for the action duplicating itself: seeing how it has happened twice in the month it's been on server I'm going to assume it's not my code that's fucked up but that it's arma.

Why not?

That's because actionKeys returns an array of numbers and "==" can't compare a number with an array.