ThreadBoard ArchivesSite FeaturesActiveworlds SupportHistoric Archives |
dead bots do tell tales (Sdk)
dead bots do tell tales // SdkmagineJun 15, 2006, 12:05am
I've found that in 4.1 SDK build 60, after calling aw_destroy, I can
still select the presumably nonexistant instance using aw_instance_set, without getting an error. (This kind of broke a function in Magsbot that expected to get an error if the instance had been destroyed. I fixed the problem as far as I'm concerned by doing some things differently, but it seems strange anyway.) cotarrJun 15, 2006, 8:04pm
What I have noticed, it works exactly like 3.6 until it disconnects.
While it is connected, MFC timer events spawn threads, and inside the timer service routine, call to aw_instance() return the current instance number. However, if the bot disconnects, and reconnects, after the reconnect, inside the MFC timer handler subroutine, call to aw_instance() now returns 0, and each call has to set aw_instance_set() first. In both cases, when aw_instance() is checked inside an AW SDK spawned event, the instance is always correct. This is only outside SDK events with Windows generated evernts (not created by SDK). I don't see this as a bug, because I always explicitly do aw_instance_set() before SDK calls, but perhaps it will help solve a piece of you puzzle. Also, with only one instance running, each reconnect seems to generate a different instance value. Perhaps they are stacking up. Also, when the bot first connects to the universe, a universe_attribute is received from aw_instance()=0, and 3.6 sdk I have never seen instance=0 when the bot is started, again, not an issue, just interesting observation. -cotarr On 14 Jun 2006 22:05:35 -0400, "Magine" <magine at turtleflight.com> [View Quote] >I've found that in 4.1 SDK build 60, after calling aw_destroy, I can >still select the presumably nonexistant instance using aw_instance_set, >without getting an error. (This kind of broke a function in Magsbot that >expected to get an error if the instance had been destroyed. I fixed the >problem as far as I'm concerned by doing some things differently, but >it seems strange anyway.) |