[3.2+] NullBot 3 ‘Reloaded’

Did you create a mod, map, music, or a tool? Present them here and earn feedback!
Note: addon requests do not belong here.
Note, everything uploaded to this forum, MUST have a license!
User avatar
NoQ
Special
Special
Posts: 6225
Joined: 24 Dec 2009, 11:35
Location: /var/zone

Re: [3.2+] NullBot 3 ‘Reloaded’ ~alpha~

Post by NoQ » 31 Jan 2013, 16:48

I never found cluster analysis to be a performance problem. It is always ... elsewhere. Right now the worst performance eater is still somewhere in the building construction code; you see it split into several parts, and each part still, for an almost equal extent, regularly overheats the CPU above 20ms threshold.

Splitting map into squares is what i consider to be the next step for improving the adaptation code performance. But it's not necessarily good: most likely the whole army will still be in a single square.

Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3775
Joined: 03 Aug 2006, 19:39

Re: [3.2+] NullBot 3 ‘Reloaded’ ~alpha~

Post by Per » 31 Jan 2013, 17:25

aubergine wrote:JS already has Array.reduce and NoQ is using it: https://github.com/aubergine10/nullbot/ ... sat.js.inc
I was thinking of something that split a larger job over multiple frames for you.

I agree that some tools for cluster analysis would be nice. wzscript has something along those lines, but it is not really usable (don't ask me about it, I do not even know what it is supposed to do).

User avatar
Arreon
Trained
Trained
Posts: 324
Joined: 15 Feb 2009, 05:57
Contact:

Re: [3.2+] NullBot 3 ‘Reloaded’ ~alpha~

Post by Arreon » 31 Jan 2013, 20:43

There is still no build I can use to run this new Nullbot. The git branch is empty.
OS: Windows 7 Home Premium 64-bit
Processor: AMD Phenom II X6 1045T (6 CPUs), ~2.7GHz
Memory: 8192MB RAM

User avatar
NoQ
Special
Special
Posts: 6225
Joined: 24 Dec 2009, 11:35
Location: /var/zone

Re: [3.2+] NullBot 3 ‘Reloaded’ ~alpha~

Post by NoQ » 31 Jan 2013, 22:09

Windows build seems to be finally ready!
And it also includes the latest label fixes, so it'd be usable for the next alpha, probably (:

User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: [3.2+] NullBot 3 ‘Reloaded’ ~alpha~

Post by aubergine » 31 Jan 2013, 23:52

Been investigating ways to backport 3.2 droid properties to WZ 3.1 and this is what I've come up with so far:

https://warzone.atlassian.net/wiki/disp ... roid+stuff

Any feedback most welcome! Particularly if anyone has ideas about how to backport .cost property, or better ways to deal with the other properties. Will need some additional info going in the ruleset, such as component names, to help with identification of player-built droids.

I'm fairly confident that most of the stuff can be backported, and also done in a performant (cached) manner. And I can inject the upgraded droid objects transparently in to events and function calls.

I've also got rough drafts of code for backporting certain events, such as eventPickup() and the save/load cycle events, etc., done. Will need some tidying up, but on the whole it's looking increasingly promising that we will be able to get NB3 running on 3.1 (albeit with some degradation due to inaccuracies in some of the droid properties).

I think it will be a useful exercise because as we saw with 3.1, many people will wait until the full release before upgrading -- so having ability to get feedback on NB3 from WZ 3.1 users will get feedback in earlier than waiting for final 3.2 release.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO

User avatar
Arreon
Trained
Trained
Posts: 324
Joined: 15 Feb 2009, 05:57
Contact:

Re: [3.2+] NullBot 3 ‘Reloaded’ ~alpha~

Post by Arreon » 31 Jan 2013, 23:57

NoQ wrote:Windows build seems to be finally ready!
And it also includes the latest label fixes, so it'd be usable for the next alpha, probably (:
That seemed to do the trick :)
OS: Windows 7 Home Premium 64-bit
Processor: AMD Phenom II X6 1045T (6 CPUs), ~2.7GHz
Memory: 8192MB RAM

User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: [3.2+] NullBot 3 ‘Reloaded’ ~alpha~

