js api: how to get detailed structure / droid info?

[aubergine]

Could some new properties be added to droids / structures?

For droids:

* .propulsionType
* .body
* .turret1
* .turret2 (only applicable for Dragon currently)

Use case:

I want to know what the enemy is producing and can't rely on .name. Seeing what enemy creates in more detail will allow AI to better adapt to gameplay situation.

For structures:

* .structID (eg. P0-AASite-SAM2)

And ideally (I don't know if the game has this level of detail internally):

* .base (tower, emplacement, pit, bunker, hardpoint, etc?)
* .turret (howitzer, hellstorm, sensor, wide angle sensor, etc?)

Use case:

Currently there is a vast array of structures that get a .stattype == DEFENCE. I need to know more specifically, what sort of defence? Is it a sensor (and if so, what sort), is it artillery (and what sort), etc.

I can deduce this information from the .name property, however it's going to be a somewhat crufty set of code to do that.

Knowing this is useful not just when assessing enemy defences, but also when dealing with my own defences. As NoQ found on his nullbot AI, he needs a way to determine how many sensors he's built, for example.

Economic factors:

I'd also like to experiment with an AI that makes decisions based on economic factors - eg. how much something cost to build.

Could a new property be added to droids/structures:

* .cost (total cost of the droid/structure)

Or have a getCost(obj) function that returns the cost of the passed in object?

If the other new properties were added (listed earlier in this post) then again I could deduce the cost of something by using lookup tables, etc. The issue there is that those tables will quickly become out of date, and they won't know about any custom units added by mods, etc.

[Emdek]

I would say that to be future proof there should be .turrets as array.

[aubergine]

Yup, good point. And consistency reduces code bloat...

Many years ago, I wrote a sort of XML version of JSON in Flash ActionScript 4 *shudder*. Some elements could be either an object or an array of objects. While doing that seemed like a good idea at the time, it mean that all code interacting with it had to first check whether an array was being used or not = massive code bloat. In the end we changed it so that it was always an array, even if that array only contained one object, and reduced code bloat / complexity by about 30% as a result.

[Per]

Cost has been added as a property to both droids and structures ('cost' property). It does not factor in the cost of modules, but should otherwise be quite accurate. 3.2+ only.

[aubergine]

Awesome! Thanks as always Per!

Will it be possible to get those other properties - propulsion, turret, etc? That will allow AIs to better understand what the enemy is using (a human player can see on their screen what weapons the enemy is attacking with - currently the AI is pretty much blind in that respect).

[NoQ]

Yeah, i'd also like to have a certain info on defensive structures (at least to figure out if it's artillery or if it's (dedicated) anti-air).

[Per]

Some things are easier to add than others But I am working on them.

Both structures and droids now have: canHitGround, canHitAir, isSensor, isCB, isRadarDetector, and range (maximum of all weapons).

I'm not sure how to tell if something is "artillery" or not (unless its name is actually artillery). Do you mean if the weapon(s) are indirect?

[Emdek]

Per, wouldn't be enum based flags better than lots of bool returning methods?

[Per]

Those are not methods.

I considered bit flags, but I'm not sure how used javascript programmers are with bit operators.

[aubergine]

@Per - yes, knowing if weapon is indirect is very useful.

However, what I really want is to know the ID of the weapon/system that's attached to a structure/droid.

For example, how do I know if a droid/structure has a flamer on it? Or, if it's indirect weapon, how do I work out what sort of range it could have?

@Emdek - while enum-based flags would help C++ code create the game objects for JS API quicker, I'm not sure it will benefit anyone in the long run because all that will happen is the code required to understand those enum's will have to move to the javascript and will likely be repeated many times.

@Per - it's fairly easy to work with bit operators in JS, but some may struggle with them. With my VAULT abstraction layer, I could easily create boolean properties based on bit flags, so maybe that's not an issue?

[Emdek]

Per, even in SQL you can use bit operations.
This is best way to avoid API cluttering.

[milo christiansen]

But some of us hate bit operators because we never use them often so we didn't memorize exactly what they do I suppose we could learn but a string property is much nicer.

There's no question what your doing when you check unit.Propulsion === "hover".

[Emdek]

Operator & is very easy to use.
Also more efficient (but that is not real issue).

[Per]

I've added .hasIndirect to say whether any of the game object's weapons are indirect type (like artillery). Also fixed .armed and .range bugs.