3.2 JS API Wishlist :)

For AI and campaign script related discussions and questions
Post Reply
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

@Duha, surely that would only be known on eventGameSaved() (because eventGameSaving is just letting you know that the save process is about to begin, it's only once the save process starts that WZ knows what data is going to get put into savegame file)...

Even then, could you not just look at the savegame file?
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
Shadow Wolf TJC
Regular
Regular
Posts: 1047
Joined: 16 Apr 2011, 05:12
Location: Raleigh, NC

Re: 3.2 JS API Wishlist :)

Post by Shadow Wolf TJC »

Lately, I've been trying to add wind farms to Contingency, and while I've figured out how to successfully implement them for 3.1 rc2 (via having the rules.js script check all players, instead of just the host player, when using the setPower() function every second), I'm not yet able to adjust their power generation rates (based on what power upgrades each player has researched) on account that I believe that eventResearched() is only called when the player running the script researches the given item. Instead, I wish that it was called whenever ANY player researches the item (though AI scripts could still check if the research lab that completed the research belongs to them or one of their allies).
Creator of Warzone 2100: Contingency!
Founder of Wikizone 2100: http://wikizone2100.wikia.com/wiki/Wikizone_2100
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3780
Joined: 03 Aug 2006, 19:39

Re: 3.2 JS API Wishlist :)

Post by Per »

Events are by design only called for relevant players. I'd rather not have "is this for me?" checks in every event function...

Although I see no other, good ways to do what you want to do. Perhaps have one set of events that is called for relevant players, and one set that is called for all players...

Maybe we should just move all power handling into javascript ;)
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

Shadow Wolf TJC wrote:... (via having the rules.js script check all players, instead of just the host player ...
How did you get rules.js to check all players -- were you able to change "me" in rules.js? Or do you mean you just iterate through players in rules.js and call setPower() and playerPower() with the relevant player ID?
Shadow Wolf TJC wrote:... I believe that eventResearched() is only called when the player running the script researches the given item. Instead, I wish that it was called whenever ANY player researches the item (though AI scripts could still check if the research lab that completed the research belongs to them or one of their allies)
IMHO it would be better to add a player param to the following functions:

* getResearch()
* enumResearch()
* findResearch()

As for eventResearched(), it should only fire when the script player gets a new technology, regardless of how they got it. They can get tech during the game as follows:

* Either they or an ally research it at a lab
* A script completes research for them (there will be no lab param)
* An artefact is picked up -- I think this just enables the research? Perhaps better suited to eventPickup()...?

I wouldn't want my eventResearched() getting called when an enemy, or scavs, researches something.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

Per wrote:Maybe we should just move all power handling into javascript ;)
+1 :) And have the functions I mentioned in previous post given a player param so rules.js can work out what tech any player has.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
Shadow Wolf TJC
Regular
Regular
Posts: 1047
Joined: 16 Apr 2011, 05:12
Location: Raleigh, NC

Re: 3.2 JS API Wishlist :)

Post by Shadow Wolf TJC »

aubergine wrote:
Shadow Wolf TJC wrote:... (via having the rules.js script check all players, instead of just the host player ...
How did you get rules.js to check all players -- were you able to change "me" in rules.js? Or do you mean you just iterate through players in rules.js and call setPower() and playerPower() with the relevant player ID?
The latter.
Creator of Warzone 2100: Contingency!
Founder of Wikizone 2100: http://wikizone2100.wikia.com/wiki/Wikizone_2100
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

Promote Scavengers to a first class citizen

Scavengers are somewhat of a 2nd class citizen in the JS API at the moment - specifically, they don't have an object in playerData.

Could Scavengers get an object in playerData array?
* Their .team should be 18 (team "S")
* Their .position should be defined as undefined or null
* Their .name should be "Scavengers" (it would be nice if there was a scavfact.ai that defined their name / description)
* Their .difficulty should be MEDIUM ...or EASY with the native WZ scavs ;)

The big gaping hole with scavs at the moment is that it's not possible to determine their colour via the JS API. Even a global scavengerColour property would suffice (I can generate most of the other stuff myself if push comes to shove) but I'd prefer them to have an object in playerData if possible.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

highlightTile(x,y,bool[, r, g, b]) & setTileGrid(bool)

PARTIAL IMPLEMENTATION: hackMarkTiles()

I'd like to experiment with path finding via JS, so having some way to show a tile grid and highlight specific tiles would make visualising things much easier.

