SubArctic Revisions documents changes to the library made in the reimplementation from java to SubArctic. The reimplementation should still work with the original databases.
Overal plan ...
Design of a specific Plate front screen ...
Some user interface observations ...
Mud is the backend, java is the user interface/front end.
images + type + action information is stored in the mud for all objects that the UI might display.
The UI loads an app (PALplate.PALplate & PALplate.mud.MudClient) which will recieve information about changes. It's static. Anything which wants to be told about changes (eg apps running in other frames) must register itself with that app.
anytime a change occurs in the mud, the mud code calls some code which broadcasts info about the change ... (not yet implemented)
PALplate.mud.MudClient contains the code used to connect to the mud.
I've got a ImageButton class working which can load images, but it can only load them from the server from which the applet was loaded ....
made toolbar class which allows registration and removal of several images.
How to load a page with html generated by an applet:String myHTML = new String("javascript:'<title>My Page</title><h1>My Page</h1>'"); getAppletContext().showDocument(new URL(myHTML));
(I actually don't use that anywhere, but I thought I might need it)
in order to make the display of the gifs nice, I should use a mediatracker (java.awt.M*) ...
One of the GIFEncoders I tried to get working can be found at http://www.cs.brown.edu/people/amd/java/classsrc/GIFEncoder/giftest.java the other one is at ???? anyway, neither of them worked in Netscape or IE
Modified imagemap to be a panel instead of an applet. Also modified it to be it's own package. This means changing how some vars are declared so I can subclass from it outside the package, and changing alot of init stuff.
The mud I'm using is LambdaMOO 1.8p5 with the October, 1994 database (the newest one I could find that didn't have any bugs). Lots of information about lambdaMOO is available. Also, there's some good elisp code around for editing muds and visiting them in. The mud is required to run on palweb for security reasons. It's located in ~jmankoff/MOO, if it's not running, you need to type restart test.db. I should probably move this to ~palplate. Here's my bookmarks about muds:
In order to implement mud stuff, I made very few changes to the core database: I changed the #0 object to have two new properties -- room_class and exit_class. These properties are used much in the same way as player_class -- they point at the class which should be the default for all rooms or exits created. I also changed two lines of the @dig function (in the builder class) -- it now uses $room_class instead of $room as the default when it creates a new room and $exit_class instead of $exit as the default when it creates a new exit.
I then had $player_class point at Generic PALplate Player (#266), $room_class point at Generic PALplate Room (#87), and $exit_class point at Generic PALplate Exit (#96)
Some other notes:
$guest is now a child of Generic PALplate player instead of generic player.
GOP is the player character that programs Generic Objects (GOP is a wizard).
Digger is the character who digs rooms and owns all instantiations thereof. (Digger is a programmer)
Schilit and Mankoff are GPP players for testing (generic palplate players). Guest1 and Guest2 are guests for testing.
The generic palplate room is owned by the GOP
hmmm ... object #10 is login commands. might be useful ...
had to @rmprop $player.ownership_quota to deal with guests making notes and stuff ...... also had to comment out $object_quota_utils:reimburse_quota and $object_quota_utils:charge_quota and change $object_quota_utils:creation_permitted to always return true.
Added old_do_reset to guest, and moved the code from do_reset there. do_reset now does almost nothing ... but I may want to call it to do more in the future ...
in all cases, there are exits from a higher level (more zoomed-out level) to all it's children
there is an exit from 1st floor to building floor and 2nd floor to building 4.
Building 4
1st floor
2nd floor
Every room with a pink checkmark
Generic Palplate Room:
Properties
help_msg
apps
Verbs
disfunc: this should print out #@# disconnected but it's not working so right now I'm looking for *** Disconnected *** as a special case.
confunc
enterfunc
@showApps
contentsList
@up
@areas
@locType
type
@set_x,@set_y,@set_x_coordinate,@set_y_coordinate,@set_coords,@set_coordinates,@set_width,@set_height:
sets the coordinates for the entrance to a given room (modifies property $exit_class.coordinates for the specific relevant instance of entrance)
Generic PALplate Player
Properties
PALplateMode (verb & property) : whether the mud should output not for human eyes. Right now this is ignored, it's use is for people accessing the mud directly (eg to program it).
Verbs
@makeNote <tag>: this creates a note, puts it in the player, sets it's <name> to <the number of the object created>scrib.gif, type to "URL" and action to "../scribbles/"<name>. Then it announces that the note has been created by telling the player #@#<tag> <name>
PALplateMode (verb & property) : whether the mud should output not for human eyes. Right now this is ignored, it's use is for people accessing the mud directly (eg to program it).
@showContents <where> <tag>: if where is"me", return me:contentsList(), if it's "here" return here:contentsList(). return these values in the right syntax (ie, #@#<tag> <info>).
contentsList : loops through it's contents and returns a string (list) representing them out in the format described in player<==>mud communication section
@noop -- This is a way to send the player a tag without changing the state of the mud.
Generic PALplate Exit (#96)
Properties -- coordinates: the coordinates of that excit in terms of the map of the place it leads from.
Verbs -- none
Generic PALplate Note (#230) Inherits from #232 (Generic PALplate Container)
Properties -- scribble: default value is "scribble.gif" this gets set up better in @makeNote.
Verbs -- getArgs (overrides #233:getArgs): returns whatever's in scribble
Generic PALplate Container (#232) Inherits from ... <other stuff> .... #233 (Generic PALplate Thing)
Properties -- none
Verbs -- contentsList: loops through it's contents and returns a string (list) representing them out in the format described in player<==>mud communication section.
Generic PALplate Thing (#233). Sets up the basic object attributes that the java code needs to represent any object in the mud. Usually, all of these props and functions are overriden.
Properties
type: "Object" (default type for any object in the mud that should be represented on screen)
icon: "defalutIcon.gif" (default image for any object in the mud that should be represented on screen)
action: "PALplate.awt.actor.clickAnnouncer" (default java object for any object in the mud that should be represented on screen)
width: 124 (the width of icon) -- make this -1 to have it determined on the fly instead.
height: 71 (the height of icon) -- make this -1 to have it determined on the fly instead.
Verbs
getArgs: returns an empty string. #230, for example, overrides it (Generic PALplate Note). Any arguments an object might want to send to it's java counterpart.
Ok, here goes:
The Java programs communicate with the mud by sending commands that you could just as easily type at a prompt. The commands all take a tag as their last argument, plus any other relevant arguments.
When the mud responds, it prefixes it's response with #@# tag <results>
Commands:
@showApps <tag>
@showApps returns a list of lists. {{..., ...}, {... , ...}, {...} ... }
the sublists are of the form {"type", "icon", "appinfo", args, width, height}
Valid types are:
"URL" (in which case, "appinfo" is interpreted to be a URL in the following manner: getDocumentBase()/apps/"appinfo"
"Object" (in which case, "appinfo" is loaded by the java class loader). Valid objects for appinfo must be class files in the CLASSPATH of PALplate.html and must implement UIActor. So far, these are:
"upAction" (if pressed, the button sends the current app an up event)
...
...
@showContents <me,here> <tag>
@showContents returns a list of lists like @showApps, based on the contents of the player (me), or the room (here). Basically, if the arg is "me" then player:contentsList is called, otherwise, here:contentsList is called. here:contentsList is different for map rooms, right now it adds an image file to the beginning of the list ...
If the room contains any players, they are *not* added to the list ...
@makeNote <name>
@makeNote makes a new note and puts it in the contents of the caller. It stores the name of the file where the scribble is stored.
@areas <tag> ... this is defined on $room_class but maybe should be moved so it's only defined on the map rooms ...
@areas lists the exits from this room which have coordinates defined (see @coord* above) in the format #@#tag {x, y, width, height} {x, y, width, height} ...
@up <tag>
@up <tag> moves the player up to the room with an entrance to this room, and prints out #@#tag <room,map>. It should, in the future, also broadcast the fact that the player moved to all other palplates which are logged in (ie, all other characters). <room,map> is information about whether the player has moved to a room or a map.
@locType <tag> prints out "#@#tag <room,map>" (see @up for details on which and when)
@noop <tag>
this is for broadcasting stuff ... later might want to add arguments saying who should be told. Anyway, it just prints out "#@#tag" to the player who called it right now.
...
When a PALplate boots, it knows the <number? name?> of the room it belongs in ... that's reasonable assuming that it's just the name on the door of the room where it hangs. (how does this affect a plate in the entryway or hallway of a building?)
So that's a *name* (even though it's numerical)
Why not make that the name of a particular guest character? That character's home would then be the correct room for that PALplate ...
Ok, assuming I can do that, when the PALplate connects, it will automatically be in the right place. What happens then?
it's really hard to use teh paidnt application. That's *got* to improve if we want the every day user to have the patience to use it (eg francoise).
Also, she wants to wipe out bad stuff ... even when using the erase button, she wipes.