Getting game version from JS API?

[aubergine]

Is it possible to get game version from the JS API?

This would allow me to make a mod that works across several versions of the game to make end-user experience better because it avoids the need for multiple versions of a mod - the mod can internally adapt to differences in API between game versions.

[Per]

The global variable 'version' contains the version number of the game.

(Sorry to be so late to reply to this.)

[aubergine]

I think you replied already in another thread and it's in the JS API doc so no worries

BTW, is there a URL to get latest JS API pdf file? I'm not sure how it's created...

[dak180]

I think you replied already in another thread and it's in the JS API doc so no worries

BTW, is there a URL to get latest JS API pdf file? I'm not sure how it's created...

You should be able to open the pdf from the help menu (mac build) from the most recent revision of master in git.

If you have Xcode installed you should be able to open the project and build it just by opening the project file and telling it to build (see CompileGuideMac for full details).

[aubergine]

Help menu?

As for building the game, I'm not keen on installing too much stuff on my mac as I use it primarily for work. I'm pondering getting a mac mini and hosting it somewhere so that it can be used for nightly builds but it's quite an expensive option.

Perhaps veering off-topic, but would the devs be interested in an alternate approach to documenting the JS API?

I've set up a wiki to document my Util and Vault libraries (the vault does so much stuff I needed to start documenting it's features just so I could remember them as I have very bad memory like that blue fish in Finding Nemo) and also my EggPlant AI. Because I kept needed to refer to JS API in my I created another wiki space and created pages in it for every function, event, constant and global... which gave me the idea that a wiki might be a good approach to the docu as more people could work on it and put in examples and so on?

[Emdek]

aubergine, probably HTML output similar to that done by Doxygen hosted somewhere, with ability to comment it (easy to enhance), would be best idea.
But I don't know which tool is used to extract current information (I could try to judge from layout of PDF file, but I've still didn't manage to get it ).

[Per]

The extraction tool is custom made. Actually, just a couple of lines of grep and sed...

cybersphinx found a way to generate HTML output from it. We could look at a way to host that automatically.

[Emdek]

So... Should I add this to my wz TODO list?

[aubergine]

So, I've continued on with manually writing up infos in my wiki (not publicly accessible yet) - my main reason being that the wiki pages make it much easier to add examples, links to other information and allow collaborative authoring + discussions which is always a good thing for docu.

While the wiki pages won't update automatically, I still feel they are a viable way to deliver the information because the API doesn't change fast enough to outpace edits to the wiki. Once in the wiki, quick reference guides can be created - for example, a page that gives me a quick overview of all droid related stuff with links to relevant API docs.

[Emdek]

It is possible to integrate this with wiki, but will take more work.
For example dynamically extracted part could be put as variable to be substitute when parsing, like BBCode.

[aubergine]

Uhm, that's part of the point though - I'm not sure any sort of integration is needed. If a PDF can already be output based on the code comments, then that PDF can just be uploaded to wiki from time to time (there is an API for uploading attachments). The wiki also allows PDF file to be embedded inside the wiki page so it can be viewed directly in the browser without downloading the PDF.

The wiki page versions of the docs will be completely different content, written in a different way with examples, images, videos, tables, etc. The extra flexibility gained this way allows much richer content to be created.

Note: The wiki is not the same as http://developer.wz2100.net - it's different software (Confluence) with Java back-end.

[Emdek]

I prefer textual data (including HTML), PDF has a bit bigger requirements.
Also I would stick with wiki like in Trac or simple custom one.