Jump to content

UH-80 Ghost Hawk Gun Lock / Unlock Function


Recommended Posts

I noticed that the lock / unlock guns functionality for Ghost Hawks has been worked on. I didn't like what I saw and the action also duplicated itself upon use, so I rewrote and tested the code.

Depending on the status of the guns the action shown will now either be "Lock guns" or "Unlock guns". It is only possible to lock or unlock both guns at the same time.

 

  1. Create file "fn_helicopterGuns.sqf" in "/Functions/CustomPlayerActions" and fill it with the following code:
    params ["_mode"];
    
    switch (_mode) do {
    	case "AddAction": {
    		player addAction ["Lock guns", {["Lock"] spawn AW_fnc_helicopterGuns;}, [], -99, false, true, "", 
    		"((vehicle _originalTarget) isKindOf 'Heli_Transport_01_base_F') && ((vehicle _originalTarget) getVariable ['gunLockStatus', 'UNLOCKED'] != 'LOCKED')"];
    		player addAction ["Unlock guns", {["Unlock"] spawn AW_fnc_helicopterGuns;}, [], -99, false, true, "", 
    		"((vehicle _originalTarget) isKindOf 'Heli_Transport_01_base_F') && ((vehicle _originalTarget) getVariable 'gunLockStatus' == 'LOCKED')"];
    	};
    	
    	case "Lock": {
    		_helicopter = vehicle player;
    		[_helicopter, ["LMG_Minigun_Transport", [1]]] remoteExecCall ["removeWeaponTurret", 0, false];
    		[_helicopter, ["LMG_Minigun_Transport2", [2]]] remoteExecCall ["removeWeaponTurret", 0, false];
    		_helicopter setVariable ["gunLockStatus", "LOCKED", true];
    		systemChat "The guns have been locked.";
    	};
    	
    	case "Unlock": {
    		_helicopter = vehicle player;
    		[_helicopter, ["LMG_Minigun_Transport", [1]]] remoteExecCall ["addWeaponTurret", 0, false];
    		[_helicopter, ["LMG_Minigun_Transport2", [2]]] remoteExecCall ["addWeaponTurret", 0, false];
    		_helicopter setVariable ["gunLockStatus", "UNLOCKED", true];
    		systemChat "The guns have been unlocked.";
    	};
    	
    	default {["Unknown parameter."] call BIS_fnc_error;};
    };

     

  2. Edit class CustomPlayerActions in "/Functions/cfgfunctions.hpp" as follows:
    class CustomPlayerActions {
    		file = "functions\CustomPlayerActions";
    		class clearVehicleInventory {};
    		class helicopterDoors {};
    		class helicopterGuns {};
    		class slingWeapon {};
    	};
  3. Edit the pilot actions in "onPlayerRespawn.sqf" as follows:
    //Pilot actions:
    if (roleDescription player find "Pilot" > -1) then {
    	//Despawn damaged helicopters in base:
    	[...]
    
    		//Ghost Hawk actions:
    		["AddAction"] spawn AW_fnc_helicopterGuns;
    		["Respawn"] spawn AW_fnc_helicopterDoors;
    };

     

Edited by ansin11
Now using isKindOf instead of typeOf.
Link to comment
Share on other sites

With the old system, for one, I didn't like having to lock the two guns manually and having to use the menu three times to achieve that. Makes the setup routine longer if you know what I mean. Also, the functionality used to include like ten files and looked like it could use some updating, so that was something I always kept in that "Yea, I will do that one day" place of my mind.

 

When I noticed today that my scroll menu now said "Toggle guns" (?) I was not content with that because I could no longer tell wether I was locking or unlocking the guns without first trying it and then reading the chat to check the feedback - not ideal when flying. Not ideal in general either, but okay, I know the I & A development approach, so let's see what I can do later.

 

When I then proceeded to put the action to use I noticed I now had two "Toggle guns" actions in my action menu, both with equal functionality. At that point I was pretty sure that this had actually not been tested.

 

So naturally, I wanted to see what modifications had been done and behold - I could not find a corresponding function file. It took me (familiar with I & A 3 code) a good five to ten minutes to figure out that there was in fact no function, that instead a variable holding code had been used - placed in the convinient location "Scripts/misc/sharedFnc.sqf". Obviously.

 

On a side note I hope that you, dear reader, can now understand why I frequently discredit I & A development: to me it is most often deeply disappointing. But that deserves a post of its own. One day.

 

