Page 1 of 2

What is missing?

Posted: 30 Jun 2012, 15:28
by Per
I have been rather busy lately, and so I think I've lost track of what is needed to be done in regards to expanding the JS API.

I know that there is still a bug in the chat command that I need to fix.

Anything else that is missing / broken?

Edit: Keep this thread on topic, please. This is only for javascript API related things. All other posts will be removed.

Re: What is missing?

Posted: 30 Jun 2012, 15:51
by NoQ
Per: If you just focus on fixing the chat, i will be really thankful. There are a huge lot of things i'm dreaming to do with it!

playSound(), research data

Posted: 30 Jun 2012, 23:13
by aubergine
The beacon display feature of playSound() was broken last time I checked - despite specifying x,y,z params no beacon was being shown on the map/minimap.

If you could extend research objects to contain more data about the tech (eg. what does it affect, and in what way, etc) that would also be much appreciated.

Droid settings

Posted: 01 Jul 2012, 23:54
by aubergine
Ah, almost forgot - the ability to set states that you see on unit/factory right click menus.

New properties on droid objects:

.attackMode -- Attack mode: Fire at will, return fire or hold fire
.retreatMode -- Retreat mode: Do or die, retreat medium damage, retreat light damage
.rangeMode -- Target range: Short, optimal, long

I think that's all of them, have I missed any?

New constants:


Currently AI has no way to do this other than lots of manual coding around attacked and seen events.

Working with transporters

Posted: 02 Jul 2012, 23:43
by aubergine
Transports are currently a bit tedious to work with via JS API - some new properties and events would make life much easier...

New properties on DROID objects:


.cargoSlots -- how many slots does the transport have? null if not a transport
.cargoUsed -- how many slots are currently filled? null if not a transport

On all droids:

.bodySize -- size of a droids' body: SMALL, MEDIUM, LARGE, SUPER

Note: If there was some way to query the stats I could determine this by looking at the existing .body property and seeing what size is associated with it in the stats.

NoQ mentioned that in skirmish mode, a medium tank will use two cargo slots, a large tank will use 3 slots. So the .bodySize will be useful for determining how many slots a droid will use if it's put on to a transport.


A new function to get a list of droids on a transport:

* enumCargo(transport) -- returns an array of droid objects that are in the transport's cargo hold. If no droids on the transport, the array is empty.


* eventEmbark(droid,transport) -- triggered when a droid embarks a transport
* eventDisembark(droid,transport) -- triggered when a droid disembarks a transport
* eventTransportLanded(transport) -- triggered when a transporter has landed (so I know I can disembark it's droids)

Related topics:

* Amount of transport slots depending on vehicle weight / type
* Droid limits in transporter (size based)

Targets / destinations

Posted: 02 Jul 2012, 23:57
by aubergine
I'm not sure if it was added yet, but knowing the destination / target of an object would be incredibly useful.

For example, if an enemy droid is detected I can see if it's heading towards me and react accordingly. The human can do this easily just by looking at the screen / radar, but currently the only way an AI could do this is to sample the enemy droid position at two points in time and then work out the general direction -- that would be crufty and unreliable (particularly considering the AI knows nothing about the map terrain) so it seems more logical to just provide the AI with the relevant target/destination.

New property on droid/structure objects:

.target - a POSITION, DROID, STRUCTURE or FEATURE object defining the current target or destination associated with a droids current .order

Depending on what I used to order the droid, the .target would be:

* orderDroidLoc() sets .target to a POSITION object
* orderDroid() sets .target to a POSITION or STRUCTURE object as applicable
* orderDroidObj() sets .target to a STRUCTURE, DROID or FEATURE object as applicable
* orderDroidBuild sets .target to a POSITION or STRUCTURE object as applicable
* null if not applicable

In cases where .target is no longer relevant, it would be set to null. For example, I order droid to attack something and it destroys that something, the .target would become null. Not sure what would happen for VTOLs while rearming - their .target should remain the thing they were told to destroy or the position they were circling around, etc?

Re: What is missing?

Posted: 03 Jul 2012, 19:05
by NoQ
aubergine ... please allow him to finish the chat first :cry: :cry: :cry:


Additional Events

Posted: 04 Jul 2012, 13:30
by aubergine
I assume that will be the priority, but no harm in listing the other missing items :) Speaking of which...

