GreyEcho

Hi everyone ! It's been worked on for the past few weeks, but we are now ready to announce it : Moose-2.0 is out ! Here is a small explanation of the changes. You are highly encouraged to RTFM here : http://flightcontrol-master.github.io/MOOSE/, as well as : For the mission designer : http://flightcontrol-master.github.io/MOOSE/Usage_Guide.html For the tester : http://flightcontrol-master.github.io/MOOSE/Beta_Test_Guide.html For the contributor (or the curious ;) ) : http://flightcontrol-master.github.io/MOOSE/Contribution_Guide.html Release process : We are now releasing a stable version of Moose as regularly as possible. You can grab the latest Release from here : https://github.com/FlightControl-Master/MOOSE/releases, no need to use GitHub Desktop anymore Setup and update : If you are already a Moose user and want to use the latest Release, you can ditch your local Moose repository as well as GitHub desktop, and simply download the latest release (link above). In your missions, load the Moose.lua that comes in the download. If you are already a Moose user (i.e. already installed GitHub, LDT, and have a local Moose repository) and still want to access the latest bleeding edge features of Moose, then you need to setup a Tester environment. First, install 7-Zip (requirement) if you don't already have it, then use the automated process; Sync the repo, then browse to MOOSE/Moose Development Environment Setup/ and start MooseDevelopmentEnvironmentSetup.exe as an administrator. Input the location of the folders it asks for, and let it do its magic. Now, in your missions, you should load the Moose.lua that is in DCS World/Scripts/Moose/. More information about the setup of a tester environment and the MDES tool here. If you are new to Moose, then the doc is your best friend. Repository : The repository has been cleaned up, and the test missions are now available here for the latest stable Moose Release : https://github.com/FlightControl-Master/MOOSE_MISSIONS/releases If you are using GitHub (Testers), then access the latest updates to test missions by cloning the MOOSE_MISSIONS repository, and switching to the release branch Features : If you have been syncing your Moose local repository regularly, then there shouldn't be anything new. The huge news is that Moose-2.0 is as stable bug-free as possible ! We spent the last weeks cleaning up the code and fixing up the bugs in preparation of this release ! Why did you have to change everything ? It was just fine before ! The simple answer is that the way Moose was released had some not-so-subtle drawbacks for everyone involved. The truth is that MOOSE development is fast paced in will stay this way, which introduced some problems : Instabilities for the mission designer The need for the mission designer to use GitHub Desktop. The contributors needed to generate a static version of moose before any pull request to the master, which is a source of errors and confusions The test misisons don't version control well, and it was a pain to maintain them with Moose static loading. The testers workflow was really complex and undocumented, meaning that testing a regularly updated Moose was a pain. We felt like the end user and the contributors shouldn't have to deal with either of those problems. That's why we changed the release plan. Although we tried to make this change as smooth as possible, any change this huge is bound to raise issues or at least question. We will try to be as available as possible to swiftly answer your questions, on this topic or on slack. In the name of every MOOSE Contributor and Tester, we wish you happy mission designing with MOOSE-2.0 ! EDIT : This is only relevant for TESTERS : The .lauch files (the automated tools to manage .miz files, in LDT->Run->External tools) won't work for now. We are working on a fix that will come ASAP. Sorry for the inconvenience and thank you for your patience. Note that the rest (dynamic loading) is working !

The RadioComs Branch has officially been merged, which adds a radio communication feature. Concretely, you can attach a RADIO to any POSITIONABLE and use the methods in RADIO to broadcast your radio transmission. For example, in vanilla DCS, a Unit switching freqency to 115AM and then transmitting "Noise.ogg" looked like that : Unit.getByName("myUnit"):getController():setCommand({ id = "SetFrequency", params = { frequency = 115000000, modulation = radio.modulation.AM, } }) Unit.getByName("myUnit"):getController():setCommand({ id = "TransmitMessage", params = { file = "Noise.ogg", duration = 0, subtitle = "", loop = false, } })In MOOSE, it now looks like this : local UnitRadio = UNIT.FindByName("myUnit"):GetRadio() UnitRadio:SetFileName("Noise.ogg"):SetFrequency(115):SetModulation(radio.modulation.AM) UnitRadio:Broadcast()Please read the full documentation of the RADIO class here http://flightcontrol-master.github.io/MOOSE/Documentation/Radio.html

