Communication in Rooms in v5

1. Presence: Where am I, and whom am I talking to?

By default, there are no connected player icons in the room display in the web frame. Note the difference between connected players and sleeping, or logged out, players: Sleeping players, if their home is this particular room, will still show, since they are part of the room's inventory.

The icons and names of the connected players are moved to the frame below, the player frame. This player frame is updated on every move in and out of the room, so that the player frame now shows a reliable list of who you are together with in this room. The web frame did not account for players entering or leaving the room, nor should it, since the web frame holds other objects than rooms, and should not be updated unless the user wants it to (or a slideshow is run in a particular room).

However, if you want to keep the old way (connected players being shown in the room display in the web frame, and their movements not being accounted for), you may specify that in your Preferences. The player icons will then be displayed both in the web frame and in the player frame.

Note by the way that you may specify if player icons should be loaded into the player frame or not. This is for space purposes; if you have a very small screen and many users are connected in a room, there might be an overflow in the player frame, which can be prevented by leaving out the icons.

Note as well that you may position the player frame where you want to; there are eight settings now. You may as well specify the initial percentage of the frames. Since all frames are now resizable at all times, this is not an important choice any more, but left there just for convenience.

This (free adjustment of all frames) means that although the player frame is not optional (it carries all the notification sounds and alerts as well as the players), it may be graphically reduced to a minimum. You may thus imitate the old style, but keep the advantages of being notified synchronously.

2. Perception: How am I talking?

"Say you, say me, say it together"

The "say"-function is now largely customizable, including the possiblity to keep the "old style". This works on room level, i.e., if you own (or co-own) a room, you can customize the room. There are no scripts involved; there are only properties on the room to be changed, so one doesn't need programmer status either.

You may now specify if the talking player gets a receipt ("You say, ...") or just reads his name like everyone else in the room ("Daniel says, ..."). This works for all the sub choices described below.

You may change the global default settings by altering the property on the language object. The strings are found in "$lang_utils.verba_dicendi_strings". You need, of course, to be a wizard to change that. If you want to alter the workings alltogether, you may do that in the $room:say verb, provided you are a wizard. If you are a programmer, you may consider building an own room with a custom say verb.

Perception of utterances is technically tied to the room. There are no player defined settings that would generate situations where one player reads MSN style, the other player reads custom style, and the third the default language aware style. It's either off or on for everybody in that room.

Note that language setting can be change from "player defined" to "area defined". A MOO like MOOssiggang, e.g., defines the player's preferred language as his location's setting. Meaning, when in a German room, there will be German verba dicendi, regardless of the player's personal language settings (they never kick in), and when the player moves to an English room, there will be only English verba dicendi, again regardless of the player's personal language settings.

Remember also that emoting will always work like before. If you type, e.g., ":coughs before saying "Hello", this will of course not be translated to any other language.

3. Is there anybody out there? The Intercom device

Many of you have been requesting simpler-to-use Intercom device, i.e., controlled by web. Although originally scheduled for later, I couldn't resist and made one nonetheless.

This intercom device is build from scratch and has no code common with the old device. Thus, it won't affect the classic text command intercom device Jan Rune made; his device should be working like before.

3.1. Design and workings

The new intercom ($intercom_device) is one object. There are no receivers and controllers, this one object contains both functions. This object may be connected to other intercom objects. When two or more intercom objects are connected, they can be switched on and off in order to broadcast and listen to each other. Broadcasting and listening are reciproque states on connected devices. It is possible to use a device only to listen to another room without broadcasting your current location's conversation to that other room. You may at any time switch the microphone on, and talk to the players in that other room.

In the picture above, the player in the room "Headquarters" (Daniel) looks at the intercom device. This device is connected to three other devices. All four devices are owned or co-owned by Daniel (else the checkboxes would be greyed out and no submit button would be visible). In this particular case, the three other devices are placed in three rooms: borrough I, borrough II, borrough III. Daniel has chosen to just listen to borrough I, to have a two-way conmmunication to borrough II, and to broadcast the conversation in Headquarters to borrough III.

