virgo47

I believe, the file structure did not change, although for some planes this requires more Lua, especially for two-seaters. A few examples from my Config/View/Server.lua. In all the cases I mostly only modify limits_6DOF, but for your needs, did you try to change CameraAngleLimits and *Restrictions (not sure what the difference is)? A simple example for F-5: ----------------------------------------------------------------------------------- -- Custom view settings overriding defaults from other planes -- Axis mapping minus-to-plus: x - back-to-front, y - down-to-up, z - left-to-right ViewSettings["F-5E-3"] = { Cockpit = { [1] = {-- player slot 1 CameraViewAngleLimits = {20.000000,140.000000}, CockpitLocalPoint = {3.022,0.860,0.0}, CameraAngleRestriction = {false,90.000000,0.500000}, CameraAngleLimits = {200,-90.000000,90.000000}, EyePoint = {0.05000,0.100000,0.000000}, ShoulderSize = 0.25, Allow360rotation = false, limits_6DOF = {x = {-0.05,0.21},y ={-0.10,0.08},z = {-0.19,0.19},roll = 90.000000}, }, }, -- Cockpit Chase = { LocalPoint = {-5.0,1.0,3.0}, AnglesDefault = {0.000000,0.000000}, }, -- Chase Arcade = { LocalPoint = {-21.500000,5.618000,0.000000}, AnglesDefault = {0.000000,-8.000000}, }, -- Arcade } This is how you set multiple types the same way: -- This is how to reuse one setting for multiple plane sub-types: local viewSettingsMustang = { Cockpit = { [1] = {-- player slot 1 CockpitLocalPoint = {-1.500000,0.618000,0.000000}, CameraViewAngleLimits = {20.000000,120.000000}, CameraAngleRestriction = {false,90.000000,0.500000}, CameraAngleLimits = {200,-90.000000,90.000000}, EyePoint = {0.025000,0.100000,0.000000}, ShoulderSize = 0.15, Allow360rotation = false, limits_6DOF = {x = {-0.050000,0.500000},y ={-0.230000,0.230000},z = {-0.250000,0.250000},roll = 90.000000}, }, }, -- Cockpit Chase = { LocalPoint = {0.200000,-0.652000,-0.650000}, AnglesDefault = {0.000000,0.000000}, }, -- Chase Arcade = { LocalPoint = {-21.500000,5.618000,0.000000}, AnglesDefault = {0.000000,-8.000000}, }, -- Arcade } ViewSettings["TF-51D"] = viewSettingsMustang ViewSettings["P-51D"] = viewSettingsMustang ViewSettings["P-51D-30-NA"] = viewSettingsMustang And this is how it can get complicated with a two-seater - but the original C-101 config was even more complicated, but I inlined some stuff: -- Mods\aircraft\C-101\Views.lua is more complicated, so some calculations are repeated here local function playerC101(x,y) return { CockpitLocalPoint = {x,y,0.0}, CameraViewAngleLimits = {20.000000,140.000000}, CameraAngleRestriction = {false,90.000000,0.500000}, CameraAngleLimits = {200,-90.000000,90.000000}, EyePoint = {0.05000,0.100000,0.000000}, ShoulderSize = 0.25, Allow360rotation = false, limits_6DOF = {x = {-0.05, 0.3}, y = {-0.3, 0.1}, z = {-0.23, 0.23}, roll = 90.000000}, } end local viewSettingsC101 = { Cockpit = { playerC101(3.326,0.526),--front cockpit playerC101(1.74,0.841),--rear cockpit }, Chase = { LocalPoint = {-5.0,1.0,3.0}, AnglesDefault = {0.000000,0.000000}, }, Arcade = { LocalPoint = {-21.500000,5.618000,0.000000}, AnglesDefault = {0.000000,-8.000000}, }, } ViewSettings["C-101CC"] = viewSettingsC101 ViewSettings["C-101EB"] = viewSettingsC101 From my experience, the limits_6DOF don't transfer (or at least not completely) to the movement freedom of the TrackIR itself, but allow to move the center more around, from which the TrackIR movement starts. It also helps with creating SnapViews that would not be possible by default.

Same here today... I don't understand why "Favorites Only" doesn't try the favourite servers first. I can use Connect by IP, but only to a single server (I guess the last one), instead of choosing from my favourites. Now the list loading doesn't allow me to do anything. Is the problem on my end? Perhaps - or perhaps somewhere in between (more likely)... but even if the problem is not on ED's end, the design is lacking, especially when I want to focus on my favorite servers only. BTW: This may be connected to much longer authorization I've been encountering the last day or two, but I don't know.

As a beginner, here and there I suffer a tailstrike and I always end up with no power pedal authority. I decided to investigate what happened and created this demo (TRK file is also attached): It seems that: Tail skid has no function at all, doesn't even change/bend after the tail strike. Tail body dives under the surface without any problem and damage. However, the tail rotor is "trimmed" (0:16 in the video) - which results in the loss of left pedal effect, the helo is naturally unplayable with such a small tail rotor. The part with the tail rotor is related to the general loss of damage reporting for helos: But the physics of the tailstrike is still suspicious. How can the tail dive all the way to trim the tail rotor? Either bare the strike or break the tail or something, depending on the force, of course. uh-1h-tailstrike.trk