RADIO is coming soon, I swear :) [EDIT] To be more specific, the RADIO class implementation is at its core a wrapper for DCS' "TransmitMessage" command and the singleton function trigger.action.radioTransmission(). The first goal is to make a radio transmission as easy as BatumiRadio = STATIC:FindByName("Batumi Tower"):GetRadio() BatumiRadio:NewGenericTransmission("YourSoundFile.ogg", 115, radio.modulation.AM, 100) BatumiRadio:Broadcast()When this is done (and I'm on the final steps, the code is written and tested, I'm now working on documentation), I'll be working on implementing a BEACON class to wrap DCS' Command "ActivateBeacon". That should keep me occupied for a while. I am aware that there is a demand to make tasks and command centers use some sort of radio communication (@Flagrum : You're not alone !), and it's on my todo list if nobody gets around to do that before I do. But I really want to finish BEACON first, it looks very promising and seems like it would allow the mission designer to do some very cool stuff ! [/EDIT]

Yep, that worked very well, thank you! I edited the hoggit wiki accordingly�.

Hi ! I'm designing a very dialog intensive single player mission for the Mirage 2000. Since it has a lot of sound files that have to be played at very precise time intervals, I decided to try to use a Lua script rather than making a huge number of triggers. Here is my code, which is scheduled to execute at a precise moment : Unit.getByName("Volt"):getController():setCommand({ id = "transmitMessage", params = { file = "l10n/DEFAULT/Noise.ogg", duration = 10, subtitle = "Noise", loop = false, } })And I get the following message error in dcs.log: Unknown command "transmitMessage" in function 'setCommand'My understanding is that the command transmitMessage isn't recognized by DCS, and sure enough, it isn't mentioned in the (very outdated but official) DCS Wiki. It is however listed in the more recent Hoggit wiki. So, my questions are the following: Is transmitMessage a command recognized by DCS? If not, I'll use the singleton function trigger.action.radioTransmission(). Is there a way to add a subtitle with this?� Thank you for your help !

I've been playing around with the mission editor and I came across the following issue that I was able to reproduce consistently, whichever mission I ran. Basically, some triggers/combinations of triggers and actions aren't saved when I close the trigger pane. I happened especially with the following combination:� - Trigger: ONCE - Condition: TIME MORE 10s - Action: RADIO TRANSMISSION Is it an intended behavior, a known bug, or am I the only one with the problem?� Video of the problem (sorry for the poor quality)�:

Thank you for the detailed answer that clears up quite a bit! I sent you a PM.

In a multiplayer environment, when flying the Su27, you should always play to the plane advantages: sneak, IRST and ETMissiles. If you can't be detected, there no dogfight and there's no missile to evade...

I'm discovering MOOSE, and I got to say I'm quite impressed by the automation that it seems to bring, leaving the micromanaging of units to the code. Although the documentation is very well done, some details still aren't clear to me. 1. When is my lua script executed ? At the beginning of the mission ? Or is it running in parallel with the mission ? Is it executed every frame ? Every second ? 2. Let's say I want the player aircraft to explode when he reaches 3000ft, using trigger.action.explosion() on his coordinates. As I understand it there is no way to do it. I would need to use a Mission Editor Triggers. Correct ? 3. Is there a way to wait ? Let's say I want a smoke to spawn at the crash of the player (EVT-104 - OnEventCrash Example), but 10 seconds after the crash. Is there a way to do that ? 4. Is there a way to interact with FLAGS set up in the Mission Editor ? Do they generate an event that may be caught by the event handler, for example ? 5. Am I blind or trigger.action.explosion() isn't wrapped in MOOSE, while trigger.action.smoke() and trigger.action.signalFlare() are ? Is there a specific reason or is it just an overlook / WIP ? Thank you for taking the time to read me and for your answer !

Thank you for the very detailed answer ! Everything makes so much more sense now, especially the TR Switch and the hydraulic alternator stuff. I'm off (re)reading page 39 of the manual ;)

Yep, I retested and I was wrong. When The Battery Switch and the TR switch are both on, but the alternator switches are both off, the plane will work with most instruments off for about 33min. Then everything shuts off you loose control. Strangely enough, In this configuration, you can't use afterburner.

