Redglyph

DCS 2.0.4.59428.142 Control box UPK 23-250-2 not present, whether parking hot or ramp start. Does not appear when added in hot re-arming either. This control box simply isn't available in the current version, and so the pods cannot be used.

Also seems to happen when I try to have an aircraft start from ramp or parking hot, from Groom Lake, which is apparently impossible in 2.0.4. The ME puts the aircraft at TTR, I try to move it to GRL (which fails) and after that, the ME gets in this broken state. Should be pretty easy to reproduce.

Glad it helped :)

I'm getting the hang of it, this time it took 5 minutes. Included are the two dummy missions I used for this. I should try to retrace my steps, but they were as follows: - launch DCS 2.0.4 - open Mig21.test.miz - zoom / unzoom and move the map - create a new group of 3 F-177A at the North of TTR - save the mission file - save the mission file as Mig21.test.2.miz - trying to edit the TF-51D on parking D13 => couldn't (clicking on it does not select the aircraft) - trying to exit => couldn't (opens the pop-up saying to save, clicked yes, no effect) Hope it helps :) EDIT: it's funny, no mention of the Mig21.test.2.miz in the log. Has this something to do with the "save as" feature? ME_crash.zip

Actually, I just had this after 10-15 minutes of editing basic mission files (still in 2.0.4), with a fresh DCS start. I'm never entirely sure the files are saved correctly when it happens, I think so but it's certainly not reassuring. Yes, I've somehow created this in the wrong forum, sorry.

DCS 2.0.4.59428.142 After editing a mission for a while in the mission editor, it is not possible to exit, I have to kill DCS. It can save the mission, and if I just saved the mission and click on exit, it gives a warning pop-up saying the mission should be saved or data may be lost. Choosing to save or not leads to the same result, the ME doesn't close and there is no way to exit. It happens everytime I use the ME for some time, even if that's just one mission. When it is still possible to exit after a while, there is often a black screen. Sometimes it's just the matter of waiting for something (garbage collection? Freeing virtual memory? Something else? No idea), sometimes it just doesn't recover and DCS has to be killed. Perhaps both are linked, and there are massive memory leaks, though I'm not sure why it would disable menu features. Using it only for a short while is fine.

Or try the other work-around if you have 2.0 installed.

Try the work-around in post 17. No fix yet, many missions in DCS are suffering from this bug.

I suppose it's a no then :no_sad: ;)

Yes, they are, you can see an exemple in . It's very well done, and there are complements of information in the campaign, some more advanced stuff. Plus, it's a great aircraft, I recommend! :)

Or this link. But here SierraFox says the score is 0, with the progression problem I think the score was fine. Well, actually it's the result that dictates the outcome, not the score (in mission 1 I suppose it should be null), what's its value?

I have to agree with Baltic, a hold would make that so much easier, safer and cleaner, instead of having to deal with dirty tricks that don't always work or render the situation very improbable - why a truck or a jeep would be there anyway? ;) Trying to write a few missions, I lost quite a lot of time because generally the AI aircraft would just ram the vehicle. You have to place them just right, and hope it'll survive updates. There aren't much obviously missing features in the scripting area, but it's frustrating not to have them, and this has probably an impact on DLC, both in quantity and quality.

DCS 2.0.4.59428.142 / release 1.5.5.60565.216 In the file R_NAV_data_Nevada.lua, the location of the BTY beacon is incorrect, which makes it unusable. Fixed file in attachment. { airbase = 'BEATTY', --15 lat = [b][color="Red"]38.80056[/color][/b], long = 116.74750 * long_modifier, alt = 890, rwy = -1, length = -1, code = '-... - -.-- ' --/N/ BTY_ }, should be { airbase = 'BEATTY', --15 lat = [b][color="SeaGreen"]36.80056[/color][/b], long = 116.74750 * long_modifier, alt = 890, rwy = -1, length = -1, code = '-... - -.-- ' --/N/ BTY_ }, R_NAV_data_Nevada.lua

Yeah, it's getting to the point I'm drawing pentagrams and performing a little dance while throwing salt behind my shoulder before starting a mission ;) Hope they find out what it is.

That's pretty weird, it should have the opposite effect, make sure you have the latest version of BIOS.

Yes, the last time I had this problem I could only quit DCS to make it disappear, restarting the mission wasn't enough.

