derammo

this isn’t hard to fix, but I’m sure it was frustrating please create an issue here https://github.com/BlueFinBima/Helios/issues/new then we can help you and also make sure this gets fixed for future releases

I did it partly for kindness, but mostly to do some testing with some seriously old stuff :) Anyway, I ran it on 1.4.2019.1005 and it worked fine I enjoy having some old test cases in my test library now. Also, the Export script is wild. :) Unfortunately, I don't have a Ka-50 mock up in my test scripts, so I can't really bang on it that hard yet.

They should? If you have some profiles somewhere you are concerned about, make them available and I will take a look. Edit: I don't know anything about 1.3 but I can easily check if any issues you see are bugs or just lack of backward compatibility in general if I run them on my dev setup.

Yes, this is currently in a mess, since we (Helios) haven't done enough to create compatibility between the different ways of doing Exports. I am working on it. Soon it won't be an embarrassing mess any more :). That's why I am not putting new files out there right now for people to hack into their CZ export or the other way around. I don't want to put out something that is about to be irrelevant again, when we all start playing nice automatically.

Yes, I wrote this feature exactly to solve this problem, which I also have on my touchscreens. There is something funky going on where it delivers mouse events in addition to touch events. So you can adjust the slider (I use the default of 200ms) to make sure it only considers it one click. Just make the time long enough to cover how long you actually touch the screen. I3dman: If you google this, you will find a lot of talk about Windows configuration regarding touch screens and turning off double clicking etc. That isn't what I am seeing on mine, so you probably have the same issue and this feature should fix it. Let me know please and file a bug if it does not.

Does anyone know if we can access any information about the current natural light level (day/night cycle) in an Export context? I would specifically like to tell Helios what the light level is and use that information in rendering the virtual cockpit. I know I could calculate day/night cycle myself based on real world data and geo coordinates. So no, that is not what I want. Putting this out there on the off chance someone knows of something useful we can get in an Export context. I know it won't be accurate, but it would be better than what we have now. Right now, we know if the cockpit is set to night mode, but you could use that switch during the day and of course that shouldn't suddenly show dark panels :)

Ok, since people seems to have missed it somehow, I will repeat it here: Just read this post https://forums.eagle.ru/showthread.php?t=230669 It has the instructions for how to change the text colors and how to dim the map, both of which you will want to use. Cheers.

Ok I tested it now. TL;DR: At 15mi away you can LSS a spot by pointing the TGP within +/- 2.5 degrees (pessimistic) of the target before pressing LSS. Long rant: I didn't understand the LSS scan is just left and right. The TGP's sensor swings left and right, and it has to happen to catch the laser spot in the sensor for it to succeed. So the challenge is to get the vertical slant angle correct so that you capture the spot. To figure out how "tall" the sensor is, I repeatedly ran LSS in Active Pause mode. The result was that the sensor found spots up to approximately 2.5 degrees above and approximately 3.0 degrees below the angle at which the TGP is pointed. This is 1.5 to 1.7 times as tall as the FLIR sensor's view that is shown in the MFD. Depending on test range I got the same angle but slightly different numbers for the multiple of the view size, so there is something squirrely going on with the geometry or maybe I made a mistake. But the important point is that you DON'T have to capture the spot in what the camera can see. The LSS scans an area around 1.5 times taller than the FLIR camera. The horizontal scan rotates around the sensor's vertical axis, not the plane's. So the vertical slant angle changes as it scans. This means you end up scanning targets further away on the sides than in the middle of the scan. So being off in the horizontal direction will further reduce the tolerance in the vertical direction. The numbers I gave above are measured being exactly head on to the target. Like I mentioned in the TL;DR above, within a few degrees you can just ignore that effect and just try to get within +/- 2.5 degrees of the target in both axes. If you are relying on the LSS to find the target area by "scanning the horizon" it will not work well, because it doesn't scan at the same distance as it swings left and right. PS: forgot the disclaimer: I am no expert, obviously. If I misinterpreted my experiment, please let me know.

So the resolution is the ET button is already there, and (embarrassingly) is actually IN my Helios UI. All the IFEI buttons auto bind in current Helios, so I didn't even know it was there. So I have exactly zero work to do. Thanks TOYKILLA.

I only asked because I was unsure if the F/A-18C has an MFCD somewhere I didn't know is called that :). Anyway, check the forum post I linked above. I think it is the same question and there are some answers.

In real life, yes. In game, no. As Grimes has already confirmed above, the aircraft in question don't have a detailed damage model. So you will always see those holes when the damage is above a certain threshold and the pilot will always be dead. Think of it more as a canned set of damage based on the overall aircraft health. That's because the detailed per-system damage model hasn't been done yet. At least that's what Grimes said, and they are an ED Tester, so I believe it.

