FourSpeed

As a follow-up, in case anyone else is looking for the solution, Grimes' idea works very nicely. (Thanks!) Basically, to track exact time since a particular flag, or more generically between any two triggered "events" in a mission you need the following script snippets: Event #1 Occurs / Or Flag X gets set (Note: these can be done simply with normal M.E. triggers and Flag options - We just need the script snippets to find the actual Time): Do Script: startTime = timer.getTime() Event #2 Occurs / Or determine the time (in seconds) since Event #1 / Flag X set Do Script: finishTime = timer.getTime() Calculate Time Between Events 1 & 2 / Or Time since Flag X was set: Do Script: elapsedTime = finishTime - startTime ### Total Seconds between elapsedMin = math.floor (elapsedTime / 60) ### Whole Minutes between elapsedSec = elapsedTime - (elapsedMin * 60) ### Extra Seconds after Minutes You can, of course, display that time (as Total Seconds, or Minutes:Seconds using a normal trigger.action.outText command. I'm including a very simple test mission to illustrate how these work for anyone interested. A couple "oddities" I noticed: 1> The startTime and finishTime needed to be Global variables, otherwise, when I got around to doing the Elapsed Time calculation in Snippet #3, they'd gone out of local scope. The elapsed time calculations probably also need to be global as well -- IF -- you plan to use them later. In my case, once calculated and displayed, I no longer needed them, so they could just be local in Snippet #3. 2> timer.getTime() returns Mission Time (time since started) in seconds to 3 decimal places. Oddly, however, in my test mission, Snippet #1 *always* returned a time value of X.001 seconds, and Snippet #2 *always* returned a time value of Y.701 seconds. So Elapsed Time was *always* Z minutes, z . 7 seconds... Weird.... Still, those worked well enough for what I needed, so once again, Thanks to Grimes for pointing me in the proper direction! Regards, 4 ~S!~ TimeTest_01.miz

Thanks, Grimes... That gives me some helpful avenues to explore. The conversion math is trivial, finding the time value was the stumper for me. Hopefully, this will get me going in the right direction. There's no doubt that the solution needs some scripting... the problem for me, and with your example (if I understand it correctly) is I can't get the actual time value itself. Currently, the only ME way I know is (largely) worthless: Time Since Flag (100, 120) --> Message To All ("Elapsed Time -- 2:00 Minutes",10) Time Since Flag (100, 180) --> Message To All ("Elapsed Time -- 3:00 Minutes",10) ... etc. which, of course is a Terribad approach if you want the time to the nearest second or so (hence my asking in this post). I think Grimes' post is closer to what I need, if I can capture the local time in a variable when the flag gets set, and I can do the same in a different variable when the second condition occurs, then, calculating the difference between the two and putting that value in a message is exactly what I'm looking for, and I just need the script snippet to print the final message. Thanks to both of you for your responses. It is very much appreciated. Regards, 4 ~S!~

Nobody??? Really? ...and here I was thinking this would be a simple one -- I had no idea that it's (evidently) impossible... Surely, MIST or MOOSE can retrieve the time value since a flag's state changed? I'm more than a bit perplexed that there are no replies to this thread. I'd hoped that one of the scripting guru's here could point the way, or add a simple DO Script snippet to do the job. <scratching head> 4

Hi guys, Quick one for you... I know how to trigger something when "Time Since Flag" equals or passes a certain value. What I'd like to do (and can't see how in M.E.) is put out a message showing exactly what the value currently is for "Time Since Flag" for a particular flag... So, say Flag 100 is set due to some condition. When some other condition occurs, I'd like to show in a message what the actual "Time Since Flag" value currently is for flag 100... For instance, if flag 100's value is 342 when the second condition triggers, I'd like to put out a message like "Elapsed Time: 5 minutes, 42 seconds..." I'm guessing that might need a small script, and if so, I'd greatly appreciate it if one of the scripting gurus could give me some insight on how to do it... Thanks In Advance, 4 ~S!~

Was interested in participating in the F-16 survey. Evidently, having a DCS login isn't enough -- apparently you need some kind of Google Login... wth? Fail.... "Have fun stormin' da castle boys" ... Guess I sit this one out... ttfn, 4

No advice at all ??? I guess that helps me prioritize this particular server in our list. 4

Hi Guys, I'm not sure if this is the right place to post this, but hopefully it'll do. Please pardon the forthcoming wall of text... :smilewink: :music_whistling: For several months I was hosting a DCS server successfully for occasional use for myself and some other players. I only start it up for those particular sessions. Lately (the past couple months, roughly around the v2.5.6 change from 2.5.5 - though I'm not sure if that is causal or not), hosting it has become completely unreliable. Unfortunately I've been unable to determine what the problem is that is causing this. I've tried everything I can think of (details momentarily), and I'm just about ready to sh*tcan the entire idea of hosting, so any insight you guys might have is pretty much my last hope before writing it off altogether. OK, here is some detail: Problem(s): * During missions (any missions including a simple one I've included in my attachment), it will occasionally Freeze completely for several seconds (3+ minimum). This happens seemingly randomly afaict. It's not frequent, but it occurs with any/every mission we've tried at some point. All players are affected. Usually, it will behave normally again after the freeze. * At other times, the Server will time out, and when I log into it, I see that the entire process puked and is gone. Unfortunately, there are no messages in the log that I can see to tell why it happened, at the time of the crash. Server Info This is a virtual (on Xen, iirc) dedicated server (in New York) that I rent (since 2013). On it, we normally host 3 RoF (Rise of Flight) game servers, and an IL-2 BoS (Battle of Stalingrad) server without any problems at all. Combined, those use ~25% of the CPU capacity and ~30-40% of available memory. These run 24/7 and do so for days/weeks at a time trouble free. The games are hosted on a server account with Administrator privilege. The server itself is a Xeon Class (E5-2697 @2.6 Ghz) platform with 8 cores, and 16 GB of memory. It is currently running Windows 2008 R2 / 64 bit OS. (I realize that OS is bit dated, and near, at, or maybe even past EoL, but everything on it is working fine, except DCS, and I'm not in a rush to redo the entire box yet to replace the OS if I can avoid it). I've run Speedtest on it, and with a local NYC server, it gets 400+ MB/s both up and down. Pointed at a server in my area (~2500 miles away from NYC) it gets 200+ MB/s up and down. In terms of player base, RoF is well past its heyday, so I can't recall the last time I saw more than 10-15 players logged in across all 3 servers and typically only 2-5 on the BoS servers. For DCS, we've never had more than 5 on at any time. So, given the low volume of players, and the physical stats I see on the server, I can't think of any reason for there to be problems with it -- especially considering the other hosted games run fine and DCS had also been ok until recently. What I've tried - so far * Shut down other programs and servers: Normally, even with the full compliment of games we're normally hosting, CPU is around 35%, and Memory is ~60-70% when adding DCS to the group. With those other servers down, and just DCS running as the only hosted game, those numbers drop to about 20% CPU and 35-50% memory. The freezes and crashes still continue. Even with just a single player on the DCS server (as happened today, in fact). * Repaired DCS: I've done this several times, including today. Today's crashes happened with one person on, post patch, and after a repair, it happened again with two of us on. I'm including the dcs.log file of those sessions along with a copy of the mission that was running. For the record, I don't think they're related to today's patch as they've been occurring for the past month or two (previously, things seemed to be working fine). * Set CPU Affinity / Priority: With 8 cores, I've also tried setting any other processes to use cores 0-4, and DCS to 5-7. That didn't solve it either. I'm including a zip file that contains today's mission, the log files from today's two crashes, and the options and Serversettings files I'm using. I'm hoping somebody can see whatever issue it is that I'm missing. At this point, I'm completely out of ideas, and I'm seriously considering uninstalling it from the server entirely. Obviously, I'd much rather have the @#&*$ thing work properly (like the other games we're hosting), so I'm hoping this can be resolved successfully. To quote a famous movie character ... "Help me Obi Wan, you're my only hope". :cry: Regards, 4 SvrInfo-2020.zip

Thanks, Sydy. This was on Single Player, but I've since seen it refill, and sometimes not... I wonder if there's a threshold or something. In any case, it seems to be working most times, so perhaps, I just got it mixed up a bit -- it is a new module for me, after all. In any case, thanks for your response. Regards, 4

Hi Guys, I'm currently learning the Harrier, and particularly VTOL operations. One thing I'm finding, and I'm not sure if this is a bug, or if I'm just missing something, but after a few VTOL T/Os and Landings, I eventually get low on water. That part, I get. However, when I land and have the ground crew refuel/rearm my jet, the water reservoir isn't being refilled. I'm not seeing any option / slider in the refueling screen to refill water, so, how do you do that? It seems a shame to have to grab a new jet due to a few hundred pounds of missing water. ;-) Regards, 4

Apologies for not focusing the the "Gear Extension" question .... Apart from this (maybe) being a hypothetical question, my first thought is How/Why are you running out of gas??? This is a multi-million dollar jet we're talking about - not an odd Cessna-152.... Your mission planning should be covering the target(s), distance(s), fuel load, and, ultimately, abort procedures (if it goes south). Without giving any thought to tankers, alternate landing sides, etc. my first thought, if you're running out of gas -- You're doing it wrong... :lol: How many bad guys should you shoot down to cover for a lost F-18 Jet & Pilot? Getting Jet/Pilot home safe is #1 Priority -- Killing the Bad Guys is #2.... Everything else is after those... ReThink your sortie planning... :smilewink::) Cheers, 4 ~S!~

First up, I'll confess - I'm a bit reluctant to post a reply, but that never stopped me before. :megalol: So - here we go... First, I agree with your assessment - these maps and modules *are* expensive (arguably, even during sales, though taking advantage of those are definitely your best bet). That said, ED (& partners) do seem to be making these simulations the best they can be -- for the PC $$), all bugs, and forum bickering aside. I have several modules -- a bunch of which, I haven't event begun to devote learning time to (including the Viggen). For me, the F18C Hornet is a great buy.. It's modern, it's very much in the forefront of their Dev efforts, it's a jet, it's A-A capable (and quite good at it), it's A-G capable, (and extremely good at that), it's a land based platform, and it's also a Carrier based platform. In short, it does *everything* you would expect to do with an airplane. Especially, once they add the anti-ship missiles. In ONE package, you can fly & learn all (or most of) the skills for the other aircraft in the sim. It pretty much does it all (if you exclude helos -- but's *that* is a different thread :lol:) and it's being actively worked on.... I do NOT mean for that to exclude other modules like the Viggen, Harrier, or even the Sabre, which all have different things to bring to the table, but if you want an aircraft that can do it all, grab the Hornet and every map you can fly it on... Everything else, is just icing (and, tasty icing) on the cake, but the F18 is a great place to start (in addition to anything else that interests you). Just one guy's opinion. Best Regards, 4 ~S!~ PS> Have the Sabre, Mig-15, A-10C, Viggen, Harrier, and F-15, which, with apologies, languish, because the F-18 has *it* covered. Rest assured, I *will* take advantage of those purchases down the road, but right now, they're on the back shelf *because* the Hornet can cover the basics of all of them.... Of course, I still fly the Huey, because nothing the Bug does can offset that bird's strengths... :smilewink:

My definite preference is for Cold Starts -- for several reasons. 1> I'm flying several different modules (F15, F18, Sabre, Huey, Frogfoot, Free Mustang), so I have 4x6 index cards I use as checklists for each eaircraft, and I find that more immersive and realistic (magically appearing in the sky just feels weird) for me, so going thru the appropriate start procedures and checklists just feels right, and it helps reinforce the various procedures for each of those birds. 2> Air / Hot starts are, for me, straight up annoying. NEVER is the particular aircraft set-up the way I would set it up when I fly it, so I'm trying to figure that stuff during spawn-in (not good), I have virtually NO SA for the situation I'm literally thrown into, and of course, almost by definition, the sh*t is hitting the fan the moment you spawn... A recipe for almost pure irritation and frustration (ymmv). 3> Cold Start also lets me (usually) set a load-out I'm comfortable with for the mission, which oftentimes, isn't what the default is. 4> As a PPL holder, I *enjoy* the entire flying experience. Sure, the combat / furball / wanton destruction is all fun and good, but I truly enjoy the whole flight process, and it feels to me, more like flying a real mission when I go thru the briefing, make notes on my mission card, and then go out to the aircraft, load it up, and fly it by the checklists... and, I enjoy the scenery and whatnot on the way to the IP while building up my SA enroute. Afterwards (if I live thru it), I enjoy the decompress of flying home, setting up my approach, trap or landing, and taxiing back to the ramp and shutting down after a mission well (hopefully) flown. So, definitely Cold Starts for me... Cheers, 4 ~S!~

As a general checklist item, you should also look at the Master Caution list on your Left DDI right before spooling up. It will show whether your wings are folded, or your canopy is open, and other interesting items you may want to be aware of (and fix) before blasting off into the wild blue yonder. Regards, 4 ~S!~

Mine is also failing to start as well (different msg though). I also ran a repair twice with No Joy... 2019-03-02 00:26:27.727 INFO EDCORE: DCS/2.5.4.28090 (x86_64; Windows NT 10.0.17134) 2019-03-02 00:26:27.729 INFO EDCORE: 2019-03-02 00:26:27.730 INFO EDCORE: # C0000005 ACCESS_VIOLATION at 0F6918B0 00:00000000 2019-03-02 00:26:27.734 INFO EDCORE: SymInit: Symbol-SearchPath: '.;C:\GAMES\DCS World OpenBeta;C:\GAMES\DCS World OpenBeta\bin;C:\WINDOWS;C:\WINDOWS\system32;SRV*C:\websymbols*http://msdl.microsoft.com/download/symbols;', symOptions: 530, UserName: '############' 2019-03-02 00:26:27.736 INFO EDCORE: OS-Version: 10.0.17134 () 0x100-0x1 2019-03-02 00:26:28.397 INFO EDCORE: 0x00007FFC0F6918B0 ((module-name not available)): (function-name not available) + 0x0 Hoping this gets sorted out soon. ------------ UPDATE -------------- I rolled back the patch with a revert back to 2.5.4.27430. That was successful, and the game was working once again (flew an SP mission to verify that) I then let it update once again to 2.5.4.28090, and this time, the update installed successfully and I was able to run the game with the current patch. I'm not sure why a "repair" didn't fix whatever the original issue was, but the revert and fresh update worked for me, so atm, my situation seems resolved... -------------------------------------- Regards, 4 PS> I did change the UserName in this posting (for privacy purposes). The crash is real though

Ok. In my first foray with Tracks (more on this in a bit), I flew two missions to look at this bug (and I'm now 100% convinced there IS a bug). The scenario: * Take off from Kobuleti and fly to the target area. * The target area (the little X runways between Batumi and Kobuleti) has 16 unarmed trucks (SKP-11). There are two soldiers at the center of the target area beside two trucks * On arrival set various combinations of Gunner RoE (Hold / Ret. Fire / Free Fire) and observe results. * Once the two soldiers are dead, land in-between a group of 4 trucks. Set Door Gunners on Free Fire and observe results. * Take off, Return and Land at Kobuleti. Here's what I found: Flight #1 -- My Helo spawned in unarmed. Using Ground Crew, I loaded it with the 4 miniguns. -- Set RH Door Gunner to "Ret. Fire" rules. Flew past central trucks and was fired upon. RH Gunner tracked targets, and the barrel spun minimally, but NO shots were actually fired by him. Reset him to "Hold" rules. -- Set LH Door Gunner to "Ret. Fire" rules. Passed central trucks again. Was fired upon again. LH Gunner behaved exactly as RH Gunner (tracked, spun barrels, No shots actually fired). Reset him to "Hold" rules. -- Set CoPilot to "Ret. Fire". Flew past central trucks and was fired upon. CoPilot returned fire killing the soldiers. Set him to "Free Fire" rules. He fired (properly) upon the trucks. Reset him to "Hold" rules. -- Landed between a group of 4 trucks. Set both Door Gunners to "Free Fire". Again, they tracked, but No shots were actually fired. -- Took off and returned to Kobuleti. Flight #2 -- This helo was already armed with the 4 mini-guns at spawn time. -- Following the same Door Gunner procedures as above, Gunners fired properly in "Ret. Fire" mode. -- Landing between a group of 4 trucks, both Door Gunners fired properly in "Free Fire" mode. -- Took off and landed back at Kobuleti. Conclusion: In all situations, the CoPilot appears to function properly in all RoE modes. If the Helo is armed when it spawns in, the Door Gunners will also behave properly in all RoE modes. If the Helo needs to be armed (or re-armed) by the Ground Crew, the Door Gunners will NOT fire as expected. They will track the target(s), and appear to shoot (the gun barrels will spin a bit), but no rounds are actually fired. I believe this behaviour is a bug, and was introduced with the last significant patch. As mentioned earlier, this was my first foray at saving tracks, and for me at least, I was quite surprised by the results. In both tracks, things did NOT occur accurately. Specifically, in track one, upon playback, it crashed my helo into the trucks that I actually landed between during the real flight. In the second track, it shows my helo landing well away from the group of 4 trucks when, in actual fact, I landed in between them. Upon takeoff the playback helo went in an entirely different direction from Kobuleti, where I actually flew to and landed during the real flight, and it eventually did a CFIT crash in higher terrain. Thankfully, I believe the tracks show the buggy Door Gunner behaviour but I was quite surprised with how poorly they replicated the actual flights they were supposed to be records of... Go Figure. I'm not sure if others encounter similar issues with Tracks but based on these ones, that system leaves quite a lot to be desired imho. Regards, 4 UH1H-GunnerBug-01.trk UH1H-GunnerBug-02.trk

As a follow-up / clarification, if you set the gunner RoE (Rules of Engagement) to "Return Fire" they appear to work properly (at least they did for me in the UN Pilot campaign). However, if they are set to "Free Fire" ... ie. shoot first when seeing bad guys, they don't work, although the CoPilot does under the same rules. That's in my own personal SP training mission. If I get the time / opportunity, I'll try to create a track showing the behavior. Regards, 4 ~S!~

I can confirm similar problematic behaviour in my SP test mission. Loaded all 4 miniguns (2 front, and the sides). All Gunners set to "Free Fire". The CoPilot will fire properly (even setting Master Arm ON if needed). The Door Gunners do not fire. Graphically, they track the target, and the guns rotate thru the barrels (a little, not a full spin) and no bullets are fired. This began with the recent patch. Previously, all AI gunners would fire properly under "Free Fire" settings. Regards, 4

I have VA, and I use it for the Hornet (although, you have to define a crapton of keyboard definitions first). Sadly, I haven't got around to flying the A10... so I don't have a VA profile for that one ... yet... When I get to that aircraft, I'll be making one, but that doesn't help you right now -- sorry... :( Regards, 4

For me, ADF, VOR beacons, and ILS works just fine. Even the FM Homing works fine ... UNTIL you try to contact ATC. @Thrustvector -- what exactly, did you test? Try this: Load up the "Elbrus Rescue" UH-1H mission. The homing beacon is (iirc) 40.50. Take off normally. Set FM homing radio frequency and homing switch. Verify the homing needles point to the top of the mountain... THEN use the Comms Menu to contact Skala on 116.0. Select Skala, and press F2 to request an Azimuth to them. For me, immediately after I do that, the FM homing needles stop working and the little yellow, no-signal bars pop up, the beacon signal stops, and that's all she wrote for the FM homing beacon - nothing I do after that, can fix it (afaik). You can do it before takeoff too. Start up your bird normally, set the radios and FM beacon, verify the homing sound is on and the needles are deflected. All Good. Contact Skala, and request take-off clearance ... bye bye, homing beacon. That's what I see .. and not only in that mission, that's just an easily testable example... I see it in any mission (or, at least, every mission I've tried that uses an FM homing beacon). It's fine until you call ATC -- then, it's gone. YMMV. Regards, 4

I too have noticed and can confirm this issue if the F18 is parked for a few hours. How did I notice it? I have an SP training mission (with all the planes that I own) for practice purposes. Normally, it's a daytime mission, and it lets me practice all the "normal" stuff (A2A, A2G, refueling, carrier traps, etc.). When it came to doing night VFR / IFR ops & Cat III traps with the Hornet, I ran the mission normally, then parked it on the carrier for a few hours while I went golfing, and then tried to do "night work" when I got back home, only to discover that ground power was needed to start the F18 after that amount of time. I certainly agree with others that this isn't a big deal, especially compared to the other items they're working on for the bird, but some of us *do* actually run long missions occasionally, so getting this on the fix list (even if it is fairly low priority) would be welcome and appreciated. Cheers, 4 PS> Yep. I get that "most people" would simply edit the mission to make a night-time one, but in my case, it was just easier to leave it running... ;):thumbup:

Hmmm... In the absence of any other replies, I guess I'm the only one seeing (or interested) in this issue. 4 PS> note to self: Don't use ATC Comms, while trying to use an FM homing beacon... :(

So nobody else has noticed this? Hmmmm... Strange..

Hi Guys, I hope you don't mind my piggy-backing on this thread. I've run into a small problem with the FM homing radio, and I'm not sure whether it's a bug, or something I'm not understanding, or doing properly. I tune in a beacon, say 40.50 (in the SP Elbrus Rescue Mission), and I'm receiving the tone. As soon as I use a Comms option like "Request Start-Up, or Request Take-off, or even a "Request Azimuth" while enroute) the homing radio stops working. The gauge with the homing needles shows two yellow bars (ie. no signal), the audible homing signal goes away, and even powering off all the radios and turning them back on again doesn't fix the problem. I'm not aware of any logical reason why speaking to ATC would break FM homing as (theoretically), they're all separate radios. At worst, I could imagine that the FM radio might need to flip from "Home" to "TR" to use VHF Comms, but that switch doesn't move, and once Comms are used at all, FM homing becomes entirely inoperable for the rest of the flight. Any light that can be shed on this issue would be most appreciated. Thanks, 4