The supply drop is basically a huge tin can which can be filled with all sorts of goodies, ranging from vehicles (the printable ones that is), machinery, printer, all sorts of crates, etc. The rich guts of said "tin cans" are protected by a hatch which the player can remove. The hatch itself will be detached and can't be reattached again in the game.


There are three different, well, approaches we can use in our own scenarios. Each slightly more difficult then the other, which means more coding, but also more awesome.

All together there are two different types of supply drops. One you'll find in the scenario editor under the vehicle section "Manned SP(Single Player)" as the Supply Module (landed). This supply module is rather unspectacular. You have to place everything inside of it manually in the editor by dragging everything inside.

The other one, under the section Supply Drops is way more versatile. For starters, you can make it land somewhere. It has a nozzle with an inflatable heatshield and can carry up to 4 different supply modules all in one stack, that seperates upon landing. Or you can choose the already landed version. This types of supply modules have a special ability, spawning. What that means, I'll explain in a second.

This approach is easy. All you need to do is place (an empty) supply drop in your scenario. Place the items you want inside of it and play it. That's it. This aproach works with both supply drop types, the single player type as well as the spawning type.


This approach has a few problems. You can't relocate your supply drop. If you find out that you want your base somewhere else etc. you'd have to move the supply drop (or create another one) and move it's contents. You also can't make the supply drop land towards your position, or at all.

A different better way is to use a spawning supply drop. By the means of the generic string value (inside the scenario file) you can point a supply drop object to a predefined configuration file that defines it's contents. What that means is, that your supply drop is actually empty, but the moment a player opens the hatch, all that is defined in a said configuration file will be spawned right inside of it.

Mind you this does not work for the Manned SP supply drop.

Each entity in the game, is it a vehicle or a player character etc. can store generic values. What they mean is depending on who uses them. The supply drop stores the path to a configuration file, the self destruct device (mod under developement) can use it to store the activation password etc.

When you open the hatch of a supply drop, the controller script for it reads the generic string value (GENSTRING). If it contains a path to a configuration file it will open it, read it and spawn everything that is defined in said configuration file.

All you need to do is edit the path to the supply config file into the supply drop definition line in the scenario file:


What I have added is following line:

What those mean:

Now why would you use that and not the first approach? For starters, it would be a pain in the OMS engine to make a supply drop land in front of you with the contents you'd like without using the config file. You'd have to place each content object inside of the drop pod in the editor while it's in the air. You can't carry it in. And chances are it will fall out or break once you start your game. The other reason is, you might change your mind in terms of position etc. so the process of relocating your supplies with the first approach is crazy work.

Following this approach, you create your supplay pod, empty. Put it where ever you'd like. Save. Change a value in the scenario file, done:


Now again. The pod is empty all the time right until you open the hatch. That's when the spawning takes place.

The only catch is, that you have to use the predefined config files, which are located in the standard path:

Right now all you can use are the following:

• 3dprinterdrop.cfg
  
• foodwaterres_mki.cfg
  
• foodwaterres_mkii.cfg
  
• machines_mki.cfg
  
• machines_mkii.cfg
  
• suits_mki.cfg
  
• suits_mkii.cfg

You'll find that most of the time that is more then enough. If, and I stress the if, if you're interested in a how to create your own supply config file, check the appendix section of this guide, it's a pain, but you only have to do it once. The appendix section also contains a manifest with the contents of the predefined config files.

There is one config file I have omitted, the "example.cfg". You wouldn't use it in a scenario, but it's great to demonstrate you how the spawning process I've talked about. As a homework, try it out ;)

But there is more. There's actually a special kind of vehicle, that stacks up to four supply drops together. The landing sequence is awesome. A piston with an inflatable heat shield, lots of thrusters, simply awesome. In order to give each and every one of the four cans (or three, or two, depends which one you pick in th editor) all you need to do is create the 4xsupply drop in the editor, but using the "landing towards cursor" option. Then go into the scenario file and add some lines. And this is how the process looks like:


Awesome, isn't it? Of course you can use the 3x, the 2x or the single supply drop with this approach. Depends on what you want from your scenario. You also have the possibility of leaving some pods empty, simply omitt the GENSTRING line for that pod.

