Group AIs

[hoijui]

I am a bit confused, as of how they should really work.
what i understand:

• a group of units can have an AI, which is called group AI.
• Group AIs are unsynced, like Skirmish AIs
• it works a bit like a skimrish AI, just only for a group of units:
  it gets updated every frame, receives events from the engine and can send commands back to the engine.
• a computer only handles group AIs of teams controlled by a local instance (therefore they can be/are unsynced)

what is unclear to me:

• only real players can use group AIs? (i think it currently is like this. should it be changed?)
• on each computer, there are GroupHandlers initialized for all teams in a game, so it is possible ot switch the team and use group AIs too there.
• when switching a team, the groups/groupHandlers/groupAIs from the old team are not deleted/released, and the ones on the new team, that already existed before, are not reinitialized?

i did read into the code a bit already, and i may could find out all of this by doing so. but the question is not just how it is, but also how we want it to be.

the main questions:
should Skirmish AIs be able to use Group AIs?
pro:

• good algorithms could be shared by skirmish AIs
• these algorithms could be developped and tested separately, and can also be used by normal players (-> more testing)

contra:

• a Skirmish AI that uses Group AIs will only work if the user has the appropriate Group AIs installed.
• the Skirmish AIs do not have total controll over all their units anymore -> may make some things more difficult for them. (eg, units controlled by a group AI blocking the path for a skirmish AI controlled unit.)

other question:
what happens with group AIs when switching teams?
a problem i could think of:
for units A, B and C, i create a group AI 1.
i switch to an other team, play there for some time, and then switch back to this team. unit A died, but my instance of the group 1 still references unit A -> problem?

as said.. i am confused, maybe i am seeing problems where they are not. i just wanted to see clear. help me please.

[Agon]

Do we need GroupAIs really?
Most modern mods are using Lua to control units.
Like metal extractor upgrading. I only used GroupAI one time to know what it is.
Besides they are really out dated, aren't they?

But I would like to have Skirmish AIs which can play for a human player that it looks like a human player plays but a AI is playing.

[AF]

Yes they have a use but its not quite what they are intended for. Ill outline it once I get to a computer with a working space key

[AF]

The original intention of groupAIs was that they would be assigned ot a handful of units which would then be managed, the prime example being metal extractors.

However most groupAIs either have no bearing on individual units, or run in such a way that what unit they are assigned to is irrelevant, for example, the metalmaker AI.

The original intention of group AIs is now obsoleted by lua widgets, however, group AIs ran as native code and thus had both a speed bonus and the use of native libraries.

Thus I believe that the group AI interface should be changed into a native library interface. This interface would not be accessible to the user and would be called from a lua widget or gadget as a library.

Otherwise for groupAIs to be viable as they once were, we would have to re-implement all the lua call outs in a C API, and this would be an extravagant waste of time.

[hoijui]

Thus I believe that the group AI interface should be changed into a native library interface. This interface would not be accessible to the user and would be called from a lua widget or gadget as a library.

I dont get what you mean with that. A sort of general interface for Lua to call native/C libraries? what does it still have to do with group AIs (as you said: converting the group ZI interface to this)

Otherwise for groupAIs to be viable as they once were, we would have to re-implement all the lua call outs in a C API, and this would be an extravagant waste of time.

i am used to write code conversion code now :D
where is that LUA stuff? i gonna C it!!


so do you suggest i remove everything that has to do with group AIs?
it would make life easyer for me right now. I too cant see a future for them.

what i am most concerned now, is the LUA stuff, as it gets more and more important and is still in-accessible for skirmish AIs.
maybe we should revive the discussion about that?
(i remember two vague/theoretical proposals of you, AF)

[AF]

Look at it this way, the vast majority of groupAIs do things the groupAI interface was never intended for.

Also the lua APIs are too variable to change, and they are great in number, and keeping a C interface for them would be far too much work both for you as the interface maintainer, and for any developers wishing to use them, it would be pointless.

Existign groupAIs are serving functions that would gain huge advantages from being able to use lua style callouts to generate GUIs, as well as the wider range of information. Thus the whole idea of the group AI is utterly obsolete as lua widgets already serve its original purpose far better and make the whole idea more accessible due tot heir non compiled nature.

Thus we should allow lua widgets and gadgets to take advantage fo the native libraries that are currently beyond their grasp. For example, a head tracking group AI would be fiddly, but if it was a lua gadget that called out to a native library when needed, it would be a viable additional camera. It would be easier to use, and it would gain a huge amount of potential functionality from the lua APIs.

This would also be far easier to implement.

[Tobi]

IOW, you say that GroupAIs can be removed, and one line somewhere in LUA dir commented out, so that LUA can "require" native DLLs with LUA bindings to some native library?

Not sure I'm pro that idea cause it would make widgets potentially platform dependent. (Like GroupAIs are now, of course.)

[AF]

There are numerous things for which native code is needed, and thus they are inherently platform dependent. As long as there's a mechanism for a lua widget to degrade gracefully when a platform lacks the necessary binary then I don't see why we couldn't do this.

[hoijui]

ok, no C interface then.

i am still unclear about his:

Thus I believe that the group AI interface should be changed into a native library interface. This interface would not be accessible to the user and would be called from a lua widget or gadget as a library.

i can imagine that for some things, LUA gadgets or widgets want to call antive libraries, but why woudl they need a special interface for that, and why should that be derived from the current groupAI interface?
i mean... can LUA code not do soemthign like:

Code: Select all

myLib = loadNativeLib("libName")
myLib.foo();

?

hmm.. i guess it is non of my business anyway, as it will not have anythign to do with the new AI system at all, right?

[Tobi]

Yeah LUA code can do that, apart from that it has been disabled now. (as security consideration, I suppose)

Hence my earlier post, stating basically that GroupAIs would be pointless for this purpose, as LUA can load native librarier without any help from GroupAI code...

[Argh]

If I get a vote, I'd say kill all of the current GroupAIs, until the day arrives that they can do things Lua cannot do. The speed advantages are heavily outweighed by the facts:

1. They often override behaviors which modern game designs are doing with Lua, so the first thing any game designer wants to do is shut them off. The easiest way is to remove all of the DLLs from Spring.

2. They have no Lua call-in / call-out functionality, and are thus unable to be extended, invoked or otherwise kludged into game designs that go outside a very narrow box.

3. Most of the ones that exist are ancient, bitrotten, and probably not all that much more efficient, when compared to their Lua equivalents.