Captain Orso

I'm a total nuub to the Huey, but still... IDLE STOP/IDLE OFF: one button press to move from IDLE OFF to IDLE, one button press to move from IDLE to IDLE OFF, a bind to put those together as a combi-switch so that it works with TM Warthog Throttle with lower-end indent and beyond-indent switch working as both (buttons 29 & 30). This works in the A-10 with the bind added manually, in the FA-18, and in the Harrier (these are the only modern aircraft I'm flying. Only the Huey has this very odd configuration forcing you to mess with the keyboard to do things not required in the actual Huey. This can be a very easy fix. TURNING DIALS: in all the other aircraft I fly, right click turns a dial to the right, left click turns it to the left; very logical, very sensible, very... not in the Huey. This can't be that difficult to fix and make it conform to all the other DCS modules, can it?

I only found DCS one day about 6 years ago, because I was thinking, "hey it's only been about 20 years since Jane's Longbow came out", and I didn't even have a PC that could run it at the time; had to be happy with playing Gunship and Gunship 2000 , "somebody must have put out a serious sim of the Apache in the meantime". Echoing voice fading into the darkness: "... somebody must have... could have... should have....." DAMNIT!! But I did find my second favorite aircraft of all time, the P-51D HOTDAMN!! Move over Dick Pretty and I've been hooked ever since. So I've been looking forward to putting my butt into the pilot's seat of a really good Apache sim for over 20 years. I know this module is putting many very new innovations in DCS to the test - two-man-crew, AI-crewman, ground radar, advanced weapons systems out the kazoo, maybe even an update to the IR world (I can dream can't I). So if it takes a bit longer, by-god, it takes a bit longer. I don't want a rush-job, I want a blow-you-out-of-your-seat-job. To all those who think the delays are a bad omen and are pessimistic, well that's just your opinion, man.

This must not have gotten converted from the old forum, so now the linked-to pages say: You do not have permission to view this topic These links apparently explain the entire situation, but now that information is unavailable. Can we get the correct links, please, or have the relevant information posted here instead? Thank you

ED has to deal with the customers it has, not the customers it wants. Please stop trying to talk about things of which you have absolutely no idea. I only ever spoke about the instructor seeing the cockpit and having a pointer. That's it. Nothing more, nothing less.

Wow, thanks for the script. I'm going to try with the in-game setting first. I think once set, the server parameters should stay the same, so anding the lua script would be redundant. But we'll see. I'll check it out. Thanks again

I googled discord screen share and found a bunch of hits talking about lag in the games of players doing the screen cast. The channel is the site you login to, to access it's threads and chats. If the stream can be locked by the streamer so that only those he chooses can view it, all the better. I've spoken to too many people over the years about this. It's one reason very few use public voice-chat, especially if the language they are speaking is not their mother tongue. I can't change it. It's a fact of life. That remains to be seen. One would have to compare the different products to determine which works the best. And it would still leave the question of motion sickness. DUDE! you're stuttering!

Thanks for the reply, cfrag! I think it would be easier than that. The V-pilot is already generating the input. The DCS module interprets the input it and applies it to the aircraft flight program and the internal instruments. This results in the actions of the aircraft within the 3d space including the instrument displays in the cockpit. All the data is always there. It need only be duplicated to a stream going to the attached instructor for it to be fed into his client to render the aircraft cockpit of the V-pilot whos cockpit he's sitting in. So, everywhere a process produces output for rendering cockpit instruments and flight effects must be sent to the instructor stream. Then both clients render the results more or less at the same time. The work is in determining all the points in the module program, which are creating output, writing a collection process, and a process to transmit the data over the network. Then on the instructor's client to accept the input to recreate the same aircraft the pilot is flying and render it for the instructor to see in his 3d space. Basically, most of this is already working. Every time you see another player's aircraft, your client is using the other aircraft's pilot's flight data to determine how and where to reder the other aircraft. This only needs to be expanded to the cockpit and instruments.

Thanks for the reply, Furiz! You can be an independent camera view with a pointer that the V-pilot can see? Or do you mean, the V-pilot can share his display? You can do that with any number of video conferencing apps - Skype, Zoom, etc. - without having to be on someone's Discord page. A quick search for discord screen share results in many reports of extreme lag while playing games, so that doesn't sound like a viable solution. Additionally, it might also cause a performance hit on the Discord channel, which certainly wouldn't be welcome by the channel owner. Will everyone on the server be able to access the screen share? That will definitely cause many players to reject using it. I've heard too many talk about how they don't want others to see their training, because they are embarrassed and afraid of being ridiculed. Baring technical/performance issues, I guess that could be used, but it would not be terribly user friendly, because the instructor would be restricted to viewing only exactly where the pilot is looking, including every head motion he makes (VR, TrackIR), which can quickly lead to motion sickness. If the instructor could "be in" the pilots cockpit, the only traffic it would cause would be the current instrument settings being sent from the pilot's client to the instructor's. The instructor would already be in DCS and therefore be doing his own rendering, which should not be any different than when flying himself, thus very little, to no addition performance cost. Instructor Mode™ would be native in DCS. No need for additional software, no or very little additional network load, no additional burden on foreign servers. A simple solution providing a large benefit.

Many thanks Tippis!! Yes, that is exactly what I was looking for

I think more practically. You can already just fly along in spectator mode and talk to the V-Pilot through voice chat. Being able to basically sit with the pilot in the cockpit at the same time would have two fold advantages. 1) No need to modify any aircraft for it to work. It would simply be a different kind of spectator mode. 2) Both V-pilot and instructor can see the exact same thing at the exact same time. Both could point to things in the cockpit to help ask questions and give instructions and training. This is something you will never be able to do in a trainer aircraft. I know it's not realistic, but it's supposed to be tool for helping people learn to fly and operate aircraft in DCS, and not be DCS - Flight Training Simulator.