You know now how to make a supply drop land at a predefined position...more or less. But that happens right when the game begins. What might be probably more interesting is using a triggered event to get those supplies to land at a certain location.

You've guessed it. We need some code. But not that much. All you need is a trigger and a script event linked to it (as shown in the second scenario guide). Of course you could utilize a more complex approach using the mission script, objectives etc. But for now, a trigger that activates an event script will do just fine.

The code you have to type in your event script is:

This example shows a 4x supply drop. Notice how we have to define 4 supply config file paths? Of course you can ommit them or some of them, in that case those supply drop pods will remain empty after opening the hatch.

The most important part is the

method call. It needs the filepath to the vehicle's config file, the position where to spawn the vehicle and if it is currently performing a landing or not. If you leave it at that the supply drop will spawn, but the pods will be empty, even after opening their hatches. Thats where the rest of the code comes in. You remember, the contents of the supply drop pods are stored in the GENSTRING line in the scenario. Now, we don't have that here, we create the supply drop "out of thin air" so we have to set the generic string values ourselves. The LandingZone definition is not required, it all works well without, I find it helpfull to make the supply drop land more or less where I want. You'll have to test it, adjust the values and test it again.

Here's an example of a single pod drop that contains the 3D printer:

Notice that I have changed the vehicle config file path to supplymodule_1 and removed the superfluent generic string definitions. That's all there is to it.

This section contains the "manifests" for all predefined supply config files. Those config files contain the contents that will be spawned the moment the player opens the hatch.

• 1 x 3D printer

• 4 x waterpack (in a box)
  
• 4 x space food (in a box)
  
• 2 x vitamins + 2 x potato seed bag (in a box)
  
• 3 x space food + 3 x potato seed bags + 3 x vitamins (in a big box)
  
• 3 x space food + 3 x potato seed bags + 3 x vitamins (in a big box)
  
• 3 x resource barrel (Water)
  
• 3 x resource barrel (Oxygen)
  
• 3 x resource barrel (Methane)
  
• 1 x Water station
  
• 1 x Hydroponics Station

• 3 x space food + 3 x potato seed bag + 3 x vitamins (in a big box)
  
• 3 x space food + 3 x potato seed bag + 3 x vitamins (in a big box)
  
• 9 x waterpack (in a big box)
  
• 9 x waterpack (in a big box)
  
• 9 x space food (in a big box)
  
• 6 x waterpack (in a big box) + 3 x potato seed bag (in a big box)
  
• 4 x resource barrel (Water)
  
• 4 x resource barrel (Oxygen)
  
• 4 x resource barrel (Methane)

• 16 x resource barrel (empty)
  
• 2 x drilling rig
  
• 1 x refinery

• 8 x resource barrel (empty)
  
• 1 x atmospheric processor
  
• 2 x topsoil extractor

• 1 x construction tool + 1 x vitaminx + 2 x water pack (small box)
  
• 1 x construction tool + 1 x water pack + 2 x space food (small box)
  
• 1 x medium suit + 1 x medium helmet (small box)
  
• 2 x light suit + 2 x light helmet (big box)
  
• 2 x light suit + 2 x light helmet (big box)

• 2 x heavy suit + 2 x heavy helmet (big box)
  
• 2 x medium suit + 2 x medium helmet (big box)
  
• 2 x medium suit + 2 x medium helmet (big box)

Creating your own custom supply drop configuration file is work, granted, but doable.

Each configuration file lists the objects (crates, suits, machines, vehicles, etc.) which it will spawn. Therefore it is neccassary to state what type or category of object you'd like to create and where <i>inside</i> the supply drop you want to create it. Actually, all you have to do is define an offset position (and angle) from the center of the supply drop pod. If you punch in a position that is "outside the box" or in this case, outside of the pod, the object will be spawned outside, as can be seen in the example.cfg file video.

To make life easier on you, I have created a map or rather blueprint you can use to figure out where to put what, to plan the layout and make sure everything is inside. But even with the plan, you will have to reload the scenario and test it out. Hence the work warning at the beginning.



