derammo

Yeah but that isn't the same as what he is asking about. Before the changes, it was possible to use a combination of TOO and PP to designate (for example) 4 tanks at range and program their coordinates into separate JDAMs. Then you could drop all 4 at almost the same time and avoid the tanks running away when the first one gets hit. Apparently, that behavior didn't match the real system, so it was removed. What you are describing would require something like mark points so you can snap the targeting pod to a number of targets rapidly. That's why someone else above is asking about mark points, albeit in a rather negative way. Mad respect for your signature!

That's cool, thanks for the links! So yes, it does decrease the force effect but you can hack around it by running your FFB stick at twice the current that it was designed for? Seems safe :) :joystick:

You can use saturation or custom curves to make the non-FFB stick reach maximum output before it reaches its physical limit and then "flatten out". If this issue is a problem to you, then you would sacrifice a little bit of the range around the outside of your stick as an allowance for the maximum deflection from trim. I have to admit, I never thought about that before though :)

Thanks for all the time you folks took giving your views. I guess I will keep it on the shelf for now and if FFB support for the F-18 is some day amazing, then revisit it. JoeyJojoJunior: how much did you extend it? I read on another forum that a realistic stick extension would end up with only about 1lb of force left?

I have had an MS FFB2 in storage a long time and just started using it again to see how it is. I get force feedback effects, such as speed-dependent resistance and shaking in the FW-190. But it doesn't seem all that exciting to me. I know I could disable the dead man switch and get the stick to stay in place in the Ka-50. That doesn't seem like a big deal either. Neither makes me want to switch from my warthog stick with a long extension. A lot of people seem very excited about force feedback. What am I missing? Is it just about feeling the plane getting close to stall pretty much? Or does it help you formation fly by feeling movement if you have everything correctly configured? Please convert me :)

I'm also pretty surprised nobody has answered this. Either you CAN hack the various planes' view definitions to have different named viewports or you can't (at least not without triggering cheating detection.) Seems like someone would have figured this out long ago?

Thanks, but no. I did ask the exact question I meant to ask :). The differences between DX11 and Vulkan (or DX12) are obvious to any graphics nerd I think? I was wondering why everyone is making such a big deal out of going to Vulkan over going to DX12. You mentioned untangling from MS and that several (or most?) big open world engines would go to Vulkan, which is interesting. So that part kinda makes sense to me. If domain experts believe the support from MS and perhaps larger pool of developers (?) are worth less than having more agency and control over their own destiny, I think I buy that. Sorry you wrote so much stuff on the other topic, but I am sure someone who doesn't know what Vulkan is probably will learn a lot from your post.

one way you could maybe get that going is to work with the folks in the "Mods and Apps" forum It is possible to render 2D UI into the DCS VR context using SteamVR's overlay app rendering (I tested this) So you could in theory make an external app (let's call it Helios VR :)) that would display various numbers and indicators in VR that you need. However, it is unclear to me if you could get the ship's ball lights state into the export context. But there are much more experienced modders that would know this. Just a dream right now...?

Does everyone see a flickering mess when looking at the text of the main menu and the pre-flight mission briefing screens? If I compare what I see in the DCS menus to any other VR application, the text looks like a flickering mess for some reason. The edges of all the letters shimmer like a graphics bug where subpixel rendering is just plain wrong. In case you are wondering, I am using an HTC Vive Pro on RTX 2080 with 2x MSAA and 8x Anisotropic Filtering. I am using equivalent settings in other VR programs with no problems. Is this just frame interpolation noise caused by dropping frames and having SteamVR try to fix it? If so, it is very surprising to me that I get this flickering on interpolation between frames that basically don't change (I am staring at a static scene showing the menu, trying to move as little as possible.) Anyways, is this a common experience?

Next steps: 1) report a bug in the bug forum now that you know the details: a) you have a clean install b) do you have any mods / hacks? c) you are getting 0 magnetic variance in every location 2) if you don't get any help, read the DCS error log in the Saved Games logs to see if it logs anything useful. sorry, I am out of ideas :(

I would be very surprised if it was limited to Caucasus. The magvar data is here (see screen shot with path into DCS folders) and it is worldwide data from NOAA. So if your airplane model knows its latitude and longitude and date / time, then it will get the variance (declination) from this model. Take a peek in that folder and see if it is messed up. I know you said you reinstalled, but this makes zero sense to me. Maybe some mod management software you are using blew it away or some other accident happened. If that isn't the problem then I would check the DCS error log next to see if it says something like "oh crap I can't load my COF dll" or something like that :). Sorry I am just making educated guesses, you probably need an expert (like from ED.) For interest, here is the source of the data: https://www.ngdc.noaa.gov/geomag/data.shtml