My first test was very short indeed, as I didn't try to see the long term consequences. So I did more testing. RWR : It will stop working if damaged, and the DA light will sometimes remain lit, and sometimes blink. (Seems like intended behavior to me). No other alarm or light. (The video linked in the first post suggest that a failure of the RWR may trigger the research sound ?) HYD PUMPS : The Hyd pumps 1 and 2 fail don't do anything, whatever the state of the other one is (even after waiting for 10min). A failure in the Hyd pump 3 (which I assume is the emergency pump) won't do anything either, but if you disable it manually, the red light on the "problems" panel turn on, as well as the master caution, regardless of the state of the 2 main hyd pumps (which makes sense to me). Even if all three are damaged, the landing gear, the air brakes and the aileron work properly. RADAR : It seems to react accurately to damage, an X appears on the VTB, and you can't lock contacts anymore, even with special modes. OIL SYSTEM LEAK and OIL SYSTEM FAILURE : Nothing happens, even after a 15min flight. LANDING GEAR : Not affected by by HYD Pressure, or by speed. I managed to deploy and retract it at Mach 1.5. If you feel very gamey in MP, I think you could drop the gear and deploy airbrakes, and you would literally stop on the spot... ELECTRIC SYSTEM : Both engine alternator fail, a battery fail or both aux transformer fail don't do anything, regardless of the combination. If you play around with the battery switch, the TR switch (which I don't understand the purpose) and the 2 alternator switch, you obtain different results, ranging from some instruments stop working, to a progressive inability to control the aircraft. Lights of the problem panel switch on, as well as mater caution. So that seems to work as intended. HYD ALTERNATOR FAIL : I have no idea what it should do but it has no impact as far as I can tell, even after waiting 15 min. INS PARTIAL FAIL, INS TOTAL FAIL and INS GYROS FAIL : Don't have an impact on INS functionality. The INS doesn't seem to drift more or less than it usually does. The only damage I got from spawning an explosion near the aircraft are RADAR, RWR (different sensors + total failure), and Jammer, as well as some physical damage to the plane which greatly affected it's stability and controlability. No instrumentation damage, or hydrolic failures... I never manage to damage the HUD either, which is something that happen pretty frequently in FC3's F15. So my question is : does RAZBAM plan on improving the damage, or do you consider it to be accurate enough ? Either way I love the Mirage and I thank you for your outstanding job !

Cool ! Note that during this sortie I also the multiple failures showed in the screenshot and nothing showed up on the error panel, nor did I get a master caution sound or light. Is that intended behavior ?