So after I managed to find the four lines of code I was interested in I already knew that I was defenitely not going to bother figuring out why the action duplicated or when and where the variable was placed in the script argument of an addAction command. I was also very disappointed at this point, and pretty angry too.

 

I then more or less followed steps one to three of the original post, plus some testing to ensure functionality as well as my satisfaction.

 

2 hours ago, Stanhope said:

Why not?

So basically, the more I saw, the less I liked it.

Link to comment
Share on other sites

10 hours ago, ansin11 said:

At that point I was pretty sure that this had actually not been tested.

Bold assumption

 

10 hours ago, ansin11 said:

hat there was in fact no function, that instead a variable holding code had been used

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.

10 hours ago, ansin11 said:

I could not find a corresponding function file. It took me (familiar with I & A 3 code) a good five to ten minutes

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: 

Quote

 

-condition is evaluated on each frame in non-scheduled environment.

-condition is not evaluated if a dialog is open.

- If action is added to an object (and not to player) condition will only get evaluated IF player is closer than ~50m to the object surface AND is looking at the object.

- If action is added to player, condition is evaluated all the time.

 

 

I only read reasons to keep the amount of actions limited.

 

Now let's look at the code you wrote:

15 hours ago, ansin11 said:

player addAction ["Lock guns", {["Lock"] spawn AW_fnc_helicopterGuns;}, [], -99, false, true, "", "(typeOf (vehicle _originalTarget) in ['B_Heli_Transport_01_F', 'B_CTRG_Heli_Transport_01_sand_F', 'B_CTRG_Heli_Transport_01_tropic_F']) && ((vehicle _originalTarget) getVariable ['gunLockStatus', 'UNLOCKED'] != 'LOCKED')"]; player addAction ["Unlock guns", {["Unlock"] spawn AW_fnc_helicopterGuns;}, [], -99, false, true, "", "(typeOf (vehicle _originalTarget) in ['B_Heli_Transport_01_F', 'B_CTRG_Heli_Transport_01_sand_F', 'B_CTRG_Heli_Transport_01_tropic_F']) && ((vehicle _originalTarget) getVariable 'gunLockStatus' == 'LOCKED')"];

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. 

 

10 hours ago, ansin11 said:

On a side note I hope that you, dear reader, can now understand why I frequently discredit I & A development: to me it is most often deeply disappointing. But that deserves a post of its own. One day.

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. 

Link to comment
Share on other sites

Regarding the more constructive portions:

Performance:

I would assume that using two local addActions on five clients is more performant than using a global addAction on each of the four (?) Ghost Hawks and then having all the up to 60 clients (Up to 55 of which are not the intended target client!) plus the precious server evaluate the condition on every frame, albeit provided they are within 50m of one of the Ghost Hawks.

 

 

Implementation details:

I chose to add the action to the pilot unit and not the helicopter because it would then be local and would also only be on the clients that actually need it. This approach also allows for the feature to be used on Zeus spawned or otherwise created Ghost Hawks, no matter if setup code had been run on them or not.

 

I chose to add two local actions because it is easier to implement, plus it doesn't require the if-vehicle-gun-status-is-x-then-setUserActionText-else-do-other-stuff block of code to run on every frame. Performance, yay!

 

I chose to not use

(vehicle _originalTarget) isKindOf "Heli_Transport_01_base_F"

because I messed up somewhere along the way and used typeOf instead of isKindOf, leading to my code not working on CTRG Ghost Hawk variants, so to fix that I used to given syntax

