Warzone 2100 Forums

NoQ wrote:Suppose i store a droid in a global variable

Don't. You are not supposed to do that. What are you trying to do?

(You can store its id and then grab the droid using the id with the new droidFromId() function. But this would be a nasty hack. I am thinking about better ways to mark or select units over time.)

For example, set an attack target for an AI and make sure AI doesn't attack anything else unless this thing is destroyed (?)

If I create some groups and assign droids to them, then player saves the game and later loads the savegame, how do I find out what groups I had?

Also, how do I work out what structure limits are set - eg. if user has disabled building of laser satellite station, or limited number of factories to 2, etc? I don't want my AI to get stuck in a loop trying to build something that it can't build (or research something it can't build).

aubergine wrote:Also, how do I work out what structure limits are set

viewtopic.php?f=5&t=8773#p92375

Per wrote:isStructureAvailable(structstat, player) and structureLimitReached(structstat, player) will both check structure limits for you.

aubergine wrote:If I create some groups and assign droids to them, then player saves the game and later loads the savegame, how do I find out what groups I had?

All global variables are saved and restored. Groups are also saved and restored, keeping their group ID.

Do not try to store complicated objects on in global, though, as the save function is not terribly bright.

aubergine wrote:Also, how do I work out what structure limits are set - eg. if user has disabled building of laser satellite station, or limited number of factories to 2, etc? I don't want my AI to get stuck in a loop trying to build something that it can't build (or research something it can't build).

Check with isStructureAvailable()

I thought isStructureAvailable() first checks to see if it's researched, and only then checks to see if it can be built based on game settings? So before I research it, isStructureAvailable() will always return false for laser satellite station?

Example: If I have laser satellite station in my research path, will I be able to remove it from my research plans (ie. not bother researching it) if the current game doesn't allow laser satellite stations to be built?

Also, is it just global vars that are stored, or are const's also stored on game save? Does the save handle basic arrays and objects? What about functions? Is there a way to prevent something going in to the savegame?

Yes, isStructureAvailable() also checks research availability. There is currently no way to read out the building limits. I will get to that soon.

If I were you, I would not start worrying about how much a user might have screwed up the game by disabling various things. I suggest you make it run fine for the normal case first.

There is no need to save consts or functions, they are there next time the script runs. Basic arrays are saved. Objects may or may not be saved properly, not sure what the limits are, as I have not tested that much. My recommendation is not to put objects on global. The only way to prevent something from being saved is by keeping it local to a function.

Ah, good, I was hoping that functions and const's wouldn't get saved as that would put lots of cruft in to the savegame files.

I've been pondering using classes and possibly creating a jQuery-like syntax in my AI file - are there any issues with altering prototype chains for custom objects, etc?

aubergine wrote:I've been pondering using classes and possibly creating a jQuery-like syntax in my AI file - are there any issues with altering prototype chains for custom objects, etc?

I don't really understand what you are asking.

It's probably easier if I get my AI in to a working state and show you

Essentially, I'm working on an AI with possibly some unusual features:

* Slicing the map in to sectors and then deciding what needs to be done in each sector
* Ability to manage more than one base (eg. it might build a separate base around an oil resource or destroyed player)
* Ability to build and manage multiple outposts to better defend map sectors
* Ability to transfer control of droid groups between bases and outposts, and assist allies
* Automated command interaction between bases, outposts and allies
* Ability to attack targets from multiple directions at the same time
* Better management of system resources: reduce CPU load (I hope!)

Those are the main bits I'm working on at the moment. I'm robbing a fair bit of code from NoQ's nullbot, but adding lots of my own code and structuring things somewhat differently to make AI task management a bit easier to handle. My current task is to get a class-based version of nullbot and then extend it to the extra features I'm looking to develop.

Future plans include (mostly reliant on what features are added to the JS API):

* Ability to interact with human allies via in-game messages / beacons - similar to DyDo AI
* Ability to adapt (+/-) to enemy capabilities (in single player skirmishes) to provide a more balanced game
* Ability to create multi-player groups (between allied AI players) - eg. each AI ally contributing some VTOLs to a group and then one ally taking control of the entire group (even though it doesn't own all units in it)
* Ability to coordinate multi-AI attacks on a target, with target optionally defined by human player
* Ability to create 'survivor' trucks which hide in ally bases - if the AI main bases get destroyed, its survivor trucks give it a chance to rebuild somewhere safer or as a last resort donate it's remaining power/droids to an ally

By allowing scripting in JavaScript you've opened Pandora's Box

aubergine wrote:
By allowing scripting in JavaScript you've opened Pandora's Box

just as long as you remember what happens to Pandora in the end we will all be ok.

.

aubergine wrote:It's probably easier if I get my AI in to a working state and show you

Essentially, I'm working on an AI with possibly some unusual features:

* Slicing the map in to sectors and then deciding what needs to be done in each sector
* Ability to manage more than one base (eg. it might build a separate base around an oil resource or destroyed player)
* Ability to build and manage multiple outposts to better defend map sectors
* Ability to transfer control of droid groups between bases and outposts, and assist allies
* Automated command interaction between bases, outposts and allies
* Ability to attack targets from multiple directions at the same time
* Better management of system resources: reduce CPU load (I hope!)

Those are the main bits I'm working on at the moment. I'm robbing a fair bit of code from NoQ's nullbot, but adding lots of my own code and structuring things somewhat differently to make AI task management a bit easier to handle. My current task is to get a class-based version of nullbot and then extend it to the extra features I'm looking to develop.

Future plans include (mostly reliant on what features are added to the JS API):

* Ability to interact with human allies via in-game messages / beacons - similar to DyDo AI
* Ability to adapt (+/-) to enemy capabilities (in single player skirmishes) to provide a more balanced game
* Ability to create multi-player groups (between allied AI players) - eg. each AI ally contributing some VTOLs to a group and then one ally taking control of the entire group (even though it doesn't own all units in it)
* Ability to coordinate multi-AI attacks on a target, with target optionally defined by human player
* Ability to create 'survivor' trucks which hide in ally bases - if the AI main bases get destroyed, its survivor trucks give it a chance to rebuild somewhere safer or as a last resort donate it's remaining power/droids to an ally

By allowing scripting in JavaScript you've opened Pandora's Box

In the end the Pandora's Box could very well transform into a cornucopia that propells WZ 2100 into the front ranks, finally, of elite RTSs while still maintaining its unique identity.

Let me unravel that comment some.

What you are proposing for your A.I. is gonna make it a VERY interesting and competitive A.I. - that much is clear.

The particulars of HOW it will accomplish that ALSO point to, and will demonstrate the viability of, a development direction for MP GPMs that will advance depth and breath of tactical game play like nothing else has done heretofore since 1999.

What I'm refering to in the last statement is the cognitive task ease of advanced maneuver (along with its associated situational awareness). And this is how I define "Advanced Maneuver": effective, simultaneous, command and control of at least 3 combat groups from coordinated, multiple vectors and varying velocities. (To translate from the A.I. context to MP capabilties would also require UI changes.)

I don't see anything else that has the definitive power to

"....propell WZ 2100 into the front ranks, finally, of elite RTSs while still maintaining its unique identity."

The best of good wishes in your seminal efforts.

- Regards, Rman.
.

NoQ wrote:For example, set an attack target for an AI and make sure AI doesn't attack anything else unless this thing is destroyed (?)

You can use bind() to call a function when the target is destroyed. You can also set a timer with that target as a passed in reference, which triggers until the object dies. Will this do the job?

Added new global const 'version' that gives version number of game. New object property 'health' that gives percentage damage to object (100% = no damage). Also new object properties 'armour' and 'thermal' that give kinetic and heat armour values, respectively.