Hextopia

Unfortunately we'd need a hardware survey and poll to find out exactly who the minority actually is. From anecdotal evidence polling the ~100 or so VR users I've played with in DCS, only a tiny handful (8) don't mind the hard limits in IL-2, but I do know of plenty of non-VR users who feel like VR users cheat by looking outside the canopy in PvP and get extremely vocal about it. Like I originally said though, the number of people who actually care about this is an extraordinarily tiny minority of people either way. At the end of the day, it's a tiny, vocal minority of PvP WW2 players who feel like VR users are cheating and checking six through the canopy, which is an unbelievably minor benefit. (since it's extremely easy to just kick the tail out and look around the seat/tail/caonpy)

I wanna step in and say as a VR user who's flown that other sim that uses hard head limits, I'd immediately and vocally start a shit-storm if someone tried to implement cockpit view limitations as a server enforceable variable. The way that other sim does it actually turned me off so badly I stopped playing/purchasing expansions for it. Hard limits of any kind are jarring, disorienting, and frustrating in VR and they're a terrible idea. A soft-limit of some kind that blinds you as your head passes the canopy would be fine, but it still seems like poorly prioritized effort for something that's really only a concern for a tiny subset (Vocal minority) of a tiny subset (VR users) of a tiny subset (DCS WW2 players) of a small subset (PvP players) of a small community (DCS players). I'd be willing to bet the number of people who have this as a high priority to be changed in DCS are in the literal single digits, if not under twenty people.

The lack of any kind of "virtual target" within DCS is actually a big problem. I ran into a similar issue with trying to make the KS-19 for High Digit Sams. Since weapons always and only target entities, I had no way to include any kind of aiming error in the gun depending on what was actually being used to track the target at the time (radar tracking vs optical tracking). Here's to hoping ED includes this function in the near future.

The only possible reason I can see is trying to slow down (not prevent) memory editing cheaters or to prevent malicious mod code being executed, though any malicious code would have to be in plaintext in a lua file, so it's very likely it'd be spotted quite easily.

I think the problem everyone has is that there are more people talking about modding and how to mod the game than there have been discussions concerning cheaters (that this decision would actually stop) by probably an order of magnitude. If this is some decision being driven because of something in the russian, chinese, etc. communities that we're not seeing, communicate that to us. As it stands we're given an explanation that makes little sense with no detail, which feels like the old ED's shitty community management rather than the new approach we've all come to love. Sell us on why this is something that's necessary.

I'll also step in and say hiding all the lua files is a poor move that's going to kill a modding community that's only just now starting to come out with good, complex content that improves the base game. Harnessing your playerbase to make quality content for you, especially in niche and technically complex genres like flight sims is part of how you do good community management and keep your players invested and coming back to buy more modules. If you lock away all the lua that defines the systems and objects in the game you're never going to get another High Digit Sams, splash damage mod, SRS, french pack, etc. Modders add value to your game and drive more sales, don't lock them out. Find a better way to address the cheating concerns, because as it stands you always have the option to go back to hiding everything if cheating *does* become a problem, but to do it prematurely without anyone complaining about it is just burning goodwill with the community for no gain.

I'll admit I'm not a great coder, but I'm trying to work on extending your spawn function and waypoint order functions to account for tankers using the moose controllable wrapper that allows setting enroute task options on units. (Which would allow tankers to be set to the enroute tanker task) If I can get it working, I'll send you the code for inclusion if you'd like.

I fly the Mi-8 using those as a trim hat, and I've also reduced their sensitivity by about 20% in the default.lua for the controls. It actually works really well, since the autopilot is perfect for minor trim/turns in long flights where I want to maintain near max possible speed without needing to fiddle with the stick trimmer constantly.

Does anyone know how to view or interpret these filetypes? As best I can understand looking at them, they're some way to define a system of how information is passed between different functions or parts of the program? It looks like they should be able to be opened in a viewer of some kind, but I haven't found a program that can read this specific format yet.

The Mi-8 has the autopilot knobs you can bind, which work sort of like a trim hat, but take some getting used to, and only work when the autopilot is on.

Just a short post to say I'd love to have a new type of helicopter trim implemented that's a blend of the "center stick" option we currently have, and the "Default" modes where I can push trim, and I get a short (user customized) delay before the control inputs start again, or a smoothed input period where the new trim position and the current stick input are gradually brought together. So I'm not stuck needing to completely recenter the stick (perfectly in both pitch and roll) before I'm allowed to control the helicopter again, but I'm also not stuck with the jerkiness of the instant change in default mode. I'm asking for this because both default mode and center-stick suck, and FFB sticks are unfortunately hard to come by with enough controls on them to be useful.

Hi, we had this rapid pitch oscillation occur 3 times during a multiplayer mission for two separate people. No one was above 800 knots, or low on fuel. Track is attached at google drive below: (It's long) https://drive.google.com/file/d/1rRBDHDUcvf-FiV8cxgas583Dn9NnTqxN/view?usp=sharing I wish I had a shorter track to show it off, but it's such an inconsistent bug that it's hard to grab it intentionally. First occurred at about 30 minutes into the mission, for myself. I hit the ground due to loss of control during the pitch oscillations. Track appears bugged, because my aircraft veers off and does some strange stuff at high altitude when I should be in formation with 3 others during my second flight. Regardless, the bug occurs again for my incorrect track, and occurs for another flight member just past 1 hour into the track. He goes into pitch oscillations during a turn, then an aggressive stall and flips end over end and recovers just shy of impacting the ground; I go into another uncontrollable pitch oscillation during a dive and crater.

Hmm. That sounds like a bug, because I've only ever seen them work like the video I linked, and that's for the A-10 and the Viper. Are you using any strange settings in the stores page when you get ready to drop them, or are you just using a normal CCRP drop without editing the stores page?

An easy way to check would just be to run a slow-mo track file and watch them release. Most likely they're all simulated, since watching it happen can turn your computer into a slideshow momentarily. As for the CBU-97, I don't think you're really paying close attention to it then, since it visually looks almost exactly like the real things do in the textron videos. Also, the submunitions absolutely are susceptible to winds, which is why in high wind conditions you'd use a lower HOF, or offset your aimpoint appropriately. Here's a decent video of them in DCS: And here they are in real life: If you watch them in slowmo, you'll see that they're quite well modeled.

So, DCS does model different kinds of warheads. Looking at the warheads.lua you can see the different types of "generic" warheads that exist, but are all based around the same definition: function simple_aa_warhead(power, caliber) -- By Saint local res = {}; res.caliber = caliber res.mass = power; --old explosion damage effect res.expl_mass = power; res.other_factors = {1, 1, 1}; res.obj_factors = {1, 1}; res.concrete_factors = {1, 1, 1}; res.cumulative_factor = 0; res.concrete_obj_factor = 0.0; res.cumulative_thickness = 0.0; calcPiercingMass(res) return res; end function enhanced_a2a_warhead(power, caliber) -- By Yoda local res = {}; res.caliber = caliber res.expl_mass = 1.7*power; res.mass = res.expl_mass; res.other_factors = {1, 1, 1}; res.obj_factors = {1, 1}; res.concrete_factors = {1, 1, 1}; res.cumulative_factor = 0; res.concrete_obj_factor = 0.0; res.cumulative_thickness = 0.0; calcPiercingMass(res) return res; end function directional_a2a_warhead(power) -- By Yoda local res = {}; res.expl_mass = 3.5*power; res.mass = res.expl_mass; res.other_factors = {1, 1, 1}; res.obj_factors = {1, 1}; res.concrete_factors = {1, 1, 1}; res.cumulative_factor = 0.0; res.concrete_obj_factor = 0.0; res.cumulative_thickness = 0.0; calcPiercingMass(res) return res; end function simple_warhead(power, caliber) local res = {}; res.caliber = caliber res.expl_mass = power*explosivePercent; --new explosion damage effect (explosive + fragments) res.mass = res.expl_mass; res.other_factors = {1, 1, 1}; res.obj_factors = {1, 1}; res.concrete_factors = {1, 1, 1}; res.cumulative_factor = 0; res.concrete_obj_factor = 0.0; res.cumulative_thickness = 0.0; calcPiercingMass(res) return res; end function cumulative_warhead(power, caliber) local res = {}; res.caliber = caliber; res.expl_mass = power*explosivePercent; res.mass = res.expl_mass; res.other_factors = {1, 1, 1}; res.obj_factors = {1, 1}; res.concrete_factors = {1, 1, 1}; res.cumulative_factor = 3.0; res.concrete_obj_factor = 0.0; res.cumulative_thickness = 0.2; calcPiercingMass(res) return res; end function penetrating_warhead(power, caliber) local res = {}; res.caliber = caliber; res.expl_mass = power*explosivePercent; res.mass = res.expl_mass; res.other_factors = {1, 1, 1}; res.obj_factors = {1, 1}; res.concrete_factors = {5, 1, 10}; res.cumulative_factor = 0.0; res.concrete_obj_factor = 5.0; res.cumulative_thickness = 0.0; calcPiercingMass(res) return res; end function antiship_penetrating_warhead(power, caliber) local res = {}; res.caliber = caliber; res.expl_mass = power*explosivePercent; res.mass = res.expl_mass; res.other_factors = {1, 1, 1}; res.obj_factors = {2, 1}; res.concrete_factors = {1, 1, 1}; res.cumulative_factor = 2.0; res.concrete_obj_factor = 2.0; res.cumulative_thickness = 0.0; calcPiercingMass(res) return res; end function HE_penetrating_warhead(power,caliber) local res = {}; res.caliber = caliber; res.expl_mass = power; res.mass = res.expl_mass; res.other_factors = { 0.5, 0.5, 0.5 }; res.obj_factors = {1, 1}; res.concrete_factors = {1, 1, 1}; res.concrete_obj_factor = 2.0; res.cumulative_factor = 0.0; res.cumulative_thickness = 0.0; calcPiercingMass(res) return res; end From this, it appears that the MK-118 definition does make it a HEAT warhead, given the cumulative thickness number. Looking at other HEAT warheads, they appear to also have an above 0.0 cumulative_thickness value, so it appears that's the armor pen value. Honestly, people don't give the devs enough credit sometimes, because things like the CBU-97 are modeled with insane detail (there are probably ~200 lines of code that define the aerodynamics and the model animations for the dispenser casing pieces, skeets, and parachute submunition dispensers, and that's not even considering the definitions of the explosives and the seeker heads on the skeets)

This is a straight up fabrication, and you can check this yourself by looking at the weapon definition in the lua: declare_bomb("ROCKEYE", _("ROCKEYE"), "rockeye", wsType_Bomb_Cluster, "bomb-cassette-2", { fm = { mass = 222.000000, caliber = 0.335000, cx_coeff = {1.000000, 0.390000, 0.600000, 0.168000, 1.310000}, L = 2.340000, I = 101.298600, Ma = 0.197848, Mw = 1.987409, wind_time = 1000.000000, wind_sigma = 100.000000, }, launcher = { cluster = cluster_desc("Bomb_Other", wsType_Bomb_Cluster, combine_cluster(MK118_DATA, { cluster = { count = 247, effect_count = 20, wind_sigma = 50, impulse_sigma = 2, moment_sigma = 0.0001, } }, "cluster" ) ) }, control = { default_delay = 1.2, default_open_height = 457, }, The rockeye is modeled as having 247 heat projectile submunitions. The problem is the damage of the submunitions is very low, meaning they usually don't score enough hits (and thus enough damage) to actually kill the target they hit. The mk 118 submunition weapon data: warheads["MK118"] = -- Mk-20 { mass = 0.59, expl_mass = 0.25, other_factors = { 1.0, 1.0, 1.0 }, concrete_factors = { 1.0, 1.0, 1.0 }, concrete_obj_factor = 0.0, obj_factors = { 1.0, 1.0 }, cumulative_factor= 10.0, cumulative_thickness = 0.25 }; I'll admit I'm not 100% certain of how these values work, since I haven't done extensive testing, but I believe the low explosive mass of the submunitions is the cause of the problem. They appear to have good armor pen damage bonus (cumulative_factor of 10) but the thickness of only 0.25 I believe means they do very little damage on anything with moderate armor. To complicate things further, the way armor is modeled in DCS is some really confusing code that appears to compare the incident angle of the projectile to the center of the object being hit, then applying an armor value based on that angle. Here's the relevant generic schemes from the code for example: -- armour scheme unarmed_hull_elevation = { {-90, 90, 1 }, } unarmed_hull_azimuth = { {0, 180, 1 }, } unarmed_turret_elevation = { {-90, 90, 1 }, } unarmed_turret_azimuth = { {0, 180, 1 }, } unarmed_armour_scheme = { hull_elevation = unarmed_hull_elevation, hull_azimuth = unarmed_hull_azimuth, turret_elevation = unarmed_turret_elevation, turret_azimuth = unarmed_turret_azimuth }; tank_hull_elevation = { {-90, -45, 0.1}, {-45,11,1}, {11,19,2.9}, {19,40,1}, {40,90,0.15}, } tank_hull_azimuth = { {0,10,2.9}, {10,30,1}, {30,150,0.67}, {150,180,0.20}, } tank_turret_elevation = { {-90,18,2.9}, {18,90,1}, } tank_turret_azimuth = { {0,10,2.9}, {10,30,1}, {30,150,0.67}, {150,180,0.25}, } tank_armour_scheme = { hull_elevation = tank_hull_elevation, hull_azimuth = tank_hull_azimuth, turret_elevation = tank_turret_elevation, turret_azimuth = tank_turret_azimuth }; IFV_hull_elevation = { {-90, 30, 1 }, { 30, 90, 0.6 }, } IFV_hull_azimuth = { {0, 30, 1 }, { 30, 150, 0.6 }, { 150,180, 0.5 }, } IFV_turret_elevation = { {-90,18, 1 }, { 18,90, 0.5 }, } IFV_turret_azimuth = { {0,180, 1 }, } IFV_armour_scheme = { hull_elevation = IFV_hull_elevation, hull_azimuth = IFV_hull_azimuth, turret_elevation = IFV_turret_elevation, turret_azimuth = IFV_turret_azimuth }; T55_hull_elevation = { {-90, -45, 0.2 }, {-45, 30, 0.8 }, { 30, 90, 0.4 }, } T55_hull_azimuth = { {0, 30, 1.2 }, { 30, 150, 1 }, { 150,180, 0.56 }, } T55_turret_elevation = { {-90,23, 1.0}, { 23,90, 0.2 }, } T55_turret_azimuth = { {0,30,2.0}, {30,150,1.6}, {150,180,0.65}, } T55_armour_scheme = { hull_elevation = T55_hull_elevation, hull_azimuth = T55_hull_azimuth, turret_elevation = T55_turret_elevation, turret_azimuth = T55_turret_azimuth }; So from reading this, my take would be that anything using an armor scheme (if the unit doesn't have an armor scheme defined, it uses a flat "armour_thickness" Value), should be penetrated by the mk-118 since they should only be hitting from above. For instance, a HMMWV has thickness 0.005, whereas BMP1 is 0.2, leopard is 0.125, T-72 has 0.1 BUT each one has a different HP value as well: HMMWV: 1.5, BMP: 4, Leopard: 32, T-72: 25 Now, I don't know exactly how explosive mass and HP correlate, but I do know i've seen T-72's shrug off a MK20, while trucks and such get deleted by it. I think we can reasonably assume the explosive mass is close to a 1:1 correlation with HP damage (assuming a penetration), so it might require upwards of 100 submunition hits to kill a T-72 for instance, or 320+ for the Leopard (Granted, you can start a vehicle burning without totally removing all the HP and it will die, but that's another discussion) Given the dispersion pattern of the MK-118's, probably about ~60% of them don't end up hitting a target, which is why I think we don't usually see them killing vehicles (especially higher HP/armor ones) well. tl;dr: MK-20 is accurately modeled down to the submunition, unit HP/armor causes issues, since the MK-118s don't do enough damage.

I'm not sure I understand what part jester has to play in your AIM-7 shots. He can't make the missile or the radar better, and you're usually firing those missiles from well within ranges where you should be taking the radar and locking it with PAL instead of letting a RIO, human or otherwise, attempt to do it.

So that's what that option does. I don't think I ever saw it documented anywhere what the "spot" command was in the jester wheel.

Try putting a deadzone on your TGP slew axes. We had a member in our group have this exact same problem, and it wound up being that even the tiniest bit of TGP slew input would block point/area track from working. Even an amount so small it wasn't noticeable.

So does that mean that you can have aerodynamic changes without a visual change? This might explain why I've had damaged planes that would barely fly (large loss of lift or more drag, couldn't really tell) that looked more or less fine (just the usual bullet holes texture on the nose/fuselage). It felt weird landing a clean jet with only a few thousand pounds of gas at nearly full throttle, along with not using airbrakes/DLC because the plane wouldn't stay airborne.

Bug: Pilot's HSD Brightness knob sensitivity is set too high, giving it only 10 potential brightness settings Can I reproduce it 100%: yes If not 100%, how often out of 10: N/A How to reproduce/ description: Step1: Place cursor on brightness knob Step2: Using scroll wheel, spin knob Result: Brightness changes drastically for every click of the mouse scrollwheel. DCS Version: OpenBeta 2.5.6.55960 System Specs: CPU Intel i7 7700k GPU EVGA 1080 GTX FTW 32GB RAM SSD Samsung 860 EVO M.2 OS: Win10 Peripherals: Joystick: Virpil TM Base/ TM Warthog Grip Throttle: TM Warthog Pedals: MFG Crosswind Others: Headtracker: VR Headset HP Reverb G1 Mission File: Any Mods: I do not use any mods. Solution: Editing the red text below in the "clickabledata.lua" file located at: "Mods/aircraft/F14/Cockpit" to a lower number (I like 0.05) fixes this issue. -- HSD elements["PNT_1039"] = default_axis(_("HSD Selected Heading"), devices.HSD, device_commands.HSD_Knob_Heading, cockpit_args.HSD_Knob_Heading, 0, 0.0194, false, true) elements["PNT_1040"] = default_axis(_("HSD Selected Course"), devices.HSD, device_commands.HSD_Knob_Course, cockpit_args.HSD_Knob_Course, 0, 0.0194, false, true) --elements["PNT_1040"] = default_axis_old(_("HSD Selected Course"), devices.HSD, device_commands.HSD_Knob_Course, cockpit_args.HSD_Knob_Course, 0, 0.05818, true, false, true) elements["PNT_1043"] = default_axis(_("HSD Brightness"), devices.HSD, device_commands.HSD_Knob_Brightness, cockpit_args.HSD_Knob_Brightness, 0, [b][color=#ff0000]0.1[/color][/b], false, false) elements["PNT_1041"] = default_button(_("HSD Test"), devices.HSD, device_commands.HSD_Btn_Test, cockpit_args.HSD_Test)

Bumping this for visibility. The F-14 HSD brightness knob is still oversensitive and can only be adjusted to like, 12 brightness settings.

You should be using the TID repeat option if you're using VR so it shows the weapon type on the TID when the pilot has HUD set to A/G

Hey, with one of the recent patches the HSD brightness knob sensitivity was cranked to 11, making it very difficult to get a good brightness level on the screen when flying at night with NVGs. I think a decimal or a zero got misplaced and lead to the knob being extremely sensitive compared to the other brightness/contrast knobs. It's only really an issue since flying in VR you can't "look under" the NVGs.

On the real Tomcat the launch bar is operated by the ground crew. In the sim it comes up/down with the nose strut kneeling as a workaround.