Rydygier

An alternative - likely worse, than checking positions grid, but fun, could be casting dense (like every 5-10 m), map-wide but terrain-only horizontal LOS checks along one axis, starting "for sure too high", then going down with halving the altitude back (if no LOS detected) and forth (if LOS unobstructed) - bracketing of sorts - and narrowing checks down to those axis values, where was terrain obstacle detected... Once you get one coord this way, second one may be obtained in few ways, for example by bracketing down LOS ray ends at this coord.

Well, that's yet another thing, that would need to wait, till I've free mind for it. From you, guys, said it looks like hit-or-miss hard to reproduce problem, so unless I'll have vanilla reliable repro from you (which is hard in this case), I can only try to review relevant part of the code or test myself in hope, I'll by able to see it myself. It may be either a flaw in the script logic, either some quirk in engine-level heli behavior while performing SAD.

What you would recommend? I'm looking for really living, breathing, big, rich world with some ambitious deepness included, where alone player have full freedom apart from any present or not plot devs prepared, and many options to choose from, where your actions influence that world in various, rewarding ways. A world, you can explore long time without beeing bored, full of possibilities. Or anything at least a bit alike. I of course know some most famous of that kind (Arma... :) ), but no title is too obvious nor too niche to mention.

I wonder if that would work (if still works at all...) :

FILE CFS 1.01 (Dropbox, APL-SA license) INTRODUCTION CFS script attempts to guide pointed helicopter along his waypoints using very low altitude similar to contour flight. CFS's control is paused as helicopter approaches current waypoint and resumed, when new waypoint become current. Testing run footage Parameters description: Helicopter - a chopper to be controlled. Desired speed - speed in m/s, that heli will try to maintain most of the time. Default: max config speed. The faster, the more risky flight. Desired altitude - AGL ceiling in meters: controlled heli will strive to maintain that height above the ground as much, as possible. Default: 10. Values below 10 not recommended. Overfly buffer - additional buffer in meters added to calculated minimal height necessary to fly over an obstacle (map object etc.). Default: 2. Values below 2 not recommended. Obstacle detection mode - setting for obstacles detection method. 0 - less CPU hungry, pays attention only to the map objects, ignores editor-placed objects and very few exceptions amongst map objects too (example: Tanoa's sea bridge roadway). 1 - detects non-map objects as well, may cause a bit more bumpy ride, than necessary and recognize as an obstacle also objects, that should be ignored, can be more CPU-hungry. Default: 0 (recommended unless insuffice in certain scenarios). Obstacle detection range - a multiplier of obstacles detection radius. Default: 1, which translates to the bigger of the two: (heli full length + 10) OR 20 meters. Too big radius will eat FPS fast, too low will tend to ignore big objects, that still can be collided with. Emergency pull up - if this is enabled and code would detect, that heli gets dangerously close to the ground, emergency "pull up!" vertical velocity will be added, which often (not always) may help to avoid collision. In such situation it will override sharpness setting. Default: true. Sharpness factor - the lower value, the more smoothed flight, but also more sluggish reactions which increase collision risk. Default: 0.2. Values 0.1-0.2 are risky. Values below 0.1 not recommended. Maximum: 1 (safest, but least elegant). Values above 1 or below 0 may cause weird behavior. Debug mode - added 3D visualisation markers and some numerical data on the screen. Default: false. KNOWN ISSUES & LIMITATIONS CFS was tested with few helicopters (Ghost Hawk, Hummingbird and Huron) and settings along various, demanding paths, but further tests with various settings/on different terrains may still reveal exceptions, where collisions may occur. Although I did, what I could to make it looking as natural, as possible, do not expect fully realistic flight model here. It's simplified, scripted makeshift. CFS will fail, if given map object has its shape bigger, than bounding box. One example found: sea bridges elements (pillars) on Tanoa - manual correction for them included. CFS will not try to pass obstacles sideways nor will try to guide the helicopter below any obstacle even, if possible (high bridges etc.). It will always try to overfly the obstacle instead. CFS guides the helicopter towards current waypoint along the straight line, there's no path preplanning to use terrain, avoid hilltops etc. The code is run per frame to make it fluid and reliable, so it may cause some FPS drops especially over areas with many objects, like forests etc. CODE Initialization: _handle = [heli1] spawn RYD_TI_TimidIcarus;//simple _handle = [heli1,83.3,10,2,1,1,false,0.2,true] spawn RYD_TI_TimidIcarus;//advanced //[helicopter,desired speed (m/s), desired altitude AGL (m), obstacle overfly buffer (m), obstacle detect mode (0/1), obstacle detect range (m), emergency pull up, smoothness factor, debug mode] Ending: removeMissionEventHandler ["EachFrame", RYD_TI_EFEH]; Source:

