MMM 1.0.1

MMM 1.0.1 is out. This was intended to be mainly a bugfix release however a few new features have found their way in. See here


  • Premonitions Sample Mission
  • Child Mod support
  • EntityHook class
  • Cineractive skippable property (defaults to true)
  • Forced parameter added to App:cineractiveFinish
  • GameObject.specialEnergy property
  • GameObject.maxSpecialEnergy property
  • GameObject.specialEnergyValue property
  • TextInput.hooks property
  • TextInput:unhook functions
  • Added Media:stopSounds function


  • Cineractive skip changed to space bar
  • Entity updated to use EntityHook
  • Voiceovers no longer play when giving orders
  • Media class changed to have a global instance
  • Camera class changed to have a global instance
  • TextInput:hook function now takes an id
  • GameObject.hitpoints property changed to GameObject.hullValue
  • GameObject.maxHitpoints property changed to GameObject.maxHull
  • property changed to GameObject.hull


  • Fixed an issue with EntityFinder condition objects
  • Fixed paths having incorrect indices
  • Fixed Monitor not being passed to hook functions
  • Fixed an issue with unhook on Timer, Entity and TextInput
  • Fixed Cineractive calls crashing when not in cineractive mode

MMM 1.0.0

Megadroid's Mission Mod 1.0.0 is released. See here for more information.

This first version covers most of the Entity tree, media and cinematic functionality required to make a mission. Further versions will work on exposing the technology tree, entity type classes and more.

Remote Debugger

While developing MMM I have been developing several missions to test usability and performance. Something I noticed is that debugging is not as easy as it is in other games – without a built in console window there is no real way to store error data in a persistent way. This can be a problem if the game crashes as you will lose all error information.

As I can’t fully integrate debugging into the game I investigated alternate solutions and eventually settled on a debugger application that a MMM script can connect to. This application is launched separately from Armada and will survive the death of the game.

When a script connects to the debugger all debug print output and error messages will be rerouted to it, rather than appearing in game; it is best to play in windowed mode so that you can see the output. Alternatively you can run the debugger on another computer – it communicates over the network (hence the remote bit). You can save a log of all messages received to disk to help keep track of bugs.

The remote debugger is not an entirely passive application – you can use it to send script commands to the mission to execute. These will be executed when they are received by the loader. This allows for faster development of missions and testing of ideas, as you don’t have to restart the mission every time you want to do something.

There will be a tutorial on how to use the remote debugger when it is released. The debugger will be released along with the next version of MMM.


As you may or may not be aware (be aware please), you can use the “include” function to split your script into multiple files. This will help you to manage your code as it grows in complexity by splitting components into separate files. The only drawback to this is that you would have to distribute a whole bunch of Lua files with your bzn and dsl files – and they may potentially clash with existing Lua files.

To get around this issue you now have the ability to create a pack file. This is a zip file (given the extension mmmpack) that contains all of your script files. It will preserve your directory structure so you can use script subdirectories to keep your scripts organised. Originally packs used a custom file format, but I opted for zip in the end as almost everyone knows how to make a zip and it saves me having to write and test an entire application to create packs.

The pack will be loaded if present – that is it takes priority over the actual .lua files. You should only use the pack when distributing the mission as debugging information will be limited. Using packs means that you only have to distribute the bzn, dsl and mmmpack files when your map is ready for release.


A new feature I'm working on is exposing the GameObjectClass and derived types. That most likely doesn't mean a lot, so I will explain. Every GameObject in the game (ships, stations, terrain objects and so on) is of a particular class. That class defines the way that every ship of that type behaves and is built from the ODF file.

MMM already allows you to change properties of individual ships via the Entity and derived classes. This is all you need to change a specific ship. However suppose you wanted to upgrade a ship class - say the Akira class. You can now actually edit the definition of the Akira class in script to give it the upgrade. So you could set the maximum shields of the Akira class and all Akira class ships built after that point will be affected.

You will be able to access the class of an Entity using the class property, or browse the different classes that currently exist. Changes to classes do not persist beyond the lifetime of the mission - when you go back to the menu all changes are lost, so you don't need to worry about affecting other missions with your changes.

New Site

Well I finally got around to creating a new main site for MMM. I suppose you already know this since you're on it. I'll attempt to post more regular updates about what I'm doing on the mod in order to convince people that I am actually still alive and working on it.

New versions along with changelogs and appropriate installation notes will also be listed in the Downloads page as well as being referenced on the forum. This should be a bit easier than an ever growing sticky forum post of doom.

Subscribe to Megadroid's Mission Mod RSS