Warzone 2100 Forums

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


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

/aside: LaTeX reminds me of my school days

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

I think I shall go start the Per fan club

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

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

(:

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.

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?

milo christiansen wrote:Is there any way to list a JavaScript script in a wrf at this time?

Yes. Just use the "JAVASCRIPT" keyword.

milo christiansen wrote: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.

Cool, Thanks!

Per wrote:Anything else you need - just ask.

Well everything that's in WZScript might be nice

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?

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.

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

Goth Zagog-Thou wrote:How are INTMESSAGE's going to be handled? Same way as before?

Maybe. Got any better ideas?

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: and of course, the command to remove it:
For other messages, we can simply use console(string) and do any text output needs that way.

That's my idea.

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)