Jump to content

Recommended Posts

1 hour ago, Rydygier said:

Well, this will not work, because module checks for synced units only once, at init, and ignores anything synced later. If you want to use trigger to enable HAS calls at chosen point, do this:

 

1. Sync units to the module as usual. 

 

2. in the modules init field (for example, can be any init field in fact) put this code:

 

HAS_myUnits = [Marksman,AndListOfAnyOtherUnitNamesThatshouldGetHASCallsIfYouWant];nul = [] spawn {waitUntil {time > 0.1};{_x setVariable ["RYD_HAS_canCall",false,true]} foreach HAS_myUnits;};

 

3. In your trigger, instead of activation code, you have there, paste this:

 

{_x setVariable ["RYD_HAS_canCall",true,true]} foreach HAS_myUnits;

 

After that, defined units should get HAS calls, when trigger become activated. Not tested, but should work, I hope. May be one problem in MP, but not sure. 

@Rydygier

No joy on the Sync of module and i did remove the ,AndListOfAnyOtherUnitNamesThatshouldGetHASCallsIfYouWant from the list LOL

The options do appear on the screen but is removed again, have tried it with a trigger on 10 sec delay and that part is working

When i enter the trigger so the activation code is triggered nothing happens, the trigger is actived have put in a SFX sound when activated.

Spoiler

6784di.jpg

it is a SP game but if it can work, i will try it for a MP also.

 

Share this post


Link to post
Share on other sites

If it's vanilla scenario, give me, I can check this for you. 

Share this post


Link to post
Share on other sites

There was hidden, illegal symbols here:

 

