Cpt.Rookie

Just a wild guess

Tried to play with mission editor for a while and here are the results: All the options from mission editor are written into mission file (e.g. XXX.miz\mission). But settings for plane's auto rudder and t/o assistance are in options (XXX.miz\options). (Un)setting any mission option has therefore no influence on values in options file (to be honest, I was thinking about game mode as possible culprit too). Values in option file are taken from mission creator's DCS settings. So the only thing needed is to turn off auto-rudder and t/o assistant, open the mission in mission editor and save it. This will propagate the values from user settings into mission settings. This, of course, should be performed on ED side, because if user will re-save them on his own, they will be overwritten during next repair / update. But, as mentioned earlier, despite the fact that I was able to reproduce this in some of the previous version, it seems to be fixed in most recent one. I've exchanged few messages with OP (CHDT) and it really seems to be fixed for him as well, i.e. these mission options are now simply ignored / overridden by user's settings. But let's wait for the CHDT's confirmation here. Edit: I tried game mode as well and yes, it makes the plane to go straight, but w/o any noticeable rudder movement. And I remember that when testing this few weeks ago, I saw that rudder was moving on its own in order to compensate all the forces.

What options exactly do you have in mind? I haven't found any way how to edit these exact options (auto rudder and t/o assistance) in Mission Editor.

OP already tried that, it didn't help: Anyway, few weeks ago I tried to reproduce this and I can confirm that I was having same issues in P51's quick start missions, i.e. aircraft was behaving like with auto rudder and/or assistance on. By looking into file (e.g.) Mods\aircraft\P-51D\Missions\EN\QuickStart\P-51D Take Off Batumi.miz\options, there is indeed ["P-51D"] = { ["assistance"] = 0, ["autoRudder"] = true, }, -- end of ["P-51D"] When looking into other MIZ files, it is kind of mess; sometimes rudder is on and assistance at 100, sometimes the opposite. As far as I can see, these settings cannot be altered via mission editor, but have to be edited /deleted manually. I think that after I changed these options in MIZ file (in previous version), the plane started behaving normally. However, when trying with most current version (1.5.3), DCS seems to be ignoring these settings in MIZ file completely and I'm not able to reproduce the original issue anymore. Which really baffles me. @CHDT, would it be possible for you to try to edit these settings in MIZ files and let us know the result? (given that inconclusive results I'm getting now I really don't believe it will work, but let's give it a shot)

It needs some time (minutes) to warm up. Just turn it on, stay on the ground and you will hear the alarm soon.

If you will record the track, please post it also to the thread with this bug reported (mentioned in my post above), so it will hopefully get some attention.

It is a bug and it is already reported. At least on forum - http://forums.eagle.ru/showthread.php?t=148733. I'm not sure if anyone from ED QA/dev team knows about it.

%homepath%\Saved Games\DCS\Config\options.lua (e.g. c:\Users\CHDT\Saved Games\DCS\options.lua) For 2.0 it would be in DCS.openalpha ["P-51D"] = { ["CPLocalList"] = "default", ["assistance"] = 0, ["autoRudder"] = false,

I did that and I'm getting following error message in dcs.log: 00000.007 ERROR Lua::Config: load error Config/main.cfg:[string "C:\Users\johny\Saved Games\DCS.openbeta\Config/autoexec.cfg"]:1: attempt to index global 'net' (a nil value). When I remove "net.", i.e. download_speed = 256*1024 upload_speed = 128*1024 then the error message is gone, however it is question whether these settings are applied. Any hints?

Works just fine for me in 1.5 Push the pedals --> Pull Parking brake --> Release pedals --> Release Parking brake --> Parking brake activated.

Well, not entirely. Separate thread is http://forums.eagle.ru/showthread.php?t=136310 Then there were some discussion - http://forums.eagle.ru/showpost.php?p=2465355&postcount=13 as reaction to changelog posted for 1.5 I have to say that (for me!) the final result we have in 1.5 OB is disappointing. Simply because of breaking "backward compatibility". I can clearly imagine that having separate keys for every function AND need of adding toggles could really quickly lead to situation when there are no more easily reachable keys available, but this cannot convince me that this was the step in right direction.

As far as I know, there is data export is enabled (or at least was - few month ago) on ACG server, so using tools like TacView, may give you some clues about what happened. Another thing - you (and other players on the server at that time) have the mission recorded. What about using it (with external views enabled) to find out what really happened? I would say that although accusing someone of cheating is always the easiest way how to explain certain events, it *should* be in fact taken as the last possibility - after all others are ruled out. Other guys presented some possible explanations, which are definitely worth considering.

Do you have the modpack (http://www.9jg27.com/mod-pack) installed? Without it, you will always get this message. And you will of course need to uninstall it before joining other servers that have integrity checks enabled, so it is better to use JSGME.

I did few tests and I can confirm that it seems that letting the RPM drop under 1500 (inflight) for some time causes that ammeter is later showing incorrect value after RPMs are again high enough to start generator working (>1500 RPM). However, battery is definitely re-charging once RPMs are high enough. I turned on all the power-draining systems (position lights, landing light, gun heating, pitot heating, radio), disconnected the generator and waited several minutes until battery was drained (green gear light is quite nice indicator of battery level as it becomes more dim if the electricity is being taken from the battery) and then re-connected it. After tens of minutes, battery was charged again. It is question whether rate of charge is somehow affected by this (i.e. whether it is too low), but I don't have any info about how much time it takes battery to be fully charged. So even if there is probably something fishy between generator, ammeter and battery, it doesn't seem to have any significant effect. Ad your question about the initial ammeter values - I was watching some of your tracks and while not sure about lights and radio, you're definitely not turning on pitot and gun heaters. These two systems are eating quite a lot of power (just watch the ammeter jump when turning them on). So if you turn on all the systems mentioned above, the initial value should be somewhat close to 50 A.

Sorry for reviving an old thread, but is there any reason why this shouldn't acknowledged as proper bug, moved to bugs sub-forum and eventually fixed? Steps with modification of comm.lua are working just fine, but it is still just a workaround and there are apparently some missions that are offering MIG pilots the AWACS service, alas, they're unable to use it without having comm.lua modded.