3.2 JS API Wishlist :)

For AI and campaign script related discussions and questions
p0l1z1
Rookie
Rookie
Posts: 24
Joined: 25 Mar 2012, 07:40
Location: Geneva

Re: 3.2 JS API Wishlist :)

Post by p0l1z1 »

In 3.1, one of them is the droid type. Hopefully soon outdated ;)
User avatar
NoQ
Special
Special
Posts: 6226
Joined: 24 Dec 2009, 11:35
Location: /var/zone

Re: 3.2 JS API Wishlist :)

Post by NoQ »

Yeah, i've been talking about the other one.
In official dox, Per wrote:The reserved parameter should be passed null for now ... The second reserved parameter used to be a droid type.
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 »

setResearchPriceCeiling(price): Would normally be defined in rules.js, this would basically be an unhardcoded version of this block of code from research.cpp:

Code: Select all

#define RESEARCH_MAX_POWER  450
...
...
...
		if (research.researchPower > RESEARCH_MAX_POWER)
		{
			research.researchPower = RESEARCH_MAX_POWER;
		}
A value of -1 would tell the game to not set any price limits to research.

Edit: giveObject(to, object): Gives a droid or structure to another player, even if the player receiving it isn't allied with the player sending it.
Creator of Warzone 2100: Contingency!
Founder of Wikizone 2100: http://wikizone2100.wikia.com/wiki/Wikizone_2100
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 »

I've written up some code for an eventStructureActivated(structure, target) event for JavaScript. I hope that this would work (especially since I'm unable to test this for myself):

https://github.com/ShadowWolfTJC/warzon ... 1757e0f6c5
https://github.com/ShadowWolfTJC/warzon ... e6c446f34f
https://github.com/ShadowWolfTJC/warzon ... 40ebdfaed6
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 »

regarding giveObject() I'd prefer it called transferObject(obj, to), as then you could have transferPower(power, to) and the existing eventObjectTransfer() plus new eventPowerTransfer(). If there is still code lingering for tech & sensor transfers, those could be exposed with similar functions/events.
"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 »

Shadow Wolf TJC wrote:I've written up some code for an eventStructureActivated(structure, target) event for JavaScript. I hope that this would work (especially since I'm unable to test this for myself)
I'm afraid this is not very helpful, though. The largest part of the work is testing and fixing all the bugs that always pop up.

If you want to help, I'd suggest you put your time into figuring out why you can't compile the game...
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've added two new functions:

hackGetObj(type, player, id) -- get a game object from the map, where type is DROID, STRUCTURE or FEATURE. If object is not found, it will return null. Note that it will not search in transports or off-world maps. This deprecates the broken objFromId() function, which I intend to remove before final 3.2 release. It is also significantly faster than objFromId(). Note that all features are owned by player zero.

hackAssert(condition, message...) -- throws a scripting error if condition is false, printing message.
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 »

How exactly is hackAssert supposed to work? Does it deliberately cause the game to crash? In any case, I'd imagine that this could find some use in bug-testing JavaScript functions.

Also, I was about to put objFromId() to use for ShadowBot, though I'll see if I can create some version-sensitive code that makes use of both objFromId() and hackGetObj(). ;)
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 »

hackAssert() just throws a scripting error, which causes an assert, which does what asserts would otherwise do, given how you started Warzone... I usually run Warzone under gdb, where asserts cause an immediate halt and gives me a backtrace. I understand that people who do not run under a debugger won't get a halt on asserts anymore, though.
User avatar
Duha
Trained
Trained
Posts: 287
Joined: 25 Mar 2012, 20:05
Location: SPb, Russia

Re: 3.2 JS API Wishlist :)

Post by Duha »

for better code reuse and easy adding i suggest to make next thing:

add folder for js libs. (anythere in game folder)
add require function to api.

Code: Select all

api = require("api")
api.log('hello')
this will add function api to global scope.
This is blank function with no realization (it will not be saved on save)
and has a lot of additional atributes pointed in api.js in libs folder

Realization on js:

Code: Select all

function api() {}; // Main container
include('multiplay/skirmish/api/api.js');
api.js code:

Code: Select all

api.log = function (args) {console(args); debug(args)}
http://addons.wz2100.net/ developer
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

@Duha: You can already achieve that with the current JS API, just write a little "api.js" and put relevant code in to mould the environment to your needs. Also, I don't think JS scripters should be forced in to a Node.js paradigm, it should be optional.
  • For example, use Object.defineProperty() to make the global 'api' property (a function) non-configurable, and optionally use it to add read-only / non-configurable properties to the 'api' namespace. It's really not something that needs to go in to the core game.

    You can use include() to pull in a script that creates 'api' and also the global 'require()' function you mention, then it will also be clear to others when they look at the script what paradigm you are using and where to look to find out what's available in the 'api' namespace. I imagine that 'require()' will wrap include() with some additional code, but remember that include() is forced to the global object and activation object on the C++ end (so you can't use .call() to set it's context to the 'api' namespace for example)
.

@Shadow: I'll be releasing a backport that deals with objFromId() vs hackGetObj() - I just need to finish my unit tests on Util API then I can release Define API (the robust & reliable & unit-tested replacement for the now-defunct & buggy backport.js). I've already got loads of "defines" that make the JS API more consistent across game versions. My plan is to make WZ 3.1 look like WZ 3.2 from a scripting perspective, and follow that paradigm for future versions as well. I've even been able to backport events such as eventGameSaving() and a bunch of other seemingly-unbackportable stuff. Obviously, there are some things (like chat(), etc.) which can't be backported, but can still be smoothed over (eg. a fake chat() function that just echoes messages to the console rather than causing a crash with a "chat undefined" error).

@Per: Could you elaborate on "all features are owned by player zero" on hackGetObj()? In the rest of the JS API, features are owned by players 12 (oil drums, artefacts, oil resources) and 99 (trees, skyscrapers, etc). Why would hackGetObj() treat them as belonging to player 0 (the human game host)? Also, I'll update my Test API to provide a mode where it uses hackAssert(). Most likely this will go in to the Test API's config script.
"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 »

Features have always been owned by player zero. Where do you find otherwise?
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

I did a bunch of testing to see what player was associated with different features and found that they belonged to player 12 or 99.

The only time I've seen feature objects owned by player 0 is when eventDestroyed() gets called with a feature object.

But when doing enumFeature() they've always been 12 or 99 depending on what feature they are (at least last time I checked).
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
Duha
Trained
Trained
Posts: 287
Joined: 25 Mar 2012, 20:05
Location: SPb, Russia

Re: 3.2 JS API Wishlist :)

Post by Duha »

aubergine wrote:@Duha: You can already achieve that with the current JS API, just write a little "api.js" and put relevant code in to mould the environment to your needs. Also, I don't think JS scripters should be forced in to a Node.js paradigm, it should be optional.
Yes. But if I want to use someone code I must put it in my project (for example unittest).
It is not sharing code it is copy-pase. It is bad. Doy you need explanation why it not good?

At curent tume all moders make own utils function. But sharing some common function will speedup development.
Splitting program to modules is good style.
http://addons.wz2100.net/ developer
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

I did not suggest that people should copy & paste code, and nor would I because it's bad practice.

Instead libraries should be put in github so people can include them in to their projects and I've already made a dependency checking framework which can autoload libraries - see Dependency Checker (hoping to finish it's units test and release this weekend).
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
Post Reply