(typeOf (vehicle _originalTarget) in ["B_Heli_Transport_01_F", "B_CTRG_Heli_Transport_01_sand_F", "B_CTRG_Heli_Transport_01_tropic_F"]

and only now realize I could and should have used isKindOf. Performance, nooooo!

 

Regarding the less constructive portions:

I chose to use a String for the variable because it was easier to think about while working on the code (To use your common phrase: It works, so why not?).

 

I chose to use a switch because I like BI's way of doing Arma functions. The file size is 1502 bytes, are you kidding me?

 

Other:

Like probably most people looking at and working with Arma 3 mission files I use Notepad++ instead of an IDE.

I do think that the entire function framework is being provided to enable people to structure their mission code. Of course you could also run the entire I & A mission from two big files, but for some reason I wonder why that is not being done...

 

Funny that you (of all the people) first mention readability and then later even proceed to explain that you yourself are not trying to make the code pretty or easy to read, but instead consider I & A 3 to have reached the stage where it just somehow needs to bridge the gap to I & A 4. For how much longer, a year by now? And that is what's so deeply disappointing and sad to me. I love this project, I'm sure you love it too, Stan, considering how much time you spend on it, and yet I & A 3 looks like it is being treated like an unworthy, unwanted piece of junk that nobody really cares about and it hurts seeing that! Hopefully that is just my perception of the matter, but I believe this will explain why my stance on I & A development is what it is.

Apart from that I think that this approach is also terribly unfair towards other people and communities who (try to) use I & A or parts of it on their own servers.

 

So then I see something I don't like and every once in a while I redo something. In this case I rework something that's recently been changed, I then put my system up on the forum for consideration and describe in three simple steps how to easily implement it into the project. Very well, use it or not, that's not my call.

But then the first and only response is "What's wrong with the old system?". Alright, I point out what I didn't like. And the whole thing just erupts into... whatever this is, basically just to tell me "We don't want to use your solution because we don't need others to contribute possible improvements to systems that already work. You might have followed certain conventions and structures we are too lazy to follow and provided an easy way to simply copy and paste that code, but no thanks, there is no need.".

Why am I even trying?

 

It's just disappointing time and time again, and my expectations were low to begin with. Do what you want, it's your project. I'm done.

Link to comment
Share on other sites

12 minutes ago, ansin11 said:

I wonder why that is not being done...

Have a look at I&A4, then come back and tell me that I'm putting to much in that shared functions file again.

15 minutes ago, ansin11 said:

Hopefully that is just my perception of the matter

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. 

Link to comment
Share on other sites

To me that's the sad thing, you know exactly how to do all those things, you just choose not to. Instead you offer what I personally consider a rather poor excuse ("It works, I don't get paid and to some extend I don't care"). Really grinds my gears. But that's my problem, isn't it?

 

My original post does not contain anything but "Hey I rewrote this thing because I wasn't happy with it and it had some problems, heres my code and the steps to use it". After that however, we wander into the realm of things I intentionally kept out of the original post in order to keep it more neutral and less offensive.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

Ah Ansin, where do I start...

 

15 hours ago, ansin11 said:

On a side note I hope that you, dear reader, can now understand why I frequently discredit I & A development: to me it is most often deeply disappointing. But that deserves a post of its own. One day.

 

Fair enough, you can discredit development all you want, it's in your rights. But again, Stan and Ryko do this in their spare time, and I expect the bare minimum of them. if i'm being honest with you, I couldn't care less about ghost hawk doors and turrets, and i'm sure the majority of us don't. Personally, I see I&A as far from disappointing. Arma 3 was released in 2013, and I&A still exists today, so to say it's disappointing to me sounds like a joke. We've kept a playerbase (even if it's a changing playerbase) since I&A2 through to I&A3, so dissapointing is not the issue. Personally I think YOU think it's dissapointing, whereas I commend the jobs Ryko and Stan do, as realistically, I don't expect Stan to churn out the amount of updates he does so frequently - so I think to be complaining about turrets and doors and then to make the conclusion I&A code is disappointing seems very odd to me.

 

1 hour ago, ansin11 said:

instead consider I & A 3 to have reached the stage where it just somehow needs to bridge the gap to I & A 4. For how much longer, a year by now? And that is what's so deeply disappointing and sad to me. I love this project, I'm sure you love it too, Stan, considering how much time you spend on it, and yet I & A 3 looks like it is being treated like an unworthy, unwanted piece of junk that nobody really cares about and it hurts seeing that! Hopefully that is just my perception of the matter, but I believe this will explain why my stance on I & A development is what it is.

 

what is your backing on this? I&A4 has taken so long because it's Ryko working on it. he's a grown man, he has a job and a family. I couldn't care if it takes Ryko 3 years. I think more gratitude is needed that an I&A4 is coming, hell if we stuck with I&A3 I couldn't care, I see I&A4 as a luxury, and I don't see why you need to whine so much, be humble that we have devs who want to work for free anyways. I&A3 is just being maintained, and it doesn't need new features imo, and to say it's being treated like an unworthy piece of junk is a joke. If that was the case then we wouldn't touch it, and we wouldn't care enough to actually try make it stable. All I see here is your nitty picking with very little evidence, and very much a personal prejudice. 

 

