Interface Redesign

[hoijui]

What if we wish to write an AI in pure C? Best to use structs when possible rather than classes.

yeah! we should not need any C++ at all on the AI side.

what about this?:

Code: Select all

class XZY {
  float x, y, z;
  void foo();
};

That won't work since there's a member function. We couldn't reliably have an array of these objects.

the question is wether or not we can cast it to one of the other 3 things tobi mentioned, which are cast compatilbe. as it is a class (a C++ thing), and i "learned" that all C++ stuff is incompatible between compilers, i though it may be a problem. the member function should be saved in the clas, and need no space in an array of objects of this type, but maybe gcc saves xyz and MinGW zyx in the memory? or do all compilers save class data in the same way as in C structs?

[Kloot]

No, class memory layout is part of a compiler's ABI, it is not specified by
the language standard. However the order of xyz is probably always the
same across compilers, incompatibilities are most often generated due
to differences in the compilers' implementations of inheritance and such.

[Tobi]

Yes,

Code: Select all

class float3 {
public:
  float x, y, z;
  void Method();
};

Can be casted safely to float* et al. in all compilers I know.

As long as inheritance and virtual functions are not used memory layout is basically same as flat C style struct.

[zenzike]

I don't think float3 is actually safe, since it inherits SFloat3. Inheritance usually isn't the same across compilers.

[AF]

Still lets keep within the confines of pure C when possible at this level.

[zenzike]

Absolutely. I suggest we use SFloat3 for this purpose, since it's just a C style struct. I actually think SFloat3 should be named float3 since it's the more primitive type, but it seems that idea has been rejected on another thread [1].

[1] viewtopic.php?f=12&t=15318

[hughperkins]

Hey! I'm kindof waiting to see where this goes

[hoijui]

am working on it, porting the callback from C++ to C. right now, the AI receives both the C++ and C callback. The C callback is yet missing functions, so the C++ one is used still, but i am now doing the shift to C.

some questions:
* there are two functions:

Code: Select all

	// returns the size of the created area, this is initialized to all 0 if not previously created
	// set something to !0 to tell other AI's that the area is already initialized when they try to
	// create it (the exact internal format of the memory areas is up to the AI's to keep consistent)
	virtual void* CreateSharedMemArea(char* name, int size) = 0;
	// release your reference to a memory area
	virtual void ReleasedSharedMemArea(char* name) = 0;

in the callback, which i am not sure of if they are usefull or needed. anyway they seem to be usefull for C and C++ AIs only (if at all).
* we are currently only porting the GlobalAI interface, what about the GroupAI one? first finnish this, adn later convert GroupAI to C, will that not happen at all?

[AF]

The shared memory area was added a while ago as a means of sharing data. Only OTAI made use of it however.

[Kloot]

* there are two functions:

Code: Select all

	// returns the size of the created area, this is initialized to all 0 if not previously created
	// set something to !0 to tell other AI's that the area is already initialized when they try to
	// create it (the exact internal format of the memory areas is up to the AI's to keep consistent)
	virtual void* CreateSharedMemArea(char* name, int size) = 0;
	// release your reference to a memory area
	virtual void ReleasedSharedMemArea(char* name) = 0;

in the callback, which i am not sure of if they are usefull or needed. anyway they seem to be usefull for C and C++ AIs only (if at all).

Don't just assume something is useless if you don't know what it's
for. Shared memory areas let AI's communicate, or store results
of certain calculations once so that other AI instances do not have
to make them too (ex. metal spot locations). They're not restricted
to merely the C++ AI's.

[AF]

The usage of these callbacks sort of fell apart when we realized things in the global namespace were shared between AI instances. Since nobody was bothered about sharing data between AIs that werent from the same codebase, the callbacks became unused.

[hoijui]

