Redglyph

Is this bug still happening for everyone? I seem to have this problem in 2.0.5. And is LN aware / willing to fix this bug?

You're welcome :D Glad to see it's useful to someone.

Ah, nice :) As long as this doesn't disappear. Thanks a lot for gathering the info there!

I'm trying to use a cockpit argument condition to check the pilot applies the correct engine power during different phases of the flight. Usually the relevant values are RPM1, but it seems they are not straightforward. I've sampled a few values for the cockpit arguments 50 (RPM1 - low) and 670 (RPM2 - high) in DCS 2.0.5.1648.165. The values for RPM2 match pretty well what I see on the gauge, but RPM1 is completely off. Normally, the argument value is the RPM in % divided by 1.1, so arg(0%) is 0.0, and arg(110%) is 1.0, this can be found in the mainpanel_init.lua as usual. The table below shows the RPM gauge values for cockpit argument 50 at 0.2, 0.4, 0.6 and 0.8, then the same for cockpit argument 670. Obviously the green values are pretty close of the % equivalents of 0.2, 0.4, ... but not the red values. Of course I could simply get key values from this weird curve, but I'm not sure it's reliable, really. I have the impression this argument gives a completely different parameter. Am I missing something? :unsure: Also, it's impossible to get the position of the throttle, which doesn't help, but I can make do without, so no big deal.

DCS 1.5.6.1938.247 On the F-86F kneeboard, the TARGET SPEED SWITCH indication shows "HI" when the knob is on TR "LO" when the knob is on HI or LO Tested with the aircraft ready to taxi (engine running, generator on, ...), with gun-missile selector switch on any position.

By the way, what happened to the hoggit wiki? :shocking: Hope it's just a temporary glitch, such a helpful resource :)

I had two cases where I wanted to use that recently. In the first one, I had a test that was a bit too complex to code in trigger conditions. I was using a trigger zone to determine when an aircraft was North/South/East/West of it, for example for a circuit without many zones all around to get the same effect. The test would typically check "is that North of the zone?" and when it's the case, proceed to the next mission step. I replaced that by a continuous action that sets flags to tell whether it's N/S/E/W, but it had the disadvantages I said earlier. In the second test, I needed to test whether an aircraft was parked in any of several spots at TTR. Doing that with zones would just be a nightmare, so I gathered all the coordinates of the spots in a simple Lua list, that I'm checking against the unit's coordinates to return a "yes, it's in one of those", and optionally which one for the action part ("good, you are in spot ..."). Again, I had to split that. Trouble is that this test is a loop over all the spots, and having to run it continuously is a bit of a shame, so I have to guard those dummy continuous actions with yet another flag... it's just a bit messy, where a simple LUA PREDICATE would have been so much easier and cleaner. If course, perhaps it's possible to do it entirely by code, inserting a check in a scheduled task that verifies the condition in Lua, and removes itself when necessary to emulate a ONCE. So there are work-arounds, they're just more complicated. In general, I'm not keen on huge trigger condition lists (especially the OR which is awkward to handle since there is no parenthesis and you have to repeat the conditions), and sometimes it's much easier to express in a LUA PREDICATE. Except when it comes to cockpit or avionics checks, since we can't access them from the API, otherwise it would be another powerful combination. You teach this guy to start an A-10C or a Mig-21bis, for example, and you want to check that he's correctly set-up before doing something serious like starting the engine, taking off, or to make sure he's within the correct enveloppe during the landing phase. Just compare how much effort it takes with either method and you should be convinced :) In Lua I'd just call a function with a list of arguments/value pairs to check, it would verify and highlight or say what is wrong. In the current system, it would require at least one trigger/condition/action set by cockpit element, probably in double to highlight them / mention what parameter has to be taken care off (too low for landing, too slow, too fast, ...). You quickly end up with big drawings on your walls and pulling your hair out :D It's been said that mixing code and "GUI-oriented" design is not optimal ("hidden code"). Sure, it's never perfect, but I believe that if a developer has a method and remains consistent, it should not be a problem. For example the function library can be kept in a file, or in the first "DO SCRIPT" of the mission, and the other triggers only call those functions, keeping them quite simple to read, understand and modify if necessary. The GUI part has enormous advantages like presenting the waypoints, the map, list of aircraft, zones. The visual aspect helps, I don't see myself doing the whole mission in pure code, but that's a personal preference. It's most probably shared by many while the pure code approach is preferred by many others. In most cases it's a winning combination, but I think those 2-3 simple items I mentioned would amplify the possibilities and make it easier. Anyway. That being said, there are great campaigns out there with no Lua script. But I guess there are always people trying to peek and poke in the engine to bring new types of events in the missions, and that's what is great about DCS. Even with non-Lua'ed missions, taking care of the ME (and I've seen very nice and helpful improvements lately, discreete though they might seem), the AI, the infrastructure..., is in favour of a larger and better DLC choice. And I'm convinced aircraft alone don't make a (military) sim, it's great to learn one... for a while, then you want to do something with what you've learned. But that must be hard to sort out relative priorities between that, the graphics and weather, to the terrains, the aircraft, the DLCs, the bugs ... I don't believe mission design is under-valued, I just think the team is stretched thin over all the huge current developments.

