Shard 0.4/dev

[ant1]

Wow, fast reply much appreciated. :)

By metal map do you mean
-those with metal spots (dedicated location where metal extractor need to be built)
- or those where metal extractors can be built anywhere?

In my current experience Evo-RTS shard performs better on the latter.

Thank you for the work by the way.

[AF]

Ones where the metal is distributed evenly rather than in spots

[ant1]

Reporting progress (by all means tell me to stop if this is of no interest).

Broke everything I had going shortly after previous exchange. :D
Got some working order back this morning.

Situation is now very similar to what it was previously.
Can get a game of EvoRTS running with 2 shard bots in 1v1.
Full shard-esque behaviour is displayed only on metal-maps (i.e. metal extractor can be built almost anywhere and do get built; Trololo).
No movement gets initiated on map with metal spots (i.e. metal extractor need building on specific spatially restricted locations; AlienDesert).

So, provided the way things are set-up on my end (best described as haphasardly I'd suggest), everything looks as if the outcome of EvoRTS shard is opposite to stated expectation:

[...] not sure the metal placement algorithm that the engine provides is going to run well on metal maps [...]

I think this is similar to what was described in the 2nd paragraph of this post there:
http://springrts.com/phpbb/viewtopic.ph ... 05#p544905
on 16 Jul 2013, 07:15

There is some strangeness going on with Shard and buildings, it seems sometimes Build() can return true without actually starting construction, so the unit sits there doing nothing (it has no active orders visible from spectator view) until my 'watchdog timer' code finds it. I suspect maybe it gets off-map coordinates for build location, so the order is not drawn and nothing is built? It's quite hard to debug this from lua side, as I have no access to unit's current order from Shard lua.

Although same user had following to say on 06 Nov 2013, 19:05 in this very thread (p33):
http://springrts.com/phpbb/viewtopic.ph ... 45#p549545

[...] had no problems of this kind with NOTA, so c++ part is supposedly working fine. Both static and mobile builders always place mexes where there is metal.

Some testing performed with limited means of newcomer to lua, shard, evoRTS and Spring:
1) self.unit:Internal():Build(utype, p) in taskqueuebehaviour.lua is the call that allows extactors to be built on metal map. Therefore this call can result in extractors being built.

2) above call does use position values as they are returned by ClosesFreeSpot(), these position values do correspond to those of metal spot positions according to the output of game.map:GetSpot(). So the attempt appears to happen at a location that is not off-map and rather consistent with/coherent with/relevant for a metal-spot location.

3) Attempting to build the extractor systematically around said position, over an area +/- 38 position units (larger leads to packet loss says in-game console) by increments of 1 position unit, resulted in 100% of these calls to Build() returning True while still no metal extractor was getting built, nor any movement initiated. 1 building constructon position unit = 1/8 in-game map dimension unit = 1/(8*64) lobby map dimension unit.


Expect to try some more, so as to restore/obtain expected behaviour (actuated construction of extractors on metal spots) by EvoRTS shard on metal-spot maps before anything else.


Again, if anyone can reproduce, or not, said expected, or unexpected, behaviours, please comment. :)

[AF]

hmmm and this is also the case with vanilla unmodified Shard?

[ant1]

As far as I can tell yes.

But again I can not judge of how close to standard my installation and setting-up of the different components has been (Sping engine, lobby, EvoRTS, etc.) as this is all very new to me still.
I have the distinct impression that this will end up being caused by something unorthodox of the sort.


Just tested on the same two maps (AlienDesert [metal spots] and Trololo [metal map]), EvoRTS 1v1 both shard bots.

With following configuration:
Contents of Shard-master.zip > data
downloaded from https://github.com/Tarendai/Shard
dropped into my local ... > skirmish > shard > dev folder

And using the dll file from the opening post of this very forum thread:

Newer version ( dll only, drop it into a 0.35RC2 install ):
download/file.php?id=6905

Here locally, with these unmodified shard files, everything looks as if metal extractors fail to get built onto metal spots (and no other movement happens either), whereas metal extractors do get built (and everything that follows) on the metal map.

[Anarchid]

