Home

1. We have split the java vm away from the zstar executable. This will mean no more crazy configuration due to the peculiar needs of the VM. The z* client system will contain a java simulation part and a rendering part. They will use a local socket, and local shared memory when available for communication. This is much more like the X model, where clients use a well-designed protocol to get their display up. The upshot is that the simulation is now isolated from the 'browser' part of z*.
2. Instead of producing their own events, we found that we can simplify the programming model by keeping track of objects and replicating them. We chose not to use java serialization because of it's limitations (most notably that one can't send only part of an object), in favor of a scheme based solely on reflection. The upshot is that changes to object fields in the simulation server are automatically replicated to clients. This means that the simulation itself will be very easy to write.
3. Our company has become stable again, so it's much easier for us to work further. We are still here and still working on fulfilling the promise of all the compute power and rendering infrastructure that has come recently, our goal is unchanged; we wish to produce a system which makes 3d game and simulation programming approachable for beginning programmers. We ourselves have learned much over the years, and hopefully, this year will see our labors blossom.

Sun Nov 18 15:05:40 CST 2001 News -- After a marathon session yesterday, Adam and I have gotten basic interaction working on the root moo to the point where the client won't need any further editing. We fixed tons of bugs and made things generally a lot nicer. Instead of my inefficient position updates in the moo, adam thought of a nice simple scheme that limits moo cpu time for each client. My brother is working on some art, and I am working on coding in the moo. Adam is working on a PacMan clone for the client to ship with, so that there are both standalone and remote games that someone can use immediately with the client once downloaded.

Tue Nov 6 23:57:42 CST 2001 News -- Adam and I have made the linux version of the client stable on blackdown! The trick was that although it is not specified in the JNI docs, lots of JNI calls create GlobalRefs(TM) that need to be destroyed with DeleteGlobalRef. DeleteLocalRef doesn't seem to have any effect in blackdown. I have had the client running for about five hours now, and the GC is holding steady at 4 microseconds per invocation, and the frame rate is still holding at 45. I've been seriously hacking the moo. I will spend a little time on windows tonight before bed. Hopefully, we can make it stable as well. We are going to make an effort to define and stabilize the standard class library that goes into zpilot.jar soon.

Fri Oct 26 01:36:45 CST 2001 News -- I have been working on improving the client reliability for the last week. No new features to report but some bug fixes are going in. I have also learned quite a bit about java virutal machines and their relative merits. Unfortunately, virtually every java vm in existence has one of the following problems:

1. It has a bug which prevents one from using the JNI, Invocation API, or both with threaded/profiling/debugging/jitted/async-gc'd/classic/green or native-threaded jvm shared lib. In some cases, using the pure interpreter is the only solution.
2. It has a poor/slow/buggy interpreter and a buggy JIT simultaneously.
3. It has a leaky GC that eventually consumes all available CPU and/or memory.
4. It has a buggy JIT that breaks the Java synchronization model.
5. It is difficult to link or handle.

The java-linux-blackdown connector gets fairly reasonable performance with -Xint, and great performance without it. Unfortunately, it eventually leaks CPU time to the GC when running with JIT enabled. Explicity GC calls make this problem worse, not better.

I have just finished an initial crack at working with kaffe with the client. There is a kaffe config script which takes the path to the kaffe distribution, as an argument and configures appropriately. This script may be used on both windows and linux, and possibly other OSs as well. In honor of this, our CVS sources are now libtool-based. I'm still sorting out how to work properly with libltdl, which has caused me considerable headaches in conjunction with its use in kaffe so far. Other than that, the -dlpreopen and JNI linking work well, and the startup messages of all classes that have them are displayed.

Sat Oct 20 14:25:12 2001 - I have added a very simple but useful command. The command:
!zcmd "chatMSG si hi 0"
is now equivalent to:
!zs_emit "0 0 chatMSG si\nhi\n0\n\n"
Pretty simple, but helpful to those who want to play withthe client. I will do a bit more work and get a few more nice interpreter features in. - ak

Oct 19 04:02:10 CDT 2001 News -- I have added texture and object caches which will reclaim old IDs and have now properly implemented objects using GL lists. This reduce overhead quite a good bit on my video card (from 30fps on !rootbar to over 100). I'm not certain wether it helps software rendering speed on windows tho, which is pokey.

I fixed a few bugs and am now getting excellent stability out of the client. There were at least a couple bugs in the way commands were interpreted from the server. That code is now redone correctly. The chat had some problems too which were somewhat related and now that is fixed as well. I regularly use the client to edit into the root moo and I'm actively recruiting people to join by tantalizing them with the !rootbar demo. The first victim is my brother who joined the team as an artist.

