I’m extremely interested in a chatscript DLL for a game project I’m working on (unity engine, c#). Can your current build system create one or would I need to request one from you?  I’ll take a stab at trying to generate one if I have to. 

Using network for now during developement, but since the game is going to be no central server multiplayer with one of clients running the server in-game, embedding chatscript in the client makes more sense. Don’t want to run central server for chatscript when I’ve side stepped doing that for the game.

It’s been a while since I tried to create a DLL for CS. The current build system does not build one. I’d be happy if you could take a stab at it. I’m kind of busy on some other tasks right now.

Quick update on my research into this so far in case anyone is interested in this or already has knowledge of getting chat script to run embedded in C# on mono.

Unity runs on Mono ( open source cross platform .NET ) - so I believe what I need to do is covered here:

http://mono-project.com/CPlusPlus
http://www.mono-project.com/Interop_with_Native_Libraries

I’ll try to fire up VStudio this weekend and see how that goes.  Microsoft is not my native language ( I’m a (li|u)nix or mac guy ) but I can poke it with a stick and get it to squeal on occasion if I have to.  It’s a shame gcc doesn’t support CIL, looks like it might be in the works one of these days.

I don’t have the Pro version of Unity, which I believe is required to run C++ Dlls - so will just be verifying the DDL will load and run via Mono on the mac with a C# wrapper - figure if it does that it should work across all platforms Unity supports ( windoze, linux, mac).

PS Bruce - thanks a lot for creating and open sourcing chatscript!  I first used a program created by you back in the 90s when I had read about this game called Go but couldn’t find anyone who knew how to play it…   I spent many happy hours in Nemisis on the mac.  Also have your excellent training materials someplace, your contact rules put me from ~12k solidly into the single digit kyus in 1 week ( alway been better at strategy than tactics so they were a godsend ).  If you are ever in Seattle I definitely owe you dinner. 

Bruce Wilcox - Apr 18, 2014:

It’s been a while since I tried to create a DLL for CS. The current build system does not build one. I’d be happy if you could take a stab at it. I’m kind of busy on some other tasks right now.

Another update:  It’s been years since I’ve coded in C and I’m learning C# as part of this project, so with both hands tied behind my back…  I was able after some creative tinkering and a whole lot of head scratching to embed ChatScript in Unity, sort of.  I know a lot more about C# and calling unmanaged C++ code from mono now - let’s just say swig is your friend…  Roughly it involves using Xcode to create a bundle out of the chat script source after running swig to wrap it plus some hand tweaks.  Solution is for mac ( which my team is all on so it doesn’t matter ) but the technique and wrapper should work just fine for windows too and I might still do that if I have time. 

I’ll post the steps and send you the Xcode project with both targets (server and dynlib/bundle) once I get everything completely figured out - still some things outstanding.  Top of the list:  It’s running as a server, which is not what I want. 

Do I just call InitSystem() instead of the the longer signatures if I just want to call PerformChat(blahblah) from the Unity mono process it’s in instead of using tcp?  Or do I need to set some compile switches or pass some init options?  I’ll take a look at the code to get my answers if I have to but was hoping to get a quick answer without beating my poor head against some more C.

Your dll means you are embedding chatscript. So clearly not using tcp. So yes, you call InitSystem but you have to use its full signature. You can claim 0 for argc and NULL for argv and NULL for each of the 3 paths (if the system can default to current directory relative).
If memory availability is an issue, you’ll have to pass parameters to override the defaults. You don’t have to set compile switches, but the exe will be bigger than need be. COMMON.H has the compile switches list you might want to use to reduce code (but code size is probably not an issue)

but if you are compiling on LINUX, then the system DEFAULTS to running as a server and you have to pass the “local” argument on startup to initsystem.

Bruce Wilcox - Apr 21, 2014:

but if you are compiling on LINUX, then the system DEFAULTS to running as a server and you have to pass the “local” argument on startup to initsystem.

Ya, figured out passing ‘local’ as an arg looking at the code last night but something isn’t quite right, still running a server on 1024.  This is compiling it on mac using Xcode, so I think the linux defs are all getting hit.  I’m going to create a simple C# client to run on bare mono so that Unity isn’t a factor that way I can troubleshoot the dynlib better.  It’s hanging when I call PerformChat directly, but I think that may be my unity issue ( called in ongui part of the gameloop, probably needs yield or thread of it’s own ).  It works fine calling tcp though…  Calling it from just mono should clarify that plus allow me better debugging options.

Good news is the bridge between C++ and C# seems mostly figured out.  (http://www.swig.org)  With the same swig interface configuration I think chat script could theoretically be embedded directly in all the languages swig supports, which include lisp, lua, python, php, java, ruby, etc.  Once I get unity nailed I might make a Java JNI out of curiosity since unfortunately java is my current expertise.

You could just #define DISCARDSERVER 1.

Your args passed to initsystem might be wrong, in C the 0th arg is the program name and the 1st arg in the string array is the first param. So argc = 2 and argv = { "", "local"}

Bruce Wilcox - Apr 21, 2014:

Your args passed to initsystem might be wrong, in C the 0th arg is the program name and the 1st arg in the string array is the first param. So argc = 2 and argv = { "", "local"}

That did it, server is now not running!  Now just the hang on calling chat to figure out which I think is 100% my problem.  btw - I did see the discard server, but figured that someone using the library in the future might want to be able to run it that way, so didn’t want to compile it in as off.

Great!  Now if you add another argument (argc = 3 argv = {"","local","trace"}  then chatscript will log tracing data from startup on, which might tell you how far you got.

Bruce Wilcox - Apr 21, 2014:

Great!  Now if you add another argument (argc = 3 argv = {"","local","trace"}  then chatscript will log tracing data from startup on, which might tell you how far you got.

Thanks, that helped.

Pretty much there - my stand alone test mono project, which is a simple console app that uses a .dylib (mac version of ell) works.  Unity now doesn’t freeze and doesn’t run a server (yay), but the response is not making it up through the wrapper yet, will figure that out tomorrow eve if I have time.

I now have an xcocde project with three targets that produce a server binary, a package (what unity uses) and a .dylib ( what stand alone mono or other languages would use ).  Server and dylib test out fine so I’m guessing there is some unity strangeness I need to accommodate.

One question:  InitSystem, the path arguments - can you elaborate a bit on what each of them are and typical values.  I’m going to need those details to embed the chat scrip support files in my app and I couldn’t figure it out from the names.  hope I didn’t miss the answer in one of the docs, if I did please point me to the right one…

Thanks a lot for the help Bruce!

It’s working perfectly now - chat script is embedded in Unity!  :D  

I’m currently just setting all the paths to my chat script source directory to pick up the default stuff - thanks for your description - I think I’ll probably need it when I am bundling the app but for now on just my local machine it’s easier to run just the local server while working out the chat scripts and not have to copy anything to the unity bundle.

is a lot harder to marshal between managed and unmanaged code than it first appears…..

Well congratulations.  I look forward to a complete description of how this can be accomplished.

Bruce Wilcox - Apr 23, 2014:

Well congratulations.  I look forward to a complete description of how this can be accomplished.

Forthcoming with examples and downloadable code, just cleaning some stuff up first. 

Short story is (for .NET/mono/c#):

[ul][li]Wrap ChatScript with swig ( creates a .cpp <—> .cs P/Invoke wrapper )
[/li][li]Generate DLL (windows),  .so ( linux ) or .dylib (mac) with chat script source + the wrapper and put it someplace libraryish /usr/local/lib
[/li][li]Use the swig generated .cs files to call the InitSystem and PerformChat methods of chat script.
Voila[/li][/ul]

To get it into unity
[ul][li]Create a bundle instead of a .dylib ( on windows DLL should work )
[/li][li]put in /Assets/Plugins folder
[/li][li]use generated .cs files to call chat script from your unity scripts[/li][/ul]

Right now I’m playing around with a couple of other languages (java, python, php, perl ) - it should be possible to create wrapper code for any of the 19 languages swig supports (http://www.swig.org/compare.html).  That would make it easier to run chat script in say a php environment where you might not be able to run a server as well and might be faster too since there is no network comm.

Only negative I can see right now is that each of the languages seem to generate a different .cpp wrapper from the same swig config file - but I suppose one could create a lib for each language if they were using more than one.  Still experimenting.