266 Release Notes

• Fixed: Dream Daemon was ignoring the security settings (like -trusted). (AbyssDragon)

• Fixed: Some invalid urls were crashing Dream Seeker's embedded browser. (Zilal)

• Fixed: Pager information (description, email forwarding) wasn't being saved correctly for people without any friends in their pager-list. Everyone needs friends!

• Fixed: The stat & verb panels were sometimes retaining their values when moving between worlds.

• Fixed: Selected text in Dream Seeker was being removed when new text was inserted. (Zilal)

• Fixed: The scroll position was getting messed up a bit when toggling between "text" mode and "pager/browser" mode. (Zilal)

• Fixed: the verb panel was not always getting refreshed when moving between rooms. (Al)

• Fixed: since the last release (the Sidewalk Santa optimization update), view() was returning extra tiles to the north and east. (Guy T.)

• Fixed: connecting to a world with sounds turned off initially was sometimes causing sound to be muted during the entire connection session--even after turning sounds back on.

• Fixed: The Click() command wasn't being processed when no icons were visible at a valid map location. Now the turf should be returned regardless. Note that with this change map areas are effectively "unclickable", because the overlaying turf will always be returned (even when the area has an icon and the turf doesn't-- of course the designer can handle this case in the code). We can probably handle this differently if the need arises, but currently areas do not return turf location information (in the second argument to Click()), so this is a bit different from the other situations. (Deadron)

• Expansion on the client command line now avoids re-calculating expensive server-side lookups when expanding subsequent arguments. The reason it was doing this in general was for rare cases in which the syntax of later arguments depends on earlier arguments. It now detects when this is not applicable. In other words, tell(mob/M in world,T as text) should no longer lag between every word. (Guy T)

• Sound files were not being prioritized for download but were being transfered to the client in whatever order they happened to be in the .rsc file. Now sounds that were referenced already (like a background sound) are sent first. With this improvement, I have reinstituted a memory the last foreground sound that was played before the client had the data. Previously, this was sometimes resulting in a sound suddenly playing long after it was originally fired off, so we simply dropped such sounds. But now it should perform well enough to justify the foreground memory. Complain if you find a case where this is not helpful.

• Added DM instruction: browse_rsc(file,name). This is for transfering files (ie images) to the user's cache directory that will be subsequently referenced by an html page displayed by browse(). (Spuzzum)

• Added client.show_verb_panel. It is on by default, but if you don't want the verbs taking up any space on the screen, set it to 0. (AbyssDragon?)

• Added client.preload_rsc. It is on by default. This causes all the resource files understood by the client to be transfered when the player first connects (which is how it has been working all along). Otherwise, if you set it to 0, resource files are only transfered as the client finds that it needs them (which can introduce a little lag the first time a resource file is used). If you have a huge number of resources, you might be better off using this option so players don't get frustrated when they first log in.

• Added isicon(). Good call, Spuzzum. (Sorry, Gughunter, I didn't have time to slip in isroom(). I want to think about that for two minutes, but I admit that under the current system, there is no straightforward to tell if an area is off the map (you have to look for turfs in the contents list). And you can do istype(X,/list) for lists.)

• Added a "password" user input type so you can prompt for a password without having it echoed to the screen when the user types. This only works with prompt() and should not be used with verb arguments. (Al)

• The client-server now automatically queries the user (via a hypertext link) to open a port for multiuser hosting. Worlds are run in single-user mode by default, but you need merely click on the link to change this. You should probably remove your default-port setting from seeker.txt if it has a numerical value, since currently that will override this new security-conscious feature. We'll probably do away with this setting completely in a future release.

• The client automatically launches the "New Key" dialog when users don't have a key in their key.txt file (ie- upon first use of BYOND). (Deadron)

• The verbs panes are a now little more intelligent in packing entries, so as to optimize space. Some other UI optimizations have also been added, but they aren't worth mentioning here.

• sound() can now take a file directly from the filesystem (either "filename" or file("filename") will work). (AbyssDragon)

• Because of some potential problems, "http://" is once again the default style for links in the browser. That is, if you do: usr << browse("dantom.com") The browser will go to http://dantom.com rather than byond://dantom.com, which used to be the default. The advantage of the old notation was that it was consistent with the text("dantom.com") output, which uses byond:// by default, but it had some drawbacks too. We might change this decision in the future, so the best method for all involved is to always preface your links with the relevant protocol, eg: usr << browse("http://dantom.com"). You might want to check any of your existing code that uses browse() to ensure that this doesn't cause a problem.

• Dream Maker now has a "clean compile" option that removes the .rsc file before compilation. This is useful when, in the course of the development process, you find yourself adding to and removing resources from the project. The normal compilation mode won't remove unused resources between compiles, which can lead to larger .rscs than are necessary. This is a good option to use just before you upload your program to the server, since it will minimize the file size. It is also the default option now when you make an "EXE distribution". Note that you should not use this option when you don't have the original resource files for your project, since those are needed to rebuild the .rsc.

• The "Build EXE option" now generates a zip file that can be distributed to others. This format is most convenient because it automatically unzips into a -safe directory (having the same name as the EXE).

  ---

  Hub stuff!

• When players (with active location reporters) connect to a networked world, an entry is now automatically made in the "Live" hub. No pre-configuration or anything is necessary. The existing hublib which handled this before is now largely obsolete. We will release a trimmed down version of it soon that handles score reporting. Almost everything else that it did is now automatic.

  By default, the entry in the hub is just the name of the game (world.name). Players can click on it to log in.

  Since some games may have different phases (like "waiting for players", "game in progress", etc.), you can assign a description of the phase you are in to world.status. This will be displayed in the hub entry so that players can tell what they are in for before clicking on the link.

  Just that functionality alone will be good enough for most games, but some distributed games (ie player hosted) may need their own private hub area. This can be done by registering your own hub entry and then assigning the unique "id" that it gives you to world.hub. Then your game can pop up a browser page that shows just your game and all of the currently active instances of it that are running. You do this with a URL to the hub cgi script including the "id" of your hub entry as a parameter.

  In addition to world.status and world.hub, there is also a new world.version var. If you are distributing your game to players, you can use this to automatically notify players when a new version is available. You do that by recompiling with an incremented world.version and updating the official version number in your hub entry. When a player connects up using an outdated version of your game, they will be notified of the new release.

  Players who log into a registered hub game will now be automatically notified if there are other existing "live" instances of the game. This is primarily of use for distributed games (hosted by players). For example, a player boots up DragonSnot and is notified that there are other people already hosting games. The player can then click on the hub link that is provided and see the full list of DragonSnot games in progress and possibly join one instead of waiting around for others to join.

  One nice thing about that scenario, is that by booting up the local game first, the player is sure to have the game's resources pre-loaded into byond.rsc, which means other people's hosted games (some of them on mere modems) won't have to server up a lot of resource files.

  This distributed model of game deployment is very promising, because it allows your game (and BYOND as a whole) to grow very quickly without a big investment in massive central servers (which would probably still get bogged down). Instead, the central server is reserved for testing new releases, single-instance worlds (such as MUDs), and the hub. That's much more light-weight and affordable than trying to host every glitzy little game in one place. Our goal with the hub, the pager, and so forth is to bind it all together so that from the player's point of view, the entire Internet is one big BYOND server. Muuuaaaaahahaha!

  Don't worry about memorizing all of the hub details for now. We'll put some examples of usage up once the online version is completely functional.