Also, while doing some experiments, I noticed that the .z property of droids gets lower the higher up they are - is that correct or am I doing something wrong?
Last edited by aubergine on 12 Jan 2013, 19:04, edited 1 time in total.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3780
Joined: 03 Aug 2006, 19:39

Re: 3.2 JS API Wishlist :)

Post by Per »

aubergine wrote:Promote Scavengers to a first class citizen
The problem with that is that they are not first class citizens. They are a huge hack. Adding them to playerData would make that a sparse array in some cases, and even a scavengerColour would only exist conditionally or sometimes with a dummy value... The scavenger code needs a redesign, but that is not exactly a priority at the moment.
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

scriptPath

The path to the current scriptName.

eg. if the main script is multiplay/skirmish/foo.js:

* scriptPath = multiplay/skirmish/
* scriptName = foo.js

I can use scriptPath for autoloading dependencies. For example, to automatically load a different set of files depending on whether my AI is in challenge (skirmishes/) game or skirmish/mp game (multiplay/skirmish/). If I store files related to my AI in subfolders, I can use scriptPath+"someFolder/" when autoloading dependencies.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
Shadow Wolf TJC
Regular
Regular
Posts: 1047
Joined: 16 Apr 2011, 05:12
Location: Raleigh, NC

Re: 3.2 JS API Wishlist :)

Post by Shadow Wolf TJC »

A few ideas for Droid and Structure properties that would be most useful for those looking to develop a more intelligent and analytical AI:

- droid.weapon and structure.weapon: The internal name of the droid's or structure's primary weapon. Would return null if absent. Can be used by the AI to determine the droid's or structure's weapon's range, damage type, damage class, base rate-of-fire, etc. by cross-referencing either the weapon's stats directly (if individual weapon objects are created and given properties, like weapon.range, weapon.type, weapon.damagePerShot, etc.), or by looking at a list that was prepared by the AI developer and accessed via the include() function.

- droid.weapon2 and structure.weapon2: The internal name of the droid's or structure's secondary weapon. Would typically be present in some Dragon-bodied vehicles.

- droid.weapon3 and structure.weapon3: I believe that NoQ's Gyro Choppers and Big Rigs from the Ultimate Scavenger Mod would possess these variables.

- droid.weapon4 and structure.weapon4: I believe that droids and structures can have up to 4 weapons at a time.

- droid.construct: Internal name of the construction turret used by the droid template. Would normally return "ZNULLCONSTRUCT" if a droid lacked any construction turrets. Can be used by the AI to determine the droid's construction speed.

- droid.ecm and structure.ecm: Internal name of the ECM turret used by the droid or structure. Would normally return "ZNULLECM" if a droid or structure lacked any ECM capabilities.

- droid.sensor and structure.sensor: Internal name of the sensor turret used by the droid or structure. Would, in most cases, normally return "DefaultSensor1Mk1" if a droid or structure lacked any sensor turrets. Can be used by the AI to determine the sensor's range, or whether the sensor is a standard sensor, a CB sensor, a radar detector, etc.

- droid.repair: Internal name of the repair turret or repair system used by the droid (as can be determined in templates.txt). Would normally return "ZNULLREPAIR" if absent. Can be used by the AI to determine the droid's repair speed.

All these object properties would allow AI developers to develop AIs with a strong sense of situational awareness. These AIs could, in theory, be able to choose targets based on which targets are weakest to their weapons (offensive targeting), or which targets pose the greatest threat to the group (defensive targeting). For example, if the AI player's Assault Gun Tracks are being attacked by a group of Cyborg Lancers, Lancer Tracks, and Cyborg Machinegunners, then the AI could tell its Assault Gun Tracks to target the Cyborg Lancers 1st (since they pose a bigger threat than the Cyborg Machinegunners, and are more vulnerable to the Assault Gun than the Lancer Tracks), and then (depending on whether the AI is focusing on offensive targeting or defensive targeting) focus on either the Cyborg Machinegunners (if prioritizing offense) or the Lancer Tracks (if prioritizing defense).

By the way, is there any means for JavaScript to read files such as weapons.txt or bodies.txt in a way that a JavaScript programmer could create an array from the data contained within those files (which seem to be designed to be read as arrays anyways)? While an AI developer could take the time to recreate the information stored within those .txt files in a format that is usable by JavaScript programs, there always exists the possibility that the information within those .txt files could be changed, either by a new version of Warzone 2100, or through being overwritten by a mod.
Creator of Warzone 2100: Contingency!
Founder of Wikizone 2100: http://wikizone2100.wikia.com/wiki/Wikizone_2100
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

