EggPlant AI ramblings

[Emdek]

I would just give labels() method returning list of available ones.

[Per]

A naming convention for labels would be nice. Suggestions?

And yeah, if a label is not found, null or undefined (not sure which), is returned.

[Emdek]

I would vote for null as value to return for not found one.

[aubergine]

enumLabels() for getting a list of what labels exist on the map.

As for naming convention, I have no idea as I've never used labels before and don't know what sort of things they are used for.

@Emdek - functions that don't return anything actually return undefined. Having them return null would be very strange from a javascript perspective, it would be better to leave them as they are now returning undefined (JS doesn't have a void class so if a function returns nothing the JS engine actually translates that to undefined, which means it's defined as being undefined heh).

@Per - if label not found, then undefined should be returned (null would be weird, because that would indicate a label being defined as null, rather than indicating that the label itself is undefined)

[Emdek]

enumLabels() for getting a list of what labels exist on the map.

Why such long function name?

null vs undefined vs false vs 0 - I think that in this case all those would be reduced to bool in if statement.
Use of undefined doesn't void possibility to check function existence in this case?

[aubergine]

enumLabels = consistent with all the other functions that return a list of stuff, eg. enumDroid, enumFeature, enumBlips, etc.

As for undefined, I prefer to stick with the JS way of doing things. If something is not found, JS always returns undefined. For example, if a function returns nothing, the ECMA-262 standard, since edition 3 or earlier, and certainly in edition 5 that is the current version, states that undefined should be returned. So, "undefined" is the ECMA-262 de facto way of saying "it's not been defined yet".

Now, if the label existed, but was empty, then that would suit null better (although again, in JS, really it should still be undefined, because an undefined value of a property defaults to undefined).

But no label = label is undefined = return undefined please

http://saladwithsteve.com/2008/02/javas ... -null.html

http://javascriptweblog.wordpress.com/2 ... nceerrors/

[Emdek]

OK, so if others have enum prefix then it makes sense, however this is good candidate to cleanup later (remove it), since it is confusing (at least for me), as enum is something a bit different for me (from C++ point of view)...

[aubergine]

yes, enum is also something different for me. however, for now let's stick with the current naming convention.

i don't think we should try to do a full cleanup until at least v3.3 (start C++ cleanup in v3.2, then JS cleanup in v3.3).

[Emdek]

Cleanup could be done for 4.0, among for example other changes.
To not break compatibility too often but also don't wait too long.

[aubergine]

Yup - would make sense as I imagine Campaign 4 will be nearing completion by then so would be a good time to do cleanup.

[Emdek]

In offtopic of new campaigns, I would say that those (if officially added) should be always trilogies, like current ones (one will be too short for new plot).
Also there are at least two separate attempts for new one...
Personally I have some ideas for new trilogy too (just need to write them down).
And the main issue is that new ones would require new technologies (to be like current ones)...

[Per]

enumLabels() has been added to master. It returns an array of label strings.

[aubergine]

yay! now we just need some way to make sense of what those strings mean... I guess that's going to need some sort of naming convention, but probably deserves a new topic...

[aubergine]

Not posted an update for a while, so ... posting an update!

I've been stroking my beard trying to work out how to deal with adaptive research paths. This required me to first grow a beard.

I'm currently trying to condense down the masses of research in to some consistent categories and sub-categories. Currently I'm wading through research.txt and names.txt, compiling the information in to a single document that correlates:

* research ID (which is actually the .name property on JS API research objects)
* research name (from names.txt) - just so I can retain my sanity
* type (eg. defence, armor, etc)
* sub-type (eg. AA, thermal, etc)
* structure - still pondering over this, I want bi-directional lookup between structure and research
* probably some other stuff, eg. can it attack stuff (if so, what?), does it relate to sensors, etc.

I'm then going to refactor my VAULT code so that I can create multiple vaults. I want a vault to store research data and a vault to store map object data. I thought about storing it all in one vault, but it just seems crufty to do so.

Whilst refactoring VAULT I'm going to refactor all the wrapper classes I'd made, because the types/subtypes I'm coming up with for research stuff seems a better way of organising things. I certainly want a close correlation between map objects and research stuff to make my AI code more transparent.

The plan is to give EggPlant a few starting paths to choose from (similar to NullBot) but mostly let it decide it's own research path, droid configurations and base defences, etc., based on what it encounters in the game. This is quite high risk because I'm literally going to have no idea what path it will choose in a game, so when it comes to fine tuning that's going to be .... interesting.

[aubergine]

So, it seems that I've embarked on yet another huge project. I've decided to create a spreadsheet that contains pretty much everything my AI will need to know about technologies (research), structures (defences, buildings, etc) and components (propulsions, bodies, etc), plus sensors, turrets and a whole bunch of other stuff.

I've currently identified the following key research "categories":

* AA guns
* Artillery
* Assimilate (Nexus links)
* Borgs (cyborgs)
* Building (eg. base materials)
* Cannon
* Command (command turrets, etc)
* Construction (engineering)
* Droid (stuff that relates to all droids, eg. engines)
* EMP
* Flamer
* Laser
* Machinegun
* Missile
* Mortar
* Perimeter (defences and walls/gates/traps)
* Power
* Railgun
* Repair
* Research
* Rocket
* Sensor
* System (affects everything, eg. auto-repair)
* Tank (mostly relates to propulsions for factory-built land-vehicles)
* Transport (cyborg and heavy transport)
* Vehicle (stuff that relates to anything built at a normal or vtol factory)
* VTOL

Once I've got this spreadsheet finished, I'll be able to create a fully-adaptive AI. For example, if it spots that it's units are getting killed too quickly, it can query the data to see what upgrades are available, how much research/power is needed to get them and then make a choice as to what to research next.

I'm documenting the columns that are in my spreadsheet here: https://warzone.atlassian.net/wiki/disp ... Tree/cruft

And some early pondering about a propulsion matrix here: https://warzone.atlassian.net/wiki/disp ... ropulsions

I'll be uploading the spreadsheet somewhere once finished, as well as a javascript representation of it (eg. each row converted in to a JS object and placed in an array).