DCS 1.5.5.60565.216 Steps to reproduce: - launch DCS - click on the settings icon (so from the main page, not in a mission) - click on CONTROLS - select M-2000C - click on Axis Assign - change settings (for my part, I clear the pitch / roll / thrust from the rudder pedal settings, I don't think it makes much sense) - click on OK => black screen, DCS does not respond, has to be killed. dcs.log in attachment, has the following relevant error message: I have tried a few others, but it is only happening for this aircraft, it is 100% repeatable. I see no other work-around than - setting up the controls in 2.0.4 (2.0.4.59428.142), and copying the file in 1.5.5, - starting any mission to set up the axes. Once the file exists, the crash does not occur anymore, otherwise all attemps I've made to create this file by changing anything from the main settings produces the crash. Or perhaps copying the so-called "default configuration" file, if one doesn't have the 2.0.4, I haven't tried. dcs.log.txt

I don't think they had the time to really look into it, it appeared at some point in mid-/end-December I believe, and there was a lot of things for them to do. The work-around is not too hard, so that shouldn't stop you from going on with the campaign (I suppose you meant the A-10C, not the F-86, unless it's a surprise in a later mission). I had some funny times with mission 8, because it seems I had to apply both tricks of - running the mission a 2nd time - waiting a while before contacting the ATC to start-up. so you can try a mix of that for those missions, or the other tricks mentioned elsewhere, even if it's not a 100% success rate. :)

Hello, DCS version 1.5.5.60565.216 I'm not entirely sure it's a bug, or a missing feature, probably a mix of both. In DCS you can set default controls, for example to set the rudder pedals so they are not automatically configured to change the pitch, roll and thrust, which would make no sense. If I do that for a new device or a new DCS installation, the correct Config\Input\Default\joystick\<device cfg> file is created. It does not exist yet for the individual modules, for example the P-51D has no such file yet. When I configure the P-51D, it does not seem to use the default configuration as starting point, instead it maps by default the pitch, roll and thrust axes to some imaginary analogue axes of the rudder pedal device, and creates a new Config\Input\P-51D\joystick\<device cfg> file from scratch. Which happens to be the default configuration for this device before it was modified by the user. So the problems are - the default configuration seems to be ignored, at least regarding the axes, - the user has to configure individually each aircraft when a device changes, - the user has to remove all the "nonsense" configurations for a new module (or if the update makes it mandatory to start with a new configuration because of incompatibilities). I realize not all aircraft have the same controls, for instance the Spitfire only has one brake axis, the A-10C has two, and so on. But at least we would be able to remove all the nonsense axis mappings for a new device, or for any new module. If names or IDs are identical, the settings could also be copied. In the current situation, the user is spending a lot of time clearing all the axis mappings for the joystick, the rudder pedal, the throttle, which could be avoided. :) I cannot test the key mappings for now, so I cannot tell if the same problem/missing feature is true for these settings.

Heh, my only kills with those M2K were "head shots" on the 1st merge. Definitely not a good habit (*) :D I'll have to try flat scissors, thanks for the tip! (*) meaning, what was the last thing that went through his head before dying? me and my F-5...

Thanks a lot!

I think he means the temporary updates in the first post :) You'll find the original Campaign directory under this directory, just unzip the downloaded ones and replace the originals with their new version until the next DCS patch is up. Perhaps today, who knows. <DCS>\Mods\aircraft\M-2000C\Missions\ where <DCS> is your installation directory.

Not losing too much energy there is the main difficulty with the F-5, as the M2K will quickly disappear, I try to lure him close to the deck and slow down to make him overshoot, though usually I don't have enough time to get the nose up and catch him before he's gone. And if I'm faster he has no trouble placing himself in my six. Perhaps trying the same with some buffer to the hard deck would help to regain energy more quickly. The Mig-21 shouldn't be too easy either.

There's a hints and tips thread here with some references: https://forums.eagle.ru/showthread.php?t=180110

I'm trying to create a little tutorial mission, and I'm looking for two features that I think are not available, but I'd rather ask to be sure. 1) Is it possible at all to interact with the cockpit from a lua script? I'd like the highlight to appear after a while if the user hasn't clicked the correct button in the cockpit. My main motivation here is to save a lot of redundant triggers with flags, delays and so on, by having a simple lua function to do that (list of elements in a parameter, check for their values, and illuminate after a while if not correct). Seems a bit hopeless from what I found so far, but it would be such a basic feature and so useful to have :) 2) Is there any other way to have persistent data than removing the sanitizing in MissionScripting? Here for example I'd like to keep a record of what went well / wrong, with a score, and retrieve that in a later mission. And if possible, without asking the user to modify this file and thus introducing a security risk. Allowing to read/write files in a fixed, dedicated directory only would do, since I suppose serializing that in the logbook would be a terrible way to do that. Or is there another way that wouldn't require the user to modify things?