Captain Orso

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.

Did you download it?

Sorry for only just now getting back to you, brain like a siv, only good for noodles. The basic rules of fuel-tank usage in the P-51 are: - Alway startup and takeoff on the left tank. The carburetor fumes and overflow return line only goes to the left tank. If you use a different tank on takeoff you might be puting overflow into a full left tank which then has to vent it off into the environment through an overflow valve. - Once airborne and in stable flight, if you have fuel in the fuselage tank, switch to that, because carrying fuel in it produces a disadvantageous shift of the Center Of Gravity rearwards, and since you have already used some fuel from the left tank so there is room for minor overflow to it and while flying within normal parameters below max-cruising speed it is very unlikely to get overflow. Using fuel in that tank first removes the COG issue. In general you will never have fuel in the fuselage tank, unless the mission creator wanted to simulate a very long range mission, otherwise, per default it is always empty. - The P-51 does not have a left-to-right-tank cross connection so if their fill levels become greatly uneven you will shift your COG to the heavier sided and cause an unsatisfactory flight behavior. To avoid this, you will switch between drawing fuel from the left and right tanks so that each is used about evenly. You can always look down at the fuel gauges below the front left and right corners of the seat on the floor to check their fill levers in level flight, but you should get into the habit of switching from one tank to the other in periodic intervals. Using a simple scheme to determine which tank you use when will eliminate guessing and alleviate burden on the pilot. - Switch ever 10 minutes. Look at your clock and note the minutes of the hour. -- If the current time has the minutes value starting with an even digit (00-09, 20-29, 40-49) use the left tank. -- If the current time has the minutes value starting with an odd digit (10-19, 30-39, 50-59) use the right tank. If through combat flight or periods of climb the tanks become noticeably unevenly filled, compensate by using the tank with more fuel for a longer period of time than the allocated 10 minutes until the tanks are evenly filled. That's it. If you have any questions, feel free to ask. I'll be happy to help you where I can.