@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.
A scripting guide once wrote:
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.