3.2 JS API Wishlist :)

[aubergine]

For stuff I don't want to save I create a global function and then use it as if it were an object

I was considering pre/post events for las sat strikes and save, but was worried it might be overkill. I guess it's more semantically correct to separate them out, but I usually just use events to trigger code elsewhere (eg. trigger code within an OO structure), for example:

Code: Select all

function eventGameSave(before) {
  if (before) { // generate saveable data objects
    PersistanceMgr.prepareForSave();
  } else { // clear down saveable data objects
    PersistanceMgr.tidyAfterSave();
  }
}

function eventLaserSatelliteStrike(from, warning, x, y) {
  if (warning) { // lassat about to fire
    droidMgr.scatterDroids();
  } else { // recover from possible damage
    sectors.getSector(x,y).initiateRepairs();
  }
}

I like the idea of an eventLoad() but at what point would it be called - before or after eventGameInit / eventStartLevel?

I currently handle the load scenario like this:

Code: Select all

function eventStartLevel() {
  if (typeof loaded != "undefined") PersistanceMgr.gameLoaded();
  eval(null,"var loaded = true;"); // if game is saved then loaded, we'll detect this next time evnetStartLevel runs
}

That approach is flexible because I can choose whether to do it in eventGameInit or eventStartLevel, or even before eventGameInit, if desired, just by running the code outside of an event.

[Duha]

For stuff I don't want to save I create a global function and then use it as if it were an object

hm. Propably only instances crushes save. (var test = new PersistanceMgr())

I was considering pre/post events for las sat strikes and save, but was worried it might be overkill. I guess it's more semantically correct to separate them out, but I usually just use events to trigger code elsewhere (eg. trigger code within an OO structure), for example:

Code: Select all

function eventGameSave(before) {
  if (before) { // generate saveable data objects
    PersistanceMgr.prepareForSave();
  } else { // clear down saveable data objects
    PersistanceMgr.tidyAfterSave();
  }
}

It looks more readable:

Code: Select all

function eventGamePreSave(before) {
    PersistanceMgr.prepareForSave();
}

function eventGamePostSave(before) {
    PersistanceMgr.tidyAfterSave();
  }

And OOP style:

Code: Select all

events.PreSave.bind(PersistanceMgr.prepareForSave);
events.PostSave.bind(PersistanceMgr.tidyAfterSave);

I like the idea of an eventLoad() but at what point would it be called - before or after eventGameInit / eventStartLevel?

Sorry I miss that events.

I currently handle the load scenario like this:

Code: Select all

function eventStartLevel() {
  if (typeof loaded != "undefined") PersistanceMgr.gameLoaded();
  eval(null,"var loaded = true;"); // if game is saved then loaded, we'll detect this next time evnetStartLevel runs
}

Don`t use "eval". It is slow.

Code: Select all

define it as global variable and check if it is True

// var loaded // in main scope
if (!loaded) {
loaded = True
}

[aubergine]

Also, in many cases I don't instantiate classes, I just define a class and use it's constructor as if it were the instance -- particularly if the class is a singleton (why bother instantiating a singleton?). If I do instantiate classes then I store their instances somewhere where the JS API won't try saving them. Basically, this scenario:

Code: Select all

function TheseAreNotTheVarsYouSeek(){};

TheseAreNotTheVarsYouSeek.whatever = "The JS API will move along without saving this";

Eval is slow, which is why I rarely use it (and when I do it's one-off hit, not something that will be called over and over).

It might be worth splitting out any further discussion on OOP and more advanced event binding to a separate topic, as I doubt either of those things will appear for quite some time.

For me, at least, the main focus is getting more of Warzone exposed to the JS API - I can cope with mess, I can't cope with missing features.

[aubergine]

objectExists(gameObject)

A function that returns true if gameObject exists, or false if it doesn't.

There are still scenarios where I really, really desire to temporarily cache some game objects to avoid doing masses of repeat processing on a subsequent game tick. Obviously, those objects could get killed before I get round to acting on them, so a way to find if an object exists without causing exceptions (which are slow and have to be trapped) would be most welcome.

[Duha]

objectExists(gameObject)

A function that returns true if gameObject exists, or false if it doesn't.

There are still scenarios where I really, really desire to temporarily cache some game objects to avoid doing masses of repeat processing on a subsequent game tick. Obviously, those objects could get killed before I get round to acting on them, so a way to find if an object exists without causing exceptions (which are slow and have to be trapped) would be most welcome.

If game objects will have unique ID (unique for all type of game objects, I don`t test it) you can ask for function getObject(gameObject) {return gameObject;}

[aubergine]

There is already objFromId(), which is a useful function in it's own right, but I'd like in addition the objectExists(gameObject) function (or maybe just pass in it's id as sometimes that's all i'll have) to simply check whether the object is still present.

[Per]

There is already objFromId(), which is a useful function in it's own right, but I'd like in addition the objectExists(gameObject) function (or maybe just pass in it's id as sometimes that's all i'll have) to simply check whether the object is still present.

You can check if objFromId(gameObject.id) returns NULL.

[aubergine]

Ah, cool. Last time I used it it threw an exception if object didn't exist. I'll update my docs to indicate the improved return value. How do I find out what version of WZ the return value was changed in?

[Per]

Ah, cool. Last time I used it it threw an exception if object didn't exist.

Returning NULL is what it should be doing. I did not actually test or read the code to see if it actually does.

[aubergine]

It was Beta 2 when I last tried it so it could well be returning null by now I've added it to my to-do list of things to check, but it's a long list heh.

.isHost property on PLAYER_DATA objects

NOT REQUIRED: Player 0 is *always* the human game host.

[Duha]

Ability to dump short strings to log file
I always imagined debug() would do this, but it seems not. I'd like the ability to do something like log("short string") and have it go directly to the log file.

I make tool, to read output. It shows debug() output.
viewtopic.php?f=35&t=10080

[aubergine]

The reason I want to be able to put stuff in to log file, without throwing exceptions, is so that once my AI is out in the wild people can send me their logs and I can see what my AI has been up to (as no doubt it will do lots of stupid things that I'll want to rectify).

[Duha]

The reason I want to be able to put stuff in to log file, without throwing exceptions, is so that once my AI is out in the wild people can send me their logs and I can see what my AI has been up to (as no doubt it will do lots of stupid things that I'll want to rectify).

I can add button sent to "aubergine"
And I will think about easy launch. May be I can make mod manager over this.

[aubergine]

enumMods()

Return an array of strings listing active mods in the current game, similar to the list of strings shown at the top of menu screens.

This will allow an AI, for example, to determine if Ultimate Scavenger Mod is installed and thus act differently - with USM installed, there is less chance of being able to capture oils further away from the base at the start of the game as scavs will send cranes very early to capture them first, so AI will know to avoid that strategy.

@Duha - your app only runs on Windows, it would be difficult for me to run it on Mac without a lot of extra effort so being able to put stuff in to log files easily would avoid users having to do that extra work.

[aubergine]

propulsionCanReach(prop, x1,y1, x2,y2)

IMPLEMENTED: NoQ's patch committed to 3.2!