Javascript API documentation

[Per]

I am starting to generate the API documentation for the new scripting system based on Javascript. It is in a PDF where most of its content is automatically generated from documentation inside the source code. This is a work in progress - it is not recommended to start working with this scripting system yet.

However, if you have any feedback on the documentation or the API design, feel free to post your thoughts in this thread.

The new scripting system is already being used to determine winners and losers, set up bases and starting techs, and control scavengers. I am also in the process of converting the Semperfi AI to the new system -- it currently builds some trucks and does some research, and that is about it. Be patient, please

javascript.pdf

(71.48 KiB) Downloaded 936 times

Master docs autogenerated by the buildbot:
One page: http://buildbot.wz2100.net/files/javasc ... cript.html
Multi page table of contents: http://buildbot.wz2100.net/files/javasc ... index.html

[Chojun]

/aside: LaTeX reminds me of my school days

[milo christiansen]

Yay!!!!!! just what I've been waiting for

I think I shall go start the Per fan club

[cybersphinx]

Don't know about the formatting needs, but since we use that anyway it could be in asciidoc format instead of latex.

[NoQ]

DORDER_PATROL

Hmm, so all those "secondaries" are now deprecated? Also, what about some "DORDER_REARM" for VTOLs? (a wrong place to ask?)
Well, anyway, that's nice to hear! I don't care about format as long as it's searchable (:

/aside: LaTeX reminds me of my school days

(:

[Per]

There are some orders missing. I am mostly adding stuff as needed at the moment. Not sure how much of the underlying complexity that should be exposed, as some of it is rather painful. If you read carefully, you'll see that I've removed templates from the scripting system -- you now just pass the list of components directly to the factory, and the underlying code handles the templates stuff for you.

[milo christiansen]

It would be really nice if some cam oriented stuff got in sometime... The biggest need would be unit spawning.

Other than the missing stuff it looks very well done, reading the docs is like reading a Christmas list of things I wanted

Is there any way to list a JavaScript script in a wrf at this time?

[Per]

Is there any way to list a JavaScript script in a wrf at this time?

Yes. Just use the "JAVASCRIPT" keyword.

It would be really nice if some cam oriented stuff got in sometime... The biggest need would be unit spawning.

Ok, then I just added unit spawning. See addDroid() in the new version of the doc attached below. It creates a unit out of the supplied components. Does that look ok?

Anything else you need - just ask.

javascript.pdf

(74.13 KiB) Downloaded 635 times

[milo christiansen]

Cool, Thanks!

Anything else you need - just ask.

Well everything that's in WZScript might be nice

[NoQ]

3.4 eventDroidBuilt
...
3.5 eventDroidBuilt

Typo or actually overriden function? Cause "eventStructureBuilt" looks right here.

pickStructLocation(droid, structure type, x, y)

For some time I've been curious: what is the "droid" parameter good for?

[Per]

Yeah, typo. Will fix. The droid parameter for pickStructLocation() is to make sure we suggest a placement that is (at least theoretically) reachable by that droid.

[Goth Zagog-Thou]

How are INTMESSAGE's going to be handled? Same way as before?

[Per]

How are INTMESSAGE's going to be handled? Same way as before?

Maybe. Got any better ideas?

[Goth Zagog-Thou]

Actually.. yeah. At least partially.

Let's take beacons, for example. You know, the ones on missions that are dropped onto the map to show the player mission objectives and things? Currently requires:

1.) an entry in the .vlo
2.) an entry in the .slo
3.) a PROX.txt file of some sort, containing all the particulars of that beacon
4.) another .txt file that mirrors it (and it IS required to be there for some reason)
5.) yet ANOTHER .txt file that shows what the beacon is named when the player clicks on it.

All of the above should be handled by a single command in the script.

My proposal:

Code: Select all

addMarker (internalName, location[x], location[y], location[z], color[red, green, blue, and perhaps yellow too?], soundFile[something.ogg], "[message(in quotes)]") 

and of course, the command to remove it:

Code: Select all

removeMarker (internalName)

For other messages, we can simply use console(string) and do any text output needs that way.

That's my idea.

[vexed]

They had a reason for all that ugliness... Not sure that can be done like that.

Also, I did a quick fastplay tutorial conversion to JS to see how it was like, it did work IIRC, but I don't think any of that code made it into the codebase with all the changes that were needed.
(It was a 1:1 conversion more or less, not the "correct" way so to speak)