Captain Orso

Most very excellent!! I did notice one thing though. All my to install lists went blank. Only one was actually in use--I was just too lazy until now to delete all the others --and the one in daily use was quickly rebuilt, but I though you ought to know. Questions, under 'Manager options' is there any way to put the 'Open Contexts at startup' in a specific order? Thank you PS you should have one of those, 'buy me a ( beer | coffee | McDonald's Happy Meal ) links in your Github page

The Apache has a bug you may be hitting. Open the TSD page To add a waypoint (WP) click POINTS [B5], ADD [L2], WP [L3] Now to identify the waypoint through button inputs you click IDENT> [L1], but here can be a problem. Whether you have a keyboard key bound to L1, a controller button, or you're clicking with the mouse, if you assert the key too long, it flips back off. This only happens if L1 starts unasserted, ie INDENT> is not boxed /actually the type of identifier directly below IDENT>, which in this case shows 'WP'. If WP is unboxed and you click and hold L1 WP will box for about a second and then unbox again. If it is boxed, no matter how long you hold L1 clicked, it will only unbox and remain so. This is the only ever happens with TSD -> POINT and nowhere else I could find--I've already reported it as a bug. When Scratchpad runs thru entering the point data, I've seen it press L1 long enough to switch it off again--IIRC I had upped the 'TICKS' variable to 5, because I wanted to see something and had forgetting to turn it back down. You may have to try different settings until it works for you. When you click 'Load wpts' watch L1 and see if WP gets boxed and unboxed. If so, try turning your TICKS variable to one lower and try again.

That is not the question. There was a statement that the Hornet has a PTT key. I'm asking where that is documented and where it is in the cockpit.

The Early Access Manual only says: Communications, COMM1 - COMM2 - MIDS A - MIDS B. This is a four-position switch that controls transmission over the four radios. • Forward. Transmit over COMM1. • Aft. Transmit over COMM2. • Down. Transmit over MIDS A. • Up. Transmit over MIDS B. Where is the PTT switch to be found?

That depends on the aircraft. As I stated above, the Apache has this. You have one PTT button. You select the radio, and press PTT to speak over the selected radio. I suppose you could write VOIP to work like the Apache in ever aircraft, but then you'd run into conflicts, like what if you change the active radio in-cockpit and change it to a different radio in VOIP.

Okay, the issue is not specifically how many radios an aircraft has, but how many PTT's it uses. The AH-64D Apache has five radios(!!), but only one PTT button - brilliant! The F/A-18C Hornet has two radios and two PTT buttons (not including encrypted radio) - meh whatchagonnado. The A-10C 2 had three Radios and three PTTs - almost like having one phone for person you know. The issue is, up until now, using SRS, I could create a profile per aircraft and assign only one button per PTT the aircraft actually has. So for the Apache I only have one PTT defined, but for the A-10 I have three. That meant that two buttons not used as PTT's in the A-10 are free to be used for something else in the Apache, like switching the mic from one radio to another upward or downward through the list. With DCS VOIP, to accommodate the A-10's 3 PTT buttons, I have to assign these buttons under VOIP controls, but if I'm flying the Apache, they still must be assigned even if they cannot come to use!! That is a tremendous waist, plus if forces me to find completely irrational solutions to problems I didn't have before On top of all that, I use at least two buttons/switches as modifiers on nearly all aircraft, but on some aircraft I actually use more(!!). The issue, even though these switches/buttons are know through the controls of the aircraft I'm flying, VOIP had no idea they are defined. So when I assert on of these aircraft-defined modifiers and press one of the buttons defined as a PTT in VOIP, instead of DCS doing what I have defined in the controls for that aircraft, it openes the PTT in VOIP(!!) and that's not right! So I have go look at every aircraft I own, find which modifiers is has assigned and add ALL these to VOIP--even though they will NEVER be used within the context of VOIP--so that VOIP knows to ignore buttons/switches being asserted while these modifiers are also asserted. DCS KNOWS which aircraft I'm flying and can easily look to see which--if any--modifiers that aircraft is using, and have VOIP ignore anything being pressed along with the aircraft's modifiers, unless explicitly assigned under VOIP controls. That would be completely reasonable IMHO.

Short Summery, uninstalling OB Dedicated Server, downloading 2.9 OB Dedicated Server and installing that fixes the issue - at least for me. NOTICE: only the download page in English says 2.9 OB Dedicated Server. If you select a different langue at the top of the page by clicking on one of the other flags, all the pages in all the different languages say 2.8(!!) I didn't test to see what they download. When installing, you will be asked, which if any of the maps you wish to install. If you are installing the Dedicated Server onto the same system where your DCS World installation resides, these maps will not be downloaded again, but rather copied from you DCS World OB installation. The copying will take some time--how long will depend on the hard disks or SSDs you are using--but it will certainly be far quicker than if you have to download the maps. The 2.9 OB DS does not install a DCS Server Update icon onto your desktop, and the start icon calls DCS_server.exe directly and not DCS_update.exe, so if you want that link you will have to create it yourself.

The List of Missions is currently Left Aligned so that Mission names which are 35 or more characters long are truncated and cannot be read in any way. Please make the List of Missions Right Aligned so that the Mission name in its entirety is always visible. Thank you

Thanks for the answer Bignewy. I wish to god you guy would decide on one set of nomenclature that makes sense and stick to it. I don't know if it's a language barrier or what, but "(modular installer)" in English means the installer is modular, not the server. Thank you

Please, what is the "modular server"? Thank you

What is the "legacy" server? I'm trying to run the DCS Dedicated Server I downloaded separate from DCS World.

hmmm lemme seeeeee........ ....... yep, I'm officially stupid and my inner calendar is out of whack

