307-314 Beta-test Release Notes

In the next major release of BYOND, we will update the color format to handle 24-bit (true color), so that none of this quantization will be necessary. However, in practice the current results are pretty good and this is considerably more efficient.

In BYOND b38 and below, clear=0 all the time (no option) in b39 and b40 clear=1 all the time (ditto); now it simply defaults to clear=0, and you can control the history as needed. No more complaints.

If you do not call Lock(), a lock is automatically opened on the first write operation. If a lock cannot be immediately obtained, this operation will fail with a proc crash. The lock remains active until the file is closed or Unlock() is called.

The advantage of the object based method of icon manipulation is that it is directly modifiable in memory, whereas the old style operators often resulted in extra loads from disk or at least copying of cached data in memory. When doing a single-step operation, that doesn't make any difference, but when doing multiple operations, this method is better.

The other advantage is that we are no longer constrained by the limitations of trying to squeeze all of the icon manipulation functionality into a small set of operators. Procedures may be added for any number of arbitrary operations, and once a big enough base of functionality gets built up, soft-coded procedures may be added to the /icon object or new types may be derived from it in order to augment the built-in functions. Example:

One good use for this is to automatically place large images (bmp files) on the map. Each icon_state of a large image is automatically assigned to an "x,y" name representing its coordinate-offset in the graphic, ie: "0,0", "0,1", and so forth. You can use this information to perform some nifty placements without having advanced knowlege of the graphics:

Note that client.images is a specially allocated list. Each client has its own independent list which cannot be pointed to some other list or anything like that, just like atom.contents.

The format of screen_loc is designed to be extendable in the future. It is a text string that currently supports the following syntax:

Notice that in one of the examples above, it set y=NORTH+1, which falls outside of the map view. This is known as a "border" object. You are allowed to create borders of any size as long as the full size of the inner map plus border is within the 21x21 maximum size. Since these objects do not cover up any part of the map, this is good for graphical controls such as toolbars, indicators, and the like.

Screen objects obey the normal layering rules, so you can make screen objects that overlay or underlay the objects in the map (or something in-between, which would be odd).

One nifty way to create the client.screen list would be to design the screen in the map editor. At run-time, you could add the objects from the map into each user's client.screen list. That works out particularly nicely with tiled bmps, since the map editor lays it all out for you. Just make sure you use objs or mobs and not turfs or areas, since screen_loc is only defined for atom/movable. We'll probably make a library for this in the near future.

Since screen objects can serve as the source of verbs, adding objects to this list (even with screen_loc="") would be a convenient alternative to dynamic modification of client.verbs. To make the verbs accessable, just do "set src = usr.client.screen", replacing "=" with "in" if you want the other style of syntax.

It should be mentioned that unlike objects in atom.contents, the same object may be placed in multiple client.screen lists. There is nothing special about the screen list. Multiple clients may even use the same list.

The worst dangling references to clean up are references from a turf variable to an object that is getting deleted, when the map is really big. The turf contents list is no problem; I'm talking about a user-defined turf variable that points to an object that you delete without first removing the reference. As a last resort, the sweeper ends up scanning through the whole map in order to find the dangling reference. Still, this is way better than not having a sweeper at all, considering the horrible sorts of errors that can occur with dangling references.

Since some games might want to handle banned users specially (silent bans), a new world proc has been added called world/IsBanned(key,address). If this returns a false value, then the user is allowed to log in. The default behavior is to return null unless the user is listed in cfg/keyban.txt. Consult the new release notes for more info on the return code.

If you are testing this out, note that the preload_rsc URL is ignored by DS when you connect from the same machine as the game server. Also note that unlike dynamic downloading of resources from the game server, there is no provision for filtering out unwanted file types. For example, if a user has sound turned off, sound files would not be downloaded from the game server, but the preload package is all or nothing, so if it happens to contain sound files, these will get downloaded along with everything else. This is probably acceptable in most cases.

For the final 307 release, you'll probably never need to set preload_rsc from within the code. That functionality will be available as a hub-entry setting.

One difference from before is that 'layer' is now respected for images. Previously, images were always drawn in FLY_LAYER, regardless of the layer setting applied to the source object used to create the image. If you were creating images from objects, make sure the layer is set to what you want. Images created from icon files are still drawn in FLY_LAYER by default.

Note that midis can only play on a single channel (channel=-1) and that not all wavs are mixable. Example:

Note that after outputting a sound, deletion of the sound object has no audible effect. If you want to terminate a sound, you must do sound(null,channel=X), where X is 0 to stop all sounds, or 1-8 to stop sounds on a particular channel.