ROGER_BALL

SUCCESS ! I wish to thank you: Thank you all for spending your time and sharing your expertise and helpful code. I have taken what I learned from each contributor and experimented with the code using the DEBUG console in the 'Editor' and placed code in my mission that does exactly what I want. Thanks to you and for what it's worth, each example and comment you all wrote in this thread was given 100% attention. My feeling is that if someone is going to donate their time and expertise to enlighten those of us on the bottom of the coding food chain, then by golly we owe the utmost of our effort to grasp, understand and implement that expertise. In this case, this thread provided me with outstanding examples and code to dissect for learning and use in my mission plan. While the effort took days and days from Oct 2021 until now to get everything working (error free), this whole experience was very enlightening and I have you to thank. Just in the process of Googling and researching your code structures and syntax, the learning curve was a steep climb. A whole lot more learning of peripheral topics naturally occurred. So, not only did I appreciate what you all wrote, the process in and of itself snowballed - gathering all sorts of great stuff along the way. It was easy to go down rabbit holes via Google/Bohemia but the trip was always a learning experience. Multiplicative learning, if you will. Sorry for the poor problem statement from the beginning. From now on, I will start my post with all the elements to define the goals as suggested by Pierremgi. Thank you. In retrospect, lacking this first step on my part, I'm surprised you all took the time to untangle my question and sift it for the facts. I double-thank you for that and the help here on the forum. I have about 3,500 hours spent on ARMA3, both gaming and mission designing and debugging. Hardly a day goes without a 2 to 3 hour session with ARMA III. I just absolutely love the immersion of it all whether it's playing or mission designing & debugging. (In present company, I use of the terms very loosely in claiming that I am "mission designing & debugging"! ) . "Attempting" to do so is more like it. Again, I can't thank you all enough. How could I ever return the favor. Best regards, Roger Ball

Great info and advice from all and, it is very much appreciated and helpful. Thank you for taking your time to share your expertise men. Check six.

Yeah, right? Since you put it that way 🙂 .. yeah, I guess that's the answer, isn't it. The init.sqf runs this other aforementioned .sqf which is just a infinite loop that runs every 5 seconds, moving the marker to my location at the moment. So, then, I suppose that since I spend most of my time flying a helicopter, I will have to investigate what position data gets sampled just at the moments after being shot while flying. I have no idea if the BIS_fnc_findSafePos grabs the helicopter's 3D position data as it plummets or my dead body's 2D or 3D position data. I have much work to do before I can impose further. Thanks 7erra. Much appreciated my friend.

I have always been able to self-teach just about any language I wanted over my life but I have to say, this ARMA3/SQF combination has seriously Kicked.M.A. I venture to wager that I have encountered the simple answer to this question without understanding the cryptic definitions and conventions. I must surrender at this point and just come here to indulge someone's good graces and thank you in advance. Maybe I'm just getting old. 😕 Anyway, my logs show perhaps 2,000 hours or so doing mission designs and I muddle through but this is a brick wall for some reason. Quite simply, I have an init.sqf that contains execVM "respawnMKR_INDEP.sqf"; This sqf contains the following code: while {true} do { _pos = [INDEP_Roger_Ball, 1, 50, 3, 0, 20, 0] call BIS_fnc_findSafePos; "respawn_guerrila" setmarkerpos _pos; sleep 5; }; My question is: Other than the one time that the init.sqf runs, does this code ever run again if I never "call" it or otherwise refer to this .sqf file? My understanding is that it only runs once. May I assume that "while {1}" will never fail and the execVM initiates this "5-sec" loop ? I conclude this from seeing a moving "respawn_guerrila" marker on the map. This blows my simple mind to have a loop in my code. That's something I have avoided in past lives and thus I ask these questions because it seems a waste of resources. Maybe not. If my assumptions are correct, and since the moving respawn position is only used when I die, would it make sense for me to figure out a way to just keep track of the _pos without doing anything until I die and actually need a "safe _pos"? Perhaps there is negligible differences in the two ideas. The BIS function may be small or may be huge - I donno the overhead in this new world I find myself loving - and I really do obsess over ARMA3 and envy the worlds of young, quick and skillful minds. My missions would really take on a different life. But, I digress. Third, even with good parameters feeding this BIS_fnc_findSafePos function, it still puts me into the water/ocean or some other weird location - but I am not asking for that to be addressed here until I exhaust the huge data mine that exists on this topic. I can hold my own with coding electronic interfaces in C+ but this is a whole different world. My hat is off to the many experts I lean on here for ideas and advice. Thanks for your time to comment briefly from your expertise. Thanks.

Come on! You guys are experts at this, I get that but quit torturing the fellow with trying to be his 'teacher'. Just simply answer his questions or go away.

I know this is an old thread but this "situation" still applies. So, for late-comers, the solution is simply via the "environmental" settings in the main editor menus. The default environment settings fields for WIND DIRECTION and WIND (DIRECTION) FORECAST are both "0". Place some non-zero values there and the pole will be nicely adorned with a "sock". Voila. Perhaps someday, the game programmers will add a "limp noodle" to the object pole when there are calm winds. In the real world, a calm wind indication is just as important as anything else.

Coming from an 'old salt' (2001), thank you very much. Cheers

Thanks for the supplemental info for the viewers. And thanks for your kind words as well. Cheers.

My pleasure entirely. Thank you.

If I may, I'd like to add a little clarification for readers who may not have a background in aviation. A no-flap landing in most high-performance aircraft (including fighters and swept wing bombers) is most often included in the EMERGENCY (or at the very least, the ABNORMAL) section of the operating manuals. For military and commercial pilots, demonstrated abilities to master "no-flap" landings is a training requirement. In the gaming forums, most opinions you'll read regarding the purpose and theory of operation of flaps are often bogus or flawed to say the least. Let's begin with the real facts. On high-performance aircraft (and even low-performance aircraft for that matter) Flaps exist TO ALLOW LANDING (and takeoff) AT SLOW SPEEDS. Why? In the case of fighters, fast approach speeds result in very high sink rates and touchdown speeds which can easily exceed the maximum touchdown speeds for aircraft tires. On takeoff, flaps provide a slower lift-off speed (less runway required). In aviation, there is a saying: "Nothing is more useless than altitude above you and runway behind you." Except in extenuating circumstances (like flight control problems for example), no-flap landings are considered an "abnormal" procedure at the very least. In some aircraft, no-flap landings require specific emergency procedures to deal with the reduction in safety margins. Leading-edge slats are sometimes added to aircraft designs to further reduce the approach/touchdown speeds. Anyone who has ever landed a high-performance, swept-wing aircraft without operating flaps and/or slats in icing or slippery runway conditions knows how risky this can be. No-flap landings are not optional in most aircraft, regardless of the runway length. All sorts of factors counter to aviation safety principles are impacted. Just to clear the air, flaps and (in some cases, slats) change the aerodynamic shape of the wing, making it possible to get very slow without stalling so touchdown speeds are as slow as possible. FLAPS ARE NOT AND SHOULD NOT BE USED FOR SPEED BRAKES. The misconception is created, in part, because folks (airline passengers) associate the fact that the aircraft gets slower on approaches and they mistakenly assume that flaps they observe are being employed/extended to "slow" the aircraft. While it is true that, aerodynamically, anytime lift is increased there is an associated increase in drag. There are no exceptions. However, it IS possible to increase drag without adding lift. We all know that "SPEED BRAKES" are one way to do this. Pure drag. When pilots begin the approach, and as the airspeed bleeds off through the use of these high-drag devices designed for that purpose (as well as flying techniques) the aircraft reaches a speed where flaps can be safely (structurally) extended. Above this maximum "flaps-extended speed", flaps CANNOT be deployed. Prior to reaching this speed, the slowing of the aircraft is aided by speed brakes and/or spoilers. As the aircraft reaches a slow enough speed where flaps (sometimes referred to as "barn doors") can begin to be incrementally extended. As the speed continues to drop, more of the "barn door" can be put into the slipstream and so the flaps are incrementally lowered on a speed-schedule (maximum for each flap setting). The aircraft, when fully configured for landing is flying now at a speed far below the flaps-up stalling speed. That is, we have changed the aerodynamic shape of the wing - in effect we "reconstructed" a wing that will fly at slow speeds. This allows for the slowest possible touchdown speed and maximum safety margins for many more reasons than just runway length (the reason often and incorrectly suggested as a criteria as to whether flaps are needed or not). Having flown high-performance combat aircraft ashore (10,000 feet runways), flight decks as a Navy Tailhooker, and as well as trans-Atlantic wide-body aircraft for the airlines, I hope to help youngsters separate fact from fictions. Here's one to think about. FACT: Fighters sometimes land at speeds SLOWER than jumbos. The converse is also true. As for the game itself, the flight characteristics one experiences are far from reality in most every way. The game does do an excellent job of providing a general sense of reality. So, in my opinion, there is enough aerodynamic modeling so as not to diminish the enjoyment of the game. And, furthermore, I am totally impressed with the designers ability to create this level of immersion. I agree with those here that lament over the absence or removal of the modeling for control surfaces' aerodynamic impacts on speeds and performance. Mastering the flight characteristics and operational functionality of the game's models is very challenging. When folks who won't expend the time and effort to learn basic flying principles end up voicing displeasure and complaining about not being able to just strap on the jet and go cruising, this can sometimes lead to a 'dumbing down' of the challenges - leaving those who did earn the achievements (expending the time & effort) with a simplified model. I feel your pain. Even having flown for over 40 thrilling years in aviation around the world, I still absolutely love ARMA 3 and find the scenarios and battles very rewarding. There is something for everyone and I hear kids laughing and carrying on some servers and, on my server, I hear serious minded veterans who mentally fight as if the arena was almost real - letting their minds completely immerse in the moment. Finally, take my advice on this: Flying a gaming model should never form one's basis of conclusions as to what an actual aircraft can or cannot do or how any particular type of aircraft system performs in the real world. Focus on the mission and enjoy the game for what it is and most of all, use your imagination to keep it real. Cheers.

UPDATE: Even with all the good graces and help from you all, I must be operating outside my pay grade and can't get things going like I wanted. Don't think I'm giving up though nor is your time wasted. I copied / pasted this thread's contents to this project's folder and saved it. As I learn more and more, there will come a day when I get that pay raise. 🙂 When that day comes, I will return here to celebrate and thank you all again. Cheers

In solo, I spend over an hour stealthily closing on Bright Light crash site. I finally sneak in there and get overrun by enemy numbering about 20 against 1 (me). I don't feel that's it's unreasonable for me to expect to succeed at least 1 mission out of every 15 attempts. Yet, I fail EVERY SINGLE TIME. The same is true for Ma Bell missions. It's just too much time to waste. I've gotten to the point that I have to say to any Bright Light crash survivors, "Sorry 'bout your luck but ya ain't gettin' out of there alive." The odds and game play is just not balanced well at all.

Holy scripts! Thanks for these new ideas and especially your time donated to help. I REALLY value your time and effort. Now, I must really read and study the last three posts carefully and do some testing. As before, I promise to get back here and affirm any successes so others following along will also benefit from your good graces. The "pyramid" of learning, if you will. Back soon & thank you again. Roger_Ball

Clearly, I'm operating over my head. Dead in the water. Getting old sucks. LOL.

Thank you for this information. I will fix that later but right now, actually, I'd be happy if ANYTHING was being displayed that indicated to me that any type of increments are happening. As I mentioned "0" is the only value being displayed. So, I'm actually not even getting "suicides + player killed" -- I get "0" no matter the manner of death, so to speak. That is, whether I sit on a grenade or get shot the chat output is still, always "0". Any ideas pierremgi? Thank you.