Regarding the persistence, it should really be something that does not require the user to modify DCS (specifically, removing the sanitizeModule in MissionScripting.lua). If a developer wants to share missions, those should be independant from the installation; requiring the users to modify files they may not understand, and to do it after each update, is an awkward solution. The functionality is already there, so I don't think making it available in Lua scripts would endanger anything. I've already mentioned one use-case that could greatly benefit from this improved API, yes it's possible to access the positions and highlight indicators, but not from a script. So if you want your tutorial to check a group of switches and show the one that is wrong, you have to write tens of triggers which is a nightmare - I know, I've done it ;) Whereas it would only take a few lines in Lua, would be easier to maintain and extend, and much simpler to port to other missions. The alternative is a separate continuous trigger that sets a flag. It's awkward, impacts the performances, and is more difficult to understand or debug. As for the rest, I'm not sure I understand what you are saying, actually :D Anyway, if it's there and often spoken of, there's a reason, it would make life easier for those who need such a link between Lua and the triggers (link that must be there, since it's not possible to access the cockpit and other things from Lua). ;)

Hehe, I saw that on the known scripting engine issues. Hopefully it'll get fixed at some point. It's not always easy to convey one's point of view in posts. Don't get me wrong, I find DCS a great sim environment and community. But I've started building missions more seriously for a few weeks and found it a very frustrating and tedious experience, so I'm simply trying to identify a few simple ways to improve the possibilities. I thought it was a bit confusing :D All sorted then :)

I never said otherwise. So, same answer as before: Well, then why provide Lua to mission designers at all? I'm not sure I'm following you. Being able to insert scripts is a powerful tool, you are not forced to use it if you don't want to. It's not more hidden than the rest, a GUI-based development is always awkward in nature when it comes to easily getting the whole picture and reading back the code. Granted, the small text boxes don't make for easy reading, I usually copy/paste them from separate files I keep (in a revision system and so on). You could have the whole Lua code in a separate file - even if that's pretty awkward at the moment in the ME, and only put one function call per DO SCRIPT or LUA PREDICATE. Except you can't access the cockpit, and probably some other features. But otherwise, yes, why not. Personally I prefer to use a mix of both for efficiency and get the best of both worlds. For instance I'm not keen on writing down the coordinates of the waypoints, triggers and so on, then coding them in Lua code (I've done it in some case, it's a bit tedious). I'm not a good Lua programmer, just began using it. And sorry, I'm not getting involved in a debate over programming languages here, it would quickly get out of topic ;)

I'm not talking about the language, but about the API. Please check the reference, and what FlighControl was referring to: As I understand it, this post was aimed at how Lua intefaces with DCS, not the language in itself. I certainly have some gripes with the language, but this is not the current topic, and it fits the bill in the DCS context so no problem there :)

I know those frameworks, thanks all the same :) I'm just pointing out a few simple improvements, in answer to a previously asked question. AFAIK, those frameworks don't address those problems because they're current limitations in DCS.

