drawing on the map, for debug or other purposes

[eronoobos]

In the spirit of extending the API, rather than bloating the BA/BAR config some more, I was thinking about how best to add the ability to show information on the map.

For the Spring Skirmish AI, is there any kind of interface already in place, similar to https://springrts.com/wiki/AI:Development:MonitorAndDebug ? If not, the only way I know of is, as the BA/BAR config has done, write information to files, which a widget then reads & interprets into visuals. The widget would have to be copied into place.

The Spring LuaAI implementation could send similar information directly to the same widget, which in its case could be a part of the ShardSpringLua package.

As for how the the functions would be accessed from within Shard Lua, should it be in map, or would this be a case for adding another object, draw, or similar?

Sketchily, the functions would be something like
DrawPoint(position, color, label)
DrawRectangle(position1, position2, color, filled, label)
DrawCircle(position, radius, color, filled, label

[tomjn]

Historically the Spring AI interface has provided primitive mechanisms for displaying data. You can place markers, or draw lines, but they're not performant, and they're in 3D world space. Drawing map overlays or shading units has been impossible.

In the past I've written code in NTai to display TGA files in world by drawing lines for each pixel above the ground. I've created group AIs that draw symbols above units. These are laughable in quality when compared to what Lua widgets can do.

Those APIs exist in the current interface, but only in the legacy API. The C API has them, but there are no OO calls for them in the C++ OO API that Shard uses. They could be manually created, but I haven't the experience, documentation, or the toolchain to do that.

Perhaps if a gadget can send the needed commands of what to display to a widget, then Shard can send the needed information over and provide a basic API

[eronoobos]

If you're talking about the C++ AI, the C++ AI interface can communicate with gadgets? That would less messy than writing/reading from files, but then games would have to have the gadget.

If you're talking about the Lua AI, yes, definitely a gadget can send commands to the widget.

[Anarchid]

Native AIs can exchange strings with LuaRules and LuaUI, and execute code in response to said strings (up to and including abject eval).

An in-Shard example is the ZK config which receives the metal spot configuration from a gadget via LuaMessage, and uses a similar message to create retreat zones on its nanoturrets.

My own approach to debug draw was just opening a window - see the image in ZKBAI's readme. ZKGBAI doesnt actually do it anymore, but most other ZK native AIs do (CircuitAI, ZKMBAI, CSI)

[eronoobos]

Ah, thanks. To send debug information to the drawing widget, I can just use game:SendToContent, which, looking in the ZK code, is received by RecvSkirmishAIMessage. Much better than writing to a local file and reading it with a widget.

The example of receiving a metal spot config from a gadget could be quite useful for a C++ handling of the control points EvoRTS uses :-)

[Anarchid]

The example of receiving a metal spot config from a gadget could be quite useful for a C++ handling of the control points EvoRTS uses :-)

It is, however, much cleaner to use GameRulesParams. I wrote the ZK Shard config in 97.0.1-xxx days when GRP support was badly broken. It has become better since, and if Evo doesn't write control points to GRP, it should (it used to do if for mexes).

I think Circuit uses GRP parsing of metalspot map, so you can see that for reference. It's also C++, so should be pretty much c&p :P

[tomjn]

That might work for a Lua AI, but how would Shard native access that?

[Anarchid]

You mean reading GRP? I guess it should be added to Shard API if it's not there; java and cpp interfaces support it directly and examples using them exist for both (zkgbai, circuitai, csi)

[eronoobos]

i added the feature with tarendai@7be4b1d, but i'm keeping this open because if Shard becomes able to read GRP, that might be a better way than the file buffer i'm currently using for Shard native to implement drawing on the map