Shard 0.4/dev - Page 35

Shard 0.4/dev

Here is where ideas can be collected for the skirmish AI in development

Moderators: hoijui, Moderators

User avatar
Anarchid
Posts: 1384
Joined: 30 Nov 2008, 04:31

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by Anarchid »

I've now run the following tests:
ZK on engine 96.0 with mex gadgets enabled on Trololo: FAIL
ZK on engine 96.0 with mex gadgets enabled on AlienDesert: FAIL
ZK on engine 96.0 with mex gadgets disabled on AlienDesert: FAIL

EVO on engine 96.0 with mex gadgets enabled on Trololo: SUCCESS
EVO on engine 96.0 with mex gadgets enabled on AlienDesert: FAIL
EVO on engine 96.0 with mex gadgets disabled on AlienDesert: SUCCESS.

Nuff said, it's the gadgets. I will attribute ZK failures to lack of proper shard config for that game.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by Forboding Angel »

Shard tries to build mexes offset of the patch. In evo, the snapping distance is huge. It's huge to the point if you select a mex and click somewhere, it will get built somewhere. I thought that that was a bit more user friendly, especially since the line shows you where it will be built. It just happens to unfuck shards silly offset mex placement algo in the process.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by AF »

The offset Shard has is more to do with the spot algorithm the engine provides rather than an attempt to offset it ( though I did attempt such an offset in NTai to great effect ).

The offset is because we as players expect to target the center of a metal spot, whereas the algorithm gives you the upper left corner of a spot not its center. This is usually a non issue as an extractors range normally overlapped.

What would you suggest is done? The spot locations can be offset by adding in half the average size of a metal spot to try and counter the problem, but Im not sure how much that should be these days. Would you know a good value in mind? Or a heuristic? Maybe half the extractor radius added to the x and z coordinates of the spot?
ant1
Posts: 8
Joined: 05 Apr 2014, 13:20

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by ant1 »

Thank you so much Anarchid, swift and decisive. :)

So, one hypothesis is that due to the implementation of the gadget, the evoRTS shard build() command gets prevented to achieve the construction of metal extractors.

And it is suggested that:
Anarchid wrote:[...] when this gadgetized metal extraction model is enabled, mex unitdef completely loses the "metal extraction" unitdef tag. Which would cause any AI to fail to recognize it[...]



Now, I can read in the above messages that the game developper and AI developper both appear to focus on another potential cause for bot defect: offset of metal spot coordinates (upper left corner) and metal extractor coordinates needed for building metal extractor (middle of spot).


To Forboding Angel:
First off, well done for the achievements the present state of the game represents.
Second off, I realise you can be presumed to have a rather full plate in front a ya right now, related to the game going live on Steam. Best of luck with it. :)

Fixing what is a pretty efficient AI for your game surely may help as regards newcomers to the game who could set-up interesting single-player game rather than having to go up against experienced players on servers right away... I guess.

To AF And Foreboding Angel:
Has the relevance of this hypothesis (coordinate offset) you seem to be bringing forward regarding the current issue (initial worker unit inanimate on dot-metal maps) been tested recently?

As Anarchid's test demonstrate disabling the mex gadget(s) allows EvoRTS shard bot to be able to build metal extractors on metal spots again. So the offset at the very least used to be handled correctly as long as the map native metal spot coordinates were concerned. It seems.

Are we ( am I :D ) possibly facing both issues here?
1) Changed unitdef tag due to gadget
2) Metal extractor building coordinates requiring offset relative to engine-provided metal spot coordinates.

I'm currently trying to force systematic metal extractor building by EvoRTS shard bot in a 100x100 map coordinates grid around one metal spot position provided by the engine algorithm.

This is going slow and may end up not being a reliable testing method, because I have not managed to disable all other forms of building commands.

So shard bot falls back on chain-building small energy generators, resulting in workers surrounding themselves with those and eventually getting blocked enough that some building commands (such as those for a metal extractor to that specific spot far away on the map) may get dropped/abandoned as unfeasible for too long a time...
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by AF »

If a gadget cancels an order as described, the unit would be idle and the engine should fire a unit idle event, if this doesn't happen then the result is what you're seeing, idle units. I would consider this an engine bug
User avatar
Anarchid
Posts: 1384
Joined: 30 Nov 2008, 04:31

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by Anarchid »

Are we ( am I :D ) possibly facing both issues here?
1) Changed unitdef tag due to gadget
2) Metal extractor building coordinates requiring offset relative to engine-provided metal spot coordinates.
I've inspected Evo unitdefs_post and it doesn't seem to do anything to metal extractors.

You can strike the "modified unitdef" hypothesis down, sorry for spreading confusion.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by AF »

Shard relies on the engine unit def objects, it doesn't read the files directly

I'm inclined to believe it's the unit idle problem, and that this causes the issue. When this is fixed shard should simply move on and not build extractors which would be a separate issue
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by AF »

https://code.google.com/p/evolutionrts/ ... cement.lua

The check here is too strict, it checks if the position is identical or not. It also doesn't check if it's a metal map or not

I would suggest that instead it should check for a spot within a radius and snap to it
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by AF »

