3.2 JS API Wishlist :)

For AI and campaign script related discussions and questions
Post Reply
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 »

In any case, addBeacon(x, y, target player, message) and removeBeacon(target player) functions have now been added to master.
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

What is the x,y,z properties on playSound() for then? They don't seem to alter where the sound is coming from.

BTW: Thanks for beacon functions! :D How does an AI know when a beacon is placed - is there an enumBeacons() and eventBeacon()?

Also, how many beacons can be placed at once? Is there a way to use them like objective markers in the campaign - eg. where there would be several beacons on the map at once and as player completes each objective or reaches each area the corresponding beacon gets removed...?
"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 »

Sounds should be coming from the given positions. Don't know if that is working correctly.

I will add a beacon event soon.

Each player can only have one beacon. For campaign markers, you need to use hackAddMessage() instead, which requires a en entry in the appropriate stats files for each marker.
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

re: campaign - urg. I assume that prior to final release of 3.2 the hack[Add|Remove]Message() functions will be replaced with something non-evil + also not needing to have stuff in stats file to use them?
"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 »

eventBeacon(x, y, from, to[, message]) added.

I hope to clean up the message mess before 3.2, and add more generic campaign markers, but you never know...
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

Sweet :) I notice message param on the event is optional -- is message param on addBeacon() also optional?
"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:Sweet :) I notice message param on the event is optional -- is message param on addBeacon() also optional?
Yes. I've updated the docs to reflect this now.
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 »

accessibleByLand(x1,y1,x2,y2) and accessibleByHover(x1,y1,x2,y2): Basically would be used much like droidCanReach(), but can be used while the AI has no droid objects present on the map. Would be especially useful for AIs before they're able to build any hover units, to determine whether or not to prioritize research on hover propulsion, or (if the target coordinates are unreachable by hovercraft) Cyborg Transports.

Alternatively, there could be an accessibleByProp(propulsion,x1,y1,x2,y2) function instead that combines the functionality of those 2 functions.
Creator of Warzone 2100: Contingency!
Founder of Wikizone 2100: http://wikizone2100.wikia.com/wiki/Wikizone_2100
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 »

Well, i did manage to do that in NullBot pretty reliably by using only droidCanReach(); but only for land, not for hover (cause i'm never sure whether my droid is a hover, at least in 3.1). +1 anyway (:

And here comes something interesting. By calling accessibleByLand(x,y,x,y+1) etc. many times, you can learn everything about the continents and geography ;)
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

accessibleBy(propulsion, fromX, fromY, toX, toY) would get my vote

...which might be a better name for the function in this wish: viewtopic.php?f=35&t=10036&start=15#p112476
Last edited by aubergine on 04 Dec 2012, 06:26, 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
p0l1z1
Rookie
Rookie
Posts: 24
Joined: 25 Mar 2012, 07:40
Location: Geneva

Re: 3.2 JS API Wishlist :)

Post by p0l1z1 »

Strongly approve the "getTile(x,y)" ^^ Actually the only way I see to map the land (especially for z parameter and unpraticable paths) is to send a droid scouting everywhere. Not very efficient :P

Also, I thing I didn't see a distBetweenTwoPoints() that would take into account the land. Could it be done ? It would probably improve the AI in several ways. And if the pickStructLocation() fct can use this fct instead of the actual one, we will in most case avoid bases builded on both sides of a cliff and see the trucks loose a lot of time climbing up and down ...
NoQ wrote:And here comes something interesting. By calling accessibleByLand(x,y,x,y+1) etc. many times, you can learn everything about the continents and geography ;)
Yeah, kind of improvement of the scouting droid style. But still a lot of CPU loss compared to the getTile() fct :wink:

By the way, thanks a lot for nullbot. It remplaced nexus in most of our games here. And now that I started AI scripting myself, looking at your code has been incredibly usefull ^^
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

I've been working out the map as follows...

For up to 10 units, "follow them" in your code: Once a second, inspect them to see where they are. Keep a history of their previous tiles, so you know units can move from tile A to B = helps you find routes. Also, when inspecting the followed units, you can see their z index to get a rough idea of the tile height -- you need to average the z's for a given tile so as more followed units pass over that tile you get a more accurate average height.

Once you know the average heights of tiles, you can start working out where ramps are, and possibly even determine where choke points and base entrances are.

At the start of the game, I check to see if my first produced tank (which I know will be a non-hover tank because I make sure that is the case) can reach various places on the map over a period of time. I then work out from that what is not land-accessible from my base. When I make my first hover, I do the same thing, so then I can work out what water is accessible from my base. The hover also allows me to work out where cliffs are - basically if a hover can't get to a tile that's adjacent to a tile it can get to, then the tile it can't get to is a cliff (unless the inaccessible tile has a structure or feature on it).

I'm currently trying to devise a method whereby I can work out if an area surrounded by cliffs is big enough to merit further investigation - eg. it might have some buildable land that's only accessible via transporters.

As you can imagine, this is a huge amount of cruft to just get data about the map. It's not particularly accurate, it's slow and messy, but it at least gets you some idea about what the map looks like.

When the new dump() function makes it in to a Mac OS X build of WZ, I'm going to try outputting some HTML that uses canvas element to draw maps as my AI sees them. I'll then be able to visually compare what my AI "sees" to what the actual map looks like. I'm also planning to create a way to make "heat maps" to see if there are common battle hotspots, paths, etc., on a map.

What would be super awesome is a way to highlight map tiles in the game so during development I can "see" what my AI "sees" directly on the map in the game. I think something like this would also open up lots of interesting things for campaigns and challenges, for example via a script you could highlight to the player where to build structures, or places to avoid, or paths to take, or whatever. A highlightTile(x, y, r, g, b, a[, player]) (where player defaults to 'me') would be amazingly useful.

I'd still love some sort of getTile(x,y) that would return full data about that tile. And also functions for getting continent info: viewtopic.php?f=35&t=10036#p111890
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
p0l1z1
Rookie
Rookie
Posts: 24
Joined: 25 Mar 2012, 07:40
Location: Geneva

Re: 3.2 JS API Wishlist :)

Post by p0l1z1 »

Yeah I was thinking about something similar. The getTile() will specially be a good thing for CPU usage ... But I'm only scripting since yesterday, I still have to learn some things and get a usable AI before thinking about such optimization :)
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine »

Deprecate buildDriod(), add produceDroid()

In 3.2, mark buildDriod() as deprecated (keep it around until 3.3) and add a new produceDroid() function that has the two 'null' params removed.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
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 »

As far as i remember, one of these null parameters was actually designed to mean something (?)
Post Reply