I’ve begun the process of reintegrating our awesome AI features into the rewrite. It’s going well! The ai stuff was failry abstract to begin with, so it’s not particularly difficult. There are just a lot of methods to implement in the context of our new Request-based architecture. I had forgotten how much power our in-game scripting language has.
Just as an experiment, I added some computer vision to our game. Using just a webcam, you can control where you move in the game just by moving colored objects in the real world (i.e. a pen cap, a marked finger, etc.) It works surprisingly well! We need to put videos on YouTube!
MoveRequests are being synchronized (according to the tests.) But we use MoveWithMouseRequests to drag objects. These should probably be translated into MoveRequests before reaching BodyManager. Should we make a RelationalMoverModule???
Also, I haven’t yet tested anything by running the game. But I made a SimpleServer, which is like ModularSimpleGame, except that it just has a BodyManager and the server modules. In a perfect world, we can run SimpleServer then run ModularSimpleGame and see the AI-Brain-Possessed rock climbing the mountain on both the server and the client. But I am skeptical that this will actually work. Will the AIModule get angry that the rock isn’t being created fast enough? Will there be other, unforseeable problems? These things are impossible to know until the Wikipedia community gets off its ass and writes a series of articles about ModularSimpleGame.
–Stephen
P.S. Would this be cool? First, we make a module with a Will. This module opens a socket to which we can connect remotely with a simple console/shell program. The module takes incoming strings, translates them into NewRequests, and broadcasts to the connected modules. Thus, we would be able to connect to our game with a text-based user interface and mess with a running game in realtime without ever having to run the game…
Also, we could then attach a guiModule to the ConsoleModule and make an in-game console.
In spite of the lack of recent activity on this blog, it is important to note that RedPanda is alive and well. We are currently in the middle of a full rewrite, which will make the game much easier for the open source community to work on.
The rewrite is going VERY smoothly, more smoothly than I could ever have hoped. In just a few months, we have almost recreated all features from version 1.0. After finishing up the synchronization of game entities, all that’s left is to rewrite the artificial intelligence feature set.
We’re hoping for an official release at the end of Februrary!
I know how much you like ticket trackers, Bobby. Do you want to set one up on RedPanda?
This was ridiculously difficult and is probably still broken in many ways.
Here’s the simple explanation of what is supposed to happen:
1) You join two models together (as explained in my previous post.)
2) The parentChanged boolean field is set in the child.
3) OurGraphicalController detects this change in the child and fires off a message that contains the child’s parent’s name — as a string.
4) The server gets this message, finds the child about whom it refers, and changes the child’s parent to the Wicket referenced by the parent name string contained in the message.
5) The server sends the same message out to all clients. The same parent/child joining occurs.
5) All is well.
Unfortunately, step 4 requires corresponding Wickets on the server and each client to have the same name. Otherwise, sending the name of a child’s intended new parent will be useless. So I did a fair amount of work to be certain that Wicket names are synchronized. They are now named according to the SyncWrapper id that they happen to end up wrapped in. The problem with this is that the SyncWrapper id always starts out as -1 until it is set (via some back-and-forth message passing.) So for a short time the Wicket will have a weird name, like “tree.obj#-1.” But this name is changed fairly quickly. Hopefully there will never be a time when two Wickets have the same name. But I am not yet prepared to certify that this is the case until we do further testing.
To make a long story short, when everything goes properly, Wicket joining now works. In a perfect world, you can join two objects, move them around, log out, come back, and they will still be where you left them. And they will still be joined.
But the world is not perfect. I will blog about the current problematic issues momentarily.
So, I’m making a fairy, right…but somehow the texturing goes horribly wrong and I end up with this:
Hot, huh? Just thought I would share.
Today, we finally solved the item problem 
and changed the startup location of the chat palette.
Does anyone know what we need to do to get emails working on redpanda?
Ummm… Does anyone know why we have suddenly lost the ability to build with ant on Redpanda?
Here’s the error:
/usr/bin/build-classpath: error: Could not find xml-commons-apis Java extension for this JVM
/usr/bin/build-classpath: error: Some specified jars were not found
java-gcj-compat: tools.jar: failed to read /usr/share/java/eclipse-ecj.jar
java-gcj-compat: tools.jar: failed to load org.eclipse.jdt.internal.compiler.batch.Main
java.lang.ClassNotFoundException: org.eclipse.jdt.internal.compiler.batch.Main not found in java.net.URLClassLoader{urls=[file:/usr/share/java/eclipse-ecj.jar], parent=gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/java/ant.jar,file:/usr/share/java/ant-launcher.jar,file:/usr/share/java/jaxp_parser_impl.jar,file:/usr/lib/jvm/java/lib/tools.jar], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}}
at java.net.URLClassLoader.findClass(libgcj.so.7rh)
at java.lang.ClassLoader.loadClass(libgcj.so.7rh)
at java.lang.ClassLoader.loadClass(libgcj.so.7rh)
at com.sun.tools.javac.Main.<clinit>(Main.java:80)
at java.lang.Class.initializeClass(libgcj.so.7rh)
at java.lang.Class.forName(libgcj.so.7rh)
at org.apache.tools.ant.launch.Locator.getToolsJar(ant-launcher-1.6.5.jar.so)
at org.apache.tools.ant.launch.Launcher.run(ant-launcher-1.6.5.jar.so)
at org.apache.tools.ant.launch.Launcher.main(ant-launcher-1.6.5.jar.so)
java.lang.ExceptionInInitializerError
at java.lang.Class.initializeClass(libgcj.so.7rh)
at java.lang.Class.forName(libgcj.so.7rh)
at org.apache.tools.ant.launch.Locator.getToolsJar(ant-launcher-1.6.5.jar.so)
at org.apache.tools.ant.launch.Launcher.run(ant-launcher-1.6.5.jar.so)
at org.apache.tools.ant.launch.Launcher.main(ant-launcher-1.6.5.jar.so)
Caused by: java.lang.NullPointerException
at com.sun.tools.javac.Main.<clinit>(Main.java:95)
at java.lang.Class.initializeClass(libgcj.so.7rh)
…4 more