Please, introduce TrackIR Enable/Disable toggle to the global UI Layer - with the same function as the toggle in Controls, click on the triangle in the TrackIR column header, Disabled. Reason: With the TrackIR active there is no quick way to toggle it to get "traditional" non-TrackIR camera rotation without all these clicks in the Options/Controls. With TrackIR program running, this gets detected and enabled (which is good), but if for whatever reason I want to stop tracking, I can only do so in the TrackIR program - but this does not enable the non-trackIR camera rotation until I manually disable TrackIR in DCS. After this, it stays disabled even if I start DCS with TrackIR program active. I have to re-enable it manually. Simple binding for this toggle would be very practical - because enable/disable on DCS side has additional benefits, it doesn't just "freeze" the view, it also enables all the View * (slow) bindings and mouse look as well. Currently, it is possible, but it requires many clicks through Options, has a lasting effect for another start of the game, and is generally impractical/slow.

Today I tried to shoot the ground - and while the FPS went down, it wasn't THAT bad (still above 10 with my config), and - the most important thing - the game DID NOT STOP/CRASH! Can anyone confirm this improvement? I can't pinpoint it in any changelog, but I like what I'm seeing.

I can't pinpoint anything in the changelog, but for me, the game crashed with a lot of dust/smoke/shooting into ground/explosions - after the FPS dropped to sub-10 numbers. But with the latest patch it seems manageable. FPS still go down, but not under 10 - and the best thing is - no crash. Anyone else experiences this improvement?

I considered both M2000 and Harrier, interesting modules, and both were quite approved lately (except for very recently). Now I'm sad about this whole situation that I watch (on and off) quite impatiently. And unless I forgot, this is likely my first post about it (useless as most others in this thread anyway). I postponed any buying until the resolution. And I'm concerned quite seriously. The silence is deafening. While just a speculation, right or wrong, if ED somehow disrupted the potentially fragile cash flow of RAZBAM, it could have had a devastating effect. If that's what happened then RAZBAM, drama queen or not, had little chance. Sadly, that's the most probable thing I came up with... and we will perhaps know more in... months? That sucks.

I'm following the weapon training for UH-1H and I got stuck on "Press the M key...to turn on the aiming sight." There was no indication that I should change the spot and flexible sight should be used - nor I believe it was intended. But that's what the mission checks - the copilot's flexible sight: It's pretty easy and fast to get to that point (with some "time zoom") so I don't attach a track or video.

I was confused why some VORs don't transmit their callsign - they are simply silent all the time. I investigated and the conclusion is: Pure VORs (BEACON_TYPE_VOR) transmit just fine. VOR/DME stations (BEACON_TYPE_VOR_DME) do not transmit the code. I checked this with UH-1H both VHF AM and NAV-COMM radios and also with C-101EB with its VOR radio. I could clearly hear the signal from various VORs, but never from VOR DMEs. For example, sitting at Mezzeh (Syria), Damaskus 116 MHz VOR is totally silent (navigation still works). I checked the same on Persion Gulf map and found the same. Video demonstration: My position: Mezzeh 113.90 MHz is Baysur VOR (no DME), close to Beirut, 70 km away with mountains in between, code BAR - clearly audible. 116.00 MHz is Damaskus VOR/DME station, 25 km away more or less plain, code DAM, never received.