I will not be adding any more features to the client for the next two weeks or so... I will be debugging and hopefully make an incremental release at the end of november. Meanwhile, my brother, adam and I are working on fixing up the root moo. It already loads a scene when you connect, and allows you to walk around. Nothing has been done about avatar position yet, but I'm working on it.

Oct 15 23:30:12 CDT 2001 News -- The root bar demo is available from the client command !rootbar . Added is a generic walkable terrain interface that allowed me to take the loaded bar and make it walkable. It's the first time I've walked up the steps of the root bar to the cozy rooms on the second floor! It's significant enough that it was worth cutting a new incremental release for. There are new interior shots on the screens page.

The root bar geometry was contributed by my brother John.

Oct 14 22:47:58 CDT 2001 News -- I just whipped out an AC3D loader. Here is a nice cap of the rocky walkdemo scene with the root bar loaded:

This scene was created like this:

!zs_emit "0 0 meshAC3D si\nhttp://localhost/~arty/inn.ac\n0\n\n"
!zs_emit "0 0 object ii\[3f\n0\n0\n0\n0\n-30\n\n"
!walkdemo

I put up a machine which will serve as the root server, and put a lambda moo on it. I had good luck with lambda in the beginning for prototyping power, so I'm going back to it at least temporarily. I did a nifty hack on net_multi.c which makes Lambda speak z* protocol by itself without an outside translator. This makes it a little easier on my old IPX that is being the root server for now.

Oct 13 21:29:14 CDT 2001 News -- The walkdemo is more polished now (you can't fall through the floor in most places :-) although you can still fall off the world. (For now, restart the demo if you do...). In any case, I feel this is a big step forward for us. Here's how to use the walkdemo:

• Do !walkdemo at the client prompt
• !keybind generic.turn.x and generic.thrust to your liking. (-1 and 1 for both axes). Then you can walk around.

Oct 12 22:57:50 CDT 2001 News -- I have just checked in some nice test/demo code that is fairly easy to use. It's a nice generic way to do terrain walking. Given some triangles, you can very easily use it to determine wether you 1) fall, 2) hit the ground, or 3) follow the ground. The code is in zstar/lscape. I'm going to make it into a core interface soon since this facility is likely to be used almost everywhere. Currently, it will walk along the Z surface of mesh of any form. This is definately a needed piece of code.

Needed classes and standard ML source for some needed classes for the walk demo are at plane.zip. I am still trying to figure out if I want to check this code in as SML or convert it to java source.

We also managed to pick up some classes to put us closer to Java3d totality from Kenji Hiranabe.

Sep 7 09:36:27 CDT 2001 News -- Two big things happened:

• The core game messages are back into the client and now working perfectly :-) The only one in common use that's still left out is meshVRML. This one will come back soon.
• There is a directory of ML source in src/games/twinax that contains the source for the walker/rpg game as it stands. You can walk around with generic.turn and generic.thrush and do certain other things with chats beginning with -

Sep 5 01:35:06 CDT 2001 News -- I have just fixed up a couple of the more serious bugs in zstar, and gotten my first ML server running, adding another language to the set of languages that a server has been written in (bourne shell, tcl, C, java, ML, etc, ...). Although incomplete, the source is in twinax.tgz. The zstar client again does connections and bidirectional traffic correctly. Sorry, we broke it a while ago and didn't fix it up again until now. What's in CVS is working more spiffily than yesterday.

Sep 4 19:08:12 CDT 2001 News -- Adam and I are back out of hiding much refreshed from our sabbatical from this project. I spent this time learning ML and doing some general studying about 3D and multiuser gaming. I am still working on a root game server. I have made progress in the intervening time (I just picked it back up this past weekend) but it's still far off. I'm also doing some debugging on the game client, as it has urgent bugs. Overall, I hope to have more to report soon, but for now, I am fixing bugs and getting things back in good shape. I have switched back to Linux as my main dev platform, so the Linux port (which has always been a bit ahead of the windows port anyway) will probably get a bit better soon.

Jun 30 21:26:02 CDT 2001 News -- We are pleased to report that the java scene system is nearing completion. We have added 3DS model loading, program-provided textures and models, and a nifty new scene graph built from scratch as a hybrid native and Java cooperative. I have added a startup demo that runs when zpilot is initially started just to give some nice eye candy to new users. It should be very simple from this point to implement AWT-like window objects as textured polygons to draw radars, ammo counters, etc on. The startup demo shows the current tick count on a polygon, and that code is roughly 1 page long. Hopefully, we can provide some library assistance that makes this yet easier. We have commuted object loading into java, which allows games to use custom objects, or even SQL databases to store the objects in, and means that the z* team no longer needs to support a scene loader. Each game can choose a scene loader as either source or binary, and use our network loader to bring it into the client. We have implemented enough of java3d that a textured TriangleArray can be used to store scene data. The upshot is that with a little patience, java3d scene loaders can be used with z*. This makes quite a few formats accessible without writing any new code.