Could this be possibly related to the fact that since a while on dot-metal maps ZK and Evo resort to their own implementation of metal stuff?

Unless i'm wrong, it does all of the following and possibly more:
- runs its own dot detection algorithm
- can be overridden in a config file by map or game
- overrides metal values for discovered dots as it pleases (evo has 0.5 income for all spots, ignoring how bright it is in map's metal channel).
- plays merry hell with conventional extraction tags in mex unitdef (i think this also breaks RAI, which since a while has unlearned to build extractors in ZK)
- falls back to engine metal extraction when dot detection algorithm fails, such as on Trololo and Speedmetal.

[AF]

I wasn't aware of that, and have no information on how that impacts AIs.

Also, the git repository is the latest and greatest, all other sources can be ignored. Especially zip archives in this thread

[ant1]

Thanks Anarchid, that all sounds very consistent with what I observed so far:

1) Worker does attempt but fail to construct initial metal extractor on metal spot positions provided by shard engine (presumably based on, and apparently self-consistent regarding, map info).
2) Failure to construct initial metal extractor appears to result in worker not initiating further action.

Assuming the problem is related, one concern from what you wrote is changes to "conventional extraction tags in mex unitdef" (I'm new to all this):
. Can those tags be expected to be essential for in-game creation of metal extractor?
.. Are they essential in convential mods?
.. Can they be suspected to be essential in the new EvoRTS implementation?

And one glimmerofhope seems to reside in "can be overridden in a config file by map or game", although I have no idea how to do that yet.


At the moment I would like to be testing systematically every position in a dot-metal map for metal extractor building.

However, as stated above, from what I can gather (essentially playing with .. > shard > dev > ai > taskqueuebehaviour.lua), following the one initial attempt at constructing one metal extractor, no further action seems to be taken by shard bot.

What causes shard bot to stop issuing commands after this initial failure to build? (reminder: build function seems to return True in 100% of cases -at least in this scenario- , however overriding that outcome to be False still results in shard bot taking no further action following the one initial unsuccessful attempt).


What I see of shard bot playing EvoRTS on metal-maps is quite an incentive to find out how to get it back onto dot-metal ones. :)

[AF]

I'm worried that its suddenly stopped working on non-dot maps, are you sure this isn't specific to that map and not on others too? When I was developing it, and forb making adjustments, it was non metal maps that got tested on.

Does issuing a stop command to the unit make it resume its queue? If a unit issues a command and it fails, but there is no failure event or unit idle, the AI doesn't know that it failed and doesnt continue ( it thinks the unit is busy doing what it told it to do )

[ant1]

I am sure of very little.
All of this is subject to my embryonnic understanding of this environment and resulting handling of it. What it says is that there is the possiblity for a newcomer to Spring and EvoRTS to find the shard bot not very entertaining on dot-metal maps. :)

I'm getting confused in terms again, I have been using:
. Metal-map: metal is "distributed evenly rather than in spots"
. Dot-metal map: metal is available at specific spatially restricted locations/positions (i.e. spots).


EvoRTS shard bot animated on metal map and inanimate on dot-metal map, reproduced on:
Speed_Ball_TechA (metal map)
Green Comet Basic (dot-metal map)


As for the stop command, thanks for the suggestion and related basic brief on AI, I will be experimenting with that and report on progress.

[AF]

What about the maps forboding angel produced, preferably his more recent ones?

Also /cheat /team 0 or /team 1, select the AI units and see what the command they're given or executing is

[Anarchid]

.. Can they be suspected to be essential in the new EvoRTS implementation?

I don't think Evo is going back to "normal" Spring extraction model, so yes, this is something that is here to stay.

From what i can read of those gadgets:
- Mex table is stored in GG.metalSpots variable that is accessible to all gadgets, but not to native CPP stuff. You'd have to find a way to bridge it somehow.
- (actual)Mex income (per mex) is stored in an UnitRulesParam of said unit.

I don't know if Shard can access the UnitRulesParams, but if it can, you could plausibly persuade Forb to also provide a GameRulesParam for the mex table, making it easier to access with Shard.

