Page 9 of 15

Re: 3.2 JS API Wishlist :)

Posted: 09 Dec 2012, 12:33
by aubergine
listDroid(), listStruct(), listFeature() functions

They'd take same params as their enum() counterparts, but instead of returning full game objects they'd just return simplified objects.

A simplified object would be:

* id
* type
* name (for feature objects) / droidType (for droid objects) / stattype (for structure and certain feature objects)
* x, y, z
* health
* armed (if applicable)
* order (if applicable)
* selected (if applicable)

Why these functions? Increasingly, scripts are wanting to cache objects and define extra properties on the cached objects. A set of functions that return much less information will allow crucial information to be updated on a more regular basis, with more detailed updates being done only on an as-needed basis.

For example, I might have a cache of my own droids. When droids are built I add to the list, when they are destroyed/transferred/recycled I remove from the list. I'd want to get updated info on their location, health and order quite frequently, but all the other info (such as armour, born, turrets, etc) doesn't change much, if at all, and would only be retrieved on an as-needed basis (and even then probably in batches of a few droids at a time).

In many cases, I don't need all the other info, even when listing enemy droids, it seems wasteful to have the JS API generate a large number of properties when I only want basic information.

Re: 3.2 JS API Wishlist :)

Posted: 09 Dec 2012, 12:47
by aubergine
gameType global

Expose the C++ game.type value to Javascript -- without it we're having to do all sorts of kludges to work out if our script is in skirmish, mp, campaign, challenge, etc. Having a global that clearly indicates what game type we're in would be most appreciated :)

Re: 3.2 JS API Wishlist :)

Posted: 09 Dec 2012, 23:28
by Per
Per wrote:Features have always been owned by player zero. Where do you find otherwise?
Correction, features are no longer owned by player zero. This is a recent change that I've missed.

However, for the purposes of hackGetObj(), this does not matter, as the contents of the player parameter is simply ignored when dealing with features. Pass whatever you like... but I recommend -1 because that will make your scripts crash if the value is ever used, rather than give strange errors :ninja:

Re: 3.2 JS API Wishlist :)

Posted: 10 Dec 2012, 00:57
by aubergine
So the player param on hackGetObj() should be -1 regardless of object type or owning player, and also -1 for features?

Re: 3.2 JS API Wishlist :)

Posted: 10 Dec 2012, 01:10
by Per
aubergine wrote:So the player param on hackGetObj() should be -1 regardless of object type or owning player, and also -1 for features?
Sorry, what I wrote was not clear at all. I've updated the post to make it clearer that I only meant that comment related to features. For droids and structures, the correct player parameter is entirely crucial!

Re: 3.2 JS API Wishlist :)

Posted: 10 Dec 2012, 01:15
by aubergine
Ok, that is somewhat clearer. If I understand correctly, when getting feature objects with hackGetObj(), I should specify a player of -1 to ensure my script crashes rather than causing strange errors?
Per wrote:Pass whatever you like... but I recommend -1 because that will make your scripts crash if the value is ever used, rather than give strange errors

Re: 3.2 JS API Wishlist :)

Posted: 11 Dec 2012, 01:27
by aubergine
enumBlips() .type

Objects returned by enumBlips() could do with a .type = POSITION to be more consistent with rest of JS API.

Re: 3.2 JS API Wishlist :)

Posted: 13 Dec 2012, 04:57
by aubergine
Stuff to make working with transports easier


Also, what propulsion / turret should be used when creating one?

Re: 3.2 JS API Wishlist :)

Posted: 15 Dec 2012, 13:10
by aubergine
setTimer() and queue() -- ability to pass string instead of game object

IMPLEMENTED: Can now pass in a string instead of a game object!

Re: 3.2 JS API Wishlist :)

Posted: 18 Dec 2012, 08:06
by aubergine
I've been looking at c001.ogg and wondering how we might recreate it in the game. We've already got most of what's required, but there are a few additional things that would be needed...

playVideo( filename[, windowed] ) and update to eventVideoDone()

Note: These will allow deprecation of hackAddMessage() and hackRemoveMessage() ;)

Plays a video, by default full screen. When playing full screen, the game is paused in the background until video completes.

If windowed param specified, the video plays as an overlay in the game, with the game still playing and accessible in the background. Parameter value defines where the video is played, DISPLAY_TOP_LEFT, DISPLAY_TOP_RIGHT, DISPLAY_BOTTOM_LEFT, DISPLAY_BOTTOM_RIGHT, DISPLAY_CENTRE -- taking in to consideration where normal game elements appear (eg. build menu, factory production, minimap, mission timer, transport status, etc).

In windowed mode, video plays at a fairly small resolution - it's more for effect than detail, the audio usually contains the detail.

Also, in widowed mode, the game music volume is faded out a little while the video plays (not all videos will have audio so fading probably just 10% or so).