It's probably somewhat subjective but I can easily come with a few limitations that shouldn't be hard to remove to make the life much easier, and enhance the missions. - No persistence between missions or when repeating a mission is a very annoying limitation which could be easily removed, off the top of my head being able to load/store files in a fixed directory would already bring a lot of possibilities. - The LUA PREDICATE condition field, which is broken, is also a bit sad and requires convoluted and awkward work-arounds. - Not being able to access the cockpit would currently be another major drawback to Lua scripting for me. Any tutorial mission would benefit from it, and simplify the logic. Check if a set of switches are in the correct position and if not, highlight them for instance. Or monitor the gauges / controls. Instead huge lists of repetitive conditions and actions are necessary, which render the missions prone to bugs and almost impossible to maintain (not mentioning it's not possible to copy a set of triggers to another existing mission). So Lua, while being a bit of a weirdo language, could still allow a lot of creativity and simplifications, but the interface to the aircraft is very limited. And trying to mix what is accessible from Lua, and what is accessible from the ME is not user-friendly (or dev-friendly) to say the least.

The video clearly shows about 320 m altitude and 1200 km/h speed. I've tried many times, but it seems to be quite random. Once I could hit two armoured vehicles by dropping the cluster bombs from 400 m, at about 1200 km/h, they have dispersed at 50 m AGL, but way ahead of what the piper showed, so as for most bombing deliveries, it's actually a bit longer than what the piper indicates. Still, nothing comparable to CBU-87/97, don't expect such a wide dispersion. And I find it quite hard to be exactly aligned and keep the MiG stable enough for the required precision, so some amount of practice is necessary. The settings were the same as what is required for dumb bombs: - ASP master mode: GND - ASP piper mode: MSL/FIXED - ASP bomb/firing: B - ASP auto/manual: here auto, so without any pre-computed angle correction - MSL RKT LNCH and relevant pylon breakers: ON - weapon select on B position of relevant pylons - tactical release: ON - ASP gun/rockets and target size: don't care in this mode (- radar beam ON, though I haven't checked the launch/break off lights, not sure it helps here)

bump, has this been reported?

When one starts a mission, especially if the aircraft is on a "parking hot" start waypoint or in the air, there are remnants from the previous mission for various state variables, including: - the engine state, - the roll / yaw / pitch rate. As a result, the aircraft starts in conditions that are sometimes very bad, I had a few occurrences with the Mig-21Bis having an engine failure on a new mission because of negative Gs that were induced by the state of the module when quitting the previous mission. This is typical when training for bombing, where the mission is quit mid-air or after a crash. If the previous mission ends with the aircraft landed and immobile there is of course (almost) no problem, or at least it's less acute. But even in this case, the engine is not at the correct regime to match the speed of the initial waypoint. So even if the aircraft was still in the previous mission, there's a problem when starting an air mission. I've tested that with various aircraft, the Mig-21Bis, the M-2000C, the Bf-109 (was reported before but without reply). So it looks like it's a DCS systemic problem and not a module problem, although it has more consequences on some modules than others, and more impact on some missions than others. DCS versions 2.0.5.1648.165 / 1.5.6.1938.247. To reproduce: (1) Initial yaw/roll/pitch rates with previous mission - launch any mission starting in the air (training mission for example) - pull a lot of Gs, quit the mission - launch the mission again - observe the erroneous transients on the aircraft, it will jerk around before stabilizing, even if the stick is neutral. (2) Initial engine regime with previous mission - launch any mission with runway start, or parking hot start - put the throttle on max - quit - launch the same mission again (or same type of mission) - observe the transients on the engine, it will surge forward then throttle back to idle. (3) Wrong engine RPM / failure to sample the throttle controller (HOTAS/...) - design a mission (a) with initial speed (adapted to the module) - launch a mission (b) in which the aircraft is still (ramp start) - quit - launch mission (a) - observe the transients in engine state, with and without moving the throttle - * without moving the throttle: usually the engine gets to idle or a wrong regime, the throttle control is not sampled - * with moving the throttle: the engine adapts to the appropriate regime once the new throttle position is sampled.

DCS 2.0.5.1648.165 I don't have crashes, so this must have been solved. However, I can't get any of the cluster bombs to explode. Since the manual is not finished and has no information on that, I searched and found a few posts with guesswork, and one video, but I can't seem to reproduce any of that. Have they been reported to work since this crash problem was patched?

Did you find anything? I've checked in 2.0.5.1648.165 and it's not there either. It would be nice to get them :)

That'd be the A-10A, there's also one available on Avialogs :)

Hehe, it does also look a bit spider-like on a satellite image :D Coordinates: 37°30'02"N 115°37'34"W There are apparently other Easter eggs, guess where this one comes from ;) (probably well-known already, anyway)

It's not necessary in this sim. It's not necessary to have any of the clickable features in the cockpit, really, there is an auto-start. :rolleyes: Come on, I don't see what there is to argue about, it's part of a normal procedure for the Spitfire, and some people - actually mostly in those forums, like the realism, even if not everything is modelled yet. :) If some of you don't want to do that, that's perfectly fine, but why would you want to prevent others from being able to get the feature? That's beyond me.

Mainly for realism, and to be able to perform tests that are otherwise not possible.

+1, that and wheel chocks ;)

Yeah, many missions are broken one way or another. You can either: - try the work-around mentioned by Baltic (it usually works in this campaign), so simply launch DCS, start any mission, come back to the menu and launch mission 9. It's probably the easiest option unless you're playing other campaigns that might be blocked too. If you see the spotlights of the other aircraft shortly after the mission starts, it will be OK; - switch to the beta branch and update to 1.5.6.1648.240, those days it's usually pretty stable and often the same version as the release anyway.

Normally that's been solved with the two latest 1.5.6 patches. Which version of DCS do you have? Ah... I see the release is still 1.5.5. That's annoying, I guess that's your case?