Additional events for Situation Reporting:

* eventObjectSelected(obj,by) -- triggered when a droid/structure is selected
* eventObjectOrdered(obj,by,order) -- triggered when a droid/structure is given an order

"by" would either be a player object (if player directly ordered the object) or a structure/droid object (eg. if order came from sensor/commander to which the object is assigned).

An example could be that if arty is set to fire at enemy because a CB radar tells it to, I'd be able to play "Counter Battery Returning Fire" audio. Or if human tells VTOLs to move somewhere, I can play "On our way!" audio.

For more information & related discussion see: Hard-coded Audio Messages

Re: What is missing?

Posted: 05 Jul 2012, 18:10
by aubergine
It would be useful to know what game mode the script is running in (and for rules.js also)...

New global:


*DEATHMATCH doesn't exist yet but I will be finding out what Pumpkins plans for it were and maybe we'll see it one day...

We can sort of differentiate SKIRMISH and CHALLENGE via subtle differences in things like starting power (but not particularly reliably) and we can scan through playerData array to work out if there is more than one human to identify MP games, but these are somewhat cludgey ways of determining game mode.

Re: Working with transporters

Posted: 18 Jan 2013, 22:47
by Per
aubergine wrote: New properties on DROID objects:


.cargoSlots -- how many slots does the transport have? null if not a transport
.cargoUsed -- how many slots are currently filled? null if not a transport

On all droids:

.bodySize -- size of a droids' body
Done. (Undefined if not a transport.)

Re: What is missing?

Posted: 18 Jan 2013, 22:50
by aubergine
Awesome! Does this mean we are getting closer to being able to access a group associated with transports?

Re: What is missing?

Posted: 19 Jan 2013, 04:00
by aubergine
Just been looking at bodySize -- does that relate to the amount of cargo space used directly?

So if bodySize == 2, that uses up 2 cargo slots?

Also, just noticed that .cargoSlots is using calcRemainingCapacity() -- so does .cargoSlots return number of free slots? (I initially thought it was total slots) -- if it's just number of remaining slots then perhaps rename to .cargoLeft, so total cargo space = cargoUsed + cargoLeft

Re: What is missing?

Posted: 19 Jan 2013, 14:30
by Per
Seems that I was a bit quick on the transporter stuff. New changes:

Added enumCargo(psDroid) -- Returns an array of droid objects inside given transport.

Added to droids:
cargoCapacity -- Defined for transporters only: Total cargo capacity (number of items that will fit may depend on their size).
cargoSpace -- Defined for transporters only: Cargo capacity left.
cargoCount -- Defined for transporters only: Number of individual items in the cargo hold.
cargoSize -- The amount of cargo space the droid will take inside a transport. (For campaign, this is 1. For multiplayer, this is identical to body size.)

cargoSlots and cargoUsed removed.

Also added .weapons array to droids, which give .name and .lastFired for each weapon. And new function getWeaponInfo(weapon name), which only has a few select properties for now.

Re: What is missing?

Posted: 19 Jan 2013, 14:54
by aubergine
Awesome! :D

Looking forward to a .systems and getSystemInfo() ;)

Re: What is missing?

Posted: 19 Jan 2013, 14:59
by NoQ
Ah, uhm, yeah, that just reminds me. I had a few ideas to improve my AI's sensor management.
  • eventSensorActive(sensor, target); // fires when a sensor droid or structure starts targeting a certain object
    eventSensorTargetChanged(sensor, target); // not sure if necessary
    eventSensorInactive(sensor); // when a sensor has no more targets to target
    object.sensorIsActive // a property
This is probably mostly interesting for stuff like CB sensors. Suppose an attack group has a CB sensor tank and a few mobile howitzers. Then enemy howitzer emplacements start shooting at the group. Then eventSensorActive is triggered for the CB sensor tank, and the AI instantly attaches all howitzers to CB (and also keeps attaching newly produced howitzers to this CB, depending on sensorIsActive property). Once shooting is done, eventSensorInactive fires, and howitzers detach from the sensor and keep moving.