317 Release Notes

• This release includes a few additions to the language, so worlds compiled in 317 can only be run on 317 servers. Older clients can continue to connect to them, however. You may want to keep this in mind when distributing games over the hub, or tell people to upgrade.

• Fixed: Occassionally, calls to the walk() routines were causing DS crashes. (Canar)

• Fixed: It was possible to get some .rsc corruption when running two clients on the same machine.

• Fixed: DS was going invisible on exit, but the process wasn't always closing. This occassionally caused the multi-client problem mentioned above.

• ALT+S is now a keyboard shortcut to send a page from the Page dialog. (Alathon)

• Nested loops of the type for(x = Lower to Upper) are handled more efficiently now.

• Added for(x = Lower to Upper step N). In other words, you can now specify a "step" value, which is used to increment x on each iteration. The default step is 1. Note that either "=" or "in" may be used, but that is nothing new. It is easier for the compiler to optimize loops using this syntax, but it really doesn't matter except in super high frequency code.

• Made some slight optimizations for screens with a lot of "paralax" going on. Basically, when more than 50% of the inner map contains screen objects, it stops assuming that most objects on the screen will shift with the map. This case still needs more work though.

  You will find it a little more efficient in cases where screen objects and map objects do not overlap, so get rid of any needless icons, such as an old background turf or area that is completely covered up by a new screen object background--Ebonshadow:) In the future, we can optimize those sorts of things away, but for now, they still generate overhead.

• Added preliminary support for background procs. These essentially achieve the same thing as if you periodically call sleep() within the proc so that it doesn't block up the cpu, except this mechanism avoids some of the problems you get when sleep() is called either too frequently or too infrequently. proc/EventLoop() set background = 1 while(1) //blah blah You probably still want to sleep at least once inside most types of infinite loops in order to control how fast they iterate. Running in the background just means the proc won't create huge lags each time it iterates.

  Background procs never trigger the infinite loop dector. Procs which do trigger the infinite loop detector now merely issue a warning and then switch into background mode, which makes it much more practical to leave world.loop_checks turned on, even in a production version.

• sleep(0) and spawn(0) no longer wait until the next tick. They are scheduled immediately after other events that are already pending. This allows you to continue to control the order in which things happen without paying the penalty of unnecessary sleep time.