252 Release Notes

Fixed: Constant and object variables were sometimes not being allowed in expressions requiring a constant. They should work now.
Fixed: there was a bug in the new savefile code that was causing successive objects in a list to overwrite previous ones. (Deadron)
Fixed: the compiler was generating error messages on valid expressions of the form: It was also misinterpreting certain nonsensical expressions such as: to be The parentheses around the conditional expression now isolate it from any following statement. (Guy T)
Fixed: the del instruction now works with /client objects.
Fixed: flick() was not working for objs. (Spuzzum)
Fixed: the compiler was now complaining when you left off the right-hand argument to an infix operator (X == ).
Fixed: canceling an upload was sometimes failing. (Deadron)
Fixed: Sometimes the wrong icon-state was appearing for icons inlined in text. (Guy T.)
Fixed: Text documents {"..."} now are colored correctly in the text editor. (Guy T.)
Fixed: The right-click popups were occassionally not showing up for items with attached verbs. (Spuzzum)
Fixed: world.tick_lag was only allowing a resolution of about 100ms, so setting it below 1.0 wasn't having any effect. Now it has extremely good resolution. This allows making arcade-games like pacman that (in theory) will run pretty quickly when given a small tick_lag (eg: 0.1). This change involved using some external multimedia timers that hopefully are not platform dependent, so be on the lookout for problems. We will probably be able to use this support for a higher FPS to produce better smooth-movement for generic worlds in the future.
File uploads should be significantly faster now (up to twice the speed).
Valid looking URLs like byond://dantom#cerulea are now automatically displayed as hyperlinks. I would not encourage designers to make use of that feature, but it is handy for players who want to tell somebody else a link without using complicated syntax.
Added hascall(Obj,ProcName) as a way of testing at run-time if a given object has a proc or verb by the specified name. You can then safely use call(src,procname). This feature is useful for library writers who want to adapt dynamically to the characteristics of user-defined objects. In the future there will also be a hasinterface(Obj,ObjType) which tests for all the vars and procs in one pass.
The compiler now warns if you call a procedure by reference like this: Instead, you should explicitely use call() like this:
Click() and DblClick() now have the following definitions: The Location argument is either the name of the stat panel where the object was clicked (same as before), or the location on the map (ie the turf) where it was clicked. The turf information has been added in case one cares about the location on the map where the object was when the user clicked it. Since a moving object might change positions between the time the user clicks it and the time that the Click() proc gets called, Location and Object.loc may be different. (Zilal)
You can now loop over instances of non-atomic types (such as /client, /savefile, /list, or any user-defined type). You do it by looping without specifying a list. Incidentally, if you have a lot of mobs, and you want to loop over just the players, it is a little more efficient to loop over instances of /client than over a sub-type of /mob.
Also be aware that even though you can use this for-loop to find all instances of data types, you should still maintain a reference to those objects somewhere or the garbage collector will destroy them. You don't have to worry about that with the 'atomic' types (area, turf, obj, mob) because they are always at least referenced by world.contents and will therefore never go away without you explicitly deleting them.
The second argument to Move(Destination,Dir) is the direction that the mob should turn to face. If it is 0, this will be computed from the relative direction to the destination from the original location. There are a couple reasons for that. One is so when users call Move(), they can leave off the second argument and it will be auto-calculated. The other is so when a user hits the arrow key to move off the edge of the map (Destination=null), I can still pass in the direction to face, since it cannot be calculated from the relative position of Destination. In a user-written redefinition of this proc, a common mistake would therefore be to directly assign dir = Dir without checking to see if it needs to be calculated. The server now correctly ignores assignments of dir to 0. It will retain its previous value.
The server now has a -CGI execution mode, so .dmb files can be used to process web scripts. Fun! The world boots, creates a /CGI object and an associated client and mob, and calls the CGI object's Topic() proc with the query text. Any output sent to 'usr' is transmitted back to the browser.
The new form library (about to be released) works just about transparently in either web (CGI) or BYOND mode. It just requires a slightly different invocation and things like prompt buttons don't work on the web. You could use world.Export() to communicate between the CGI program and a running world. I can't wait to see what people dream up with this!
Added another standard library to go along with stddef.dm. This new one is called cgi.dm. It defines the /CGI object type among other things. Instead of building that into every world (when most aren't going to use it), I thought it would be better to have it in its own library. As a bonus, when you include it, it configures the world for CGI operation (setting a new variable called world.executor to tell the web server how to run the .dmb file). The CGI object can also be used to get cookies and other environment information. There is a new client variable (client.CGI) which is initialized to an instance of the /CGI object at run-time in -CGI mode.
Added getenv() to retrieve environment values. This is used internally by the /CGI object.
Instances (such as icon-states) displayed in Dream Maker's object panel are now sorted by alphabet. (Guy T.)
The banner links now display the url in the status bar at the bottom of the screen. (Zilal)
Dream Seeker will now only automatically scroll new text if the scroll bar is positioned at the bottom. This allows you to look at old text on the screen without being interrupted by incoming text. (Zilal, Gabriel, others)
Dream Seeker now treats links inside user-generated browse() pages as byond:// by default (they used to be http:// by default). So if you do: The output will be sent to byond://#test rather than http://#test. This makes the text links and browse links equivalent. (Guy T.)
Dream Seeker's layout system has changed dramatically. When the stat panel is sufficiently small, it is moved over to the right-pane as another toggle button to accompany the browser. The definition of "small" may be decided by the user in the new Layout Preferences (by default it is less than 100 pixels tall). The icon sizes are treated in a similar fashion; map icons will be shrunk when the interface decides that there isn't enough room to show them with the text panel.
Handy CTRL keys for Dream Seeker: CTRL+1, 2, 3 toggles the "text", "browse", and "info" buttons. CTRL+I toggles the info-panel from left->right.
There is now a "Build EXE distribution..." option in Dream Maker. This allows you to build a directory that may be distributed to other people to allow them to either host or link to your world. A pseudo-EXE file is created in the distribution; this is merely a stub file that first checks for the existence of BYOND before launching Dream Seeker on the corresponding .dmb or .dms file in the directory. If BYOND is not found to be installed on the user's machine, they will be prompted with a link to the download page. In this way, designers never need to explicitely link to or advertise BYOND when building their games. (Zilal with most of the badgering on this one)
You can now use big icons on the map builder. Simply assign an object an arbitrarily sized BMP file. When you place it on the map, it will be converted to tiles. Each tile is actually an icon-state with a coordinate specified as an offset from the lower-left tile. So the first tile will have icon_state = "0,0", the second icon_state = "1,0", and so on. If you know the size of the pixmap you can thus generate large images at runtime by iterating over the states. Note that each of these tiles is an independent object, so this method is really only suited for static pictures. Making a big 2x2 mob won't work (yet). (Guy T. with the excellent method suggestion)
When given a BMP larger than 32x32, the icon-editor is bypassed and your local BMP editor is run. We can't handle large images just yet.
The install procedure has changed quite a bit. Not only are things done more cleanly with a self-extracting, self-installing EXE, but the entire structure of the user directories has changed. BYOND now installs into two places: the "system" directory (BYOND/lib, BYOND/bin ...), and the "users" directory (BYOND/users/[username]/lib...). For most people this won't matter much, but for those of you running multi-user accounts under UNIX or 2000/NT, this allows separation of global files from individual configurations and such. It also allows us to provide the basic system distribution libraries and binaries without disrupting your own user settings. As a rule of thumb, you shouldn't need to futz with the "system" directory, unless you want to add, for instance, a globally accessible library yourself.
The reference has been updated.
Check out the snazzy new icons. Thanks to Guy T. for making them!