1 hour ago, ansin11 said:

It's just disappointing time and time again, and my expectations were low to begin with. Do what you want, it's your project. I'm done.

 

I'm going to be real with you. If you don't like it go elsewhere. go play a mission which you think has "better development." I see no place here for such attitude that you're showing, and I think at this point ansin it isn't constructive criticism anymore. it's you whining about how you hate our developemnt scheme.

 

33 minutes ago, ansin11 said:

To me that's the sad thing, you know exactly how to do all those things, you just choose not to. Instead you offer what I personally consider a rather poor excuse ("It works, I don't get paid and to some extend I don't care"). Really grinds my gears. But that's my problem, isn't it?

 

yes that is your problem. Humble yourself and actually appreciate the hard work both @Ryko and @Stanhope has put into I&A. I haven't seen you once acknowledge this, instead you seem to want to give opinions about how things should be run in your own eyes.

 

 

I hope this is a wake up call for you ansin, constructive criticism is good, but this has steered away very far from that.

Link to comment
Share on other sites

I disagree with you @Xwatt, this has not steered away from constructive criticism at all. In fact, this post's entire comment section never contained any constructive criticism.

 

Next I would like to decline your kind offer to go somewhere else, because I actually like it here, recently even more with the new big Zeus missions you guys are creating.

 

Last but defenitely not least I want to clarify that I 100% do have a personal problem with the way especially I & A 3 is being handled. You are also 100% right that it is me thinking the development is disappointing; in short mostly because I see way more potential for I & A 3.

I agree that I & A 4 development may take all the time it needs, but, as stated, I really dislike how I & A 3's potential is deliberately not being reached just because it is scheduled to be replaced at some point in the future.

43 minutes ago, Xwatt said:

Humble yourself and actually appreciate the hard work both @Ryko and @Stanhope has put into I&A. I haven't seen you once acknowledge this, instead you seem to want to give opinions about how things should be run in your own eyes.

Of course I give my opinion on how I would like to see things being done, what other person's opinion should I give?

You are right that I usually just criticise, however saying that I have not once acknowledged the developer's achievements is only true as far as this post goes.

And again, the problem here is not even the original post, the problem to me is that I was asked to give my opinion (On what I thought was wrong with the original code) - which I intentionally did not do in the initial post because I wanted to keep things calm and focused on, well, locking and unlocking Ghost Hawk door guns. What then followed was this, and that's just what I was trying to avoid because this was, as always, bound to become offensive to everyone involved while also being quite pointless and lightyears away from what I was trying to do - help improving the coop gamemode we all love.

And I don't think that it is fair to now complain that I did respond and did give my opinion and the reasons for that opinion after I was asked to do just that.

Link to comment
Share on other sites

The turret lock works exactly as requested by among others myself. Guns are locked by default and both guns can easily be unlocked on the pilots command. It is not hard it is not confusing it works, has no major performance issues, it was included in the change log and was tested. 

 

Now as I seems to recollect you had your go at development. You no longer have a position on the dev team so you choose to whine about small details and functions?

 

My personal opinion is that the saber rattling between yourself and Stanhope has gone on long enough and should be ended. It brings nothing but bad blood and does nothing but divert us from what we are here do to; enjoy ourselves with a computer game.

Link to comment
Share on other sites

So this is the new every-about-six-months-occuring-rant-about-how-bad-AW-is episode?🙂

 

 

My opinion:

First of all I want to say that I am a bit dissapointed that this is only one page so far as we are used to have longer episodes before. It also worries me that only one ranter could've been found. These two points make me wonder wether this series might be getting old and people are putting less effort into it.🤔

But nonetheless I do enjoy the new spin that it focuses on EU1 this time and not on AWE as that topic was really getting old.👍

As a side-note: Even though this is a EU1-spinoff-episode, I like the 'If you don't like it here, leave and play somewhere else'-quote as it kind of belongs to the series at this point!😉

 

Conclusion:

I would give it a 4/10 at best and put it in line with SCRUBS Season 9!!!!!1!!!!😡

So my advice would be to just end the series and start a totally new one. Maybe something with Aliens...seems to be hyped atm👽🤷‍♂️

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Forum Statistics

    11.1k
    Total Topics
    66.4k
    Total Posts
×
×
  • Create New...