Shard 0.4/dev - Page 38

Shard 0.4/dev

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

Moderators: hoijui, Moderators

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

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by Anarchid » 18 Nov 2015, 20:39

but nobody has ever gotten it working in Shard
Incorrect! Sethaven actually used to work for me at some time. Though that might have been offline-only, hmm.
My official recommendation would be to build things so that using sendtogamecontent is unnecessary to begin with
Not all things are doable as commands.

AFAIK SkirmishAIMessages are supposed to be at least somehow synchronizable in the same way that LuaUIMessages received by a gadget and modifying game state are synchronizable. In case of sethaven, the handling code for LuaUIMessage is exactly the same code as for SkirmishAIMessage, so if that caused a desync, all ZK games using retreat gadget would desync.

Some things to test:
- does removing sethaven from Shard fix the problem?
- are messages actually sent network-wise?
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by AF » 18 Nov 2015, 21:00

What does sethaven do?
0 x

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

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by Anarchid » 18 Nov 2015, 21:09

Judging from the source, unless i'm misreading, CallRules does in fact just execute code and doesn't send anything. So the function is kind of completely useless.

Sethaven sets a location. Units with retreat value will retreat to a closest haven if their hp is below critical percentage, as ordained by a gadget.

Oh damned it actually does in fact do just that.

In this case, sethaven is a global command, not tied to any units. How do i get it transmitted from RecvSkirmishAIMessage to everyone?

There also doesn't seem to be a way for the gadget to send anything to other machines without creating a command; not in this exact case (gadget unsynced -> gadget synced).
0 x

Kloot
Spring Developer
Posts: 1865
Joined: 08 Oct 2006, 16:58

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by Kloot » 18 Nov 2015, 21:22

Spring.SendLuaRulesMsg

Since native AI's run on a single client and are not commonly used in multiplayer games, CallLuaRules doesn't bother sending crap over the network.
0 x

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

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by Anarchid » 18 Nov 2015, 21:34

Aha, thanks. I assume this will work from unsynced gadget to synced gadget?
0 x

Kloot
Spring Developer
Posts: 1865
Joined: 08 Oct 2006, 16:58

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by Kloot » 18 Nov 2015, 21:55

yes (IOW, perfect for forwarding RecvSkirmishAIMessage)
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by AF » 19 Nov 2015, 13:16

Thanks for dropping by Kloot, I'm hoping to write those parts up and get something friendly/more comprehensive written up

The other part now is testing that Shard can receive a response
0 x

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

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by Anarchid » 19 Nov 2015, 14:51

I don't think responses work currently at all, hence "half duplex".

I'll fix up zk handling of RecvSkirmishAIMessage to relay it to rules by next stable.
0 x

User avatar
1v0ry_k1ng
Posts: 4656
Joined: 10 Mar 2006, 10:24

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by 1v0ry_k1ng » 19 Nov 2015, 16:00

Can someone give me a heads up when this is working again then.

GBCAI must be born
0 x

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

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by Anarchid » 19 Nov 2015, 16:03

You can test it locally already, the problem only occurs in MP games.
0 x

lamer
Posts: 146
Joined: 08 Mar 2014, 23:13

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by lamer » 19 Nov 2015, 16:10

Anarchid wrote:I don't think responses work currently at all, hence "half duplex".
Incorrect. It's 3/4-duplex: ai can ask gadget for info, but gadget can't ask ai.

Of course LegacyCpp can do both, thus it's possible to write own wrapper in Shard to emulate behaviour through SSkirmishAICallback* that ai got on init.
0 x

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

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by Anarchid » 19 Nov 2015, 16:15

Ohhh how did i miss that! Especially having actually commented on it! This allows Such Wonderful Things!

For example, in one fell stroke, RecvFromSkirmishAI could eval the received string and return its value to the AI, completely leveling the field between gadget AI's and native AI's.

One could even eval it in a sandboxed env to not allow abject evil -- but then, native AI's can already cheat if they want to.
0 x

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

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by Anarchid » 19 Nov 2015, 19:54

Problem: it is not possible to SendLuaRulesMessage as a specific team.
They get sent with the implicit team stamp of whatever the host player is.

I guess that can be part of the payload though and the synced part can verify that player sending the LuaRulesMessage hosts the AI for the team it tries to act as.

Shard desyncs in ZK are now fixed (ZK-side).

That wasn't very straighforward :|
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by AF » 19 Nov 2015, 22:11

Shard doesn't use the legacyCPP API, it uses the newer OO API
0 x

lamer
Posts: 146
Joined: 08 Mar 2014, 23:13

Re: Shard 0.35RC2 & 0.31.1 Not So Ballsey

Post by lamer » 19 Nov 2015, 22:41

AF wrote:Shard doesn't use the legacyCPP API, it uses the newer OO API
Yes. But! One can workaround some missing functions (because new OO API still gets SSkirmishAICallback* on init).