I'd prefer an array of weapons, so for dragon body for example there would be an array with 2 weapon objects in it.

Getting this extra info on droids would be most useful, I myself have been wondering how to determine such things, particularly after seeing viewtopic.php?f=30&t=10090&start=15#p113213

My worry is that if too much stuff is added to those objects, functions like enumStruct() and enumDroid() are going to be returning ever larger data sets. In many cases, looking at scripts such as nullbot (which is quite mature now) and my own (which is still very early stages of dev) code often only wants to know about basic info like .droidType, etc. But then again, if the extra properties were there I'm sure scripts would be making extensive use of them already.

EDIT: See my comment later about "Expose ini stats..." for updated ideas...

I like the idea of reading the stats files, maybe as the files get converted to .ini format, some functions could be added to allow js to read those files, or better still, have some globals that provide the data in ready-made objects?

<global>.ini = {}

<global>.ini.ecm = object containing a JS representation of ecm.ini

...etc?
Last edited by aubergine on 16 Nov 2012, 09:27, edited 2 times in total.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3780
Joined: 03 Aug 2006, 19:39

Re: 3.2 JS API Wishlist :)

Post by Per »

I'm not sure I want to cram all that data into the results from enum*() functions. Maybe a new function that is passed a game object, returns more data on it. Let me think on it. And while we are waiting for me to think (and I think so sloooooowly...), you can play with two new fun functions: cameraSlide(x, y) and cameraTrack(droid). They were added in fdf2db19fcb56fb99a1bb2d36639cf5342e7d794. These control the warcam, the game's dynamic camera, allowing more cut scene like behaviour to be scripted. Pass in a null object to cameraTrack() to stop tracking.
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

Those two new functions look awesome!

I was wondering, for the cameraTrack() could it be altered so that it keeps the camera in the same position but pans the camera so that it's always facing the droid? And then maybe a separate cameraFollow(droid) function that makes the camera follow a (perhaps different) droid?

From a cinematic perspective, I'll often want the camera to be perched on top of a hill or behind a building, and have it pan (for example) to watch a transport that's doing a fly-by. Also, I might want a camera on a truck and have it track some other droid as if it's from the trucks perspective.

cameraFollow(gameObject[, xOffset, yOffset, zOffset]) -- the offsets are optional and are in relation to the droid position

So if I do:

cameraFollow(droidA); cameraTrack(droidA); // camera placed a distance behind droid, pans to follow droid

cameraFollow(droidA, -3, -4, 0); cameraTrack(droidB); // camera behind and to the left of droidA, view pans to follow droidB

so cameraFollow() is used to automate x,y,z of camera, cameraTrack() is used to automate the direction the camera is pointing in
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

@Per: In my experience, thinking slowly about code is a very good approach! It leads to much better code.
Mark Twain wrote:“I didn't have time to write a short letter, so I wrote a long one instead.”
Expose ini stats to JS

* enumIni([path]) -- get a list of ini files (by default from the stats folder)
* enumIniSections(iniFile) -- get a list of sections in a specific ini file (if no path in filename, assume stats folder)
* iniSection(iniFile, section) -- an object containing the properties and values of a section of an ini file

Note: the object returned by iniSection() should just return what's in the section and not try and create any missing properties. Let us JS scripters worry about the missing properties/defaults etc. For example, we can just insert the ZNULL section in to the prototype chain of the other sections thus filling in missing properties in a very performant manner.

With this, JS scripters can then easily make an API that loads ini files in to an object structure in their script. We can play around with different ways of representing the data and start writing functions that provide more info about droids, etc., based on that data and existing data such as what research has been done.

On droid/structure objects, all we'd need is the id's of .turrets[], .body, .propulsion, etc. WZ 3.2 is already giving .body and .propulsion of droids, a .turrets[] array is all that's missing there.

There are obviously things hardcoded in to C++ that aren't really exposed from ini files, but we can just go hunting for the C++ code and make JS functions that perform same algorithms.

After no doubt quite a bit of trial and error, someone is bound to come up with a really eloquent way of doing things, and that in turn might lead to a mass-unhardcoding of stuff in the game.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
Post Reply