The video would be semi-transparent, if possible, so it appears like a HUD display floating above the map.

When the video ends, the game returns to normal and eventVideoDone( filename ) is triggered (note new 'filename' param).

Videos are primarily used in campaign, the windowed mode will enable us to have the game continue while status updates are provided (eg. video explaining new tech).

Only one video can be played at a time.

playImage( filename, windowed ), removeImage() and eventImageDone( filename )

Works similar to playVideo, but always in windowed mode. Displays an image, semi-transparently, as an overlay on the game.

The image can be dismissed by clicking it or a call to removeImage(). eventImageDone() is triggered when the image is dismissed.

Only one image can be active at a time.

playMusic( [filename] ) and eventMusicDone( filename )

Fades out current music and plays the specified audio file. When the audio file finishes, eventMusicDone( filename ) is triggered (filename being the music file that just finished, this is very helpful when sequencing music).

A new music track can be started during eventMusicDone() if desired.

Calling playMusic() without any parameter has the effect of starting the music.wpl (normal in-game play list).

In many cases, playMusic() will be used to play atmospheric effects or even mission briefing audio rather than actual music.

fadeOut( [duration] ), fadeIn( [duration] ) and eventFadeDone( state )

fadeOut(): Fades the entire interface to black (including any windowed image / video ).

fadeIn(): The opposite of fadeOut()

The 'duration' param is optional, defaults to 1500 milliseconds.

After transition is complete, eventFadeDone() is triggered. The 'state' param is false if the interface has just been faded out, or true if the interface has just been returned to normal.

Audio and, if applicable, video, keeps playing while the fading takes place. The game continues in the background.

Note: It's possible that setSunIntensity() could be used to do this, maybe fadeIn() and fadeOut() could just be helper methods to make sun intensity transitions a bit more fluid by doing the transition in C++ rather than JS (where timer is limited to 100ms blocks).

Re: 3.2 JS API Wishlist :)

Posted: 21 Dec 2012, 17:45
by aubergine
Move initial camera view to rules.js

Could initial camera position be moved to rules.js?

Code: Select all

var pos = startPositions[playerData[me].position];
centreView( pos.x, pos.y );
Note: In campaigns, camera position is set by mission script (eg. cam1a.js) not rules.js

Re: 3.2 JS API Wishlist :)

Posted: 21 Dec 2012, 18:00
by NoQ
Nice idea. Cause on some maps trucks and command center are very far from each other, and sometimes you fail to see your trucks in no bases mode ... not sure about the exact mechanism, but sometimes it happens. Could be nice to play with it.

Re: 3.2 JS API Wishlist :)

Posted: 21 Dec 2012, 20:34
by aubergine
New/altered camera features & ability to radar blip objects...

See: viewtopic.php?f=35&t=10427

blip(gameObject[, turnOff]) -- force a game object to emit a red radar blip while "un-seen" to the player. Similar effect to numerous campaign videos where they indicate location of enemy troops/etc with red radar pings. If turnOff == true, blip is turned off.

terrainLight(x, y, range[, time]) -- light up some terrain, optionally fading in the light over a given time (in ms). Does not show any DROID or STRUCTURE objects (but blips would be shown if set). Call the function with no parameters to turn off the light. Only one terrain light can be in effect at any given time.

Re: 3.2 JS API Wishlist :)

Posted: 25 Dec 2012, 02:25
by aubergine
setSunIntensity() - ability to set it for terrain and base foundations as well

Currently setSunIntensity() only affects PIE models on the map (droids, features, structures). It doesn't affect terrain or base structure foundations.

Using crazy values to illustrate what the current function affects:
If it could set the lighting intensity for terrain and base foundations as well (possibly some way to specify what it gets applied to?) it would allow much more flexible custom map lighting scenarios. For example, ambient rgb could be set fairly high to make stuff appear whiter when it's snowing, or set lower to make stuff appear duller when it's cloudy or raining. Short bursts of high intensity blue-ish white could be used for thunder effects during rain storms.

Re: 3.2 JS API Wishlist :)

Posted: 27 Dec 2012, 01:24
by aubergine
Ability to get/set x, y, z and scale of objects, plus a few other bits...

setX(object, x), setY(object, y), setZ(object, z)

setScale(object, scale), getScale(object)

setOpacity(object, alpha), getOpacity(object)

alwaysFaceCamera(object) -- makes the object always face camera -- although this would be better in the .ini file that defines the object

setTexture(object, filename) -- apply a specific texture to an object

Some example uses:

* Creating floating labels for things -- a rectangular object with a texture containing some text, always facing camera
* Creating clouds, sun, moon, stars -- would facilitate much more advanced skies
* Creating scene captions for cinematics

There are likely better ways to do the above, I'm totally open to suggestions.