Closed GoogleCodeExporter closed 9 years ago
It would also allow debugging the client side, unfortunately not server side,
which
most users should not need.
The disadvantage is that the maintainer will loose valuable time in which he
can code
a star-craft bot ;)
Original comment by igalve...@gmail.com
on 28 Dec 2009 at 3:29
Original comment by dpershouse@gmail.com
on 29 Dec 2009 at 4:42
Well now that the code runs outside the broodwar process using .net remoting
this
should be a lot easier (I can use .Net com interop not mono). then we will have
Starcraft->bwapi.dll->c++ ai module->.net ai module (server)->tcp remote
transport-
>.net ai module (client)->com interop layer->python. so so many layers :) oh
and soon
ill release the java BWSAL running on a .net jvm for extra added layers
Original comment by dpershouse@gmail.com
on 30 Apr 2010 at 4:29
[deleted comment]
[deleted comment]
hello, i hope u still continue work at this wrapper? It very usefull for me and
one of my friend,
i used it at are local starcraft AI cup and win ;) Please apprise and commit
new version soon :)
Original comment by psychow...@gmail.com
on 10 Jun 2010 at 5:56
After trying all .NET bwapi projects I found this 1 that works, but I need to
work remote because I want to add a C# editor where you can realtime change
your code.
but your remote project slows down SC very much and maybe its good to make a
frame counter to see if you loose frames.
Personally I am for a simple socket instead of remote objects. the F# sharp
bwapi bot got that, but I couldn't get it to work.
If I declare a socket in your not remote project than SC crashes.
Original comment by grooovi...@gmail.com
on 7 Sep 2010 at 9:09
Someone is updating BWAPI 3.1 compatibility. I am helping them out.
Original comment by dpershouse@gmail.com
on 19 Oct 2010 at 11:11
bwapi-clr-client should solve com interop difficulties.
Original comment by dpershouse@gmail.com
on 28 Oct 2010 at 11:41
Original issue reported on code.google.com by
goo...@teabix.com
on 27 Dec 2009 at 2:38