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 !

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 ;)

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