3.2 JS API Wishlist :)

[aubergine]

@NoQ the docs would read better as:

Code: Select all

+//-- Return true if a droid with a given propulsion is able to travel from x1,y1 to x2,y2. 
+//-- Does not take player built blockades into account.

[Per]

Added game object return values for addDroid and addStructure now. Also added propulsionCanReach() from NoQ. See be44aaf8429f6da22e24ca9243500e01e675177f and 958993e6091261303e8cb20b258d42b1c2c64947.

[NoQ]

tx! yay'd on irc.

[Shadow Wolf TJC]

Are you specifically looking to know what was just added or removed from the selection, or is having a list of all selected things sufficient?

More like "how" it was added to be precise. Were the droids added to the array of selected droids through drag-selection, hotkey, shift+click selection, etc?

If unit voiceovers were planned on being unhardcoded and ported to, say, rules.js, then I wouldn't want the units of a particular group to say "Group X reporting" when they were selected through a drag-selection than through a group hotkey.

[aubergine]

@NoQ/Per: That propulsionCanReach() will make hover-only and VTOL-only maps much more understandable to AIs, right from the start of the game Thanks for adding!

@Shadow: Hrm, yes, I see your point. In that case, eventUserSelectsGroup(groupNum, droidList), eventUserSelectionChange(objectList) might be the way to go?

I'm wondering if Per has some cool ideas up his sleeve though, for example, allowing an AI to select several droids and then issue commands to the selected droids (rather than needing to iterate the droids ordering each one individually)?

-----------

I'm continuing my quest to bring about the demise of the hackAddMessage() and hackRemoveMessage() functions, which would put an end to the messages/*.* millions-of-files-in-billions-of-styles tyranny.

addMessage(INTMESSAGE, MESSAGETYPE, PLAYER, PLAY_IMMEDIATE)
This adds a message to the interface for the PLAYER. INTMESSAGE is a variable defined in the values file. MESSAGETYPE is a predefined type - see Script function constants. PLAYER is the player who gets the message. PLAY_IMMEDIATE is a bool for whether to bring the Intelligence Screen up with the message immediately or just store it.
removeMessage(INTMESSAGE, MESSAGETYPE, PLAYER)
This removes a message from the interface for the PLAYER. INTMESSAGE is a variable defined in the values file. MESSAGETYPE is a predefined type - see Script function constants. PLAYER is the player who loses the message.

With recent features like add/remove beacon, we're getting closer to a point where we could ditch the messages/ folder and everything in it.

One glaring omission from the JS API is to do with adding/removing messages on the intel screen, showing/hiding intel screen, and showing a specific intel report. This could open up a massive new area of gameplay customisation -- being able to send the user nice reports, objectives, etc., via the intel screen....

addIntel(), removeIntel(), showIntelScreen(), enumIntel(), INTEL_DATA, intel object

* addIntel(intelObj[, player]) -- adds a new message to the intel screen, optionally for specific player (default to me)

* removeIntel(intelObj[, player]) -- removes a message from the intel screen, optionally for specific player (default to me)

* enumIntel([player]) -- returns a list of all inel messages, optionally for specific player (default to me)

* showIntelScreen(show[, player]) -- show the intel screen, optionally for specific player (default to me)
Note: that would require network msgs in mp games, so if player param is nightmare remove it.

* showIntelReport(intelObj[, player]) -- shows intel screen and also opens specified report.
Note: to close use showIntelScreen(false)

* INTEL_DATA -- the .type property of intel objects

* Intel Object -- I'm not entirely sure what the actual properties of this are, but here is my best guess (any help greatly appreciated!!):

.id -- unique id of the message
.type -- INTEL_DATA
.player -- which player does the report belong to?
.format -- what format is the report in? VIDEO_INTEL, TECH_INTEL, TEXT_INTEL
.topic -- what is the report about? either a research id, or topic constant
.tip -- tool tip when hovering over icon, also title of detail view window
.subject -- report subject (1st line of text)
.summary -- summary of report (2nd line of text)
.detail -- technical detail (3rd line of text)
.notes -- any other notes (4th line of text)
.text -- used for TEXT_INTEL report format
.video -- a video to play when the report is opened
.viewed -- has the report been viewed