On the messaging front, I have done two things of benefit; I implemented java handlers the same way in zpilotgl as in the old zpilotj code. The message "load3DS s" will search the message handlers list for void load3DS( String arg ), and execute it if found. This allows any class registered as a message handler to receive network messages easily, and, of course, any java code can use Zpilot.emit to emit network messages. Why have native network code? Because we want a uniform protocol layer that firewalls eventually will understand and agree with. HTTP is successful partly for this reason.

The scene graph is maintained exclusively by java code, which necessitates a small change to the messaging system. The client will honor the existing server protocol with respect to the scene when I get the handler in for it.

Here is a teaser of the startup demo:

May 22 17:17:15 CDT 2001 News -- Development of the Java system is going well. There is now a coupling between Java and the scene system that allows a Java program to instantiate objects and manipulate them. Each type of node in the scene graph will eventually have a Java form that is generalized. We are also exposing the cache functionality in Java. This process will take a while, but will allow Java programs almost perfect control over the client, making possible predicitve world modelling like that used in most action games on the market. This will also allow muds, for example, to enjoy a higher level command set when speaking with the client. We also hope to add support for loading models using Java in the near future. This will allow the client to load new model format when they are required by game authors.

May 5 19:47:47 CDT 2001 News -- We are working patiently at some nice new features. We determined that while some applications are possible with only the server to run things, most action games will need a client side component to give them good response times, and to limit used bandwidth to manageable levels. For this reason, we have been hard at work on Java integration. Currently, we have two test sites, one is a sparc ultra with Sun's JDK, and the other is a RedHat 7 box with Blackdown. We have both of these configurations running properly, and are working on the Windows version. This work will make certain things easier for a game implementor, while still making the system cross-platform. We are currently working on support for manipulation of the scene graph from java programs, as well as a couple of other goodies (3DS loading is high on our list). We are doing most of this based on problems we've encountered so far writing real-world apps with it, and we anticipate that each change will make some aspect of the app-writing process easier in some way.

So, on to java; currently, we support the 'emit' primitive in java, which emits a message to the z* client. This is a little analogous to a javascript program writing a web page. The command emitted goes straight to the command stream. We also support two types of message handlers from the z* environment; ProtocolMessageHandler, which is passed each message not caught directly by the client and FrameMessageHandler, which receives control just before we begin creating the frame in GL. It's essentially a 'last chance' for java to submit messages to the client, adjust the scene, etc. It's even possible now that a game could be written with only game-specific messages, and all client work taking place in java... Such a game would receive a benefit by being put into a nice accelerated GL app with model loading, communications, and rendering infrastructure already built in, as well as receiving benefit from the protocol handlers we have written. Such an application gets both TCP and UDP style transports transparently and for for free.

Those wanting to write apps to our system should use CVS for now, and when the Java support is stable, and functional on windows, we plan to make a new tarball. Any suggestions about the java interfaces to the client would be helpful and encouraged. We can be contacted through sourceforge's nifty redirector.

Apr 10 22:16:15 CDT 2001 News -- Some good things are happening with the system as we get ready for our real launch... Thanks to everybody who is helping out with the root server, display driver work, etc. This is going to be great.

• Adam added windows style resources to the build (new builds of the windows version have an icon!) and is investigating a small info file that can be downloaded and used to start a local server. This would make starting zTetris and the clock app a double-click action.
• We finally added a menu. You don't have to type very much in the commmand line anymore, but it's still there for chats. There is an 'open location' menu option that works, as well as a 'Add Bookmark' and a bookmark list. We're getting very 'real application' like. Next on the agenda, a good keybinding interface. Taking away the menu saves frame rate, so we enabled the user to toggle the menu by hitting escape.
• Server side control bindings are now better. I made all controls 'disable' so that they could be 'enabled' by the server with a controlDef command. This has the effect that only the specific bindings asked for by a server are in effect at any time, and hyperlinks turn off all bindings. I am no-longer experiencing unintended binding sets on overloaded keys (like with tetris and the sh demo).
• I have enabled 'smooth' movement in the camera, objects and lights. This means that these objects have their movements taken slowly over a specified time interval. Servers can take advantage of this to make displays look more realisitic. In the code, we use the 'sigmoid' function on the percentage of time passed between the time interval start and end to determine object location on 'between' frames. Movement has a far more natural aspect now.
• The Root server is progressing... I've got things limping in a scenario where the geometry server uses UDP to aggregate clients and uses a reliable channel to speak with jamud. I have checked in edits to Jamud so that it can aggregate all clients to one TCP socket. This makes life very simple.

  What I have now is a client login coupled with movement. You can walk around the geometry server and interact with the mud simultaneously. This is a nice effect, and gives me recollections of EQ. Hopefully, we can achieve a similarly fun combination of action and roleplay.

  The geometry server knows about everything geometric... It takes care of client positions, object positions, will eventually determine hit locations, spell damage, etc. JaMud knows what spells you have, and geomserver determines hit based on radius. For this, we have to elaborate communication between JaMud and geomserver. This is the next thing.

