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.