The devices in borrough I, borrough II, borrough III are, however, not interconnected. They answer to Headquarters only. So in a way, the device in Headquarters could be called a master device, although there is no technical difference between the four devices. They are jsut connected the way they are. Hence, the intercom device in borrough I looks like this:

Note that this is the exact opposite of the master device; "listening" and "broadcasting" are mirrored. The active connection may thus be turned on or switched off on either of the devices. You must, of course, be owner, or co- owner, to of the device to connect it to one of your other owned, or co-owned, devices, and to enable/disable broadcasting and listening.

3.2. Connections

There is no limit to the number of connections. You may connect a hundred intercom devices to each other and switch them on. You probably might not want that though. The connections are conveniently set in the Object Editor like this:

The intercom device is not technically connected to the room. It just happens to be located there. Thus, you might collect all you intercom devices and drop them in other rooms [NOTE TO SELF: we should maybe have a setting that they can only be dropped in owned and co-owned rooms]. The control panel always labels the connected devices dynamically by their current location.

3.3. Impact

Note that broadcasting and listening affect the whole room the device is located in. ALL utterances in a room will be broadcasted to the other room. Be warned that not only your own talking will be heard, but everything said in the room you are located in. The Intercom is thus not a personal device, but a local device.

3.4. Integration

The Intercom device is integrated in the EduCenter. When you create a multiple-creation-template "EduCenter", an Intercom device is created for each of the main and satellite rooms, the main room's device being connected to all of the satellite rooms, and the satellite rooms' devices connected back to the main room only.

You may create additional Intercom devices at any time from the Objects Creation web page.

3.5. Recording

A main difference between the text-mode Intercom device and the web-controlled one is that the latter does NOT record anything. It is NOT a recorder. There might, if the need arises, be a function in future version to switch recorders on and off, or, alternatively, intercom devices may have an integrated recorder on their inside. This is not the case in the present design.

The reason for this is that the Intercom device is conceptually a synchronous thing, and it facilitates teachers' orientation in a multi-room environment. Since the default setting on users is the HTML Chat, all output is by default recorded into the Chatlog and can be retrieved from there.

3.6. Visible Activity

As for the recorder, I have implemented a routine that changes the gif of the intercom device according to its state (shutoff/listening/broadcasting/two-way). But I am still waiting for the icons. Once they are done, the change will show immediately.

4. Paging/SMS

This section is on this page because many users do page other users in the same room. The page command has thus taken over the whisper command. (This is at least my personal experience.)

The page commands (-player message) continue to work as before. In addition to them, or, as replacement for the basic page, I have made the page a web controlled function. Whereever you see a small cell phone next to a player or a group, this cell phone can be clicked to evoque a popup window in which to type the page message. This is now called SMS (MOO-SMS).

The message is received in the Chat area, and clearly marked as SMS, with the date, the name of the pager and a callback-link. The message is not visible for anyone but the addressee. The SMS received, and the callback SMS, are printed in the Chat area, and not in the popup-window. This might, if the need arises, change in future releases, so that the received messages could be printed within the popup-window. But there are a few technical implications which should be discussed before we implement such a change.

The SMS is, by default, accompanied by a pling. The pling is a hidden sound file in the player frame, which is reloaded with the sound whenever an SMS arrives. You may specify the pling sound, and even if you want a pling or not, in the Object Editor.

You may page groups as well. The Who Browser displays all players connected, all of them with a cell phone. In addition to that, the Who Browser displayes pageable groups. These pageable groups are computated on each Who Browser load: You must own or co-own a group, or be a member of a group, and at least one of the group members must be connected to the MOO. Thus, the number of pageable groups may vary. A group SMS is basically a batch, where all group members are paged one after the other. A report is written into the Chat area; the result (received or not) are stated for each member of the group.

5. Will there be changes to the other rooms?

There are a number of room types I haven't done anything with: The $classroom, the $moderated_room, the $webpage. The text commands connected to those rooms should still be valid and working, as should the functionality and graphical representation of the web page object. Converting the commands to clickable web commands will have to wait. However, as the intercom device shows, I can't see anything standing in the way for that to happen. It might prove to be an interesting student assignment as well.

(End of file)