I fixed fogging and lighting effects from the VRML background object just in case anyone noticed them broken. I used both lighting and fogging in the 'rundigit' demo so it looks really cool... I've been staring at it full screened for about 20 minutes.

In any case it's a fairly good example of a simple humanoid terrain follower. It uses knee level as the cutoff for things that are too high to step onto.

Mar 2 ??:??:?? CST 2001 Hi -- well, after a long night for us, the build process is much cleaner under UN*X and win. I (ak) will be the win maintainer since Art now has only UN*X installs (congrats!) - added zs05.zip to the downloads page. More docs coming soon, promise.

Feb 23 11:42:20 CST 2001 News -- Lots of good things have happened today:

• I have started work on a preliminary zstar interface object in java that will tie the java VM in. The mechanism will be specified per platform, but be presented in a uniform way to the client classes so that the same java extensions will work on all platforms.
• We got hosting for a game server. We're still deciding what to do with it, but we thought a z* metaserver would be a good idea. Stay tuned!!
• vast has been doing some models for the nethack display driver. While this code is immature, there's a certain appeal to nethack in 3D, but we need a good look for it.
• I have been writing example code and documentation that's getting to where it needs to be.
• I put up a phpwiki part of the web pages. I will give write access to interested people.

Feb 20 03:54:11 CST 2001 News -- OpenVrml is now correctly integrated (no patch is needed anymore). In addition, I have reconciled the openvrml concept of a vrml background, by creating a background object that implicitly uses model #-1. Assignment of a vrml to model -1 not only draws that model at the origin (this object cannot move), but also draws any background data (bitmap, sphere, color, fog, and lights) from that object. Make sure that this object contains a light, otherwise your scene will be dark. If the background object is unassigned, the z* client uses a default headlight as usual.

In addition, I have integrated gnu configure... Hopefully, this will allow more people to build, and such. Please email me or the forums if you have build trouble. I'm hoping to shake out all build troubles soon on normal machines (sparc, intel, ppc), with (linux, sol, be, win, osX, amigados, next). So if you have any experiences building drop me a line.

Currently, vrml animation works, but we are not sure if we want to guarantee it yet. Stay tuned.

Some of the system elements are still not working. In particular, server specified meshes are not working now. I am trying to integrate this stuff with openvrml, but other things are higher on my list.

My longevity tests are going well too. I think most of the leaks are out.

Feb 15 10:55:30 CST 2001 News -- z* is not dead!!! We are working on making the client more stable and such, and we have made some important decisions for the future:

• We will eventually use a Java virtual machine in the z* client. This will make client plugins easier.
• We will allow java access to a polygon somewhere between the viewer and the frustum as a sort of frame buffer. This will allow those who are inclined to write cockpit displays in 2d against their z* games.

These two things should make everything easier to work with.

We have incorporated the openvrml display engine... Here's a shot showing an object loaded with the model 'http://www.lightscape.com/VRML/lib/chamberV2gz.wrl'.

Dec 14 12:03:52 CST 2000 News -- We're working on games (and client debugging). I will put up another client snap as soon as we feel comfortable with calling the client beta. In the meantime, I put up an indoor snap on the screens page from the MOO rpg I'm working on. PK forever!!! }:-)

I added a couple of TCL bindings for various things: TCL is now aware of control messages via a proc called zs_control. The two args are the control name and control value... This can be used to implement motion prediction client side and give a very nice smooth feel to the client at high framerates. It can also be used for standalone TCL games using only the client, or possibly to allow the user to explore a mostly static environment. A rather complete VRML viewer can be scripted in TCL and use the client for viewing at this point.

