Jump to content

Recommended Posts

------------------

Found a problem. If the server config is -autoinit , then there is no menu 0-8.

or sometimes the menu may still appear (if the mission is restarted several times), but the script will not work. strange. because even if this mission is not placed first on the server list with autoinit, it will still not work if you put it on with your hands or the third, fifth one.

but the script is very convenient. I have been waiting for this for a long time. thanks for the work

P.S. damn magic)) on Linux still does not want to work ((
I do not know why. without autoinit and with an empty server config. on linux only one error on client rpt

" 2:55:05 Setting invalid pitch 0.0000 for RYD_HAS_Base"

Share this post


Link to post
Share on other sites

Sadly, can't help with server config, do not know anything about it, also not sure, what's the purpose of autoinit, from what I searched through this forums, this parameter can be indeed a source of various headaches though. Looks like nothing, I could fix my end anyway. 

 

No idea, if that makes sense, but what if one would start his mission with HAS scripts, but without HAS stuff initialized, then only after some delay spawn in RYD_HAS_Base logic object, crewed helis (perhaps on the preplaced helipads), synchronize them via script with said object, and only after that initialize HAS? 

Share this post


Link to post
Share on other sites

When I enter a helicopter, one of the AddAction entries is instantly in my face in the center off the screen. Useless, if I issued the command before entering. I think you should do the addaction silently ("showWindow=false" argument).

 

Ah, thanks for the script and mod. I like it, it's handier than the MCC one (I've always loaded MCC). Not sure if fastrope extraction worked. I waited like 20 seconds, then ejected because impatient and died.

Using 0-8 support menu and, if currently in use, adding addaction is a good design choice IMO.

Share this post


Link to post
Share on other sites
Quote

When I enter a helicopter, one of the AddAction entries is instantly in my face in the center off the screen. Useless, if I issued the command before entering. I think you should do the addaction silently ("showWindow=false" argument).

 

Frankly, it is on purpose that way, to let player know, there are new actions awaiting his decision, but if more people feel that way, as you do, no problem, can be changed. Fast roping seems working OK in my tests, precise positioning may take some seconds, but usually rather 10 than 20. 

  • Like 2

Share this post


Link to post
Share on other sites

After mission start, the helicopter approaches me without me having asked for. I receive a "Get in" order. I get in, tell Pilot where to go, it goes up and just lands again and I get kicked out of the heli. I could again get in, endless loop.

 

I think this Hermes script collides with MCCs GAIA in some way. The player object is getting waypoints from GAIA (so I can get some meaningful orders and do what GAIA thinks is useful), by:

(group player) setVariable ["GAIA_ZONE_INTEND",["2","MOVE"], false];

 

Or anybody have other ideas? EDIT: Ah, I guess it's because the Hermes chopper may be part of the player group and controlled by GAIA either. Will investigate.

Share this post


Link to post
Share on other sites

Don't know GAIA too well, but first, that came to my mind was to exclude HAS helis from GAIA control.

 

If not possible - do not use GAIA together with HAS. AI mods tend to interfere each other. If GAIA offeres functionality similar to HAS, then conflicts seem inevitable. Pick one. 

 

Quote

Hermes chopper may be part of the player group

 

Don't know about GAIA, but better do not do that in HAS. 

  • Like 1

Share this post


Link to post
Share on other sites
24 minutes ago, Rydygier said:

Don't know GAIA too well, but first, that came to my mind was to exclude HAS helis from GAIA control.

 

To my current knowledge, if "MCC_GAIA_ATTACKS_FOR_NONGAIA = false", then GAIA should not control non-GAIA units.

What I can see is, the the player receives a "Get in" waypoint and the RYD_HAS assigned chopper approaches that exact position, without asking for throwing smoke. Then RYD_HAS scripting stuff starts, like the orange Addactions appear and the pilot asks where to bring me...

 

What I also see is, the HAS helicopter is not part of the player group, which is good. So currently the big question is, who is giving the fly and landing command to HAS chopper...?!

 

It's difficult but I'd really love to use GAIA. MCC has a builtin transport and CAS module, but it's too clunky.

Share this post


Link to post
Share on other sites

Perhaps try without GAIA and with HAS, then again, with GAIA, but without HAS. Comparing results should shed some light. For sure in HAS heli shouldn't fly anywhere without prior request (and doesn't in demo scenarios, I hope). 

  • Like 1

