llRez return value

llRezObject really should return the key of the new object . That or it should updated the Detected Key so that llDetectedKey(0) will return the key of the most recently created object.

-Pat Murphy

I second this.

Will be even more usefull when Obj -> Obj IM is added too.

In case folks hadn't noticed, there is a new event:

object_rez(key id)
Triggered when object rez-es in another object from its inventory.

Cory

another event??? I really love the script language, but an event driven script gets more and more unreliable and complex when there are more events. For that there are states, but that's also not my favorite (I never use it)
Just a quick question though, is it possible that two events (maybe even the same) are executed simultaniously? Or is there some kind of event queue?

there is a que per script, but you could have multiple scripts on an object.

Never use states? I'm curious how you polymorph your events...true false flags for everything? I'm interested because I find states VERY powerful, and once I started using them well it really allowed me to do a lot of things that otherwise took a lot of work to do.

Conceptually I've started thinking of states as objects...albeit you have to use them synchronously unless you spawn other scripted prims and send external messages out. The way I'm see it, a state is an encapsulated unit of execution with it's own scopes and definitions...polymorphism. Global events are sort of like external code modules. Looking at the coding this way gives me the opportunity to leverage some of my OOP background (to a point), and start thinking in terms other than procedural. I wrote the 21 tables using this technique (for example "doAce" is a state, but is used like an object to return values and properties from it's own internal definitions of the events...this is a different behavior than the standard "playGame" routine for non-aces, but without states required fairly extensive boolean checks and a lot more code, which was tougher all around to debug).

FYI the only evident way to do the multi task thing is to use external objects and communicate via external messages. More than one script can run on an object, but you can't manage the info in script 2 from script 1 directly without external messaging. There's no "thread" type, or way to grab references to all running instances of object scripts from any one script and manage them.

Just my humble view.

Apparently the object_rez() event has been in the docs for at least a month. (I hadn't noticed it either. )

Can you elaborate on this? I always think of polymorphism as the ability to manipulate instances of derived classes as if they were instances of the base class, where the objects perform class-specific behavior without the caller having to specify it. How are you doing that in LSL?

Polymorph is the wrong term for what she is talking about. But she is using the states to simulate some OO practices and thats kinda cool.

If two scripts handle the same event on the same object,both will get called. It is something you have to be careful of and which can be taken advantage of.

One thing I noticed is the permissions event on a few peoples swords doesn't check that the permission gained is actually the controls permission they asked for. Which screws things up if someone adds another script that asks for different permissions, because when it asks for permissions the sword control script will think it got permissions too, when it didn't.

I can talk directly to another script on the same object. llMessageLinked(0,number,message,NULL_KEY) will message the same object. In my limited tests I use number to specify a specific script (each script on the object uses a different number when sending) so I can tell which script the mssage comes from. I am being very generous in sharing this because it is key to a couple of really nice scripts I am working on. But it should be helpful to a few people.

Despite her relaxed view on what polymorphism is, and OO in general, Tcoz has a very specific view on multi-threading. I on the other hand believe the tools are there to control other 'threads' in the system, and that the system is multi threaded. <shrug>

Aaaahhhh I started out not using states but .... that changes quickly once I really got going on my arcade. States help a lot in debugging and keeping code clean. It is much easier to follow what is happening and control how things are going with states. the alternatives are boolean or integer state controller varibales ( if (stage == 3) .... or if(someCheck()) ) wheras you can bypass most if not all of that sort of thing if the only way to get into the state is when everything else is set.

Well thats clear as mud. So here is an example. I recently made a memory game - you know, a bunch of tiles you 'flip over' two at a time. If they match you leave em flipped over, if they don't then they flip back. Well yes I can do it without states, but the touch event handlers would need a lot of if ... else cuz it acts differently depending on if the game hasn't started, the game just started, one tile has been clicked, the second tile was clicked, the tiles match, the game is over. So instead I seperate it out. When you pay it, it checks the pay amount then jumps states. When you click on one tile it jumps to the next state. And here is the real beuty - if when you click the next tile they match it goes to one state, but if they don't it goes to another.

I don't have huge if statement or global variables deciding where I am going or what is happening. Where they could get screwed up in where they are set or where they are evaluated. And they get set quite a bit so thats a lot of chance. With states I know that in the oneClicked state things are a certain way and the next click means a specific thing. It is just clearer in practice.

Ok guys whatever I'm out, it's all yours.

Thanks, Ama, for the reply. Another question: you mention both using multiple states and using multiple scripts. It seems that these are related techniques, but not the same, since you could declare all your states in a single script, right?

Don't go, Tcoz. I'm still interested in hearing your thoughts on using states.

each script must always be in a state. The scripts are seperate even though they are on the same object.

If you have stateA, stateB and stateC on script1 and stateD and stateE on script2 then .... the object is never 'just' in stateA or stateB or stateC or stateD or stateE .... the first script could be in stateA while the second is in stateD or stateE .... they are independant of each other.

So ... they aren't really closely related.

The original discussion was about the advantage of using multiple states. Then you started talking about using multiple scripts. If you don't consider these related topics, why did you bring it up?

From Mark:

From Nada:

From Tcoz:

Sorry, it was a continuation of an old topic really. I also apologize to Tcoz. Didn't mean to offend or anything. Just differing views.

And actually the original topic was about llRezObject() returning a key id. Not about multiple states.

My mistake. I was reading your post in the context of my earlier question. Sorry.

No problem Jake.

If you have any questions about states / multiple scripts per object or any other more general script questions in game - shoot me an IM or stop by the Arcade. If I can't answer I generally know who can.