Influence map overlay

[AF]

I'm going to need at some point soon a lua widget or gadget that displays a colored overlay of intensity on the map based on data sent from an AI through the C API.

Is anyone willing to help? Does it already exist? Any pointers? Anything would be much appreciated =)

[hoijui]

hmm... i guess the optimal solution for this is a well designed LUA<->AI interface. it would be the right time now to push this further, but well.. i would help and contibute and al, but its not really something interesting for me, so i wont be the main dev for this.
i dont know a hack for this eihter, but i guess there are ways to do hackishly.

[AF]

A basic prototype widget would suffice, if I have something that works with a basic API for the AI to work with I can elaborate etc, however this would be enormously helpful for AI debugging purposes. I would no longer have to output the threat map in NTai in TGA images I could see it in realtime on the map. AAI could benefit from this too, and there are various other uses for it.

[hoijui]

for this in praticular (map), it would help if we would abstract the maps like we discussed it for resources already. like.. we wont have a metal map, but each resource is an id, for *A mods this is one id for metal and one for energy, and you can fetch the resource map with the metal or the energy id (first returning a map, later NULL for example).
we coudl do the same with the other maps: radar map, jammer map, los map, ...
they would each have their own id, coordinated though a mapManager.
then we coudl allow adding arbritrary maps at runtime, eg the Lua gadgets/widgets/AI could add and fetch maps (or map overlays, if you want).

[AF]

They'd have varying scales dimensions etc, and so on, but while your proposal is good from an abstraction point of view, it endangers a lot of problems.

For example, say I have my map stored in a custom structure, say its stored in the form of a binary tree? Or a nodemap? An Octree?

An API allowing us ourselves to manage this combined with a helper library implementing what your suggesting would be best.

Metalmaps los maps etc should be changed as you said though

This isnt what i asked for though, thread split

[hoijui]

varying scales/dimensions are easy (getMapSacle(int mapId)). something i dont know how to best solve is the varying data types of the maps (float[], int[], unsigned char[], ...). so if we want ot fetch the map, we would have ot fetch it differently depending on its node data type.
the idea of a map in spring is clear: a 2D array, assignign values to points/areas on the map. this is the base, and this is how every API has to be, concerning maps. how you get to these values.. if you get them from a tree or whatever, does not matter, and does not matter for an API. aehm.. or i do not get what you mean.
an other thing... with this idea, we would kind of need a call-in to AIs.
when Lua for example requests the thread map form the engine, the engione woudl have to fetch it from the AI. this is different from an AI event as it has to return data. an other option is to make the AI write the thread map values to the engine at each frame.

[Tobi]

Note though that some maps are just implementation details, and may not exist anymore if some other algorithm is chosen to implement the feature they belong to. (read: LOS/radars maps)

(Or they may still exist, but give a performance impact iff they are used, because they aren't generated anymore as a side effect of the algorithm.)