VIDEO_INTEL means the report is just a video. Once video closes (or if not found), a text box is shown with it's transcript.

TECH_INTEL shows .video on the right, and .topic related image/model on the left.

TEXT_INTEL shows .text report

I'm not sure if the .topic would define the .format? It seems reasonable that a topic would always be reported in the same format.

[carlosjhr64]

I could use a function that returned the cost of a droid given the droid's specs. I'm aware of droid.cost. I mean a function like getDroidCost(body, propulsion, "", droidType, turret[, turret2[, turret3]]); And I don't know what "" is for.

[Per]

Added makeTemplate(player, name, body, propulsion, reserved, turrets...) that will give you a template (virtual droid) that allows you to estimate the cost of droids built from the given components (by checking its .power property).

Also changed addDroid() to no longer require the droidType parameter.

[aubergine]

What's the reserved prop for? it's been showing up in droid-related functions for about a year now...

BTW: In normal droid objects, as in droids actually on the map, their power is defined in the .cost property....

[aubergine]

getScrollParams()

IMPLEMENTED: as getScrollLimits() and setScrollLimits()

getCursorMode()

Returns the current mode of the mouse cursor:

IMAGE_CURSOR_SELECT, IMAGE_CURSOR_ATTACK, IMAGE_CURSOR_MOVE, IMAGE_CURSOR_JAM, IMAGE_CURSOR_PICKUP, IMAGE_CURSOR_DEFAULT, IMAGE_CURSOR_SEEKREPAIR, IMAGE_CURSOR_BUILD, IMAGE_CURSOR_GUARD, IMAGE_CURSOR_BRIDGE, IMAGE_CURSOR_ATTACH, IMAGE_CURSOR_LOCKON, IMAGE_CURSOR_FIX, IMAGE_CURSOR_EMBARK

Obviously only exposing applicable constants.

[aubergine]

In fact, would it be possible to rename setScrollParams() and getScrollParams() to setScrollLimits() and getScrollLimits()? -- just seems to convey what they do more accurately and simply.

[garantiertnicht]

In fact, would it be possible to rename setScrollParams() and getScrollParams() to setScrollLimits() and getScrollLimits()? -- just seems to convey what they do more accurately and simply.

Good idea but maybe made it as a copy (to keep the comalibity for older AI's and scripts)

[aubergine]

I don't think any existing JS scripts are using those functions yet. They are mainly used in campaign and we've only just started porting that to JS. Also, currently in the campaign, the scroll params are set in some weird txt file (still not found where).

If there is a script using the functions (well, function -- getScrollParams() doesn't exist) it's going to be easy to update the script with a find and replace.

[Per]

Keeping compatibility through renames is very simple, so I did that. New function getScrollLimits() added, setScrollLimits() renamed.

[aubergine]

Deprecate derrickPositions[] array -- it can't be relied on, and it's confusing:

* it's listing locations or oil resources (with or without derricks built on them), not locations of derricks = confusion
* it doesn't take map-placed derricks, or the effects that baseType setting has on those derricks, in to account
* It doesn't get updated during the game

As a result, we all use enumFeature() to find oil resources, and enumStruct() to find derricks, so there's little point in having the derrickPositions[] array IMHO.

[Per]

Deprecate derrickPositions[] array -- it can't be relied on, and it's confusing:

* it's listing locations or oil resources (with or without derricks built on them), not locations of derricks = confusion
* it doesn't take map-placed derricks, or the effects that baseType setting has on those derricks, in to account
* It doesn't get updated during the game

As a result, we all use enumFeature() to find oil resources, and enumStruct() to find derricks, so there's little point in having the derrickPositions[] array IMHO.

I don't understand this. It does not have to be updated during the game, as new oil resources cannot be added or removed during the game (only converted back/forth from derricks). It only tells you the position of a derrick, not what it is, so baseType and map preplacements are irrelevant. On the other hand, using enumFeature() and enumStruct() is a far slower alternative.

Is the problem that there is no js function for getting the object at the given coordinates to find out what the position means?