Xelagot topics

Known problems

Bot is told to move down (or up) to zero altitude, no other coordinates are changed. When observing the bot through the aw browser, bot stays where it was. Feb 25, 2000
Fixed in browser 3.0 (build 354), not fixed in 2.2 (build 306).
This is a well known old bug in the browser, the "zero altitude bug": if only the altitude is changed to zero, and no other coordinates are changed, the browser does not show the change. You can test it yourself: teleport somewhere, make sure you include 0a in the teleport screen. Before teleporting, copy this position to the clipboard. Then, once teleported, use the "+" button only to move up. Put your view to 3rd person view (hit END) to see what happens, and ask some friends to come and watch. Then, teleport back again to your previous position: just paste the contents of the clipboard into the teleport screen. You are actually only changing your altitude back to zero, without changing other coordinates. You will not move down, according to your aw browser, and other people looking at you will also fail to see you move down. Now, just take one step forward: because you changed another coordinate, the altitude change will also be executed by the aw browser, you will go forward and down to zero altitude. No workaround. Just move the bot slightly horizontally, or have the bot do a gesture.
Program freezes for some 40 seconds at a time during disconnections. Feb 25th, 2000
Roland Vilett says this is due to the fact I program in Delphi pascal and not in C or C++: Delphi would fail to communicate correctly with the aw.dll, which is written in C. I have tested a few other bots written in C and C++ under the same disconnect conditions, all of them show the same problem. No workaround.
Notes: I tested the behaviour of aw_wait(0) in these cases. aw_wait blocks the execution of the thread it is in , and that is the cause of the freezing (this can be seen in the new versions of the bot: the middle 'led' light, which is an indicator of aw_wait exclusively, freezes, first in yellow, then in red). A curious fact: the aw browser, supposedly using the same SDK, does not freeze as the bots do. The way disconnects are handled by the sdk is not good: if the bot is in a world, it should get an event world_disconnect in these cases. In some cases, when the universe or the isp disconnects, this event is not triggered. The only way to find out that this has happened is by checking the session number, which will change to an error code. The aw browser, in some of these cases, fails to recognise or mention a disconnection: if you are building at the time, you don't get the usual message "your changes will be lost", but when you come back later, your work is gone. The world server, when caught in some disconnects, just blocks: the heartbeat is not registered, there is no mention of "heartbeat rejected"... but you can see that the last time an event was registered by the world on-screen log was minutes ago (world heartbeat occurs once every 60 seconds).
Bot has bot right in a world, but no enter right (bot right is what the bot needs to enter a world, enter right is for tourists and citizens). Bot suddenly gets a message "not welcome" after a disconnection or after changing world attributes. Feb 25, 2000
AW SDK bug, reported by myself and Ima Genius months ago to Roland Vilett. Workaround: give the bot enter right as well as bot right.
Bot is in world A at GZ, gets ejected or the world goes down. It is then sent to world B, far from GZ. It lands in world B, not where it is sent to but at GZ (previous coordinates in previous world). If this world B happens to be a COF world, gets the boot from Customs Aide because it is in a forbidden zone. Feb 25, 2000 Apr 27th, 2000: workaround found and implemented in Xelagot. For programmers: set your new coords, without doing aw_state_change(), before doing aw_enter(). This sets up the new coords which may be used by a silent aw_state_change called by the aw.dll in certain error cases when you enter a world before you plan to set them yourself.
AW SDK bug up to build 16. I filed in a report to Roland Vilett on February 7th, 2000.
On April 26, filed in a similar report (same bug), with CC to Faber. Faber solved the mystery, and the bug was acknowledged by Roland. May get fixed in next upgrade of the SDK.
Bot is in world A in universe X, jumps to world A (same name) in universe Y (different universe). Error code 439 "No connection", gets a short universe disconnect, cannot enter world A. Feb 25, 2000
Fixed in AW SDK build 16, April 3, 2000
This is an AW SDK 15 or earlier bug, it happens to other bots (i.e. Preston) alike: world A in any universe except universe X where it entered succesfully the first time, are banned for the bot. I filed in a bug report on Friday Feb. 25th 2000 to Roland Vilett, maker of the AW SDK.
Bug has been confirmed by Roland Vilett (Feb 25th): Alex, You are correct, in order to avoid unnecessary load on the universe server, the SDK caches the address/port info of worlds when the world is first looked up. Further lookups of the same world are resolved out of the local cache rather than going to the universe server. Currently this cache does not distinguish between worlds of the same name but in different universes, and this is obviously a bug. -Roland
Bot creates speakers or objects, and then deletes or changes them. Objects stay visible in the browser, or midis get muddled... Aug 2nd, 2000 No real workaround as yet, but read below...
This is one of the most difficult bugs to reproduce. It has been reported a few times. To-day, at last, I could reproduce it and Roland found the cause of the bug. The object must be at an exact cell border at a Southern or Eastern coordinate, for example, at 23.000S 2.003W, or 17.090N 21.000E. All full AW coordinates (with no decimals or with only zeros after the decimal point) are cell borders. Due to a very old bug in the code, the browser does a faulty rounding off operation from single precision float to integer, and the added object is sent to the renderer with a wrong cell address. When the object is deleted, the renderer looks for it and fails to find it, so it just leaves it in view. This is a temporary problem, next time you come back to the area the ghost objects are gone, but it is a very annoying one if you try to play midis, or slide shows, or achieve effects by changing objects. Note that if you select the object yourself and deleted it, your browser will delete it correctly, but others browsers watching the same view will not see it disappear. By the way, this bug should not affect the cache on disk.
Practical workaround: Do not put your speakers or other changeable objects at full Southern or Eastern AW coordinates.
Bug investigated and confirmed to-day by Roland Vilett. Thanks, Roland, for your quick response, and HamFon and Hal9000, for helping me confirm the bug :)
Bot walks due South, its avatar keeps jerking back to look North - October 2000.
A 3.x browser bug, does not appear in 2.x browsers. Workaround: move the destination coordinate a few cm to the east or west, so that the bot does not walk due South.

Index