There are several categories of objects you can place inside a supply drop pod. You have to know which category an object belongs to. Each object you placed is defined by a relative offset position inside the pod itself. The supply pod's controller needs this information to spawn the objects.

Placing inventory items into crates or resources into barrels requires adding a seperate line, one for the container (crate, barrel) and one for the resource or invetory item referencing the container it will be in. I'll show an example shortly.

The BBLOCK or building block belongs to the category of objects you can print. The 3D printer, crates, resource barrels, etc. are all building blocks. In order to spawn a building block inside the supply drop pod you'll need following config line:


The path would usually point to something like this:

The config file path that you specify defines what object will be spawned (a small box in this example).

The index is important. Should you decide to place an inventory item into the box, you have to know the index of the container (box) the inventory item will be stored in.

Now mind you, the buggy, that you get fresh out of the printer, is also a building block. Only after an assembly it turns into a vehicle.

Here's an example taken from the stock 3dprinterdrop.cfg that makes a 3D printer appear:

Yes, you can place vehicles inside the supply drops...if they fit :). It works exactly the same as with building blocks.

As with vehicles, you can place characters inside supply drops...how about a MarsZ mod with supply drops filled with space zombies falling down :). Works exactly the same as with the building blocks.

Dynamic objects can also be spawned. The values you need to provide are equivalent to those for the building blocks.

The "world stored" inventory item is an inventory item (datapad, construction tool, helmet, etc.) that is simply laying around. Works exaxtly the same as with the building block.

This category describes inventory items that are stored inside a container, which could be a crate (or a character). To spawn an item like this you need following line:


The entries mean following:

The first number specifies the index of the spawnable object inside the config file. So if you have defined a box that can contain inventory items, and it's index i 5, you have to supply that number here.

To explain the second number (Inventory Number) I'll have to take a little detour into the game's inventory system.
Everything that is able of storing an inventory, like a crate, or the mobile lab, does so by the means of an Inventory object. Now a crate only has one. The mobile lab has several storage places. You can check it out. Just go around the mobile lab and you'll find several places which you can "open" to store stuff to. Now if you could spawn the mobile lab in the supply pod (which of course you can't, it's to big. Actually, it's to big to make sense, but spawning by opening the supply drop pod hatch, that we can do), the Inventory Number would specify which one of the several storage places you want your inventory item to be placed into. To verify how many inventories a vehicle etc. has, just open it's config file and look for the INVENTORY entries. The manned mobile lab for example has 8 of them.

The Inventory Slot Number defines which slot the inventory item has to go to. Remember, the first is always 0. The second 1 and the last is always:

To find out how many slots a certain inventory has, locate the config file if the object in question (crate, vehicle, etc.) and look for the INVENTORY_SLOT definition. For example the "Crate 02 bright" has one INVENTORY, and 4 INVENTORY_SLOT. Two of which are "Large" slots and two are "medium".

The path to the object config file defines what it is you want placed. Is it a construction tool or part of a suit?

Just beware, the object has to fit inside of the slot you specify. All inventory items define what slot types (large, medium, small) they can fit in, you should respect that restriction.

Now the resource operates some ways like the INVITEM_STORED:


The entries mean following:

The first number, here 0 is the index of the object you want the resource to go into. It should be something capable of holding a and that resource. A resource barrel is capable of storing resources, just as is a tank. It is possible that later in the game developement more objects become available (maybe the new life support system?) that can hold resources but only a certain type. You wouldn't put Methane in your life support, now would you.

The second number specifies which resource index to use. Now for a barrel or tank, it's always 0, since each of those objects can only contain one type of resource at a time. But the game is actually capable of dealing with building blocks that can store several types of resources (again, the life module...oxygen and nitrogen?). At the time this guide was written, there were no objects like this, so stick with a 0 here.

The resource name is self explanatory, "Water", "Oxygen", "Methane", or whatever resource you deem worthy.

The last is the resource amount. Here you should respect the restrictions of the given container, 130 for a resource barrel for example.

I hope this guid has helped you figuring out how to use supply drops and maybe how to define your own. Have fun with it, and good luck on Mars!