Update on Friday!! Update on Friday!! After nearly 35 years in IT I learned one thing, you never ever Ever eVeR EVER do an update before a weekend or holiday... EVER! For a while ED was only doing updates on Wednesdays--at least it was my impression. Did I read a statement a couple of years ago that declared this? I have the feeling that I did, but maybe not. Not that I want to upset everyone whoa like myself has been waiting excitedly on the coming 2.9 update, I have to say, every time I see an announcement that an update will come on Friday, I get a little knot in my stomach--probably because of IT-PTSD. I just had to say this. I don't expect anyone to change anything, and ED is responsable enough to do what they think is best. Thank you--breathing into my brown paper bag for now.

There is a saying, Slow is Smooth and Smooth is Fast Unnecessary deadlines only make pressure for no good outcome. In the end, everything takes longer. You might get a product into customer hands quicker, but it will be at a cost to quality. You can have quick or good, but never both. It's difficult to wait, when you don't know for how long - it really is. But think of all the times things got "rushed". Think of how many people constantly complain, they will never buy an early-access module again - that's fast, but not good. it's not bad either, it's just not finished, and their might be bugs in their too. When I learned IT, my boss and mentor taught me, 'if you do work, you make mistakes, if you don't do work, you can't even manage making the mistakes'. Let's let ED do their work and not try to put pressure on them. Firstly, they won't let you - you'll be sitting on the curb so fast your eyes will spin, but secondly it can only do more harm than good. Good things take time. I bet there are other things to do in DCS than the Kola map. I bet there are.

Many thanks

No problem. Whatever you need. Here are my control setting: If you need anything else, please let me know

You didn't post a question

I understand completely. I worked in service and support for nearly 40 years. I know the routine Yup, Synchronize Cockpit Controls with HOTAS... has the checkmark.

ctld.lua and moose.lua are both written to call STTS (Simply Test To Speech) from SRS. Looking back at the messages (you never said where they are appearing - I'm not clairvoyant enough to ascertain that) but it looks like from DCS.log, inserted by ctld.lua along with the messages showing that the JTAC input is garbled. When I open 'JTAC-Test Academia-Caucaso-Range-SIN-ATIS.miz' in the ME... I was about to chastise you for not doing the JTAC call properly, but I realized I was only looking at the call in the trigger actions list, and when selecting the action, I see that it is correct--although the drawing on the map indicating freq 1680 is wrong - insert Kermit drinking tea meme here What I did note is that after calling each script file, you have no pauses. So let me explain. I learned that when loading scripts like moose, mist, ctld, etc, you load the first one in Trigger Type -> 4 Mission Start. All subsequent scripts are to be loaded in Trigger Type -> 1 Once with -> CONDITIONS = TIME MORE 2 (I've used 'TIME MORE 1' also without issue too - YMMV). TIME MORE x is how many seconds since mission start, so for each subsequent script being loaded, you need to increase the TIME MORE parameter. EG: 4 Start Mission -> Actions = Do Script File(mosse.lua) 1 Once -> Conditions = Time More 1 -> Actions = Do Script File(mist.lua) 1 Once -> Conditions = Time More 2 -> Actions = Do Script File(ctld.lua) 1 Once -> Conditions = Time More 3 -> Actions = Do Script File(another_script.lua) 1 Once -> Conditions = Time More 4 -> Actions = Do Script File(yet_another_script.lua) This is to insure that all scripts are actually loaded and ready, before any calls can be made on them. Since your triggers run one after the other as fast as they can, and all with 4 Start Mission, it might be that the JTAC call is running into a not completely loaded ctld.lua script and things go awry. I'd suggest giving that a shot and see if it helps.

I have a toggle switch assigned to CMWS ARM/SAFE, CMWS/NAV, CMWS PBYPASS/AUTO. and to the safety cover for the JETTISON switch. I tested with both hot and cold starts, with all the switches both ON or OFF. Only the CMWS ARM/SAFE switch synchronizes with my HOTAS. CMWS/NAV always starts in the CMWS position. CMWS PBYPASS/AUTO always starts in the AUTO position. And the JETTISON safety cover always starts closed.

You're getting all over the place now. If JTAC-Test Academia-Caucaso-Range-SIN-ATIS.miz is the mission with the JTAC issues, the JTAC call is missing all of the information. I noted that some of the many lua scripts you are loading may be calling SRS. I'm very bad at lua so I'm not going to try to debug anything--just a waist of time on my part. Look into the scripts you are using and their requirements.

Absolutely not. You just set the unit(s) name(s) and frequencies and anything else I'm forgetting and it works. At mission start you get an on-screen message that the JTAC unit has taken up service, and if it has a target, it will tell you the type (T-72, SA-8, whatever) and if the status changes it well be reported. From the moment the message is posted, the JTAC is lazing. The only issue I know, is that the JTAC tends to lag behind moving targets, which can be a problem if the targets are fast.

idk there were a number of updates since I've noticed this issue. And since I have this issue already, and I can either somehow go back to a previous version or press on forward, I installed the update that just arrived today and am now on 57.0.0.254.153. I have yet to test how well switching out to Dash works, or how long it takes until it doesn't--sometimes only minutes.

Many thanks for the reply, Lange_666. I have 56.0.0.193.155. I have no idea what I had before and when changed from what to what. I'm thinking of going a complete reinstall.

Am I the only one who every experienced this issue? I opened a case with oculus and spent hours testing, trying and gathering log and dump files and they never gave me an answer as to what the issue is or what I can do. It is a MAJOR issues if you cannot switch out of DCS if you have touch anything outside of DCS on your PC. If you use a Rift CV1 and regularly use the Remote and the Oculus button to switch from DCS to the Dash board, let me at least know that it is working for you - Always - Nearly always - Sometimes - Never - What are you jabbering about, are you on drugs? Many thanks in advance.