Mono AI wrapper

[Agon]

For C# I think making a small C++ AI that allows interproces communication (ie. TCP over loopback) and has a way to start a process is way easier then integrating either mono or the CLR directly into an AI DLL.

EDIT:
Some advantages:

• AI can just use WinForms or WPF or whatever for realtime debugging windows
• Debugging the C# code with express edition of VS and/or MinGW compiled Spring would actually work
• Spring memory corruption can not crash the AI
• AIs compiled for different .NET runtimes can be combined in a single game (it's impossible to load different .NET runtime versions in same native application; that's also the reason windows shell extensions need to be written in C++)
• AI would run in different thread (process) automagically, no need to think about threading issues etc.

Some disadvantage:

• Getting unitdef etc. will be somewhat slower because data actually has to be copied a few times.
• AI may lag a bit behind engine.
• Everything AI does is asynchronous, makes certain things a bit harder.

This has some advantages.
But what about D-Bus, maybe it is faster and needs no network card?

[aegis]

dbus would have more overhead than a specialized loopback connection

you don't need a network card to do a loopback connection

and it would be cross-platform

[Tobi]

Aaand .NET has TCP support, I don't think it has d-bus support since d-bus is X11 only (right?) and .NET is win only (not counting mono).

Only alternatives I can think of that do exist on win are pipes and shared memory, but AFAICS TCP is way easier.

[Agon]

Aaand .NET has TCP support, I don't think it has d-bus support since d-bus is X11 only (right?) and .NET is win only (not counting mono).

Only alternatives I can think of that do exist on win are pipes and shared memory, but AFAICS TCP is way easier.

D-Bus was heavily influenced by KDE2├óÔé¼ÔÇ£3's DCOP system and has replaced it in the KDE 4 release; it is already implemented in Qt 4, GNOME, Windows, the maemo mobile platform, and the OLPC XO-1. In GNOME it has gradually replaced most parts of the earlier Bonobo mechanism.

D-Bus is available under windows.
Okay maybe a bit overloaded :D

Mono can do TCP connections, too.

TCP has another advantage, we could connect to a server which runs a autohost and setup the AI remotely.

But we need something like a protocol to transfer the informations from and to the AI/Spring.

[Tobi]

Anything would do, I guess easiest is to just transfer binary blobs. Doesn't need much thought unless you want to make the TCP itself a public interface too.

[Agon]

I read this article: http://www.mono-project.com/Embedding_Mono
And it does not look that hard to implement. I think TCP or embedding Mono is nearly the same work.

@Tobi:

# Spring memory corruption can not crash the AI

If Spring has memory corruption would it not crash, too?

GUI could still be used with an embedded Mono.

I have no experience in this so I don't know what would be easier/faster to implement or what would be user friendlier.

[Tobi]

Does mono have as good debugging facilities as the CLR in combination with Visual Studio?

[Agon]

Does mono have as good debugging facilities as the CLR in combination with Visual Studio?

Nearly: http://www.mono-project.com/Debugger
More informations: http://www.mono-project.com/FAQ:_Technical

[Tobi]

The debugger package includes a console debugger named "mdb", and MonoDevelop (http://www.monodevelop.com) will also provide a GUI interface for it soon.

(From: http://www.mono-project.com/Guide:Debugger)

Note: The Debugger Addin is currently NOT working in MonoDevelop

(From: http://www.monodevelop.com/Enabling_the_Debugger)

Doesn't seem like it's as polished as Visual Studio. (ie. unless that wiki is outdated there is no IDE with integrated debugging functionality yet)

[Agon]

Monodevelop from SVN which will be 2.0 has debugging abilities.
I never used debug in VisualStudio so I can't say if it's similar to Monodevelop debug functions.
Windows user can use Sharpdevelop 2.x which supports mono building but only limited.

[imbaczek]

if there's one thing that I hate about open source devtools, it's the lack of Visual Studio debugger.

[Agon]

if there's one thing that I hate about open source devtools, it's the lack of Visual Studio debugger.

http://www.mono-project.com/Working_wit ... ual_Studio

Or use Monodevelop.

[Licho]

Imo its much easier to embedd mono into engine and wrap around important AI calls (pass them to loaded AI dll which is hosted by mono).

It will be much faster and easier to debug/implement than TCP.

And if i remember correctly, there was already such project - there was working C# AI.
I think it used mono/.net wrapper inside C++ AI dll to run actual .net assembly.

Going TCP is the hard way now.. you have to serialize/deserialize arguments, route calls to proper method, handle exceptions etc. Wrapper would be much more complex,slow and prone to bug compared to reusing existing facilities for embedding mono

For development/testing you can use visual studio and microsoft .NET and for actual game mono.

[Licho]

D-bus is no way to go. Its better for interprocess communication than for this and its implementations for windows/.net are complex and need extra software installed.

[Agon]

Yeah, totally true. Embedding Mono is much better than a TCP connection.
And D-Bus would generate another dependency.

But to the bigger question: Who would do this? And who could do this?

I can't do it currently.
I do not have the knowledge to do something like this.
I could try to learn it but o.O a hobby programmer tries to embed Mono in Spring.

Before someone can start, we need to wait for the new interface