i did not "just assume".
i though by myself: accessing a shared memory area through this interface, from a Java AI for example, is extremely unpractical (from a pure technical point of view), and i am pretty sure that it is so in any other language except C and C++ as well. It would be done better with files.
from a more abstrct point of view:
As AF said, it is hardly usable for AIs of different codebases, as they would need to agree on a common "protocoll" for laying out the memory. which seems very unstable to me. i generally think it is a quite bad way for AI<->AI communication, becuase of many reasons. (unstable, unspecifiec protocol, version conflicts, possible inter AI memory coruption, ...)

assuming != guessing with no reason

and if it really is as bad as i think, and not even used by any AIs in practice as AF sais, then this is a good moment to get rid of it.

[AF]

I would see it as an opportunity to allow message based inter AI communication as a more viable alternative since discreet atomic messages can be sent across the network whereas a pointer to a memory area needs checking and updating and invovles all sorts of issues if its ever to be maintained across multiple client machines.

[Kloot]

The current method is not much less practical than file-based AIPC
would be (AI's would still need to define a common protocol and do
version checking, as with any messaging scheme allowing arbitrary
passing of data). I do not see the issue with cross-language access
either, it's really not different than the callback that enables AI2Lua
communication with the exception that AI's can read from / write to
the memory directly (as opposed to through a callback taking an ID
etc, which would have been preferable because of the safety issues
you mentioned).

The point is that you didn't elaborate on any of this in your first post
or offer an alternative of equivalent power, so that your motivations
for saying "this does not look useful" seemed somewhat illegitimate.

With that out of the way, let's discuss a better system. (Network-
based, as suggested).

[zenzike]

It seems to me that using a heap of memory is not the best way of communicating within or between AIs.

A messaging system is better because:

• An established protocol is more future proof.
• The events and commands can be registered, which facilitates debugging and profiling.
• The AIs can use the handleEvent() to handle these communications -- we have a common point of entry. (Which brings in all the advantages discussed before in this thread).

There is only one practical drawback that I can think of

• There may be duplication of datastructures (and therefore calculation) amongst the AIs, since they all need to hold their own copy of whatever would have been stored in common memory.

I don't believe this is a problem because:

• Within an AI static members mean there is no duplication.
• Between AIs there exists no established protocol for this.

If we add Events that handleEvent() will process that share whatever it is you think AIs might want to share, then we gain the fact that the communications could occur between AIs on different clients, since the engine handles the destination of messages.

This would mean that we would have to create a few commands that handleCommand() processes, but this should also be trivial, and again, the engine is control of what gets passed around.

Having the engine in control of message passing may seem costly in terms of network traffic, but I doubt that this adds significant overhead. The benefits are that the engine can intercept these messages and handle them as needed -- it could prevent AIs from communicating (if that's desired, since it might give the AIs an advantage if playing on opposing teams), or provide compatibility between messages of different versions. I'm sure there are other examples.

I'm looking forward to hoijui completing the handleCommand() side of things!

[hughperkins]

With that out of the way, let's discuss a better system. (Network-
based, as suggested).

Ice? http://www.zeroc.com/

[Agon]

With that out of the way, let's discuss a better system. (Network-
based, as suggested).

Ice? http://www.zeroc.com/

Ice instead of a wrapper for .Net or Java?
Or for all AIs?
Or only for the AI communication?

[hughperkins]

> Ice instead of a wrapper for .Net or Java?

Just brainstorming really.

Note that since the posting, I vaguely browsed over installation instructions for Ice, and it doesnt seem to support mingw natively out of the box, or even be officially supported http://www.zeroc.com/forums/help-center ... mingw.html

[Agon]

> Ice instead of a wrapper for .Net or Java?

Just brainstorming really.

Note that since the posting, I vaguely browsed over installation instructions for Ice, and it doesnt seem to support mingw natively out of the box, or even be officially supported http://www.zeroc.com/forums/help-center ... mingw.html

Hm, not official supported is bad.
What about D-Bus?
But I see a problem with windows. There is a port of D-Bus (winDBus) but I don't know how good and up to date it is.

[AF]

Wouldnt a network based layer end up invoking the windows firewall etc? This already happens with access unblock block prompts from innocent looking games.