It would be nice if there were an option to start an MP server from the DCS client without the mission starting paused.

I requested this very thing many moons ago. It would be so very useful. I went so far as to also request to have the "instructor" have a pointer that the trainee can see to assist in instructing. I think it would be a real boon for DCS.

The Scratchpad keyboard cannot provide input outside of the Scratchpad. What you can do however is enter the text within one of the Scratchpad pages -- you can have up to at least 9 or 10, maybe more -- then select and copy that text, go to the save - file name field in the save track window and paste the copied text into it. Ofc you will have to learn to find <Ctrl><C> and <Ctrl><V> by touch, but that shouldn't be terribly difficult. The other -- IMHO better solution -- would be to learn to type with ten fingers

Bitdefender has no issues, neither at download, nor when scanning for viruses.

I understand that I can make "overlapping" packages. Is there a way to make the opposite, packages which are designated as being mutually exclusive? For example, if I had a number of background images for the main menu, it would make no sense to have OvGME put one BG into place, and then replace the first BG with the second, and the second with the third, etc. What would make sense would be to have all these backgrounds grouped together so that only one can be implemented at a time. This is just an example; not something I have, but I do have a bunch of VRScene setups: Main menu hangar

Suggestion: On p. 167 add to the beginning of 6. "Once the DDI display has reverted from the grid, ". Reasoning: If you start to add the easting/northing coordinates, before the DDI display has reverted, digits entered up to that point will be rejected. You must wait until the DDI display has reverted before entering the easting/northing coordinates.

Yes, I am aware of this. This feature is especially for MP usage, in which the player needs to be able to set the laser code during the running mission. My point is that all other OSB have their texts boxed when selected, and on the UFC after successfully entering a value the UFC button is no longer indicated with ":". I'm only requesting that both work the same as all other OSB and UFC buttons.

With LGB's loaded, on the stores page, when you press OSB 16 code the code word next to OSB 16 is not boxed done with other selected options. Once you go to the UFC and press the button next to code to put the ":" carrot on it, and enter a valid value, the ":" carrot is not removed, as is with all other options entered through the UFC.

Some further clarifications on deathbysybian's post:

Thank you Foka! That helps a lot!

Edit: oops, "Laser" Codes Management Summary Is there a method of setting or copying the laser code to multiple stations in one action? -- I'm aware that the laser code on GBU's are actually set on the ground by the weapons specialists, and that in DCS it's simply a user-friendly option -- especially for using on MP servers. From my understanding, with the A-10C it's the same issue; only ground crew can actually set the code. But in the Hawg you can at least set stations opposite each other to the same code at the same time (load sym), instead of having to go to each station individually to set the code. Is there a trick to do this quicker -- with fewer steps -- in the FA-18C?

I still get massive lag in the rearm & refuel menu, but it's different than before. Before it was only while the mouse pointer was hovering over the hard-point box - weapon type (AA Missile, AG Missile etc), which would cause the pull-down menu of weapons to populate and appear. This happened every time the mouse pointer entered one of the hard point boxes and hovered over the weapon type, and the lag the first time was about 15 sec IIRC, but if a box/weapon type had already been access, subsequent times were a little bit quicker. Now as soon as I select rearm & refuel DCS completely freezes for me for about 15 - 20 seconds. Nothing continues in my client at all until the entire weapons menu system has been generated, but not yet displayed. For example, if I'm starting up the FA-18, and the APU is green and I toggle to crank right engine, you can see the temps and RPM's increasing and hear the engine spooling up. As soon as I select rearm & refuel, that freezes, the screen freezes, the sound remains the same, although the engine should be spooling up. Once the rearm & refuel menu appears, everything else starts to run normally again. Now when the mouse pointer enters one of the boxes now and select the weapon type (AG Missile, AA Missile, Bomb, Rocket, etc, there is a momentary pause -- fraction of a second -- then the pull-down menu with the weapons selection appears. So overall the situation has improved, but still there is a very nasty lag.

I need to take a nap. The LST code is displayed just above OSB 17 right above the LST text so it was there all along.... *cough*

It seems that with the TGP on the FLIR page the laser code displayed next to OSB 14 is always the LTD/R code (default 1688), even when LTD/R is off. But when LST is on, the LST code is never displayed. Is this WAD? Shouldn't the LST code be displayed, if LST is on? I cannot think of any situation in which both LTD/R and LST should be both on at the same time, so there should be no conflict.