Warzone 2100 Forums

NoQ wrote:Hmm, seriously? Are all snapshots broken currently?
Cause i'm compiling the game from git directly, and never needed to check out snapshots.

P.S. Lol, just noticed that i've been packing calling the mod .zip since eternity, and it worked.
Re-named anyway.

Still broken.

File renaming wasn't relevant to your issue; it worked anyway.
We actually need someone to make a snapshot for us

Can only share a little video featuring the new AI (on both sides)

NoQ wrote:github

Thanx! It was good game.. The bot is very different from the first version nullbot for 3.1 =)
He became stronger opponent.

Aha, we've got a linux/source snapshot now, but not a windows one yet.

aubergine: what do you think, how difficult would it be to use your backport code to make this AI run on 3.1? Even if it won't do very well (i'm mostly afraid of performance issues, and, of course, we won't have much fancy adaptation). Maybe you'd like to just fork me and try this out? (: (: (:

I'd love to give that a try. Is there some way you can get a list of what 3.2-specific features NB3 is using?

The old backport code (backport.js) was broken, but I've got a replacement called Define API -- it requires a couple of extra libraries to be included and I still need to write unit tests for it. I can prolly get the unit tests done by end of this weekend if I limit the amount of tests I write for the dependency checker that's part of Util API. As for performance issues, I have a Cache API that might help solve those Things like enumRange and enumArea backports would still be somewhat laggy though, but I believe there's enough stuff to get this new NB working on 3.1 branch...

Is there some way you can get a list of what 3.2-specific features NB3 is using?

Well, the moment you try running it, you'll easily see what's missing (:

enumRange, droid/structure.weapons/propulsion/body/.armed/.range/canHitAir/canHitGround, orderDroid, the new componentAvailable, buildDroid droidType tweaks, propulsionCanReach, ... that's a lot, in many cases it'd require some thinking; probably the trickiest will be all the buildDroid stuff.

One more limitation is that i wouldn't like any game stats mentioned outside the ruleset or personality code. That is, it'd be better to not backport .canHitAir using a list of turrets that can hit air; but if all such code is inside in the backport module and not overcomplicated, then i'd have to live with it (:

Yeah, some of those things are going to be "interesting" to backport, particularly the droid properties in the scenario of enemy droids (I already have some part-baked code for generating most of the props for own-built droids). I'll see what I can do.

I assume if I "fork" the nb repo, I end up with my own copy of it under my github account and stuff I push to it won't harm the main nb repo?

BTW, if you could, can you find out what the value of the scriptName and mapName globals are? I've not got round to documenting those and have no idea what sort of stuff they contain (eg. are path/extension included?).

I assume if I "fork" the nb repo, I end up with my own copy of it under my github account and stuff I push to it won't harm the main nb repo?

Yeah, right. But i can take some commits from your repo and apply to my repo, and vice versa.

BTW, if you could, can you find out what the value of the scriptName and mapName globals are?

scriptName is something like "nb_generic" (without even .js), you can see it when the AI introduces himself in the chat.
Will have a look at mapName now.

aubergine wrote: I assume if I "fork" the nb repo, I end up with my own copy of it under my github account and stuff I push to it won't harm the main nb repo?

https://help.github.com/articles/fork-a-repo

mapName is something like "Sk-Startup" or "Riviera-T1", i think it is based on how it is called in addon.lev.

Tks for infos.

fireLassat() is a scary function -- if there's 1000 enemy objects, you'll be doing 1000 enumRange()'s and then iterating through the objects in each of those enums! Maybe better to use a for loop and increment counter by 2 or more to skip at least half the objects (assuming that decent target areas have clusters of objects, you'll still find the clusters)...?

Well it'd be a nice effect when the game hangs for a few seconds of silence, you have no idea what happens, and then bah, the mechanical voice says your most precious base will be burned in an instant ...

That was quick and dirty, maybe i'll do it the old way.

Another way to do it would be to split the map in to 20x20 sectors, enumRange() each sector to find sector with most enemy, then do a more granular search in that sector.

That's 169 enumRange's (or enumArea?) for the sectors (on a 256x256 map), then 25 enumRange's within the most densely populated sector.

Hmm add a map reduce API?

JS already has Array.reduce and NoQ is using it: https://github.com/aubergine10/nullbot/ ... sat.js.inc

What would be really useful is if the C++ code already does some cluster analysis, if that could be exposed to the JS API... There are several cases where AIs need to find clusters of own/ally/enemy stuff, and currently it's quite a lot of work to be doing in JS whereas I imagine C++ implementation would be much quicker.

Something like getClusters([player[, type[, lookingPlayer]]]) which returns an array of clusters of objects of 'type' (default structure and droid), owned by player (default 'me', but can be ALLIES, ENEMIES, ALL_PLAYERS or player id), and filtered to 'lookingPlayer' (default to don't filter by visibility).