I strongly suspect that 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, unless hardwired to identify metal extractor units by other qualities besides the unitdef tag (especially if none are found in game).

I also think that i've probed in the past about how/if it was possible for Shard to access such lua game informations, and some pathway for transfer was possible...

I'm worried that its suddenly stopped working on non-dot maps

If i'm understanding the issue correctly, the problem is completely reversed. ]It is not working on regular, dot-distribution maps, but works on things like speedmetal and trololo where zk/evo metal gadget falls back to normal spring extraction model.

[AF]

When did this change happen?

[Anarchid]

When did this change happen?

In ZK: April 12th, 2012.
In Evo: May 15th, 2013.

[AF]

Yet we only now have broken spots?

[Anarchid]

Better question: when was the last time somebody actually paid any attention to Shard in Evo or ZK?

I strongly suspect it went gebork back then, and only got noticed now because somebody tried to invest effort into making it work.

Of course, there's an obvious test case: disable that gadget in a local zk/evo install and see what happens.

[AF]

People have made changes to Shard since then and worked on it though, I find it hard to believe they wouldn't have noticed considering the amount of work put in

[Anarchid]

Quick glance at https://github.com/Tarendai/Shard/commits/ doesn't reveal any of that work touching Evo or ZK, it's all BA.

Correct me if i'm wrong or missing anything.

Doubts aside, i'll run the test this evening to see if it's really the metal spot gadget that throws it off. Any suggestions on how i should perform it? I'll need the trunk git version of Shard? Do i need ant1's work of any sort for the test to be reliable? Is trunk Shard even supposed to work for ZK or Evo out of the box?

[AF]

It should do, git master of Shard is what's pulled into spring releases these days, it should be compatible with the current spring trunk and latest release.

If things like this continue to happen then I see 2 options:

- Finally get around to adding a Spring API layer in the API to bypass Shards internal API if it's available
- Fix the lua <-> AI comms so that they work as everybody expected in full duplex

[ant1]

Anarchid, I think you have a clear view of the suspected issue.
Nothing I have worked on so far should be necessary for performing the test you are thinking of.
I would suggest (or confirm) to reproduce the issue first before trying to bypass the gadget.

Is trunk Shard even supposed to work for ZK or Evo out of the box?

Yes, only add the Skirmish.dll file provided in the spring release into ... > AI > Skirmish > Shard > dev folder where also are AIInfo.lua and AIOptions.lua

If things like this continue to happen then I see 2 options:

- Finally get around to adding a Spring API layer in the API to bypass Shards internal API if it's available
- Fix the lua <-> AI comms so that they work as everybody expected in full duplex

AF, thank you for already considering options to sort the suspected issue, that's inspiriting.

What about the maps forboding angel produced, preferably his more recent ones?

Latest ones I found on springfiles.com are 2012-mid 2013.

All dot-metal maps.

EvoRTS shard bots stay inanimated on all these.

evorts_-_riverglade_-_v12.sd7
evorts-higher_grounds-v13.sd7
evorts-new_iammas-v12.sd7
evorts-proving_grounds-v12.sd7
evorts-winter_basin-v16.sd7

On the bright side I now possess a bunch of nicely crafted maps.

Also /cheat /team 0 or /team 1, select the AI units and see what the command they're given or executing is

Yes, by interrupting (stop) the inanimate worker it then "comes back to life", and appears to resume its task queue. This results in seemingly normal building plan to be carried through from then on, including factories, minus metal extractors althought attempts at building those do happen (not sure whether later created workers also become inanimate upon being asked to build a metal extractor, but would supsect -hypothesize- so... Although I can catch Many attempts happening, unsure)

.. Can they be suspected to be essential in the new EvoRTS implementation?

I don't think Evo is going back to "normal" Spring extraction model, so yes, this is something that is here to stay.

I strongly suspect that 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, unless hardwired to identify metal extractor units by other qualities besides the unitdef tag (especially if none are found in game).

That is the answer to my re-quoted equivocally formulated question. :)
This unitdef tag and lack thereof can potentially confuse or disrupt the current implementation of EvoRTS shard bot.