llGetNotecardLine dataserver() event

Suppose I call llGetNotcardLine from one state, e.g. the default state, and then switch to another state before the dataserver() event is fired.

Will any resulting dataserver() event be lost, or will it be fired in the new state?

Is it considered bad practice (or just plain wrong) to do this?

I'm having problems understanding how this works, so any help appreciated, thanks.

Well I can't actually say whether it will or not as I've not tried. But why don't you experiment? It's only a simple script to play around with. Seriously, this is how I learn everything, trial and error. Fire off a data server command, like, get agent's name or something, and then change states straight away, in the new state, have the data server event llOwnerSay the query key and data string. That way you'll know if it works!

*grins*

It will be lost
If you know the number of requests, you can wait to change state until the number is reached.
There is no way you can make sure the sim will answer all requests though.

The dataserver event is an event which is triggered from the outside and comes in to your script just like any other event. If you have an event handler for it in the active state, it'll be handled; otherwise, it'll just be lost. It is no different than any other event. A touch is handled if you have a touch handler; dataserver is handled if you have an event for that.
It makes no difference that the event is in response to a call you made earlier; those two are entirely decoupled.

So the wise thing to do, maybe, is to either delay the state change or put another dataserver event in the new state, just in case.

Thanks for the speedy replies people.


As you say Rolig, I think I will do all my Notecard reading stuff in the default state, and switch states when I have confirmation it has finished.

I'm slowly getting my head around this scripting malarky.

Without seeing the script itself, of course, it's hard to tell but very often it's unnecessary to make a state change at all. Unless you're trying something that really needs to be cut into discrete blocks (setup things isolated from runtime things, for example), you ought to be able to use condition statements to branch from one possible task to another in a single state. True, sometimes it's easier to conceptualize a script in separate states, but it can also lead to unnecessary code duplication and a heavy reliance on global variables.