This one seems to be tricky. I extended the numbers in limits_6DOF, but this seems to work only for non head-tracking situation. I can easily move with above the central console with the bindings (when TrackIR is off), but not with the trackIR. I'm still not sure what is happening, but there definitely is a discrepancy between camera movement limits with bindings and TrackIR. I discovered this in UH-1H, but so far I'm not sure about other modules. EDIT: Perhaps the head-tracking range itself is not adjusted (I'm still not sure about it), but the "center" of the head is definitely modified - so you can combine the extended limits, move your camera/head where you want with the camera keybinds, and then additionally move it from there with head tracking. It's interesting to see your headless body this way... but I'd still like to see wider movement with the head-tracking because the head-tracking SW shows that I'm tracked in a wider range, but DCS stops moving within narrower limits.

I'm not sure what was done about it (EDIT: UHF reportedly fixed in 2.8.1.34437), I checked NAV-COMM (aka VOR/ILS), VHF AM, FM and UHF and currently, only VHF AM bindings are reversed. These: All volume bindings seem to be OK.

Naming of the elements for NAV-COMM radio (VHF navigation radio AN/ARN-82) is very confusing. I was absolutely convinced there are no bindings for it, spent some time looking at Quaggle injector setup for it (in vain), looked in Lua files in the UH-1H mod itself and after some device cross-referencing back and forth I found to my amazement that it is all there under VOR/ILS section (that "hides" in plain sight at the bottom of all sections): There is no help in the cockpit itself, because this is what the controls on the obvious VHF AM radio tells you: And this is what the similar NAV-COMM control tells you: There is nothing navigating us to the right section - and vice versa, VOR/ILS - while technically not altogether wrong - doesn't help us with referencing any other keywords "newbie" may use (VHF, NAV, COMM, AN, ARN, 82, nothing). Perhaps at least renaming the section (keep VOR/ILS there, but add at least NAV-COMM or something) would help. In the foldable view it's visible, and in the non-foldable view the category is also shown when searched for. Perhaps I'm the only one who lost nearly two hours to bind this. I don't know...

I like the gates... but for over a year it feels like nobody at ED cares enough about the gates, not even the single-player ones, to fix the scaling of the next gate. I remember vividly how important for my first steps in DCS and Su-25T the gates were - especially the scaling of the next one when player missed it. This is all gone with MT (which should be the go-to) version of DCS. I hope they will eventually fix this because I strongly believe the gates have their use and the functionality should not be abandoned, but indeed, expanded instead. It makes many missions fun and it is a useful tool.

I confirm that it works with 2.9.5.55300. Thanks a lot, guys.

It works with 2.9.5.55300! Thanks a lot!

I was happy to see F5-E, F-86F and MiG-15bis on the list! I didn't expect that (F5-E was announced shortly before the patch). L-39 is high on my bug-fix-wish list - and so is Yak-52. At least trivialities such as toggle bindings working as toggles. But overall, I'm happy to see at least some love for older modules there.

I believe the release dates are somewhat optimistic-realistic. Anything might have gone wrong. Perhaps the testing was progressing but in the end some issue proved harder. It's not like everything is tested two weeks sooner and they are just hovering over the "RELEASE" button. I've seen last minute surprises even in highly automated SW environments. Sometimes even when you didn't touch anything. I'm looking forward to tomorrow... or the day after.

Thanks for the info. DCS-BIOS profiles don't seem to handle neither axis inversion nor default switch positions. (I may be wrong, but there doesn't seem to be any parameter for these.) So for L-39 (and in the future perhaps other modules), patching/amending/extending DCS-BIOS config with PP files seems to be the only way. As for the TP-end for slider inversion, the feature request was acknowledged... but god knows when/if that is implemented. That's just an update from me, no pressure.

Will that be a free tool? I'm a bit confused about the messaging around this... Even as a premium tool - it will still be better than nothing, but that means that except for big fans or people who make money from missions will not benefit from this. Which would leave the current ME in a bit of a sad state.

Yeah, not to mention that perhaps a Shift+misclick shouldn't have such a frustrating effect.

Today I had some problems flying UH-1H after a hard manoeuvre, and while trying to figure out what is wrong, I checked Debriefing log window. No damage, so I tried to recover, believing the ship is fine. But later I saw this: Main rotor gone, no report of damage in the log. Is it OK? I rely on the info there for learning what went wrong, now I know nothing. (Well, in the picture above, I know what went wrong. But in other cases, I don't.)

That sounds reasonable... BTW, do I see it right that this does not affect F2 or other external views, only the view from the cockpit? I tried to find the device around my Albatros in F2 or F4... but I can't turn my head enough to see it in F1. Originally I though this is a very ugly hack, but if it only affects F1 view, then the position under the tail and facing backwards (just as it would in the cockpit) sounds reasonable. I also checked the night - seems good as it is, but the move/turn should not affect it at all. So yeah, I think it would be a better position!

L-39 module has a coarse trim, the action is quite fast, so even a short tick to the trim hat changes it often more than for the perfect position. In any case, without a track file, we can't say more.

That sounds taxing. Of course this is only for "sliderable" things, that is ctr(...). Not sure how that is handled. Currently, there is no sync from cockpit (you mentioned that caused some performance problems too), so it should only be relevant for outgoing changes. But I don't know the architecture and possibilities, so I'm not sure whether this can be optimized. BTW: Wouldn't a separate ictr(...) control type help? This is the tricky one... so far I only worked on some description fixes - this doesn't break anything. I may also suggest those default switch positions we talked about for L-39, that should also be OK - but for now, please leave the PP file "patches" there. But inverting a value - that breaks all existing panels built for UH-1H. Not sure how many people have that. I'll ask how they see it. For what I know the inversion may come all the way from DCS, it wouldn't be the first element that is inverted (wheel brake axes in various planes work opposite for whatever reason). I had also another idea, to suggest this to TP directly. For them it should be reasonably easy to invert the slider and it should also be efficient enough. The question is what's their backlog and when they get to it, of course. So, let's not sweat it on your end right now, unless you find some nice and easy solution , and I'll talk to TP guys first on their Discord. Even if it's not done, one can still create those top-to-bottom "inverted" sliders with a hack (inverting the value/background color) - so it's no show stopper.

Ouch, now I see... I was wondering what kind of direction the shadows represented. Strange "design". A flat 2D representation for popup would be perhaps even better than this... monstrosity. I bet it's also behind those other brightness-related issues.