Post by aubergine » 01 Feb 2013, 06:54

Status update on the backport...

Events upgraded / backported: eventAttacked, eventAttackedUnthrottled, eventDestroyed, eventDroidBuilt, eventDroidIdle, eventObjectSeen, eventObjectTransfer, eventPickup, eventResearched, eventStructureBuilt, eventStructureReady, eventTransporterLanded, eventTransporterLaunch.

That means those events now work almost exactly as they do in Warzone 3.2, with fully upgraded game objects passed in to them. Some notable differences:

* eventDestroyed() might miss some enemy/ally droid destructions if there has been no interaction with those droids via JS API (shouldn't case NB3 a problem as it will interact with them when setting them as target, etc)
* eventPickup() might sometimes report the wrong droid
* The transporter events only fire for own transports, not sure whether the 3.2 equivalents fire for any transport?

Most if not all constants are also backported, including DORDER_RECYCLE on orderDroid(). :)

As for the game objects themselves, they will get incrementally more accurate as you interact with them. Each property has a 'certainty' value associated with it, so it's even possible to check how sure we about the accuracy of a property value. Once a property is certain, it's locked.

There are still some nightmares to overcome:

* How do I detect hover propulsion on enemy droids? Particularly AI produced that don't default to having "Hover" in their .name?
* Is there any way to identify water tiles prior to getting hover propulsion?
* How on earth can .cost be calculated? *shudder*

Next task is to finish updating the vast array of JS API functions to make them work like WZ 3.2.

Will be a while before any code makes it in to repo as the code is like spaghetti at the moment (actually, more like mince) and undergoing near-constant refactoring.
"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: 6225
Joined: 24 Dec 2009, 11:35
Location: /var/zone

Re: [3.2+] NullBot 3 ‘Reloaded’ ~alpha~

Post by NoQ » 01 Feb 2013, 07:01

Aha, and now i wake up.
Thanks aubergine already, you sound really cool (:

born: not using it yet, you can skip it for a while.
droidType: it's ok if it does some mistakes, but if you come up with a fix, the original nullbot can also use that.
group: i don't think i'm relying on miscompatibility you mentioned, you can skip it.
armed: yeah, need to fix vtolReady function, that's the only appearance of this property.
isVTOL: when i tried to use isVTOL on stored droid objects, i just added an extra property to them which is equal to isVTOL return value when they were created.
cost: if you just set it to 1 for everything, it'll work. i used cost to improve adapt accuracy, but the procedure itself is so much inaccurate by design, that such change won't make it significantly worse; the adaptation will happen anyway.
isSensor etc.: not using them yet, but most likely will, later; for our objects only, so we can rely on .name; not sure what will happen if we capture a sensor via a nexus link, but i'm sure we're not using nexus links yet.
all the rest: probably it's better to avoid working on it so far. we need, at least, something similar to isDedicatedAA() of the original nullbot, and figuring weapon roles of own droids (rely on .name, need to make my buildDroid() calls set up proper names again). all other adaptation can probably be screwed for 3.1, by modifying guessWeaponRole etc. to return undefined when unsure. Note that even though i'm classifying enemy objects to attack objects and defense objects and land objects and sea objects and air objects (the only use of .propulsion on enemy objects), in fact i'm not using any of this info yet; so you can think about it later.

Note: you can rely on object .name property for structures, own droids (unless you start using nexus link) but not enemy droids.

User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: [3.2+] NullBot 3 ‘Reloaded’ ~alpha~

Post by aubergine » 01 Feb 2013, 07:50

I've just found some ways to do partial support for .born, based on droids created by 'me' script, and then extrapolation from known born times based on object ID proximity.

As for droidType, once droids are built it's not too much of a problem (although some testing will be required for the supercyborg bug you found recently). The engineer/mechanic should be relatively OK to deal with as I already done some investigation in to those.

The group property is trivial to fix :) I've even started backporting groupSizes[] and eventGroupLoss().

The .armed and .weapons are currently giving me headaches, even for 'me' built droids where I know all the components. I might need to sleep on that one.