Share this post


Link to post
Share on other sites

I guess it's GAIA taking the chopper under its control. It happens only, when GAIA has control over the player. I will see. I can use GAIA with HAS, but not give GAIA control over the player.

 

Another observation: When I set initial flight altitude higher, to 150, it does not seem to find my smoke signal. I dropped a white and green smoke, it searched and cancelled after 3 minutes (I've set 3 minutes here). I'm using the mod version btw.

If that is intended, initial flight altitude would not make much sense if it doesn't dive down on searching for the player.

Share this post


Link to post
Share on other sites

Hm. Logical conclusion would be: search for flare/smoke object is 3D, so altitude matters. But it isn't:

 

_nO = nearestObjects [_pos, [], _radius,true];

 

Where "true" means 2D mode according to BIKI. So that's unexpected, altitude shouldn't change anything. If however search radius would be 3D, then increasing RYD_HAS_SignalSearchRadius value should make a difference. I guess, I need to test that next week. Thing is, by default this value indeed is equal to 150. Weird. 

 

 

Share this post


Link to post
Share on other sites

IDK, it seemed to happen after I teleported. Then while I still was under his position, chopper did not see me.

I also do not understand: The chopper does not fly to map click position (did one single left click) - it always directly approaches player, no matter where he is.

Share this post


Link to post
Share on other sites
Quote

The chopper does not fly to map click position (did one single left click) - it always directly approaches player, no matter where he is.

 

That's intended behavior at this point. Map screen here is for optional flight path customization. Final spot is fixed though. 

Share this post


Link to post
Share on other sites
3 hours ago, Rydygier said:

 

That's intended behavior at this point. Map screen here is for optional flight path customization. Final spot is fixed though. 

 

I see, so the single click serves only as a kind of "OK button press" and has no meaning for routing.

Share this post


Link to post
Share on other sites
7 hours ago, tortuosit said:

I think this Hermes script collides with MCCs GAIA in some way.

 

Just to add that I use Hermes and Gaia at the same time and there is no inherent conflict between them. But in the way I use them both the HAS aircraft are not under Gaia control.

 

I don't think the HAS scripts can work if the aircraft pilot group is also being ordered around by Gaia. The two systems will be issuing contradictory 'orders' (domove commands) to the group. 

  • Like 1

Share this post


Link to post
Share on other sites
Quote

I see, so the single click serves only as a kind of "OK button press" and has no meaning for routing.

 

Exactly.

Share this post


Link to post
Share on other sites
On 4/27/2019 at 3:00 PM, tortuosit said:

Another observation: When I set initial flight altitude higher, to 150, it does not seem to find my smoke signal.

 

Tested that - called transport, then raised altitude to > 500 meters. Pilot found the signal wihout any problems. Then tested with modlue and set same initial altitude in module settings. No problems. BTW search is conducted around caller's position (where he was when making the call), not around heli, so heli's altitude also because of that shouldn't matter. 

  • Like 1

Share this post


Link to post
Share on other sites
On 4/27/2019 at 7:32 PM, killick said:

Just to add that I use Hermes and Gaia at the same time and there is no inherent conflict between them. But in the way I use them both the HAS aircraft are not under Gaia control.

 

Yes. That's clear, it just seems, when the player is under GAIA control (he receives waypoints, for me it can make gameplay more interesting because someone else tells me what to do :D) - in this case GAIA seems to control the HAS chopper.

 

You may test it please, add the following line to debug console. Player is not far from the chopper. After this line has been added, I get a "wait" instruction close at my position and the chopper will start coming to me.

 

(group player) setVariable ["GAIA_ZONE_INTEND",["1","MOVE"], false];

 

I'm thinking about implementing other ways to make gameplay interesting because of this problem. Maybe GAIA just reporting in a "systemchat" kind of way. It's because I like some recommendations by an artificial commander on what to do...

Share this post


Link to post
Share on other sites

HAS 1.8 wip1

 

- feature on request: from now on CAS has two alternative patterns. Previous is called "HOVER", new one is called "SAD". Caller chooses the pattern just after the call, before any sentences and before the map is displayed. It is done via mouse actions. After the choice CAS proceeds as before until heli reaches initial CAS position. Till this point is possible to switch patterns, after this point chosen pattern is fixed. 

 

SAD pattern is based on vanilla AI behavior during SAD waypoint, so you probably know, what to expect here. The difference is, SAD may be prematurely ended if chopper get too heavy damage or if player cancel the support manually. Also, if RYD_HAS_CAS_OnlyKnownTargets is left as "false", at SAD init all targets within set radius are revealed to the chopper, which somewhat boosts SAD effectiveness.  

 

IMHO in most cases HOVER pattern will be more effective. SAD is in general more risky for the chopper. It may prove better however in scenarios similar to depicted in the linked demo - infantry and vehicles without serious AA capabilities in the environment with many LOS blockers, like the town, where engaging targets from many different angles may be helpful. Maybe also where targets are highly mobile or when a bit better fire precision is preferable (friendlies close to the targets). It is more timid/hesitant as for used firepower though, especially the missiles. 

 

Also SAD pattern, as based on native AI, will be affected by any changes to the default Arma's chopper AI, bugs or improvements alike. 

 

Not tested in MP. 

  • Like 2
  • Thanks 2

Share this post


Link to post
Share on other sites
On 4/19/2019 at 3:17 PM, topden said:

------------------

Found a problem. If the server config is -autoinit , then there is no menu 0-8.

or sometimes the menu may still appear (if the mission is restarted several times), but the script will not work. strange. because even if this mission is not placed first on the server list with autoinit, it will still not work if you put it on with your hands or the third, fifth one.

but the script is very convenient. I have been waiting for this for a long time. thanks for the work

P.S. damn magic)) on Linux still does not want to work ((
I do not know why. without autoinit and with an empty server config. on linux only one error on client rpt

" 2:55:05 Setting invalid pitch 0.0000 for RYD_HAS_Base"


I tried HAS script version on a server and I couldn't get the support options as well. It works when I test in single player and LAN connection. I'm going to see about this now that I know of the -autoinit server config. Anybody else have any issues with going on a server and not receiving the support options? Any other troubleshooting tips may help me.

Share this post


Link to post
Share on other sites

OK..I'm trying to add NEW SPAWNED/RECRUITED AI units to the RYD_HAS_STT pool ..... I run this code :  [_unit] call RYD_HAS_NewUnits; ...not working.

This is run into the "new_unit_init.sqf" script inside the spawned units spawn/recruit script folder, where obviously the "_unit" is the variable name given to the new unit...:headscratch:
 

Share this post


Link to post
Share on other sites

Obviously can't guess, why it is not working for you, but here is demo showing, how it works. Initially player is not HAS-enabled. Note additional code in the init.sqf:

 

	sleep 2;
	
	_unit = (group player) createUnit [(typeOf player),(player modelToWorld [0,5,0]), [], 0, "NONE"];
	[player,_unit] call RYD_HAS_NewUnits;
	addSwitchableUnit _unit;

 

So after 2 seconds new unit is spawned as player's subordinate, then both units are added to HAS. Finally spawned unit is made switchable, so you could check, if after switching HAS actions appear for the new unit when controlled by you. Also you can do some fast roping somewhere to see, if both units are properly dropped via ropes (which means, both are HAS-enabled). If all in this demo works (as it is for me), then compare it with your scenario to find a difference, that breaks adding new unit for you. 

Share this post


Link to post
Share on other sites
6 minutes ago, Rydygier said:

Obviously can't guess, why it is not working for you, but here is demo showing, how it works. Initially player is not HAS-enabled. Note additional code in the init.sqf:

 


	sleep 2;
	
	_unit = (group player) createUnit [(typeOf player),(player modelToWorld [0,5,0]), [], 0, "NONE"];
	[player,_unit] call RYD_HAS_NewUnits;
	addSwitchableUnit _unit;

 

So after 2 seconds new unit is spawned as player's subordinate, then both units are added to HAS. Finally spawned unit is made switchable, so you could check, if after switching HAS actions appear for the new unit when controlled by you. Also you can do some fast roping somewhere to see, if both units are properly dropped via ropes (which means, both are HAS-enabled). If all in this demo works (as it is for me), then compare it with your scenario to find a difference, that breaks adding new unit for you. 

Thank you a lot for the super-quick response mate...I'm testing as we speak...so I'll report back ASAP..

Share this post


Link to post
Share on other sites

YAP...is working by adding "player" into the [_unit] call RYD_HAS_NewUnits;  The recruit script already spawned and made playable the new unit, but obviously when you switch to it the "RYD_HAS_NewUnits" need to know you are the "new" player...I hope I explained myself enough..hahahhaha

Share this post


Link to post
Share on other sites

Update

 

Changelog:

6-23-19

Update v1.8

  • Alternative CAS pattern: "SAD", based on vanilla SAD waypoint. 
  • Old pattern now is named "HOVER". 

CAS pattern is chosen just after the call via mouse actions. 

===========

Now when calling CAS support via 0-8, in  your action menu you have 2 actions:

1 is Hover, which the heli will come to his attack position and shoot at the area you designate, complete his rounds and RTB.

2 is SAD, where the heli will arrive at his attack position and then proceed to fly around the area you designate and search and destroy anything it sees, after rounds are complete, it will RTB.

  • Like 4
  • Thanks 1

Share this post


Link to post
Share on other sites

HAS 1.9 wip1

 

- also units added via RYD_HAS_newUnit later in game should get back HAS calls after respawn (not tested);

- added new user variable (cannot be changed on-the-fly - attempt will be futile) RYD_HAS_addJIPs = true;//if true, JIP-ing players will automatically get access to HAS calls without necessity of manual calling RYD_HAS_newUnit function for them. (not tested, can't test on my own anyway - testing requires two players);

- provided global and "per unit" switches for selective enabling/disabling access to each type of support. 

 

Global:

RYD_HAS_Switch_Taxi = true;//global switch for troops transportation support availability
RYD_HAS_Switch_Supply = true;//global switch for supply drops support availability
RYD_HAS_Switch_CAS = true;//global switch for close air support availability

 

Exemplary usage - disabling access to supply calls for all players:

 

RYD_HAS_Switch_Supply = false;

publicVariable "RYD_HAS_Switch_Supply ";

 

 

Per unit:

unitName setVariable ["RYD_HAS_canCall_Taxi",false,true];//disabling troops transportation support availability for 'unitName' unit

unitName setVariable ["RYD_HAS_canCall_Taxi",true,true];//enabling troops transportation support availability for 'unitName' unit

 

similar for the rest:

 

unitName setVariable ["RYD_HAS_canCall_Supply",false,true];

unitName setVariable ["RYD_HAS_canCall_CAS",false,true];

 

These are enabled by default.

 

Note to both: as observed during tests, if at that moment some player has currently opened 0-8 supports menu, currently displayed for him support options will be not adjusted accordingly. Only after closing 0-8 GUI.

 

Even when global switch is on, if unit's switch is off, that unit will have no access to that type of calls. Also if unit's switch is on, but global switch is off - there's still no access even for that unit. In other words both, global and unit's switches need to be "true" in order to provide respective support access to that unit. 

 

This one was tested, but only SP. I'll be grateful for further testing, especially in MP and for first and second features.

  • Like 1
  • Thanks 2

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

×