3.2 JS API Wishlist :)

For AI and campaign script related discussions and questions

Re: 3.2 JS API Wishlist :)

Postby aubergine » 16 Jan 2013, 10:02

@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.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
aubergine
Professional
Professional
 
Posts: 3459
Joined: 10 Oct 2010, 00:58

Re: 3.2 JS API Wishlist :)

Postby Per » 16 Jan 2013, 18:57

Added game object return values for addDroid and addStructure now. Also added propulsionCanReach() from NoQ. See be44aaf8429f6da22e24ca9243500e01e675177f and 958993e6091261303e8cb20b258d42b1c2c64947.
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
 
Posts: 3745
Joined: 03 Aug 2006, 19:39

Re: 3.2 JS API Wishlist :)

Postby NoQ » 16 Jan 2013, 19:04

tx! yay'd on irc.
User avatar
NoQ
Special
Special
 
Posts: 6159
Joined: 24 Dec 2009, 11:35
Location: /var/zone

Re: 3.2 JS API Wishlist :)

Postby Shadow Wolf TJC » 16 Jan 2013, 20:53

aubergine wrote: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.
Creator of Warzone 2100: Contingency!
Founder of Wikizone 2100: http://wikizone2100.wikia.com/wiki/Wikizone_2100
User avatar
Shadow Wolf TJC
Regular
Regular
 
Posts: 1047
Joined: 16 Apr 2011, 05:12
Location: Raleigh, NC

Re: 3.2 JS API Wishlist :)

Postby aubergine » 16 Jan 2013, 21:49

@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.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
aubergine
Professional
Professional
 
Posts: 3459
Joined: 10 Oct 2010, 00:58

Re: 3.2 JS API Wishlist :)

Postby carlosjhr64 » 17 Jan 2013, 17:41

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. :lol2:
carlosjhr64
New user
 
Posts: 3
Joined: 24 Feb 2008, 21:47

Re: 3.2 JS API Wishlist :)

Postby Per » 17 Jan 2013, 19:27

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.
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
 
Posts: 3745
Joined: 03 Aug 2006, 19:39

Re: 3.2 JS API Wishlist :)

Postby aubergine » 17 Jan 2013, 20:35

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....
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
aubergine
Professional
Professional
 
Posts: 3459
Joined: 10 Oct 2010, 00:58

Re: 3.2 JS API Wishlist :)

Postby aubergine » 18 Jan 2013, 19:46

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.
Last edited by aubergine on 18 Jan 2013, 22:17, edited 1 time in total.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
aubergine
Professional
Professional
 
Posts: 3459
Joined: 10 Oct 2010, 00:58

Re: 3.2 JS API Wishlist :)

Postby aubergine » 18 Jan 2013, 20:09

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.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
aubergine
Professional
Professional
 
Posts: 3459
Joined: 10 Oct 2010, 00:58

Re: 3.2 JS API Wishlist :)

Postby garantiertnicht » 18 Jan 2013, 20:37

aubergine wrote: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)
Player Name: "garantiertnichtDE"
You can talk to me DEUTSCH.
User avatar
garantiertnicht
Greenhorn
 
Posts: 13
Joined: 16 Sep 2010, 18:44
Location: Deutschland (Germany)

Re: 3.2 JS API Wishlist :)

Postby aubergine » 18 Jan 2013, 21:19

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.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
aubergine
Professional
Professional
 
Posts: 3459
Joined: 10 Oct 2010, 00:58

Re: 3.2 JS API Wishlist :)

Postby Per » 18 Jan 2013, 21:49

Keeping compatibility through renames is very simple, so I did that. New function getScrollLimits() added, setScrollLimits() renamed.
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
 
Posts: 3745
Joined: 03 Aug 2006, 19:39

Re: 3.2 JS API Wishlist :)

Postby aubergine » 21 Jan 2013, 08:50

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.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
aubergine
Professional
Professional
 
Posts: 3459
Joined: 10 Oct 2010, 00:58

Re: 3.2 JS API Wishlist :)

Postby Per » 21 Jan 2013, 10:55

aubergine wrote: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?
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
 
Posts: 3745
Joined: 03 Aug 2006, 19:39

PreviousNext

Return to Scripting