This is where we put random notes about what we can remember about the the inner workings of the code.
The eh Graphics Protocol.
ehMOO graphics connections are handled by a moo object, ehGprot_login, which listens on the graphics port, 11111 by default. When a player connects to the graphics port, an unconnected player object (a player with a negative object ID) is created for the graphics player and used for the duration of the session. This 'unconnected' graphics player is associated with the corresponding 'real' (text) player during the protocol negotiation phase. If the protocol negotiation fails (for instance, because there is no 'real' player with the matching name/password on the MOO), no further interaction with the MOO via that graphics connection is possible. If the protocol negotiation succeeds, the first thing that happens is that the player 'subscribes' to a room on the MOO. This is done automatically on the player's behalf by the client (currently that's ehwt/ehwtwin) when the player enters a 'portal' region. In the ehMOO architecture, a single MOO room i.e. a room object having a unique object ID maps to one or more 3-D rooms as seen by the client. Typically, you'd want to have a one-to-one mapping between MOO rooms and graphical rooms, so as to allow text and graphics players to 'see' the same thing, but for other reasons may decide to have what appears to graphics players as multiple rooms appear to text players as a single room perhaps embellished with a detailed description of the other areas seen in the graphical representation but not deemed important enough to warrant their own room in the MOO. For instance, suppose that when designing my kitchen using my VRML editor, I decide that it doesn't really look like a kitchen without a small adjoining pantry and breakfast nook. So I add these onto my 3-D kitchen space and save it as the representation of my kitchen. Later, when I attach this representation to the MOO room I've created as my kitchen (see below), I'll give the MOO room a description something like, 'You are standing in a large kitchen with a pantry and breakfast nook...'. This gives me the ability to create suitably complex 3-D worlds and still remain true to the goal of satisfying text-only players while not wasting relatively precious MOO resources defining objects for every nook and cranny of a graphical world. The result of a room subscription is that the player's client is sent the graphical description of the room and all rooms in the vicinity as well as all objects contained within them. Every MOO room has an 'adjacent' room list associated with it. This list is created as part of the world-building process by the builder of the room. It contains the object IDs of all rooms 'adjacent' to the room. At minimum, this should include every room within 'line of sight', but can include any number of rooms e.g. all rooms within hearing range. The point is that the room descriptions for all rooms in the list will be sent to the player's client when a player subscribes to a room (unless they've already been sent and are present in the client's object cache). Additionally, the object descriptions for all objects contained within the adjacent rooms are sent to the client(again, unless they're already there). Because all of this uses bandwidth, it's a good idea to keep adjacency lists as small as possible, but no smaller.