Dec 5 04:42:19 CST 2000 News -- Sound support is working thanks to Steve Baker for PLIB This is the last feature that Adam and I decided to put in the first release, so now the feature set is closed. We will proceed debugging and refining the client with it's current codebase mostly intact.

We may add a few more messages as necessary, but the core message set is now closed.

Dec 3 03:08:34 CST 2000 News -- Client side scripting (tcl) is complete. The new protocol commands are loadScript and tclcmd, both have signature s. We think that this will be a great stride toward adding effects such as the spellcasting look in Everquest, where a large number of particles are created and move around. This effect can now be offloaded onto the client completely, reducing server load.

We chose TCL because it is easy to embed and well known, and it has not disappointed us so far.

In addition, I have removed the two-argument mode, and replaced it with a nice url-oriented mode. As a side effect, the primary command is implemented and working, so I'll be interested to see if this feature is used at all.

Dec 1 02:52:30 CST 2000 News -- We have a working game (it's similar to the 2600 combat cartridge, except that there's money, etc.) This is truly a breakthrough. There is a lambdaMOO db in the downloads that has the tank game. Keybinding is in place, but not complete. To bind keys do '!keybind ssi/[controlname]/set/[value]'. You need to bind the following keys:

• generic.turn.x (pos, neg)
• generic.thrust (pos, neg)
• generic.fire (set to 1 to fire)
• combat.incline (degrees of incline on mortar)

Nov 21 17:08:02 CST 2000 News -- The windows binary (zpilot.exe) now contains the VRML parser, and libcurl, so it can load meshes remotely.

Nov 20 06:14:11 CST 2000 News -- We have our first VRML load over the network thanks to Daneil Stenberg for providing libcurl and Emmanuel Frécon and Olof Hagsand for providing their VRML parser. Without these, we would not have our triumph today.

The MOO code to do this was:
;player:tell("%%meshVRML si%0ahttp://pc.genxnet.com:2000/~arty/stash/car.wrl%0a0");
Note that we also had to make an object and position the camera.

Screen shot:

We have also decided that a file cache is the right approach, so we will be looking around for the best way of implementing a file cache. We are probably going to go for a system like the netscape one with both in memory and on disk components. This should make often played games start much faster.

Nov 3 05:33:37 CST 2000 News -- I have updated the windows port to correct a core dump that occurred with the builtin memcmp. I have also disabled -fno-stack-frame and some other optimizations in order to make debugging easier. I am getting good results moving myself around in Lambda MOO (with camera messages that come from this:draw(); (on me) and object that move themselves with this:draw(); When I have something nice an coherent, I will post it both as source and a lambda core. I would appreciate anyone else out there working with me to make DBs for LP, Diku, ... that use the java mud connector. I realized that I never filled in cp, rm, etc. in the client... (zpilot_command.cpp) Sorry about that..., these need to go in there but are not in yet.

Nov 1 04:27:51 CST 2000 News -- There is now a windows port thanks to the great work of the cygnus team. You need the latest cygnus release to compile it. I'm uploading an exe as well... I tested with the SGI opengl dll, so I'd like to hear how compatible I am with e.g. the 3dfx driver on windows.

Oct 30 01:37:44 CST 2000 News -- I (arty) have been working on z* steadily since the last news release. I have made the zstar console stable so that it is now ready to chat well. There is also good news about servers: I have written a fairly universal proxy for muds that allows zstar to be used as a mud front end. If the mud doesn't do any zstar stuff then all you get is text, but the mud may send commands to the client as well. The proxy is written in java and is in zstar/src-java/mudproxy/mudproxy.java in CVS.

Here is the obligatory screen shot... Not so impressive yet, but shows that you can now M(O+|U.*) with zstar. I think that this will help popularity a lot.

This makes me feel good about the new protocol as I have already made a small lambda moo program that does good things (not great things yet).

The lambda moo stuff is here.

Sep 23 22:31:40 CDT 2000 News -- We have been working on the clients recently in order to get a nice face to put onto zstar. There are currently two clients, a java applet, and a C++ program. Both use GL bindings.

The Method we use to transport data is now variable, so it is suited to a good range of programing languages, rather than only C variants. Tonight I am going to cvs remove the last vestages of the old protocol for good. The new protocol has four text/binary, stream/datagram variants to choose from, so it is easy to mix and match. A proxy is currently provided from text/stream to binary/datagram for use with the applet, as well as some tcl servers I'm writing.

We realized that in order to get zstar used, we had to provide a protocol that could be more easily implemented by others independently... The text protocol resembles RTSP in that it uses a header, some variable number of data lines, followed by a terminating blank line (ignoring the possibility of a message body).