I would also note, not just how would an AI know if such a gadget was in place, but how would another gadget or widget know without someone having to manually test and then start code editing?
User avatar
yuritch
Spring 1944 Developer
Posts: 1018
Joined: 11 Oct 2005, 07:18

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by yuritch »

From my work on NOTA Shard config, I also think something is wrong with idle unit detection.

Maybe the engine can skip 'unit idle' event under certain conditions. Seems to happen to builders, but maybe happens to other unit types as well, with builders it's just more noticeable as they should normally never sit there doing nothing.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by AF »

My theory is that if allowcommand returns false in a gadget, AI units become idle but the event is not fired.

Does anybody know how we could reliably test this? perhaps have it so that building a certain type of unit will return false, at which point we see if the unit halts until a stop command is issued, or if a unit idle event is fired
User avatar
Anarchid
Posts: 1384
Joined: 30 Nov 2008, 04:31

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by Anarchid »

https://github.com/EvolutionRTS/Evolution-RTS/pull/2

This allows it to cheat by placing mexes anywhere, but who cares.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by AF »

Interesting
User avatar
Anarchid
Posts: 1384
Joined: 30 Nov 2008, 04:31

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by Anarchid »

It turned a bit harder for ZK, not even because of missing config (hey that's solvable), but because of the following glitches and features:

1) the algorithm still returns the positions as offset, not as center
2) ZK denies income to mexes that are placed too far from spots (unlike evo where they are basically energy-free metal makers).
3) ZK mexes are much smaller, so even when made to snap correctly, the AI thinks its spot is unoccupied, and tries to build another mex there.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by AF »

A ZK specific version of the building behavior can be made easily by copying it into a zerok subfolder ( where zerok is the game name as returned by the AI interface )

Do you think adding a numerical offset to the spots location that was returned prior to passing it into the build order would be the best solution?
User avatar
Anarchid
Posts: 1384
Joined: 30 Nov 2008, 04:31

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by Anarchid »

I strongly suspect that magnitude of offset will be proportional to the spot size, but on the other hand, it's better tha nothing and the alternate approaches i've tried (like giving it more lease).

It always seems to offset into one direction, so i guess offset will circumvent it, i'll run some experiments later.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by AF »

The algorithm moves from the top left corner of the map and so all positions are the top left corner of the spot, not the centre as most people expect
User avatar
Anarchid
Posts: 1384
Joined: 30 Nov 2008, 04:31

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by Anarchid »

I have grepped the root ai folder of Shard and failed to find the default building behaviour that i would be able to override.

Nevermind, spothandler.lua does it. I've gotten to where it actually builds some things and sends them to fight, but then eventually this occurs:
[f=0008022] Warning: AI for team 1 (ID: 0) failed handling event with topic 3, error: 102
After about a 100 of those, it changes the tune:
[f=0009204] <SkirmishAI: Shard (team 1)>: C stack overflow

stack traceback:
[C]: ?
[C]: ?
[C]: ?
...43-gcf9dd70/AI/Skirmish/Shard/dev/ai/preload/api.lua:69: in function 'GetEnemies'
...-gcf9dd70/AI/Skirmish/Shard/dev/ai/attackhandler.lua:54: in function 'DoTargetting'
...-gcf9dd70/AI/Skirmish/Shard/dev/ai/attackhandler.lua:19: in function 'Update'
...e/97.0.1-43-gcf9dd70/AI/Skirmish/Shard/dev/ai/ai.lua:34: in function <...e/97.0.1-43-gcf9dd70/AI/Skirmish/Shard/dev/ai/ai.lua:26>
[C]: in function 'MoveAndFire'
...9dd70/AI/Skirmish/Shard/dev/ai/attackerbehaviour.lua:47: in function 'AttackCell'
...-gcf9dd70/AI/Skirmish/Shard/dev/ai/attackhandler.lua:102: in function 'DoTargetting'
...-gcf9dd70/AI/Skirmish/Shard/dev/ai/attackhandler.lua:19: in function 'Update'
...e/97.0.1-43-gcf9dd70/AI/Skirmish/Shard/dev/ai/ai.lua:34: in function <...e/97.0.1-43-gcf9dd70/AI/Skirmish/Shard/dev/ai/ai.lua:26>
...
User avatar
Anarchid
Posts: 1384
Joined: 30 Nov 2008, 04:31

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by Anarchid »

I've now gotten ZK Shard to the point where it can almost deteat the game's native CAI... except that once it succumbs to the bug, no new units are assigned behaviours.

This is something that only happens to ground attackers: i've managed to make it build and utilize bombers, and if i blow up its ground factory with /destroy, it plays the game until end with gunships and planes with no errors.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by AF »

The task behavior is responsible for building things

Specifically here:

https://github.com/Tarendai/Shard/blob/ ... r.lua#L129

You will want to amend p by adding the offset desired prior to it being passed into the build method, e.g.

Code: Select all

p.x = p.x+ 16
p.z = p.z + 16
I'm unsure of the cause of the C stack overflow, but it's worrying, are your changes somewhere I can see?
Post Reply

Return to “AI”