Stabbing in the dark / dim light: does this happen with every mission file or just a specific one? If it is a specific mission, maybe try changing the date of the mission start to something a lot different to see if you get any change. That could at least confirm if your setup still has a magnetic declination model :). Btw, can’t you just display the magnetic declination in the Data pages? I kinda think I remember it is in there (the actual +/- degrees value.) That would also establish whether your magnetic declination model is screwed up or if it is just not adding it into the heading displayed in the cockpit. Might at least help chase it down.

Helping someone program via forum posts is not something I would consider fun :) I will send you a PM to see if I can support you.

Vino: I think maybe you missed this post by wrl which answers why your scenario doesn't work?

I probably should have said step 0) google the crap out of this to see if anyone has already done this work

I figure its about 5 minutes work to trim down the export script to only send the two values you are interested in. I referenced the exact values in the first link. That said, here's how a vanilla integration with DCS goes: 1) construct (in this case, just trim down) a script that grabs the values you care about at every frame and compares them to the previous value. When they change, it sends the new values to another process via a UDP message (so you don't block the DCS thread that calls the export function) 2) create another application that receives the UDP changes and then does whatever with them, in your case calculating the values for your motion platform and sending them to whatever API/SDK/interface you have for that thing.

Just FYI: I suspect something has changed in this code recently. There was another thread talking about how bombs without an EFUZ now require EFUZ=OFF when we used to just set them to INST. So it is entirely possible this has changed since you last flew.

if you don't know what that thing is I linked, let me know :)

you mean the precise RPM or just the normal RPM percentage? the percentage values are two of the fields in the IFEI, which is exportable. All the code you would need is in the export script for Helios https://github.com/BlueFinBima/Helios/blob/7d1aabe5a0cb72d94c616ddf5a9007e5beeb3d18/Helios/Interfaces/DCS/FA18C/ExportFunctions.lua#L38 and it references this (it ends up included in this file) https://github.com/BlueFinBima/Helios/blob/7d1aabe5a0cb72d94c616ddf5a9007e5beeb3d18/Helios/Interfaces/DCS/Common/Export.lua#L177

Let’s see if the OP can replicate and confirm that this is the reason for what they are seeing. I didn’t address your new information because I was typing at the same time as you :). I still stand by my claim that all the previous (before yours) responses don’t explain what is going on and therefore this shouldn’t be marked as resolved. Awesome work on the explanation, btw. Hope that’s what is going on.

All of the claims that this is just realistically inaccurate don’t address what the OP and TeamMaximus are reporting: Namely, they dropped the bomb from different directions and it ALWAYS falls short. A) If it was related to wind, the deviation would not be the same from the opposite direction. B) Incorrect altitude data would explain it always being short, but it sounds like they have double checked that as well. C) Any random error or inaccuracy would not result in the weapon ALWAYS falling short, regardless of direction, but rather scatter around the target randomly as you repeat the test. I think it is incorrect to close this as being “correct as is.” The responses missed critical pieces of information in the report.

Thanks backspace. Saved me a lot of work right there... not all the work, but heck it was fun to experiment with ;)

Read the source of Helios. https://github.com/BlueFinBima/Helios It is conveniently in C# and it does everything you can do with DCS from a desktop application.

completely agree. Maybe give up some realism/accuracy and just add a safety to that switch. Just make it require a modifier (another HOTAS button) that must be held while using it.

Regarding the third person tools... I also am mostly interested in the multiplayer experience where you are dropped into a mission but you have no mission file for it. Sitting on the ramp, I would like to gather some coordinates from the F10 map and then quickly make up a data file that pretends it was made by ED's mission planning tool. This would then need to be loadable while I am sitting on the ramp (that sort of assumes they let us add files while already in the mission!) To simulate a future capability of being able to hook the F10 map clicks, I am currently doing something disgusting: I have a hook sitting on the clipboard change events and when you take a screenshot, it looks to see if there is LAT/LONG/ALT information on the screen where it would be if you were clicking on something in F10 map. Then it OCRs that information out of the bitmap. Yes, it is insane, but I wanted to see if it could work. In the future, we would hopefully have a script hook that doesn't require changing the installed DCS files to get this information, i.e. something in Saved Games. Then we could build third party tools to create PP data by sorting these clicks into missions and finally rendering a "data cartridge" file. In a beautiful world, ED would let us have a button to browse data cartridge files in a Saved Games location while on the ramp, so we can import the stuff. This wouldn't be simulating real processes of course, but dropping into a multiplayer mission is already not simulating reality. I think it is a quick way to pretend a DSU was previously made for you. We could call it Game-Ready Automated Mission Planning System (GRAMPS)