Components in general are proving nightmarish to determine for other players' droids. Lots of beard stroking required on that front.

I've managed to get .cost sorted for 'me' built droids, but still long way off solving it for other players' droids.

With regards to sensor/etc... I've got that working to varying degrees. I've even got some scenarios where I can determine .hasIndirect, etc. So getting there bit by bit.

Structures can indeed be identified by name, as can features (yes, I'm doing those as well), the problem arises when used in context of things like Contingency where there are lots of unfamiliar structures, etc. So I'm pondering ways to integrate with the ruleset to harvest factoids from that. One thing that would help is if the canonical names of things (such as bodies, weapons, propulsion) were included in the data -- at least then I have a chance of identifying some human built droids, etc.

As for nexus link, the enemy droids will already have been processed long before they are assimilated, so whatever data we have about them (things like .range, etc) will be retained after assimilation.

I'm also pondering the idea of exposing the prototype objects (I'm using rudimentary prototype chain splicing to deal with the extra props to keep performance fast) so that it would be possible for you to add custom functions and properties to game objects.
"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+] NullBot 3 ‘Reloaded’ ~alpha~

Post by aubergine » 01 Feb 2013, 07:54

In 3.1, do you know if there's a way to enumDroid() for all players in a single function call (and same question for enumStruct) or do I have to specify each player in turn and concat the results?
"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: 6225
Joined: 24 Dec 2009, 11:35
Location: /var/zone

Re: [3.2+] NullBot 3 ‘Reloaded’ ~alpha~

Post by NoQ » 01 Feb 2013, 09:25

Please don't do it too well! :augh: Making it simply not crash would already be a great improvement, i can't ask for more XD

No, i don't think enumDroid or enumStruct works this way. When not defined, player defaults to me. When out of 0..maxPlayers-1 range, it fails.

User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: [3.2+] NullBot 3 ‘Reloaded’ ~alpha~

Post by aubergine » 01 Feb 2013, 13:14

So it's still not possible to enumDroid(scavengerPlayer)?
"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: 6225
Joined: 24 Dec 2009, 11:35
Location: /var/zone

Re: [3.2+] NullBot 3 ‘Reloaded’ ~alpha~

Post by NoQ » 01 Feb 2013, 13:52

Emm sry ... not maxPlayers, but MAX_PLAYERS, which is bigger, i think; not sure what is it equal to.

User avatar
NoQ
Special
Special
Posts: 6225
Joined: 24 Dec 2009, 11:35
Location: /var/zone

Re: [3.2+] NullBot 3 ‘Reloaded’ ~alpha~

Post by NoQ » 02 Feb 2013, 16:41

aubergine wrote:Status update on backport: https://warzone.atlassian.net/wiki/display/EGG/GO+3.1
Wow.
aubergine wrote:Also, if anyone could get me droid .bodySize and .cargoSize for all droid bodies, it would be much appreciated :)
All cyborgs and supercyborgs, scavenger bodies and the 4 light bodies have LIGHT and 1.
Borg transport and 4 medium bodies have MEDIUM and 2.
Supertransport, 4 heavy bodies and 2 superheavy bodies have HEAVY and 3.

cargoSize is hardcoded to be equal to bodySize in transporterSpaceRequired() in transporter.cpp; it is also hardcoded to be always equal to 1 in campaign.

User avatar
Duha
Trained
Trained
Posts: 287
Joined: 25 Mar 2012, 20:05
Location: SPb, Russia

Re: [3.2+] NullBot 3 ‘Reloaded’ ~alpha~

Post by Duha » 02 Feb 2013, 17:52

NoQ wrote:
aubergine wrote:Also, if anyone could get me droid .bodySize and .cargoSize for all droid bodies, it would be much appreciated :)
All cyborgs and supercyborgs, scavenger bodies and the 4 light bodies have LIGHT and 1.
Borg transport and 4 medium bodies have MEDIUM and 2.
Supertransport, 4 heavy bodies and 2 superheavy bodies have HEAVY and 3.

If you need to get some data from ini files to javascipt, feel free to ask.

For example I can check what all tech names form stats is present in you ai declaration.
http://addons.wz2100.net/ developer

Post Reply