_x setVariable ["RYD_HAS_canCall"

 

and:

 

foreach HAS_myUnits;

 

Very weird, like letters wasn't for Arma same letters, we see, but some rubbish code, revealed in RPT. Something with symbol coding at pasting or whatever.

 

Corrected. Works for me. 

 

"Meanwhile in Poland":

 

HAS 1.6 wip2

 

Basically sorted several (all spotted) further issues with path planning, this time around CAS and supply drops. Started writing speed limiter function, but run out of time for now. 

  • Thanks 2

Share this post


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

There was hidden, illegal symbols here:

 

_x setVariable ["RYD_HAS_canCall"

 

 

It is working now, thanks

i have it also working on a hostet server, don't know about a dedicated server.

 

UPS just found out that i have been using the Script forum for my problems with the MOD.

Share this post


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

There was hidden, illegal symbols here:

 

_x setVariable ["RYD_HAS_canCall"

 

and:

 

foreach HAS_myUnits;

 

Very weird, like letters wasn't for Arma same letters, we see, but some rubbish code, revealed in RPT. Something with symbol coding at pasting or whatever.

 

Corrected. Works for me. 

 

"Meanwhile in Poland":

 

HAS 1.6 wip2

 

Basically sorted several (all spotted) further issues with path planning, this time around CAS and supply drops. Started writing speed limiter function, but run out of time for now. 

 

Ill test 

Share this post


Link to post
Share on other sites

HAS 1.6 wip3

 

- fixed, I hope, some MP issues, including reported problems with not present actions after respawn, also 0-8 supports as for calling transport seem to work after respawn;

- added during tasks speed limiter, that will make chopper slow down when approaching a turn or when is facing other direction, than current waypoint. Comes with new user config variable:

 

RYD_HAS_CruisingSpeed = 400;//maximal expected cruising speed for helicopters. Set below 10 for unlimited cruising speed and disabling slowing down at turning.

 

Now helis indeed are better at following navpoints path, much lower turning radius, although AI steering along each path section may be not exactly straight line. Of course, they need to slow down at closing navpoint, which also means less fluid flight if path enforces sharp turns and somewhat more exposure (because slower movement at turns and slowing down goes together with climbing up temporarily). Therefore it's switchable, as user prefer. 

Share this post


Link to post
Share on other sites

@Rydygier

 

I just downloaded and have been testing 1.6 wip3.

 

Addactions after respawn are still buggy

 

If you get in a helo at start, then get out and make yourself respawn, HAS stops working for the player

If you get in a helo and transport to destination, once your get to the destination and are out of the helo. The helo will start its RTB. If you make yourself respawn before the helo has RTB, HAS will stop working for the player

 

The nav waypoints are a great addition for planning a route

I found one thing

When the map opens , alt+LMB actually teleports you to that location.

A systemchat hint pops up also, makes me think it was some type of debug for testing purposes

Share this post


Link to post
Share on other sites
Quote

alt+LMB actually teleports you to that location.

 

That's editor thingy, I believe. Code should suppress native key binding , but apparently in editor it doesn't work. 

 

Quote

HAS stops working for the player

 

Could you explain, what exactly that means? There's no more HAS actions, right?

 

Share this post


Link to post
Share on other sites
Quote

If you get in a helo at start, then get out and make yourself respawn, HAS stops working for the player

 

Here's the thing. When actual caller during pending task dies (respawn or not), code appoints another of HAS-enabled units as the next caller for pending task. To test that however one needs to play at least with one more player. Meanwhile, if that was the only unit, whole HAS code disables itself because "all units are gone". I wonder, if there's any sense in modifying code, so will wait until such "solitary MP player" would respawn back. Respawns are various, including delayed, so code should wait indefinitelly in fact, "just in case". Bah. Code can't wait. Caller unit during the task is necessary as reference unit in the logic. And who is playing MP session with respawns alone anyway? 

 

Possible alternative: in such case - last HAS-enabled unit death - pending call is immediately ended (heli's RTB), but HAS isn't disabled and will be still available, when some HAS-enabled unit (like respawned player) will appear again. I've to test, if doable, but seems so. 

 

Quote

 A systemchat hint pops up also, makes me think it was some type of debug for testing purposes

 

Like hints in right upper corner? Or lefl lower corner ones? Hm. What it says?

Share this post


Link to post
Share on other sites

Did some digging , I never knew in the editor /preview if you alt+LMB it will teleport you. So this has nothing to do with HAS. I have no idea how to disable alt+LMB teleport, seems like it is built into the editor. 

 

As for respawn, it is strange, I can respawn as much as I want until i get in a helo and get the actions to transport. Once i get the actions to transport , if I respawn HAS stops working, meaning I can get in a helo and I will not get any actions. The support menu is still there and I can call for transport with the support menu but helo does not respond.

Also, If i use helo and transport to a location. if I respawn before  the helo  has RTB. HAS will not longer work, I will get no actions inside a  helo. If I wait until helo has RTB  and then respawn. HAS works fine, I get actions when I get in a helo. 

 

I hope this makes sense. If you want I can make a video and post it showing what I am trying to describe.

Share this post


Link to post
Share on other sites
Quote

I hope this makes sense. 

 

Yep. What's expected, when last HAS-enabled unit dies. HAS is still there, but you're no longer the caller of pending task (because you died), so you have no more actions related with task, and HAS isn't active anymore for new tasks (since HAS didn't found anyone else to replace you as the caller, thus for the script list of HAS-enabled units is empty, you're no longer included as dead, thus any further call will auto exit due to "lack of HAS units"). I think, I'll try this instead:

 

Quote

Possible alternative: in such case - last HAS-enabled unit death - pending call is immediately ended (heli's RTB), but HAS isn't disabled and will be still available, when some HAS-enabled unit (like respawned player) will appear again. I've to test, if doable, but seems so. 

 

Share this post


Link to post
Share on other sites
Quote

I think, I'll try this instead:

 

Added very simple two lines of code, that possibly will make that change. Not tested:

 

HAS 1.6 wip4

Share this post


Link to post
Share on other sites

Been testing 1.6wip4 , so far everything is working great. I am not getting any errors and whatever you did seems to have fixed the respawn problem. I am going to update one of my missions with this new version and test it out on my server with other players.

Will let you know if I find any problems.

 

Thanks Rydygier for the work you have put into this.

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites

Back to the CAS, testing CUP helis.

 

Part of reported issues seem fixed: not all targets or none engaged was due to very special targets location, that allowed to eradicate some weaknesses of the code in terms of assuming fire position and LOS checks. The place was actually ASL higher, than heli's altitude, so this had to be taken into account (now it is), and there was higher ground in the middle, so LOS checks had to be performed not only for the center of area, but also four edge points to know, heli  is high enough.

 

That part is sorted, still it is possible and expected, some targets may be not engaged, if despite all efforts stay hidden behind something. 

 

As for other part of issues, noted the CUP heli ("4 pylons" something), that simple refuses to open fire, like not responding to scripting command. Either it is broken in some way, either configured in a way, that somehow fools CAS script. Next time I'll investigate, if this is the latter case, that means - fixable in the script. 

  • Like 1

Share this post


Link to post
Share on other sites

Keep in mind the game has a pending update (v1.90), in que for me atm which can alter, or break the function of something, definitely test the fixed issues again after the update.

Share this post


Link to post
Share on other sites

Indeed one need to have this factor in mind each time game update appears, I would re-check new changes anyway, so no problem.

 

BTW because of that, each game update theoretically we need to test everything again. From my experience I would say: if 1.90 broke something, we will hear about that pretty soon, better put that time into improving script and leave "testing by using" to people, that don't script. More efficient. 🙂

  • Like 1

Share this post


Link to post
Share on other sites

Quick question about CUP heli "CUP_B_MH60L_DAP_4x_US". It's the one, that won't fire no matter what. 

 

I put myself inside as each crew member to see, if I can fire manually. Eventually I figured out, pilot can use pylon rockets by LMB, but there's no weaponry HUD element, I do not see name of the weapon nor ammo count. It doesn't seem right to me, but I have no personal experience as heli user. Anyone can confirm, something is off with this heli weaponry usage? I feel, it's half done/half broken and I would assume, that's why this heli doesn't obey scripting fire commands. 

 

Different matter with "MELB_AH6M". Weaponry HUD is all right, "Fired" event handler reports pulling the trigger all right, but there's no actual projectiles shot. That one I'm investigating now. AH-1Z, AH-64D and RAH-66 seem work OK. 

Share this post


Link to post
Share on other sites

"MELB_AH6M" is the same problem after all. 

 

I've a theory. Both have in common one thing: there's crew member, that is returned in script as "gunner", but it is not a gunner, it's copilot. Meanwhile in both armament is under pilot's control ("driver"), not gunner. 

 

Now, the command to make heli fire uses unit (shooter), weapon and target variables. If the heli is configured in above way, this command will do nothing for both gunner and driver as shooters. That's how it is in my tests. If I'm right, that means, as long, they're done (configured) that way, they'll not work as CAS in HAS, are semi-broken... or scripting command is. 

 

To be more constructive: vanilla Pawnee also has pilot, copilot as the crew, and the pilot controls rockets... but it works. How so? It is because in this case copilot isn't defined as "gunner" (in the script (gunner _heli) is null for Pawnee, while returns copilot for both custom helis), he's "cargo" in Pawnee. That makes a difference apparently. So, I would guess, both not working helis could be fairly easily fixed by their authors, if they would define copilots as passangers, not fake gunners (after all, they aren't gunners, aren't they?). Worth of trying anyway IMO. 

 

One thing more: noticed, in the Malden testing scenario, the Pawnee (B_Heli_Light_01_dynamicLoadout_F) DAR missiles are "made homing" (got some config flags set to 1, by default these aren't there). So due to that flags HAS treat them as homing for aiming purposes, but they are't behaving like homing to me, not sure. Another mod issue perhaps? Doesn't matter. 

 

As for, me, I feel, enough debugging with modded helis. There was some benefits from that for HAS script, is improved now, but from now on I again intend to be focused solely on vanilla helis. Next step: adaptative aiming idea. 

Share this post


Link to post
Share on other sites

No problem. 🙂

 

Perhaps time for HAS 1.6 wip5

 

All changes around CAS this time. Code was in general improved in several ways, including better positioning (bigger (not 100%) chance to get free LOS at targets), blacklisting non-combat "weapons" like flares etc. and different pattern of fire, which is bound with main new thing here - adaptative targeting for attacking targets with not guided weaponry. There's some default trajectory calculation for miniguns and target adjustement for rockets, but appeared, it may not suffice. Previously could happen, heli would consistently miss the target. Now it looks as follows:

 

- at first heli will pick the target, then shoot few to several single "probe shots". After last projectile is gone, code will calculate average hits position (where projectile disappeared, ricochets not taken into account). If such average position will be located too far or too close, script will apply some aim amendement and repeat pocedure. If not enough - repeat. If amendement was too much, it will be halved and subtracted. This will continue until average hit position become close enough or amendement value low enough. At this point heli will shoot intensively with present aim at present target. 

 

Do not expect perfect aimbotting here. There's still big influence of dispersion, which can be huge, especially, when distance is big and angle between heli-target line and terrain surface is small. Especially, helo tries to stay as low, as possible to engage targets with minimal risk of exposure. In such case dispersion ellipse will be very long, and even small trajectory difference will change hit position drastically. One may even take into account slope direction when planning CAS approach azimuth to engage targets with optimal angle. There are also other factors like map objects, target movements etc. In general seems however, now CAS helo does more with less wasted ammunition and, most important, there shouldn't be anymore constant, dumb missing the target same way all the time due to not optimal default aim calculation (which I saw for one modded gunship for example), helo will at least try to correct his fire when missing. 

 

Old ways still apply to homing missiles attack and empty space attack. 

Share this post


Link to post
Share on other sites

For adaptative targeting decided to use some trigonometry instead of plain "bracketing". Results look nice so far, accuracy gain seems substantially faster and better. Starts to inspire respect, how Blackfoot with his minigun picks infantry from the grass. Comparing to previous state at least. 

 

Added also some more informative markes for CAS and fixed some issue with updating CAS position after nav points change. 

 

Still, some notorious issue with helo positioning (rapid vector changes) sometimes is back, not sure, why, also spotted weird issue on dedi. 

 

Currently wondering,  how it is possible, so function called plainly from client is executed on dedicated server? IsServer and isDedicated just before the call are false (logs land in client RPT), but inside the called function are suddenly true, and diag logs land on server RPT and also publiced previously variable isn't properly updated at this point. Weird. Tried remoteExec this call, but no matter, which setting, where player local, server or everywhere, logs from inside that function show only in dedi RPT. Something is broken after 1.90 or what? (Nope, same thing on 1.88 legacy, just another mystery to solve)

 

If anyway someone want to try, here is:

 

HAS 1.6 wip6

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Hi Rydygier

 

All testing have been done i SP

 

i have been trying the lasted 1.6wip6

and i have seen everytime a CAS heli is shot down while it is doing CAS the marker does not get deleted from map.

the marker stays like it is pending

Spoiler

10ngxg2.jpg

and this error comes up on screen

Spoiler

15nm5hf.jpg

also if you mark the target zone before you make the route to the CASheli the heli will follow the route back to base

 

Share this post


Link to post
Share on other sites

Thanks. Some issues fixed today, including that error on screen. Fixed mentioned dedi problem, fixed - heli should not complete blue navpoint path before RTB if call cancelled, only should follow returning navpoints - grey ones. Disabled cancelling mission during planning navpoints. There's still something left for next days apparently. Mostly around nav points of course. 

  • Thanks 1

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

×