For examples of extensions (aka plug-ins), see MD's source code.
Also read MDPlugin.h because it documents on how a plug-in is structured and the protocol it must implement. If you've already seen it, you should still re-read it as the commenting or procedures may have been changed since.
To submit an extension, you upload a zipped copy and create a thread with a link attached. Also specify a short one-line description.
Before submitting, keep these thoughts in mind:
The filename of your plug-in will be used as its name. If you think your extension should have a space (e.g, "Krazy Stuff" not KrazyStuff") then please put a space. Do not use camel casing or underscores just because that is how you set up your Xcode project and were scared of spaces being in your file paths. If you think the name of your extension does not reflect what it does, also consider changing it. Change product name setting appropriately if needed.
If you are submitting a global based plug-in that can give a multiplayer gameplay advantage against other players, it should probably be a map-based plug-in instead where everyone should have the added modifications (as long as they are on a recent version of MD).
If you submit a map based plug-in that should not be ran in global mode, then you should return nil in your init method if the wrong mode is passed.
If you are submitting a map based plug-in, then any effects of your plug-in needs to be gone from the user when switching to a map that does not use the plug-in. This includes added console commands and the like.
Your plug-in should run on 10.6 and up. That said, this can be a pain. If you must, you should return nil in your initializer if it is being run on an OS you do not support (and state which API you used to do this). If this becomes problematic in future, we may add some sort of OS required field.
An update to an extension will replace the last version of the extension. You can't rely on a user having an older version of an extension, and they may even be forced to upgrade for a map-based extension.
Disable unnecessary log statements; only keep them for things that go wrong. But at the same time, make sure to also not log frequently. Ideally, there should be no log statements. Resolve errors that output as much as possible.
It is STRONGLY discouraged to have an extension that may require creating more sockets for transmitting info in-game. Firstly, this is a waste; Halo already has its own sockets set up. It should not be impossible from the server and client to retrieve their sockets and find where the (32-bit big-endian) IPv4 addresses are located; you can inspect sendto/recvfrom functions to help pinpoint this. Halo likely ignores packets it doesn't understand and you can always prefix yours. Secondly, this introduces all sorts of real potential networking troubles; one port may be able to get through NAT but another may not be able to for instance. And lastly, if what you want to do is simple enough to be done through another sort of transmission (e.g., chat or console), that is another thing to think about, and has the bonus of implementing reliability for you. If all else fails, you can try this but of course have to handle closing sockets when your plug-in is inactive.
As usual, any major annoyances/bugs are consideration for rejection and you'll be messaged if this is a problem. And since plug-ins are more complicated than ordinary mods, you may be contacted further for other reasons.
Submit mods to be added to the HaloMD database.
1 post • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest