Jump to content
jacmac

Generic Vehicle Service

Recommended Posts

It seems that when two people are in the chopper it will repair/refuel and look to be reloading. It shows full ammo for the pilot, not for the gunner, but as soon as the gunner cycles or fires the pilots count drops to actual amount the gunner sees. I did notice that if the gunner got out before landing on the repair bay it would reload, but was only able to test this once. Seems to be something to do with to players in the vehicle, or two different ammo counts. As a gunner i cant see the repair information. I wonder if that has something to do with it? Also playing tonight a friend flew over at altitude of < 80m and set off the repair zone. He got the message that it was closed for 200 sec. At that point it never opened up for anyone to use. The other repair facilities still worked but that one never came back into operation. This happened twice.

Share this post


Link to post
Share on other sites

I'm not sure what the source of the bug is, but I suspect there is a problem with setVehicleAmmo. There is no requirement in the command other than supply it with a number for 0 to 1. It appears that the gunner is somehow propagating his ammo status to the vehicle. A good test for this would be to try the following steps:

1. Get gunship, run it out of ammo with a pilot and gunner on board.

2. Go to the service point and rearm.

3. Have the pilot switch to manual fire and fire a shot.

4. Have the pilot switch manual fire off.

5. Have the gunner fire a shot and see what happens with the ammo.

I believe that setVehicleAmmo is not actually propagating the ammo status to the gunner for some reason. When the pilot fires a shot in manual fire, he would be propagating the correct status (the reverse of the gunner propagating the incorrect status). Maybe it has always been like this and you are the first to report it, I'm not sure. I'm not sure what I can do about it quickly. One easy solution might be to eject the gunner just prior to the setVehicleAmmo command, so when the gunner gets back in, he should be getting the correct status:

    _oGunner = gunner _oVehicle;
   if (!isNull _oGunner)
   {
   	_oGunner action ["GETOUT",_oVehicle];
   	sleep 1;
   	_oVehicle setVehicleAmmo 1;
   	sleep 1;
   	_oGunner action ["GETIN GUNNER",_oVehicle];
   } else
   {
   	_oVehicle setVehicleAmmo 1;
   };

Due to locality, this might be something where the code has to be executed by the gunner, and if I'm going to do that I might as well just have the gunner execute _oVehicle setVehicleAmmo 1; without getting out and back in...

Another solution might be to have the server execute the setVehicleAmmo command instead of the pilot/driver. That will take a bit of reworking to do, and there might be other side effects.

Edited by Jacmac

Share this post


Link to post
Share on other sites

PHP Code:

_oGunner = gunner _oVehicle;

if (!isNull _oGunner)

{

_oGunner action ["GETOUT",_oVehicle];

sleep 1;

_oVehicle setVehicleAmmo 1;

sleep 1;

_oGunner action ["GETIN GUNNER",_oVehicle];

} else

{

_oVehicle setVehicleAmmo 1;

};

Where do I place this code I wanna do some more testing for you. And is there anyway to disable the sound package. It is very loud and can not be turned down.

Share this post


Link to post
Share on other sites

I'm working on this, it appears that the get in/ get out doesn't work. I'm testing some things and will post a fixed version once I get it working. The sounds are all replaceable (the ogg files). If you don't like what you hear, you could replace them. I'll add in an option to turn the volume down on them, and maybe set the default volume lower in the first place

Share this post


Link to post
Share on other sites
I'm working on this, it appears that the get in/ get out doesn't work. I'm testing some things and will post a fixed version once I get it working. The sounds are all replaceable (the ogg files). If you don't like what you hear, you could replace them. I'll add in an option to turn the volume down on them, and maybe set the default volume lower in the first place

Another thing i found while testing today the "service complete" and no access for repairs timer sets off anytime you fly over the marker at any height. It also shows up half screen. The lower portion is cut off and the whole message cant be read.

Share this post


Link to post
Share on other sites
Another thing i found while testing today the "service complete" and no access for repairs timer sets off anytime you fly over the marker at any height. It also shows up half screen. The lower portion is cut off and the whole message cant be read.

I'm not sure what's going on with that, it sounds like the mission maker altered the default settings for gvs_triggers.sqf:

_veh_maxDistance = 6;		//distance from trigger that will cause abort
_veh_maxHeight = 1;			//height above trigger that will cause abort
_veh_serviceStartDelay = 8; //seconds before service starts (can abort in this time)
_veh_per_fuel_time = 2;		//seconds per percent of fuel
_veh_per_repair_time = 6;	//seconds per percent of repair
_veh_per_magazine_time = 8;	//seconds per magazine reload