PS: That said, I think there are some community-developed things that are worth so much that they should totally be integrated even at cost to ED. Specifically, the VR shader optimizations should be integrated at ED's expense as an optional graphics setting. This way, integrity check would not be violated and we could buy a year or two for everyone struggling with VR performance, while we wait for the re-engineered graphics engine.

Selling an Early Access every few months is already a subscription model :) *runs for cover*

In THEORY, ED could allow content contributions and then decide on a case-by-case basis whether something is a trivial addition or requires QA. If it requires QA, they would have to charge for the additional content, which would either require the original creator to license it for free / transfer it to ED, or it would require something super complicated like a third party creator agreement and then pay the original content producer? No way that is going to scale for this small an eco system. This isn't the Apple App Store. So I think the only way stuff could make it in would be if the new content somehow contributes to something they can charge for, like the Normandy asset pack for example. Pretty unlikely that would happen, unless there is like an open source product for DCS? Everyone contributes their stuff to an "improved ground forces" asset pack, but then somehow ED is able to herd those cats and make a tested release out of it, without having any of the devs in house to make fixes? No way. That said, I think selectively open sourcing portions of the product would be awesome. Imagine if the AI for the new dynamic battlefield was open source and the community could submit pull requests for better behaviors for specific units? This sort of thing requires a ton of research and experimentation and not a lot of lines of code, so I think the community could really help out there. This is already a paid activity at ED, so maybe having a bunch of contributions would actually help the devs out. Of course, this also won't happen unless they happen to hire some dev folks who are into working in this open source way. Otherwise, it will create chaos and resentment. Oh well, I can dream :)

I assume you mean the AMPCD in map mode? Because black text on the black DDIs would be less useful :) Read this thread: https://forums.eagle.ru/showthread.php?t=230669

Weird. How did you know I am German? Anyway, Danke für den Hinweis.

I googled it for you, so don't expect support from me on this. I have not done this ever :) You can do some insanity with Thrustmaster T.A.R.G.E.T programming. Basically you map the axis in the grey slider to some number of steps up and down in elevation, and the T.A.R.G.E.T. software will emit the number of key presses to go up or down from where you were to where you moved the axis. For an example, look at page 31 of http://ts.thrustmaster.com/download/accessories/pc/hotas/software/TARGET/TARGET_Script_Editor_Basics_v1.5_ENG.pdf Using AXMAP1 mode, you end up with something like KeyAxis(&Joystick, JOYX, 0, AXMAP1(5, PULSE+'r', PULSE+'l')); obviously 'r' and 'l' aren't the right keybinds for the antenna elevation, and JOYX is the wrong axis, but I wanted to cite from the document to confirm you are looking in the correct place.

I had assumed for the same reason as everyone else? Because other jewelry isn't "manly" enough for them but they want to feel pretty? Oh so pretty?

I sort of tried that, but I was unsure how exactly it should be done. Would you designate around the target area to stabilize it and then LSS again? Do you have to un-designate first? I am not at my virtual jet ;) but I will test this next time. The exact sequence you use would be great!

Thank you kindly! Will try that out.

I have been playing around with third-party lasing (scripted autolase, AI plane lasing, MP humans lasing) and the LSS in the Hornet frequently doesn't work for me. Are there pretty restrictive constraints (distance, angle, daytime vs night) where it actually works or should it work most of the time? I try flying right over my target, or pointing the wing where my pod is, or pulling up vs diving down at it and I can't figure out when it does decide to work vs not. Since I don't have any idea what level of success I should expect or how to pretty much guarantee successful TGP LSS, I need some input from you fine folks. In order to guarantee that the laser is actually active and not masked, I finally used infantry with the usual autolase script, so it has no "laser off" time. I then verified by destroying the target. But most of the time, the LSS didn't find the spot.

How would an F/A-18C pilot keep track of a timer that wasn't part of the mission plan? In other words, let's say you want to start a timer right now when someone on the radio tells you '5 minutes' or something like that. Is that something you do in your head or is there a stopwatch or timer utility you can start? Do you keep your high school track coach stopwatch bolted to the side of the cockpit? :) I am asking in case either a) there is already a system or b) it might make sense for me to add a stopwatch tool to my Helios UI

Ok I checked and the server that I was crashing on does have JF-17 (I assume that means it is running Open Beta) and I was able to connect to it with the Release client. So I think what Grimes says is the problem, there needs to be a change to what versions are allowed to play together.

I am also experiencing these crashes and never had them before the JF-17 came out. I patched everything (Windoze, DCS, Drivers) and got no change. I am running the Release version. I can play fine as long as there is no JF-17 present. I can't prove that is what is causing it, but it is consistent. I spawned about 8 times and turned on D/L without crashing, as long as I was on a mostly empty server. There is nothing logged in dcs.log when it exits to desktop. PS: I have 64GB of RAM, so this is not an out of memory issue.

Take a look at the project linked below. It goes much further than that. Disclaimer: I don't use this tool because these precompiled executables aren't allowed by my anti virus software. https://github.com/Santi871/DCSWaypointEditor