Warzone 2100 Forums

Since i defined my scavenger helicopter to be a transporter rather than VTOL, i wonder how exactly our old trouble #3133 with borg engineer production will look regarding to this.

The only difference between a VTOL and a transporter is their droidType. But droidType parameter can't be passed to buildDroid() any longer.

If there were no scavenger helicopters in my mind, you would have guessed the correct droidType by looking at the body being built. But it's a bad idea to hard-code those bodies when i want to add more transporter-type units via mods

NoQ wrote:Since i defined my scavenger helicopter to be a transporter rather than VTOL, i wonder how exactly our old trouble #3133 with borg engineer production will look regarding to this.

The only difference between a VTOL and a transporter is their droidType. But droidType parameter can't be passed to buildDroid() any longer.

If there were no scavenger helicopters in my mind, you would have guessed the correct droidType by looking at the body being built. But it's a bad idea to hard-code those bodies when i want to add more transporter-type units via mods

Isn't that asking for problems ?
There are much more differences between those two types than just the droid type. There are lots of things hard coded that are only meant for transporters.
I also don't think you want that scav helicopter to be a transporter, since then, it can fit 10 units in it...

vexed wrote:I also don't think you want that scav helicopter to be a transporter, since then, it can fit 10 units in it...

I want it to be a transporter so that it didn't need to reload and could accept DORDER_SCOUT orders.
Putting units (BaBaPeople) in it is a good idea too btw.

But it's not the problem. The problem is that currently i can't produce a transporter-type droid at all on master via JS.

Well, curiously enough, this question has an answer. Add to the chopper body description in body.ini, ???, PROFIT. The droidType is now auto-detected as transporter. That is why producing regular transporters always worked well.

Is there a page somewhere that describes body.ini? If not, it might be worth creating one.

There seems to be an ongoing increase in the number of people becoming interested in modding the game and such docs would likely help onramp them to productive modding.

aubergine wrote:Is there a page somewhere that describes body.ini? If not, it might be worth creating one.

If you make one, I'd be happy to add what I know to it.

Per wrote:

aubergine wrote:Is there a page somewhere that describes body.ini? If not, it might be worth creating one.

If you make one, I'd be happy to add what I know to it.

https://warzone.atlassian.net/wiki/display/mod/body.ini

flameModel: The 3D model (PIE) filename for the VTOL jet effect for that body.

size: How 'big' the body is.

LIGHT
MEDIUM
HEAVY
SUPER HEAVY

This determines which 3D propulsion model will be used when a propulsion component is added to the body.
(propulsion for each body is defined in bodypropulsionimd.txt)
This determines what sort of factory (number of modules) a specific type of body can be produced from, and also determines how big its 'collision model' is. (acts like a collision model between droids, spawn in a bunch of viper bodied droids with the viper set to SUPER HEAVY and they'll keep quite a big distance form one another)

The SUPER HEAVY body size is used by the campaign transport. And units of this body type can only be produced by a factory with a further module over the initial two. This could be done by using the debug menu to try and build a module on a fully upgraded factory. Said factory would then be able to produce SUPER HEAVY units (don't know if this still works).

Strings with asterisks around them are 'Don't translate these', usually for strings the player will never see, e.g., unused research or map features.

Thanks - updated

There's also a body.txt - what's that about, it looks like it duplicates some of the stuff in body.ini?

body.txt doesn't exist in master; body.ini replaced it.
body.txt is still there in 3.1 though.
droidType field is not present in body.txt, and it is not needed in 3.1, for the reasons mentioned above.