One thing to keep in mind is that every vehicle in the mission that is going to be used by players needs to be named. A vehicle that is not named will trigger the service, but it won't act properly. I'll need to implement some additional checking to avoid that problem. However even if an unnamed vehicle can be serviced, it will end up locking out all other unnamed vehicles for the delay duration.

Share this post


Link to post
Share on other sites

Once the repairs are done you don't get the service completed until you are above the max height and when you leave the trigger. There is nothing limiting that part of the script to keep it from firing until the service itself is completed. so everytime you fly over it will give you service complete because that part of the script activates when you enter the trigger and leave above your max height . Somewhere if possible script needs to be added to keep that asleep until you land and activate the repairs themselves.

Share this post


Link to post
Share on other sites

Well after much trial and error, turreted helicopters (the ones with a gunner position) are bugged. If a player gets in the gunner position reloading that helicopter is pretty much permanently bugged for that mission. No matter what you do, that vehicle will not rearm properly. Hopefully the developers will come up with a fix for the problem. If a player never occupies the gunner position, the rearming will work just fine. Helicopters with no turret do not suffer from the problem. I don't know about ground vehicles yet, I have not tested them in multiplayer.

Edited by Jacmac

Share this post


Link to post
Share on other sites

I have figured out that if the gunner executes "setVehicleAmmo 1", the turret is correctly reloaded. I'm planning to implement temporary code as a work around until BIS develops a fix to the problem(s) causing the ammo to be reset back to the depleted counts from full. I've spent a lot of time trying to figure out the underlying cause, but it's some kind of bug in the latest ARMA release and it isn't a bug in the setVehicleAmmo command.

One of the side effects of this is that a turreted vehicle that has a gunner at least once in its lifetime, will have to have a gunner in the turret position for the vehicle to reload. So if the gunner leaves, the driver will have to be quickly switched to the gunner position, then switched back to the driver position. Yuck, but there isn't a good way around the problem at this point.

Share this post


Link to post
Share on other sites

Updated to Version G. Added a work-around for the annoying turret/gunner ammo bug. I also lowered the sound level for looped sounds.

Share this post


Link to post
Share on other sites

So if a pilot hops into the gunner position to align the gun for manual firing and then solo pilots the rest of the time he has to hop in the gunner seat to rearm? Ok is there any way to add to the script something along the lines of gunner setammo_1 if none pilot setammo_1. I know thats not the actual code to use but just an idea. I am sure you probably tried something like it.

Share this post


Link to post
Share on other sites

It's automatic. if there is no gunner, the pilot is moved into the gunner position automatically, then switched back to pilot. It's so fast that it looks like your player disappears and reappears in the blink on an eye.

Share this post


Link to post
Share on other sites

OK I see

---------- Post added at 21:54 ---------- Previous post was at 21:53 ----------

What happens if the pilot goes into the gunner seat just to adjust the gun for manual fire and nobody else enters does it work then or is it screwed up from that point?

Share this post


Link to post
Share on other sites

It works. Like I said, if there is no gunner, the pilot will be switched to the gunner position to reload for a split second. Otherwise the gunner executes the code and it works that way too. Moving to the gunner position to adjust the gun has no effect on the process. What might be weird is that a pilot that gets out and walks around during the reloading may or may not cause a failure to reload, if a gunner is not present.

Share this post


Link to post
Share on other sites

As far as I can tell I have the script working, but I do not see the hud/info on the screen showing what is being repaired/refueled/etc...

Any clue on what I am doing wrong?

Share this post


Link to post
Share on other sites

So there is a blurb in the documentation regarding RSCTitles. Basically there can only be one class definition for RSCTitles for the whole mission. This means that many missions designers don't understand and add other scripts into their mission with description.ext #includes that have RSCTitles definitions. The effect is that the last class definition for RSCTitles will overwrite any previous definition. To resolve this issue, you must find any other RSCTitles definitions and combine them into one. I included an alternative method of defining RSCTitles for situations like this:

  class RscTitles {
#include "x_dlg\RscTitles.hpp"
#include "gvs\stc_include_alt.hpp" //Alterntive display class definitions
};

In the example above (entered in DESCRIPTION.EXT directly), RSCTitles contains two includes, one is for another script (Domination) and the other is GVS. This allows both scripts to use RSCTitles, but definitely OPEN and EXAMINE the differences between stc_include.hpp and stc_include_alt.hpp files. You may need to alter other developers scripts somewhat to use this method of class definition. If you understand classes at all it will make sense. The only other thing to worry about after this is the layer numbers, they must be unique. It is unlikely that two scripts will happen to use the same layer numbers, but it will cause one control to step on another and they can end up ping-ponging.

RSCTitles and Dialog's in general are a confusing animal to understand, it took me quite awhile to completely grasp and I still seem to find new things about them. They are very quirky and the developers did not follow any hard rules with their development. A lot of the biki documentation is old and only semi-accurate for Arma 3.

Edited by Jacmac

Share this post


Link to post
Share on other sites

Could you possibly add more parameters to the script in the future? Such as repair only / rearm only / re arm condition?

I'm using this in tandem with a custom dialog I wrote to change Helicopter missile mounts for the Kajman. I would like for the player to land on the gvs port, then just before gvs is activated, run my dialog instead, so the player can choose the loadout he wants for his chopper - then gvs will rearm the helicopter.

Im not sure how to do this though. Maybe allow some sort of way to call custom code before gvs activates? (like an event?)

Thank you for the script, it really makes my life easier :ok:

Share this post


Link to post
Share on other sites

I'm thinking about writing a more complex add-on that could handle such scenarios. GVS really is generic. It looks up configs and such, but it's all just a delay for setVehicleAmmo 1. I am interested in what you are describing, but it would not be a simple matter to implement this in a hurry.

Share this post


Link to post
Share on other sites

There is a market for coding a re-arm script that can be configured to only re-arm specific magazines/ammo.

ie. If I want the A-164 in my mission but believe that some ordnance on it disrupt the balance of the game, I want to be able to specify in the re-arm script, exactly which weapons can be rearmed and which ones should be left at 0 or blacklisted.

Share this post


Link to post
Share on other sites

Thanks for the great mod JacMac. A question as it relates to the sounds during repair. Is there a way to localize those sounds only to the general area (within 5 meters) of the source? I and my mates are hearing the "Jerky Boy" sounds across the entire base :)

Thanks again

Edited by Hajimoto
Typo correction

Share this post


Link to post
Share on other sites

Broken DL link? Would be cool if this was also updated on armaholic =)

Share this post


Link to post
Share on other sites

ive noticed that on some occasions, when leaving the service point (after successful service) in a helicopter, the gui shows up again for entering the service point, but it just says

'any' for all the text. RPT shows a bunch of the variables are undefined. Im assuming that the trigger is still calling service script and passing it null/nil values as arguments. Afterwards the corrupted gui screen will stay on the players hud for a minute or so until it finally clears up.

Might be a good idea to check if the arguments exist before running the service script (not sure if you are already doing this)

Share this post


Link to post
Share on other sites
ive noticed that on some occasions, when leaving the service point (after successful service) in a helicopter, the gui shows up again for entering the service point, but it just says

'any' for all the text. RPT shows a bunch of the variables are undefined. Im assuming that the trigger is still calling service script and passing it null/nil values as arguments. Afterwards the corrupted gui screen will stay on the players hud for a minute or so until it finally clears up.

Might be a good idea to check if the arguments exist before running the service script (not sure if you are already doing this)

I've seen this on occasion when the player jumps out of the vehicle just as the service is ending. I don't know what causes, but the trigger conditions definitely don't allow anything except the driver of a vehicle to trigger. I suspect there is some kind of latency between a player exiting as the driver (still flagged as a driver) and the trigger going off. It is like for a split second when you exit a vehicle you are the driver of yourself, which is not valid, yet exists for a very small period of time.

---------- Post added at 03:40 PM ---------- Previous post was at 03:38 PM ----------

Thanks for the great mod JacMac. A question as it relates to the sounds during repair. Is there a way to localize those sounds only to the general area (within 5 meters) of the source? I and my mates are hearing the "Jerky Boy" sounds across the entire base :)

Thanks again

Yes, look for the sound script and change the radius parameter. It's probably around 50 meters, I can't remember off hand, but you can set it to 5 meters. You can also lower the volume way down on it. I'm also amazed that anyone recognized the voices, congratulations!

---------- Post added at 03:41 PM ---------- Previous post was at 03:40 PM ----------

I'll update it with a new link, the free download services are pretty flaky these days.

Share this post


Link to post
Share on other sites

i really like this script, but... can't figure out how i could use it alongside, VVS from tonic, the one like VAS but for vehicles, the problem is that i can't see how it would be possible the uniquely name each spawned vehicle, is there away to stop the gvs_watcher part as i am not too fussed about how often resupplies occur?

if not i will implement in a different mission but would have liked it in the current project.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×