Whisper

Stumbled on this one, not sure how long it exists, at least true on latest version 2.5.3.24436 When using coalition.addStaticObject, and then using :getID() on this object, instead of having an integer returned, the result is a string containing the static name :getID() on static placed in ME returns an integer, as expected. Repro mission attached. Launch mission, drop on Game Master slot, wait 5 seconds, a second Warehouse appears west of the first one, with a marker on it. The marker contains the result of a :getID() on the newly spawned Warehouse, and it's a string addStatic-bug.miz

Best module in the DCS World. Can't get enough of her

The sole and only problem is the difference in max zoom level between flat screen and VR. I don't see why we VR users must be so restricted? There's an addon on "that other sim" (which has natively the same illogical limitation) that permits to go to better max zoom levels. There must be some kind of limitation (artefacts are visible when using aformentioned addon, but if that's the reason for putting a limit, I'm not ok with that) to VR, but a proper zoom level is a game changer and eliminates all difference between screen and VR users.

For an engine that offers transport helictopter simulation at such a detailed level, that's a pretty fundamental thing to have working flawlessly, if you ask me, and if I'm being honest, troop transport has been broken for a veeeery long time in ME, up to the point nearly everybody is using scripted workarounds (which cannot simulate transported weight, unfortunately) ED can thank Ciribob for saving transport helicopters job in DCS. So imho this is an absolutely critical feature to fix, but which is not seen as important by ED, if I judge by the state of it for months if not years...

Errrr... What is your definition of "organic flight model" and "magic numbers" ? Because it seems the only thing you seek is to prove that there are "magic numbers" in current Mig21 FM, and it's not an "organic FM", and that would be a bad thing. AFAIK there is no magic "organic" FM possible on our current PC hardware that would simulate plane physics up to every flight envelop, there are "Magic Numbers" everywhere, in every FM, including ED PFM even though they push it as close to real as possible The Mig21 FM is a EFM, ie, an AFM (with simulation/API not as advanced as ED's PFM) with added external calculations & simulations from third parties. Of course you will get "Magic Numbers" in there. The question is how much impact it has. And the only FM impact I see listed up to now is a weird behavior during stall. If these "magic numbers" were as bad as depicted, we would see other strange behaviors in other portions of the flight, that would make us fly wrong , during take off, combat maneuvers, etc... The very fact we see a rather scripted behavior is not what indicates a broken model, it's rather normal, in fact. How far away this scripted behavior is from what I'm supposed to do as a virtual pilot, that is what is important to me. Hence why, as long as the only real impact on my flying is seeing a 2G load during stalls, I won't see the Mig21 FM as broken. If this 2G makes the stall handling by us pilot completely unreal, then yes things are more worriesome, but even that is not what I'm told is the issue....

Since when is stalling in any take-off, navigation, combat or landing procedure? Never So in practice stall is something you actively avoid and you should spend zero percent of your flight time in it. It's definitely an exception. So for exception cases, Mig21 exhibit a wrong 2G load. How is that going to impact 1) my day to day flying (I can easily answer this one : basically never), 2) impact how I get out of this exceptional condition (there, it may impact, but again, the only thing pointed out is this 2G factor, not how it negatively impact the normal procedure. Does it prohibit normal stall exit, for example? ) ? Calling a FM broken on this single issue is what I call "way overblown".

"It is abandonware", "it is pre-release", "it is looney tune physics", "it is hilarious"..... When asked where all the wrongdoings are: "- It pushes 2G when stalling... - And .. ? - that is all, it pushes 2G when stalling". Yet again, another useless out of enveloppe issue being blown out of proportion. Actual impact on gameplay? I fail to see.Who is going to ab-use it, who is going to be unable to fly the Mig21 in a proper way because of this? I fail to see. Would it be nice to see it corrected? SURE, and thank you for bringing the issue up. Is that game/FM breaking? Hardly. Keep things in perspective, please. Or will you explain to me that having 2G in stalls completely prevents the DCS Mig21 to be flown close to real in normal envelop and breaks the plane limitation that must be followed?