I don't know if it even was a planned feature from the beginning but after taking hits, I realize the Mirage didn't notify me of anything. I don't know much about the IRL Mirage, but if I believe this video (pretty funny BTW), it has multiple ways to tell the pilot something's wrong. So I tested it by creating a mission (attached below, I can provide the ACMI if needed) in which I activated all of the random failures possible. I also scripted an explosion happening close to the aircraft, starting a fire, just to be sure. The results in picture (which can't capture sounds but I swear the little Mirage was quiet as a grave). If it's something that is WIP or not planned, then sorry for the time lost reading and feel free to delete the thread.

Then I'm gonna go ahead and use the IAS given in Tacview going forward, since it's what the player sees in game.

That's what I meant. I can't reliably find the corner speed because I can't test which is the minimum speed at which I can pull 9Gs (the corner speed). That's why I guesstimated the theorical ITR, and I was probably quite far off. Now, I realize that it is confusing, and since it is probably wrong, I removed it from the post. I also added CAS, since it was requested. It's kind of a makeshift solution for the moment though. For the speed, I'm not sure though : Either the hud gives you the IAS, or both DCS and TacView are wrong.

Isn't the player seeing IAS instead of CAS on his hud ? Anyway, like I said I did account for it, otherwise the G curves and the radius of turn curves wouldn't match. I used this tool : http://www.hochwarth.com/misc/AviationCalculator.html. Since I used the default weather, without wind, it should be accurate enough.

Well, as I said, my Theoretical ITR is largely guesstimated. As far as I'm aware, there is no way to pull the maximum number of g because the FBW prevents it, so there is no way to get the real corner speed. I think I made it clear enough though, but if it confuses people, then I may just remove it. I'd say that the gap is between the chart and my data is way smaller than I expected, Razbam did a very good job on this one.

Hello DCS community ;) There has been a lot of talk about the (simulated) M2000C flight characteristics, for example here and here and a lot of it is revolving around feelings and hearsay. I wanted to test as rigorously as possible our beloved M2000C. For now I only tested at 15000ft, in a 2xMagics and 50% fuel configuration. I tryed with the FBW in both "Vrille" and "AA" modes, I plan on trying the "Charge" mode asap. Test Protocol Instantaneous Turn Rate I binded a new axis of my joystick to the pitch axis, and increased the saturation as much as possible, to be sure that I "pull the stick" even harder than is actually possible realistically. Then I flew at different speed, banked to 90°, and then used the newly binded axis. I carefully reviewed the results with Tacview, and noted the TAS(knots), the number of g pulled and the turn rate (°/s). I produces around 40 data points this way. I then compared this turn rate to the theoretical one given by the following equation, being especially careful with the unit conversion. I discarded the values that where to far from the theoretical ones, and then only kept the values when the I pulled the most Gs. After the cleaning up, I kept only around 12 data points. The theoretical ITR is largely guesstimated. Sustained Turn Rate The protocol is almost the same as above, but instead of trying to pull the maximum number of G, I try to keep a constant speed during a level turn. I recorded around 12 data points for each. The Results You can either access all the data here https://1drv.ms/x/s!Aks3P6QLVda0iQsBSGkE_4fNG6zB, or refer the EM diagram below. Keep in mind that those results are experimental, and there is a low to moderate margin of error, despite my best efforts to reduce it. Comparaison with the real one Obviously, I couldn't resist comparing my results to the only publicly available data that I know of, the chart below. They happen to match my setup, both in term of altitude and payload (which is not totally a coincidence). I resized both picture to match them as close as possible. Note that the chart is using CAS as a speed unit, and I'm using TAS, but I (kinda) compensated for that, but it might not be accurate at low speeds. The red line is the STR from the chart, and the green one is my STR. I'll let you draw your own conclusions. I'm a computer science engineer, and my knowledge in fluid dynamics is as non existent as it can be, so please, if I made a mistake somewhere, feel free to correct me. Especially, if someone knows which line of the chart is the instantaneous turn rate, I'll add the colored line. If this data doesn't match your experience, please do comment and provide me with ACMI files I can analyze. If you don't do the latter, it's not even worth mentioning your data. ACMI or it never happened :). All my ACMI files are available on demand - just ask, but be aware that there is around 130 data point on 27 files. I know this kind of topic can rapidly become rather unproductive, so I ask you, the potential commentator, to kindly refrain from bringing up any other aircraft than our beloved Mirage 2000C, both in sim and IRL, if you have hard data. Let's keep it on topic and interesting:thumbup: ! Have a great flight in your Mirage ! PS : I want to thank myHellJumper, who gave me the first data, after which I went a bit wild... Merci ;)

Yep, that's what I ended up doing, but before noticing it, that was very confusing. Especially on mission 3 I think, when you are supposed to go 180 after passing a TACAN station. My question was poorly worded, I meant to say: "I wonder if the real Mirage pilot can change the declination manually, and if so, would this be something added by RAZBAM, for example by switching the PSM to VEI before alignment, setting the PCN to DEC, and editing Waypoint 00 ?

Same problem here. It's especially annoying since a huge part of the campaign happen to be in January. I wonder if the pilot can change the declination manually in the Mirage while in Prep Waypoint 00 ?

ok, thanks for the answer and the good work ;)

Hey, I'm using your software and I love it. Thank you ! Do you think there is a way for you add a link on the window that would point to this tread, to see if there is an update ? Or maybe make the updater check for updates for itself itself (Reading that sentence back, I'm not sure it's clear ;) ?

Works for me. No idea what the problem is. Maybe it's an American/European thing ?

This is cool, but I'm gonna have to modify it heavily if I want to use it, cause G940Leds.exe waits for very precise instructions, and not JSON datas. Or I could write my own program to interface with my G940 Throttle. Anyway, thanks for the link !