Lets take for example DebugDrawer from new OO API. It has only AddOverlayTexture and misses important UpdateOverlayTexture function (and others).
Lets look at how it's implemented in legacyCPP. Emulate it in our new OO AI and we have working UpdateOverlayTexture.

It is hax, but allows quick workarounds for broken parts (fixing awk-script in that example is not straightforward to me).
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Shard 0.4/dev

Post by AF » 28 Nov 2015, 22:51

I've made some changes in git master, and more are incoming, these should do the following:
  • Improve the Zero-K taskqueue economy a fair amount
  • Units that can move now have a bootbehaviour that takes control for the first 3-4 seconds to ensure they leave their factory before doing things ( does not apply to structures or units spawned before the 5th frame )
  • The attack handler had a bug that would sometimes print warnings in infolog related to handling the death of units, this has been fixed
  • The attack handler will attempt to weight different units when deciding where to attack, units are worth 1, structures and builders 2, factories 3
  • The attack handler now uses a 400x400 grid rather than a 600x600 grid
  • Attack groups have a minimum size of 8, and a maximum size of 25, if there are 50 attackers, 2 attack groups of 25 are sent to the same location. This is to ensure that attack group sizes never get so large that a group is never sent
  • Behaviours now have a OwnerDied callin, and no longer need to check UnitDead for cleanup
  • The fallback base behaviour now calls UnitIdle when UnitMoveFailed is called, as not all behaviours handled this event
  • Internal refactoring to help support use of the Spring Gadget API, use shard_include rather than require to load files that can be overriden
  • Primitive partial implementations of some Spring Gadget API wrappers ( incomplete, help needed )
Native Shard also had an issue where if you tried to call Type on an engine unit object, it would return 0, and you would always get nil. This has been fixed in the C++ portion, and will be available when new builds are created

Image

If you want to see the newer logic sooner rather than later, download the lua from the GitHub repo and replace your data folder with the new data folder. If you'd like to compare and contrast, copy the 'dev' folder, and rename it to something else, and put the new data inside there. Be sure to modify the AIInfo.lua version field to match the new folder name
Attachments
screen00006.png
(2.56 MiB) Not downloaded yet
0 x

User avatar
1v0ry_k1ng
Posts: 4656
Joined: 10 Mar 2006, 10:24

Re: Shard 0.4/dev

Post by 1v0ry_k1ng » 30 Nov 2015, 13:47

Is anyone working on the ZK config?
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Shard 0.4/dev

Post by AF » 30 Nov 2015, 16:01

I made some changes but I'm not aware of anybody else working on it
0 x

User avatar
prandipadaro
Posts: 92
Joined: 19 Oct 2011, 22:38

Re: Shard 0.4/dev

Post by prandipadaro » 30 Nov 2015, 22:23

i try to test this new logic ,on linux with portable installation of spring

-downloaded from git and extract the shard.
-copy a older version of shard that work on my spring.
-delete the AI/Skirmish/Shard/dev folder
-put the data folder downloaded from git in AI/Skirmish/shard
-rename the folder and the info inside AIInfo.lua for work correctli
-cause inside the data(now 'dev') there is not a 'libSkirmishAI.so' i copy it from a working shard

Launch a battle singleplayer but return a error:

Code: Select all

PANIC: unprotected error in call to Lua API (attempt to index a nil value)
AL lib: ReleaseALC: 1 device not closed
what is wrong?

and what you mean AF with:
-Primitive partial implementations of some Spring Gadget API wrappers ( incomplete, help needed )
how can i help? i can try maibe...
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Shard 0.4/dev

Post by AF » 01 Dec 2015, 00:47

Do you have a full info log? That error message doesn't tell me much information, and it doesn't look like any of the errors Shard would throw ( nil errors usually look different and have stack traces )

If you can also figure out exactly which version of Shard is running ( the .so lib ), that would be incredibly helpful

As a sidenote, AIs are stored like this:

AI/Skirmish/AI-name/version/

That folder then contains the AI, and is where AIInfo.lua and AIOptions etc are located. From the sounds of it you don't have the version folder, and it may be the engine itself throwing that error because it didn't find the files it expected ( it's probably thinking there's a copy of Shard with the version number "data" and is trying to load AIInfo.lua from the data folder, but ofcourse there isn't one there )

For reference, I would expected:

AI/Skirmish/shard/dev/
AI/Skirmish/shard/dev/AIInfo.lua
AI/Skirmish/shard/dev/AIOptions.lua
AI/Skirmish/shard/dev/libSkirmishAI.so
AI/Skirmish/shard/dev/data/

Alternatively if you wish to compare and contrast, you could do:

AI/Skirmish/shard/git/
AI/Skirmish/shard/git/AIInfo.lua
AI/Skirmish/shard/git/AIOptions.lua
AI/Skirmish/shard/git/libSkirmishAI.so
AI/Skirmish/shard/git/data/

then modify AIinfo.lua to specify git as its version rather than dev
0 x

Post Reply

Return to “AI”