Is this issue identified as real, or is there need for more information? We still have loads of crashes. Would be good if we could know what we can do to correct, or if it's something identified as "to be worked on" ...

I'm trying to have my buddies go past the "I'm mad" phase and come back with details. What I can say so far from yesterday's debugging : * HOTAS Warthog used by user * For Ka50 module, there is no more any key bound to any function in the keyboard section. I've ask for the rest of the details (presence of .diff.lua files in Saved Games, status of joystick bindings, etc...)

Doesn't compute.....

Thank you! I'll forward that to buddies

It happens to products like Ka50 or Su25T which are nowhere near Early Access anymore, so I don't even understand how the Early Access argument can be brought up.... This has NOTHING to do with EA state of F18

ED have really messed it up this time, though.after trying to help a buddy on this issue (at first I was like you, "don't worry, it's easy to correct") I dont see currently a way to get saved bindings back. They really screwed it up. Im gonna wait before patching myself, in case ED comes up with a fix. Would be great of to first deign acknowledge it.

Same issue latest version

A huge bunch of new awesome features, thanks for all the work

In which case Stable wouldn't have been updated since March

@anyone : Here is a good opportunity to make good money out of pure lazyness (to keep it civil) :) A T50 half the price, take it!! @thonnie : good luck with VKB. I've heard their software is top notch straightforward noob friendly, you should be home there. I'm eagerly awaiting your next message on VKB parts of the forum...

Better be fast :) @Virpil : Like others, I find it strange that T50 is being discontinued without a suitable replacement, knowing that WarBRD is targeted for desktop use and the T50 was aimed for extensions. Is WarBRD finally a correct product for usage with extension, is there any limitation that was absent from T50 (limited length, or... )

Not really what I heard, but meh, easier to separate "good guys" vs "bad guys", I guess ... As for the behavior described above : like many reported, I don't see it behave that way at all. Accelerates well, retains speed at up to 15° AoA, which gives a nice non-10km turn radius.... As well, I tried to reproduce the behavior indicated in a Mantis bug linked above, couldn't, or I misunderstood the issue... Development / Fixes on Mig21 is very slow indeed, but going hyperbolistic and sometimes plain untrue in bug reporting or issue description is certainly not going to speed up things.

The gaz FM is not on par with the rest, we kinda all know it. Too much on rails . Unfortunately, months of hyperbolic whines and out of scope FM issue pointing (who cares about behavior in reverse? I care about normal behavior flight envelop first, and this light/on rail reactions) just killed any discussion on these boards , hence the reactions to your post. It was a crusade to show how superior the Huey FM was (all the while, the Huey still had zero engine torque limitations which allowed him to have completely unrealistic normal flight envelop behavior, but who cared?). We kinda fear these days to be back (well, I do :) ), and I've come to peace with the gaz FM. She has other things to enjoy, other DCS rotaries do not. I suspect Poly have kind of a limited access to FM tweaking compared to ED. Strange that no other studio is taking on chopper models...

perhaps verify that you don't also have an axis assigned to copilot stick, in assign axis page

Which control are you using to move the camera? keys, joystick? It seems you have a permanent upward input. I don't get this behavior

Your stick has a big impact on the plane behavior, and this is not isolated to Mig21, Spitfire and Gazelle also have some extreme sensibility to certain axis, which disappear with sticks closer to the real thing, due to extension. I recently changed to an extended T50, and you don't feel anything too sensible in the 21 with it. 95 saturation is not much. Try 80 or 70 even. And the Y saturation has to be set, not the X. I was using extreme saturation levels with my X55 for the spitfire, for example.

It doesn't wipe all you have done, some actions in the Virpil software trigger a USB renumbering which means DCS sees your Stick as a new device. The old device configuration files are still there. You can reuse them by renaming the configuration files for the "old" T50 ID to the new T50 ID, and you're done. Make backup before renaming, an error (like renaming new to old instead of the opposite, which will effectively erase all your previous work.... ) can quickly be made.