Sorry, didn't read carefully enough. I wouldn't add such a thing to HAS, since in HAS player shapes the flight route using manually placed mid-waypoints. Adding some procedural system on the top of that would seriously complicate things already complicated, while seems redundant, if the player can achieve same or better results via own brain. I did some preliminary tests however if such stuff could be added to standalone CFS at least (as it was interesting scripting topic), but then other matters redirected my attention. Some day I possibly may return to this, who knows.

It was implemented in the newest (IIRC) scripted HAS wip. No official new version incoming for now, so that wip would be the best option to try the two together. HAS 1.96. Explanation in the scripted HAS thread:

To let know out of dev branch discussions and for various insights about usage of this command. Please, share with own observations, if any. Tried new calculatePath command. Finds a path from Kavala to Pyrgos in 5-6 seconds. Then tested by putting BIKI example into some terrain-wise difficult cases. Troubles was expected and indeed encountered: 1. Destination cut off by water A: - Code: sleep 1; time1 = diag_ticktime; isNil {(calculatePath ["man","safe",(getMarkerPos "Start"),(getMarkerPos "End")]) addEventHandler ["PathCalculated",{ hint format ["time: %1",(diag_ticktime - time1)]; { _mrk = createMarker ["marker" + str _forEachIndex, _x]; _mrk setMarkerType "mil_dot"; //_mrk setMarkerText str _forEachIndex; } forEach (_this#1); }];}; - positions: - result: - time: 29,4s w/o drawing part Kinda expected - code goes to swim only, if there's no any land path and it checks everywhere for it first. That would be my explanation of long execution time. 2. Destination cut off by water B: - code: same, as in test 1. - positions: - result: NONE - gave up after two minutes of waiting. - time: ? Well, cause may be similar, as in test 1, but despite visually simplier situation, algorithm might have much harder time, maybe searching even larger area due to its logic. Not sure. Anyway, that's a warning about that command's use. Can keep you hanging forever in certain cases. 3. With loadingScreen - code: sleep 1; time1 = diag_ticktime; startloadingscreen [" ","RscDisplayLoadCustom"]; isNil {(calculatePath ["man","safe",(getMarkerPos "Start"),(getMarkerPos "End")]) addEventHandler ["PathCalculated",{ endLoadingScreen; hint format ["time: %1",(diag_ticktime - time1)]; { _mrk = createMarker ["marker" + str _forEachIndex, _x]; _mrk setMarkerType "mil_dot"; //_mrk setMarkerText str _forEachIndex; } forEach (_this#1); }];}; - positions: - result: NONE - code stuck behind loading screen. - time: ? I'm doing something wrong or it's a no go. A bit pity, it can't be speed up behind loadingScreen veil - will stuck forever there, maybe because it spawns an AI first and waits for it while simulation is suspended and spawned AI never ready? Now, to leave some specific question, I was planning to use it in the function checking, if there's a land path possible between two positions. Sadly, long execution time, if there's no such path paired with loadingScreen incompatibility makes this approach impractical and leaves me with only simplified scripted solutions that would, say, check for water along straight line between two positions etc. imperfect workarounds, unless I miss something here? BTW I guess, path points density isn't customizable? If someone's wondering, tried also with boats to see, if it will take into account peninsulas etc. with this code: sleep 1; time1 = time; isNil {(calculatePath ["boat","safe",(getMarkerPos "Start"),(getMarkerPos "End")]) addEventHandler ["PathCalculated",{ { _mrk = createMarker ["marker" + str _forEachIndex, _x]; _mrk setMarkerType "mil_dot"; //_mrk setMarkerText str _forEachIndex; } forEach (_this#1); diag_log "hop"; hint format ["time: %1",(time - time1)]; }];}; It does: but: And if destination is on land: ...it goes weird but hey, what to expect? and opposite: Didn't tested: land unit, both points on the water, land unit, start on the water, land unit, end on the water, boat, one point on the isolated water area (lake), other on the sea or another lake. Finally - does this EH code run twice? Diag_log check confirms that. In total my impressions - most welcome command, great to have it, but somewhat risky in use (a risk of long, even infinite like long execution times, if "unlucky" at picked positions), and giving weird results in some weird situations. In current state impractical in some supposedly promising uses.

In Hermes Airlift Services for that purpose I use brute force, namely setVeloctiy. The trick is to ensure, it still looks convincing enough and does not end with crash. Ripped out of HAS context example of use: _frc = 0.9; waitUntil { sleep 0.1; _alive = (alive RYD_HAS_Chopper) and {(canMove RYD_HAS_Chopper)}; if not (_alive) exitWith {true}; if not ([] call RYD_HAS_ifChopperReady) exitWith {_unable = true;true}; if (RYD_HAS_CallCancelled) exitWith {true}; if (RYD_HAS_AlternativeLanding) then { [RYD_HAS_Chopper,0.5,0,_pickPos,2,3,_frc] call RYD_HAS_AutoGuideB; _frc = (_frc - 0.025) max 0; }; (((getPos RYD_HAS_Chopper) select 2) < _lvl) }; and the function: RYD_HAS_AutoGuideB = { if (RYD_TI_ControlTI) exitWith {}; params ["_heli","_lvl","_var","_refPos","_tol","_vMpl","_frc"]; private _vel = velocity RYD_HAS_Chopper; private _lvl2 = (getPos RYD_HAS_Chopper) select 2; private _vel0 = random ((random (2 * _var)) - _var); private _vel1 = random ((random (2 * _var)) - _var); private _vel2 = random ((random (2 * _var)) - _var); private _dst = _heli distance2D _refPos; if (_dst > _tol) then { private _vect = (position _heli) vectorFromTo _refPos; private _spd = ((_dst - 1) max 1) min 10; _vel0 = _vel0 + ((_vect select 0) * _spd * _vMpl); _vel1 = _vel1 + ((_vect select 1) * _spd * _vMpl); }; _heli setVelocity [((_vel select 0) * _frc) + (_vel0 * (1 - _frc)),((_vel select 1) * _frc) + (_vel1 * (1 - _frc)),((_vel select 2) * _frc) + ((_vel2 + ((((_lvl - _lvl2) max (-(_lvl2 * 0.5) max (-2 min -((_lvl2^0.6)/3)))) min (((_vel select 2) max 0) * 1.1)) * _vMpl)) * (1 - _frc))] }; This should be used instead of (not together with) RYD_HAS_Chopper land 'GET IN';, when LZ waypoint is reached. "Get in" altitude must be same way maintained until ready to take off (so this is not for RTB).

While I do not recall exact details right now, the basic rule is, the bigger will be whatever you put instead of : (((getMass _heli)^1.3)/16) * (sqrt (_velF/100)), the stronger will be the tilt. So first I would put 0 there to see, if the issue is gone, to be sure, here's the right place to tweak. If so, the rest is about testing various values until the tilt is correct. You can work with both, 1.3 and 16, I guess...

To throw at least some guess work here, when TI moves heli forward, it looks like this: _heli addTorque (_heli vectorModelToWorld [(((getMass _heli)^1.3)/16) * (sqrt (_velF/100)),0,0]); _heli setVelocity _velV; So the guess is, the torque added is too big. Formulas was tailored for vanilla assets, most like not universally correct for every model out there. Especially, if getMass is exotic/differs seriously. One could via trials and errors adjust torque value for desired models... Or figure out better formula, working with all stuff, assuming, that's the cause indeed.

Yeah, one never can rely fully on custom assets, so I tend to not bother with them focusing on vanilla. Even if one day I would return to this, since I do not own PF, can't test those for debugging.

Welcome to the BI Forums! I never tried such thing, I know, there are: https://community.bistudio.com/wiki/playMission https://community.bistudio.com/wiki/playScriptedMission but no idea, if/how they work exactly. There's also: https://community.bistudio.com/wiki/runInitScript but this does not exactly that. Question is, do you really need to actually restart the mission. Maybe just try resetting everything to initial conditions within same mission (in such case best, if everything is placed/initialized via SQF script). If this is about repetitive simulating something, such solution should suffice (and you don't need any multiplayer set up for it, just plain, local singleplayer). But depends, what exactly you're trying to do.

Introduction A singleplayer, semi-randomized, real-time but turn-based open scenario for Malden. It's designed as multi-session long gameplay, recommended dosage: few turns per session. You are Gregory Escher. As the only member of scientific staff, you survived inconceivable consequences of the experiment conducted on Malden. Now, while time is against you, try to rescue and evacuate as many, as you can from this surreal disaster. To do so, manage your town, defend it, explore to gather survivors, resources and necessary measurment data. Each day you can perform limited amount of activities and each day situation gets worse, so decide wisely and act efficiently. Gameplay overview Download Warping Plague 1.10 (Dropbox) Warping Plague 1.10 (Steam Workshop) Warping Plague 1.10 - open folder (Dropbox) Notes Please, let me know, if there's any interest in this and if so, what could be improved, added or changed. Also bug reports appreciated as always. In this scenario I'm deliberately vague as for background explanation, I prefer to leave a lot to imagination. Experiencing the unexplained and attempting to understand, what's going on there and how to deal with it is meant to be a part of the gameplay. Meant is also kind of surreal/oniric vibe. Yes, that's one of these weird scenarios rather far from classical milsim etc. As for gameplay dynamics, it starts slow and easy, but gradually should become more and more challenging. Credits Scenario utilizes 11 anomaly scripts by @aliascartoons with his permission. More credits ingame... Optional content Scenario will automatically detect presence of MBG Aliens Ground Forces mod by @mondkalb and use provided by it aliens as warper creatures if mod is detected. Scenario will automatically detect presence of Artifact Zun Tavyl mod by @Circumsoldier and use provided by it weapon as warper creature armament if mod is detected. To Do Changelog Terms of Use

Great to see such a news! RPT logs may contain some hint about the cause of the problem. Landlocked terrain may be somewhat harder to explain, how quarantine works etc. assuming, you care about that... If I may advice, if you don't - I recommend to base the port on wip6 linked above. Good luck. 🙂

The good news is, I like the idea of "init code field" and it is most likely doable and easy enough to implement. The worse news is not really a news, because I said that already. I'm occupied with other stuff currently and I've no idea, when I'll be back to the HAS topic.

Things, that could be answered: does it happen in SP, MP or both. Player local/non local. Each try or erratic. Only certain helo class or all helos CDLC/vanilla alike. That kind of stuff.

It has been long time but I recall, I encountered this issue in the past (it was on pure vanilla). IIRC, I never managed to nail down exact conditions that trigger this most peculiar behavior despite quite substantial effort I put into figuring this out. Mentioned demo works fine usually. Also no idea, when I'll be back here, most likely not anytime soon, so this probably will remain an unresolved mystery, unless in the meantime someone manage to define exact factors, that cause this.

Found time for a tiny update, 0.71: - spellbook GUI should not appear if: 1. the player is not a battle mage; 2. in the map view; 3. other custom user dialog is active. Did only few tests, but seems, it prevents spellbook appearance also when inventory GUI is displayed.

Introduction Become a Battle Mage! Show them, what the real power is with your magick! Turn modern battlefield into chaotic blaze of colors, sounds, smoke and mirrors. Video Details One of my oldest Arma 2 projects adapted into Arma 3. Note, I was a noob, when I was writing this, so the code may contain many dubious parts, but it works. It still may contain some loose ends and there's obviously space for improvements and expansions, therefore this is still tagged as beta. Further development, as usual, depends on user feedback intensity. 🙂 Addon version with default settings may be used to add magic users to any SP scenario. While it may break some scenarios (possibly in funny ways), dynamic, procedural kind of missions should work well with it (and become something quite different...). Addon version requires CBA. Magic usage in game Casting spells ability may be given to some of AI Team Leaders on the map, but also to the player. Player can open his spell book by holding pressed RMB while weapon is lowered (or player unarmed) and not prone nor using binoculars at the moment. Releasing RMB will confirm chosen spell to cast, if any was picked. More details: Online PDF manual Download Rincewinder 0.71 (Dropbox) Rincewinder 0.71 (Steam Workshop) Credits & licenses Additional sound effects (edited) from: 1. http://soundbible.com/ By: Mike Koenig, Zarabadeu, BlastWaveFX.com, Mark DiAngelo: Attribution 3.0 license thecheeseman, wrzesien: Sampling Plus 1.0 license Stephan Schutze, Doberman: Noncommercial 3.0 license 2. https://www.zapsplat.com By: ZapSplat, SmartSound, Silverplatter Audio: ZapSplat's standard license Tom Chapman: CC0 1.0 Universal License Authors of these sounds do not endorse nor support this project in any way. Changelog Terms of Use

Not sure about multiplayer. I'm SP guy mostly. However, if you spawn the smoke and delete it from the same machine, say a server, it should work same, as in SP, at least I guess so. Otherwise smoke_1 variable may need publicVariable. Others may be more knowledgeable/helpful than me regarding particles in MP.

OK then, here's an example, how I do it. Compare with your way for differences. If still no luck, I can look at vanilla repro mission, if you provide one...

Depending, how/where you do it, it may not work, since _smoke is _local _var. Try instead run the code with global var, if you wish to delete it from other places, for example: smoke_1 = [markerPos "m1",1.5,180] call RYD_SmokePillar; then to delete: deleteVehicle smoke_1;

Yes, that effect looks quite dense, like lots of paticles, so a single pillar may exhaust big part of particles limit. Had few moments and since I find this rather fun, made another variant, run with same parameters, as first one: _smoke = [markerPos "m1",1.5,180] call RYD_SmokePillar; should be still pretty "cheap" as for particles limit used, ( (180/0.6)*0.75 = ~225) while looking a bit thicker: RYD_SmokePillar = { params ["_pos","_size","_life"]; private _smoke = "#particlesource" createVehicle _pos; _smoke setParticleRandom [0.25 * _life, [2.5 * _size, 2.5 * _size, 0.1], [1, 1, 0.2], 0.5, 0.35 * _size, [0.05, 0.05, 0.05, 0.2],0.5,0.2 * _size,45]; private _col = [[0,0,0,0.5],[0,0,0,0.75],[0,0,0,0.7],[0,0,0,0.65],[0,0,0,0.5],[0,0,0,0.35],[0,0,0,0.2],[0,0,0,0.05],[0,0,0,0.01],[0,0,0,0]]; private _effect = ["\a3\Data_f\ParticleEffects\Universal\Universal", 16, 7, 48,1];//["\A3\data_f\ParticleEffects\Universal\Universal_02", 8, 0, 40,1];// _smoke setParticleParams [_effect,"", "Billboard", 1, 0.75 * _life, [0, 0, 0],[0,0,0], 1, 1.5, 1.275, 0.45, [8 * _size,16 * _size],_col,[0.5,0.1,0.05],1,0.3,"","",_smoke,0]; _smoke setDropInterval 0.6; _smoke };

Using particle array one may spend hours shaping "the perfect smoke", tweaking and tweaking... Addicitve. Anyway, to get tall pillars one need to prolong particle's average life, so it may climb higher, before die, or to make it raise faster, but this may be not realistic. The longer each particle live, the longer it reduces available particles limit on screen. So especially with such tall smoke columns one need to be careful, or a single source of his smoke will eat whole particles limit. Maybe this will suffice: in the init.sqf etc.: RYD_SmokePillar = { params ["_pos","_size","_life"]; private _smoke = "#particlesource" createVehicle _pos; _smoke setParticleRandom [0.9 * _life, [2.5 * _size, 2.5 * _size, 0.1], [0.4, 0.4, 0.5], 0.5, 0.5 * _size, [0.05, 0.05, 0.05, 0.2],1,0.1 * _size,360]; private _col = [[0,0,0,0.5],[0,0,0,0]]; _smoke setParticleParams [["\a3\Data_f\ParticleEffects\Universal\Universal", 16, 7, 48,1],"", "Billboard", 1, 0.1 * _life, [0, 0, 0],[0,0,0], 1, 1.5, 1.275, 0.45, [5 * _size,25 * _size],_col,[0.5,0.15,0.1],1,0,"","",_smoke,0]; _smoke setDropInterval 0.2; _smoke }; Of course, it may be tweaked further to achieve better look. Executing for example: _smoke = [markerPos "m1",1.5,180] call RYD_SmokePillar; params: [smoke position,size coefficient,maximal particle lifetime in seconds] _smoke is the source object. Use deleteVehicle _smoke; to end the effect. If I'm not mistaken, with exemplary parameters used, the cost of this effect will be decent. Looks like this: