Tj1376

Are you sure it's not the size of the mission? For instance, our blue flag servers have 50mb mission files. It's 6k objects. It takes dcs a minute or two to load that into memory the first time. But our test server has just 4 objectives and about 100 objects. It takes seconds. TJ Sent from my SM-N970U using Tapatalk

The forums and the game use two different login id's and passwords as they are two different authentication mediums. You may use the same ID and PW on both, but they are behind the scenes two different processes. TJ Sent from my SM-N970U using Tapatalk

/topic/311661-28-caucasus-tooltip-issue/ Plenty of data out there with a simple search. This particular post in that thread is worth understanding. /index.php?/topic/311661-2.8-Caucasus-tooltip-issue&do=findComment&comment=5092477 TJ Sent from my SM-N970U using Tapatalk

And what are your settings for tool tips? Some mission designers enforce settings. Some leave it up to the client. Your settings may be tool tips are on and DDCS may have tool tips set to client preference and thus yours are always on. Some servers enforce a setting (like tool tips must be off. Or they must be on.) Really comes down to a combination of factors you have to consider. TJ Sent from my SM-N970U using Tapatalk

I will bet money it's a udp packet burst issue. Udp packets are made to be dropped. That's the whole point of udp. But DCS doesn't like when you drop its UDP packets and will boot you off the server if you stop responding to them. Most likely (and Wireshark would confirm this) your router is getting overwhelmed with udp and choosing to drop some udp packets (normal), but DCS doesn't appreciate it. QoS of your packets to the greyflag server port numbers should stop it. Make sure both udp and tcp are prioritized. TJ Sent from my SM-N970U using Tapatalk

That's exactly the point of this entire post. ED removed the tips option from the ME GUI but didn't build code to remove it from the mission file packed inside the miz. Thus old missions that were built pre 2.8 are now doing weird things with tooltips that creators don't expect and they have no easy way to fix it without understanding that a miz is really just a zip file and you can edit all the files inside it with a notepad editor of your choice (assuming you know what yo edit. Its a ton of trial and error.) It would be so much easier if a Tips option existed in the ME GUI so designers could control this. Or if the intent was to make this client controlled only, build code that removes the values from the options and mission file when the miz is opened from the ME GUI. It's poor backwards compatible programming. Hope this helps you understand the issue more clearly. TJ Sent from my SM-N970U using Tapatalk

Its always been based on server settings. Basically a server has three options: 1) Enforce a value as true 2) Enforce a value as false 3) Let the client decide The problem with 2.8 is that the "Tips" section (what we call Tooltips, ED calls "Tips") in the Mission Editor has the Tips values removed from the GUI but enforced in the MIZ. This means mission editors must go into the "MISSION" file packed inside the .miz archive and manually edit the value with their favorite text editor of choice. TJ

I dont want to lead anyone astray, and since the above back and forth with @Flappie DID lead us astray, I wanted to come back here and document the issue more clearly, now that we know what happened. Problem Statement: Users were seeing tooltips on our servers, despite the Options file in the MIZ saying tips=false In the above Track (in the very first post), there was a conflict between the two options available in the Mission Editor. If you open the track, you will see the OPTIONS file in the track lists tips=false. However, in the MISSION file under the 'forcedOptions' section, tips=true. This is the 'conflict' and post 2.8, the MISSION file forcedOptions section is now taking precedence (as it rightfully should). If you open the same track with 2.7, you'll see that the forcedOptions section for tips is not obeyed, and instead the Options file value is obeyed. So lets better understand the OPTIONS file vs the 'forcedOptions' section in the MISSION file. First, the 'forcedOptions' section in the MISSION file is where a mission designer goes into the mission editor and selects the "ENFORCE" options and then selects a value. This will enter into the MISSION file a forcedOptions value for what you select. Notice that today in 2.8, tooltips is no longer a selectable option. To resolve the issue, we simply updated the 'forcedOptions' section to tips=false and this has resolved our issue. I then tried to play around with the OPTIONS file, but I still havent figured out what the OPTIONS file actually does. In 2.8 there is no way to select a value in the ME without selecting enforce first, which seems to render the Options file obsolete. I believe that the correct way to now enforce Options in your MIZ is to set 'forcedOptions' values in the MISSION file (either via the GUI that ED makes available in the Mission Editor, or by editing the MISSION file with your preferred text editor of choice.) Hope this helps anyone else who stumbles across issues with their MIZ's in the future. TJ

This is one of the oldest servers in the DCS community, its MIZ's have been around forever. Our Syria miz is nearly 8k units strong, our original Cauc miz is just shy of 6k units...so you can understand that the MIZs never get rebuilt (tweaked all the time, but started from scratch, yeah, nearly never.) They have always worked from upgrade to upgrade (even from going from v1.x to 2.x!), and we've prided ourselves on working with ED to resolve issues as upgrades roll out. But you sir are spot on - I went into the mission file and simply deleted all the text in the "forcedOptions" section and YES SIR, the Options file is now obeyed!!! So I imagine this "forcedOptions" section in the MISSION file is simply old (probably pre Options file) and something in 2.8 is causing the code to obey the MISSION file if the values are present. This behavior did not exist in 2.7 (go load my original track in 2.7 and you'll see no tooltips, but load it in 2.8 and suddenly tooltips are on!) Thanks - this gives us an easy workaround! TJ

@Flappie I just did a random search in the MIZ archive for 'tips' and I found a reference in the mission file that is set to true. Can you please ask the Dev team if the Options file (packed in the miz archive) for tips=false/true is no longer obeyed and only the reference in the mission file should be obeyed? I confirmed that manually setting this newly found "TIPS" value in the MISSION file to false does indeed remove tooltips, however, there is no where in the DCS Mission Editor GUI to set this value (that I know of!), so this is a manual task to unpack the .miz archive, overwrite the MISSION tips value to false, then repack the archive. Is there any way to get the devs to file this as a bug where the Options file packed inside the MIZ is not obeyed? And, is there any workaround where I can set something in the DCS Mission Editor to force tooltips off? Just to make sure we are clear: Inside each .MIZ (like the above track) is an OPTIONS file. This OPTIONS file contains the settings that the mission creator wants to enforce on their MIZ. The complaint today is that the OPTIONS file is being ignored and instead there are a handful of options in the actual MISSION file. See attached screenshot of the handful of values that are in the MISSION file (these should all be obeyed from the OPTIONS file packed in the .MIZ.) Hit me up if you want to discuss, would be happy to jump on a call and show this. TJ

No sir, we mean tooltips. Tips=True/False should control the Tooltip (per our own documentation - this appears to have changed in 2.8.) We also just rotated one server from Cauc to PG and the behavior is the same on PG Tips=False is in the MIZ, however tooltips are still displayed. TJ

Yes @Flappie- still present post the hotfix. TJ

As a server administrator, I can confirm this issue is not related to our MIZ. In 2.7, we had tips=false in all of our miz's, and tooltips were off. When we upgraded to 2.8, Caucasus mizs have tooltips enabled by default while Syria mizs and PG mizs do not exhibit this behavior. Its been posted here: TJ

After we upgraded our servers to 2.8, both of our Caucasus miz's now force tooltips on for the client. We have no idea why. tips=false is set in the Options file packed inside the miz, and this behavior was not present on 2.7, nor is it present on our Syria server (also running 2.8, and its options are the exact same as the Caucasus miz.) Ive even tried removing tips altogether to see if that would allow the client to decide, but it remains forced on despite clients setting tooltips to unchecked. Any help would be appreciated. TJ ToolTips.trk

We noticed with one of our servers that was very popular with the Harrier fliers that it crashes much more frequently than two other servers that don't experience heavy harrier flight time. Apparently Greywolf also disabled all Harrier slots on his server to stabilize his environment. I have no proof Harrier is the actual issue, just sharing the speculation we've gathered from the past three days of watching our servers crash. There is an eery pattern of "several Harrier slotted=many crashes" - We ran 10 hours last night without any Harrier slotted, and zero crashes, so we have a bit of a hunch. TJ Sent from my SM-N970U using Tapatalk

Symbols is how the operating system downloads and uploads debug info to the mothership. Its not the cause here.... the access violation is, and the reference to symbols is just the OS trying to reach home to mommy to tell microsoft the process behaved badly and to see if microsoft had any information to provide you over how to fix it. Out of wild curiosity, do the 2 missions which have issues contain harrier heavy flight times? TJ

TJ

Ive found that the trim release button requires the rudder pedals (and joystick) to return to the neutral position or it gets 'stuck' and WILL NOT move. Ive started simply removing my feet off my rudder pedals after I press trim release (so they return to center) and then step hard back on them again. TJ

But @104th_Maverick, inquiring minds really want to know how you got the George interface to the bottom right of your screen!!!! This video was great, but make a video on how to move George interface! TJ

Having come from the KA50, the Huey and the Hip, the various Trim Reset buttons allowed the trim to recenter in the middle of the axis. This was INCREDIBLY helpful when you are transitioning from fast fwd flight to slow flight to enter the hover. As an example, enable "Show Controls" and follow along in your DCS AH-64D: Hold stick in a non-neutral position, press Force Trim UP (the manual calls this force trim release, because when depressed its letting go of the magnetic devices that physically hold the stick in place - your non FFB joystick cannot simulate this.) Return your stick to a neutral position. Now, verify in show controls that your stick is being held in a non-neutral position. Now, here is where the rub is.. and where many pilots (myself included) are struggling. In the KA50/Heuy/Hip, we now have a button to 'force our trim back to its neutral position' (what many are calling a 'force trim reset.') In the Hip, this button is "Trim- RESET to default," in the Heuy this button is "Trimmer reset," and in the KA50 this button is called "Trimmer reset." No such button exists in the DCS AH-64D. The only way I have found to get the trim back to its neutral position is to open show controls and physically move the stick back to neutral and then press Force Trim Fwd (release) to reset the trim near the neutral position. Could we please compromise on a factually unrealistic "Trim- Reset to default" button that we can bind, just like in the Hip/Huey/KA50, to help us overcome this hurdle? I realize the real chopper may not have such a feature (its not needed in real life), but for those of us who use centering springs on our joysticks, it makes life much easier. As always, appreciate your dedication. TJ

I think the confusion that so many are having is that Force Trim Release doesnt do what folks expect it to do if they have transitioned from the KA50, Heuy or Hip. Having come from the KA50, the Huey and the Hip, the various Trim Reset buttons allowed the trim to recenter in the middle of the axis. This was INCREDIBLY helpful when you are transitioning from fast fwd flight to slow flight to enter the hover. As an example, enable "Show Controls" and follow along in your DCS AH-64D: Hold stick in a non-neutral position, press Force Trim UP (the manual calls this force trim release, because when depressed its letting go of the magnetic devices that physically hold the stick in place - your non FFB joystick cannot simulate this.) Return your stick to a neutral position. Now, verify in show controls that your stick is being held in a non-neutral position. Now, here is where the rub is.. and where many pilots (myself included) are struggling. In the KA50/Heuy/Hip, we now have a button to 'force our trim back to its neutral position' (what many are calling a 'force trim reset.') In the Hip, this button is "Trim- RESET to default," in the Heuy this button is "Trimmer reset," and in the KA50 this button is called "Trimmer reset." No such button exists in the DCS AH-64D. As some have suggested, simply hold Force Trim Fwd (release) and hold your joystick in its neutral position and release Force Trim Fwd. This does not work. DCS is not resetting the trim into the neutral position. The only way I have found to get the trim back to its neutral position is to open show controls and physically move the stick back to neutral and then press Force Trim Fwd (release) to reset the trim near the neutral position. This is not ideal in VR. So for now, I believe the answer is "you gotta trim trim trim." But I believe the ask from the community is a simple "Trim- Reset to default" button that we can bind, just like in the Hip/Huey/KA50, to help us overcome this hurdle. TJ

Where are you finding the force trim release?

Can confirm that I cant get althold to engage either, and the manual makes no mention of parameters to maintain to get it to engage. Im holding a pretty steady hover, wont engage. Im holding a pretty accurate attitude, trimmed out and not losing or gaining any altitude at speed and it will not engage. We must be missing something! As one of my friends said, ED needs to pay Chuck to build his guides into their manuals. Their manuals are great for 'how does a system work' but are not the best at explaining how you actually use said system. Althold is a prime example. TJ Page 63 of the quick start manual. Attitude hold is force trim left (althold is force trim right) TJ

Can anyone clarify (or point me to the manual) on what the difference is between GND and GND DLY on the GBU31v3b? I have a test mission where we use GBU31v3bs to take out an ammo depot. Prior to the 12/22 patch, you had to put the GBU31v3bs into GND DLY to kill the ammo depot with 2 bombs on the F16. Post the 12/22 patch, you now have to put the GBU31v3bs into GND to kill the ammo depot with 2 bombs on the F16. Im sure this is all still WIP, so no bug report, but was curious what the 'correct' procedure will end up being. TJ GBU31fromF16withGroundDelayNotKillingBunkers.trk GBU31fromF16withGroundKillingBunkers.trk GBU31fromF18withGroundDelayKillingBunkers.trk

No idea. All I can tell you is that tracks before this last patch had gbu31v3s in AIR mode defeating the bunkers. After this past patch, they no longer do (they must be in GND mode, although we supposedly do not have the correct fuze for this.) So probably still all WIP. TJ