Loading...
  OR  Zero-K Name:    Password:   

AI build

14 posts, 583 views
Post comment
Filter:    Player:  
sort

10 months ago
Hey so I've been going down the list of all possible ways I can see to screw with making/modifying an AI in Zero-K to see if I can get some behavior I'd like.

ZKGBAI was easy to build but crashed, Circuit is easy enough to build ... but also crashed things, Python would have been awesome (no dll's to link!) but that is stale in a bad way, Shard seemed good too but also doesn't work in Zero-K (doesn't crash which is nice, but the commander just stands there, maybe fixable?). (Why is Shard broken anyway?)

So, what is the most direct path to hacking away on an AI for Zero-K anyway? This would be on a Ubuntu 20.04 box.

I guess with a blessed build environment, Circuit would be in reach.
+0 / -0


10 months ago
Circuit AI. Give details about your crash. Maybe you built the wrong one for the wrong engine.
+0 / -0

10 months ago
Java tends to be fairly straightforward. You have to check that you built against the interface libraries from the engine you're using (stored in [engine]/ai/interface/java/0.1) and make sure that JAVA_HOME is set to a JRE version compatible with your build as well as being the same 32bit/64bit as the engine you use.
+0 / -0
I could never get Java AIs working on Windows. Your best bet would still probably be either Lua (with Shard) or C++, I've built spring before (on MSVC x64 + VCPKG, which required some significant changes the cmakelists, and to streflop but that's another story...) and contributed to the engine (only a tiny bit though, like 2 years ago) so I know a little bit about the build process, but not much about the AI interfaces.

Shard isn't broken. It's not an AI. It's an AI _framework_. See 'AI/Skirmish/Shard/README.md' in the source files for details. From what I can see using Shard (you already know how to get it working, from what I can tell) would be the easiest way if you're willing to use Lua.

For C++, in theory, you could do something like this:
* Clone the maintainance branch of Spring off Github
* Make sure it builds
* Work from the 'AI/Skirmish/{YOUR AI NAME HERE}' folder
* Make your own AI using CppTestAI as a template

This way you'll have access to debug builds of both Spring and your AI. Hopefully you'll be able to do stuff like set breakpoints, etc. and develop much faster. As for developing with this process and Zero-K... that part I'm afraid you'll need to figure out yourself. A lot of people have trouble getting the Java AIs working apparently, but if you can get it working it could probably be simpler if you like Java.

sorry if I'm talking a bit out of my depth and misguided you, just want to help. good luck :)
+1 / -0
That reminds me. By far the easiest AI to modify is CAI. All you have to do is set up Zero-K development and then edit a gadget. There is nothing to build and it is sure to work.

Getting a dev environment: https://zero-k.info/mediawiki/index.php?title=Zero-K:Developing#Getting_sources

Here is the gadget: https://github.com/ZeroK-RTS/Zero-K/blob/master/LuaRules/Gadgets/ai_CAI.lua
+1 / -0
quote:
(Why is Shard broken anyway?)

It has not been updated for a long while, it LOS cheats by default, and it requires quite a lot of hoops to jump through to get it to work with ZK, because it assumes a lot of TAisms that ZK dispensed with, cannot place or select a commander by default, etc. It's less broken than incompatible.

quote:
ZKGBAI was easy to build but crashed

I guess i'll look into this over the weekend.
+0 / -0

10 months ago
Thanks for responses.

My self-built Circuit was a segfault ("Segmentation fault in Spring 104.0.1-1544-ge1f249f maintenance") but I didn't grab any special flavor of the git code to compile against, just whatever was latest. (Which of course I knew could be problematic, but it wasn't clear how to get this precise "104.0.1-1544-ge1f249f".) But this "Getting_sources" link looks good, I'll digest that a bit.

The Java issues I had are documented so some extent in the pinned ZKGBAI thread. (Maybe this is because I am not using Oracle Java? But I'm not setting up an account with Oracle, yuck.)

That CAI is interesting. Being a widget AI, does it operate fundamentally differently from the others? One point I am interested in is how the engine and the AI interact, how tightly coupled they are.
+0 / -0

10 months ago
You can get the correct engine version by using the checksum.

For 104.0.1-1544-ge1f249f do
git checkout e1f249f
+0 / -0

10 months ago
Thanks. I'm fairly basic with git.
+0 / -0
Official engine is built with gcc5.x. From my experience there's an ABI difference between gcc versions. So either you can compile AI with gcc5 and use official engine, or compile AI and own engine version with gccX (X>=5). Engine's commit matters as DF pointed.
"submodule update --init" - pulls CircuitAI (current stable, not bleeding edge testing).
"cmake . && make spring" - builds both engine and all related AIs.

Related: https://springrts.com/wiki/AI:Development:Lang:Cpp
+0 / -0

8 days ago
Is this a bad place to ask dev questions?

Anyway I've been getting familiar with CAI, but I'm not great with Lua. My plan is to introduce a new file containing my stuff, along with an entry in luaai.lua matching the name I declare in gadget:GetInfo(). I've played around enough to see that much works.

Lua is very flexible, more than I am used to. What kind of scope is a file like luarules/gadgets/ai_cai.lua part of? I assume from luarules/configs/cai/configcoordinator.lua that I could define some new handlers in some new lua file and lean on most of CAI (I've been following the code through to see how that works). I guess lots of stuff is going into one huge global scope?

Take a variable like "mexSpot" from ai_cai.lua, it is not "local" ... so does that thing have scope in a hypothetical "ai_noobAI.lua" that I could make? I could of course test that particular detail (with the caveat that Lua would just create the variable on demand), but rather than feel my way forward I wonder if someone would be so kind as to give me a big picture of how this should work.

I might tap into CAI, or play with something distinct. Looking like some AI hackery is very doable though!
+2 / -0
I don't screw around with scope much. My recollection is that each gadget file is its own scope. I avoid having files reference anything from another file that isn't either a return value or inserted in to a global table (usually Spring. or GG.).

I mostly wrote CAI in a week or two around mid 2010. As such the code is pretty bad. I don't recall going back to it and being repelled by the structure, so perhaps the structure is ok. I started working on CAI 2, with features such as pathfinding, and the code for it is still hanging around.
+1 / -0

7 days ago
Thanks. A few more questions if you have a moment:

Is an AI gadget like this totally contained on the computer hosting it, with only the resulting commands being sent to other players?

What does this _G object do? There is a comment "is this even needed to transmit to unsynced any more?" and in another file "allow gadget:Save (unsynced) to reach them" ... is this related to Save()?

Is it harmless to decide Save() and Load() are complicated and scary, and ignore them? (Is it possible to save the game state?)

Is it OK to decide the synced and unsynced thing is complicated and scary, and ignore it? Probably the answer to this and the previous question is that its fine in regular multiplayer but in some cases like the campaign it breaks assumptions.
+1 / -0


6 days ago
An AI gadget like CAI is just a synced gadget so it runs identically on all computers. The commands are not sent through the network.

_G is a table that can be used to communicate between synced and unsynced luarules. You don't have to worry about Save/Load. It works automatically. No code for it is required in the gadget (or any gadget for that matter).

You can entirely ignore unsynced.
+2 / -0