Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

  • Medals

Everything posted by Rydygier

  1. Two things more: 1. In fact best to use dedicated way to add a chopper for airlift: //to add new helicopter run this code when no airlift is pending, after assigning the crew for new helicopter: myNewHeliWithCrewName call RYD_HAS_NewChopper; 2. Even that way, I'm affraid, new chopper may not appear on the list in 0-8 variant (as this list is also constructed only once, at init). So for now only mouse actions variant may be useable here. Soonish I'll try to remove mentioned so far obstacles and when ready, I'll link new 1.7wip script here. These things need to be sorted.
  2. Sadly no. Synced stuff is checked only once, at init (then the code collects all of it and put into same array, you may define manually - and if you do, manually defined arrays overwrite auto-collected ones, after that, one way or another, HAS uses content of these arrays only, doesn't re-check synced objects anymore). All things synced later will be ignored. For stuff spawned mid game array way is your way. 🙂 Let me now about any encountered obstacles, HAS wasn't designed specifically for such use, but I would like to optimize HAS for it, where necessary. As for CAS - sure, just to let you know HAS' CAS differs from vanilla, I believe. It's custom behavior. Better or worse - don't know, but may be worthy to check, which you prefer (or both even) . Anyway HAS' CAS is heli-specific, helo will engage targets or spot from stationary hovering position, no flybys).
  3. Yes. BTW if initially left not defined, this array is auto filled at init with helis synced with the RYD_HAS_Base logic (or with the module for mod version). But also there's another, internal array for CAS helis, RYD_HAS_CASChoppers, and this one is auto-filled only once, at init. So if you wish to introduce spawned CAS heli, add it also into this array. NOTE: it is auto-filled only basing on helis synced to the logic/module. It will not consider manually defined RYD_HAS_allChoppers. So if you manually define allChoppers, you also has to manually define CASChoppers at init. It shouldn't be that way, something to improve for 1.7, I think... RYD_HAS_DoorsToOpen is optional. You can leave it empty, but if you want to see door animations during fast roping, you indeed need to fill it following given example. And whatever heli name you put in it, it has to actually exist in RYD_HAS_allChoppers.
  4. Rydygier

    I love A3 but it goes boring

    Personally I never cared too much about variety of textures, amount of factions or, above all, about MP (could not even exist for me). To me more important is, what interesting stuff I can do with existing content, and there's lots of it. My opinion is, Arma 3 will become boring to me, when I'll be out of fresh ideas, where I could take it with my projects - scripts, scenarios, etc. I think, short answer to "Arma 3 gets boring" is already given: mods. Use them or, even better, create some. Creativity may prove to be more engaging, than playing, as it was in my case. That being said, I truly am looking forward to see Arma 4 one day.
  5. If I may, I tested this a bit on standard Stratis building, noted two things: 1. Wind factor (snowflakes can be carried inside the building by the wind (diagonal falling - generated out of building boundries) - at least tricky to reduce and rather impossible to prevent completely); 2. Without the wind mostly works, but especially in the corners some scarce snowflakes may appear.
  6. Rydygier

    [SP] Ragnarok'44

    Cool, that should solve camera problem.
  7. Rydygier

    [SP] Ragnarok'44

    One thing: in Ragnarok lots in going on in free camera mode. Any snowing solution would need to be adapted, so particle sources would follow Ragnarok's camera, not only player character in incarnation mode. Also with snowing there's always (small, but still) problem when comes to rapid position changes, which happens often in Ragnarok.
  8. HAS 1.6 wip10 Flying to corner of the map behavior should be fixed, also expanded slightly search radius, but reduced search resolution (bigger radius change each cycle) to reduce amount of cycles and added warning hints in cases, where safe LZ not found and heli goes towards unsafe clicked position. But I still know about some issues with navpoints, when user changes destination after navpoints are reached and heli goes towards final destination. - wip10 updated with fix.
  9. Thanks. Now I see, what is the problem. Code fails to find suitable position for touchdown at clicked location, because there's none within search radius. Handling this exception isn't good enough, I have to think, what HAS should actually do in such case. Probably eventually will just return actual clicked position, which will end with collisions risk. We probably can't completely escape from the user's responsibility to choose landing zone reasonably. We can in most urban areas, but forests are simply too vast, in some cases search radius would have to be way too big to calculate, where safe position is in reasonable time. Considering other objects, than buildings already made this calculation noticeably prolonged, especially when user click on some forest area.
  10. For now: HAS 1.6 wip9 First issue with unexpected CAS should be fixed, also trees and other map objects (experimentally for now) will be counted as obstacles during fast roping, affecting fast roping altitude.
  11. It was fastroping or touchdown variant? Was destination changed on the fly, or was set only once, at heli start? Happened only once, or each try? I downloaded the map, even recreated your route, but was unable to reproduce this issue so far. I feel, I may need repro mission with exact repro steps to deal with this. In fact, in my tests heli tries to land, where pointed, but collides with high trees there. Fast roping code ignores them, same as any map objects except for buildings, so if one plan to fast rope in the forest, has to manually increase in UnitConfig fast roping level. I'l test a change, where all map objects are taken into account. But that BTW.
  12. Rydygier

    Pilgrimage - Ported

    Always you can just: _softVAm = 20; But one way or another, if the map includes two or more separated land masses, there will be always some risk, the body will be on the one without any vehicle. One would need to reduce gameplay area to only one of these land masses, but that also includes more complex changes in the code. Also you could manually set one empty vehicle per each land mass with chapel, perhaps with some big placement radius, name each anyhow, say v1, v2, v3, then go to JRInit.sqf find this: RYD_JR_AllEV = []; and turn it into: RYD_JR_AllEV = [v1,v2,v3];
  13. Thanks. After that userconfig errors at 20.19 I see no further script error logs. Hm. All right, I'll have to try to deduce the cause from the code analyze then.
  14. No limit. In this case RPT logs may be helpful to learn, what and where went wrong. I see, it was after the last nav point (9th) was properly reached, so code failed at final destination somehow. Mark was placed properly, yet heli went to [0,0,0] instead (it's typical for number of errors with positions). I wonder, if the fact it was so close to destination mark, could be a cause here...
  15. Peculiar indeed. Thanks again. These details will help. Probably some simple (?) logic mistake.
  16. Thanks. So, to be sure, I understood, CAS target selection shows up when CAS is cancelled and instead of destination/disembark variant selection during troops transportation task . Weird. OK, I'll check that. Is the "CAS selection" actual CAS selection, or just map, where you can put some nav points?
  17. User config may change, if I add new user config variable (I inform about that each time)... or if I during tests change my settings and neglect to restore previous setting, but this case you can just ignore and use own file with own settings instead.
  18. Rydygier

    Pilgrimage - Ported

    I believe, we did long time ago. 🙂 It may happens especially on small maps, when the code fails to find suitable random spot. In such case vehicle is placed at default map pos. All of them on the same position. At least that was the case last time, I checked. The risk of such occurence has been minimized at some point, but still there's a risk, code will choose same spot for more, than one vehicle somewehere. The way to further minimize it may be to reduce proportionally to maps size (to the amount of not-in-the-city-free-space-not-so-far-from-some-road to be exact) number of spawned abandoned vehicles here in JRInit.sqf (Altis map size setting): _softVAm = 30 + (floor (random 20));//30-49 _armVAm = ((3 + (floor (random 2)) - RYD_JR_Difficulty) max 0) min 3;//0-3
  19. HAS 1.6 wip8 Hopefully fixed issues reported lately.
  20. Someone devastated your helo's glass with graffiti? Not me. 🙂
  21. 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.
  22. Rydygier

    What i expect from "Old Man"

    No expectations. Just some hopes. The title suggest, there will be a piece story told, probably of "personal" tone (about someone, not something), which is great, especially, if told well. "Open-world scenario" speaks for itself, which is great too, especially IMO Arma has obvious, but still untapped potential here and inclination towards that kind of gameplay - why to ignore or fight with it, when one can wisely use it. If both, good plot with good narration and open gameplay, can be successfully combined together, that would be great^2. Lastly, "Singleplayer" is for me, 100% lone wolf, another good news.
  23. 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
  24. 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.