266 Release Notes

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.