Persisting scripted behaviors


#1

This is a carryover from: Velocity is borked for models

Also this topic: https://readme.highfidelity.com/docs/scripts-digging-deeper

I am a tad confused about the run-time model for scripts, so let’s run through a few scenarios:

I could make a scripted entity creature that when an avatar sees it (not touching, just seeing), will cause the script to load and run in his client. Then the creature can respond even use the physics engine (bullet).

Q. Is the act of an avatar viewing a scripted entity enough to make the script in the entity load and run in the avatar’s client?
Q. Is the script loaded and run on all clients that have viewed the creature?
Q. Is the simulation owner the first avatar to have viewed the entity?
Q. Which events constitute switching simulation ownership?
Q. Does switching simulation owners do anything to the run state of the entity script in each client?

The avatar might sit on the creature (let’s not worry yet about that complicated process for now), and they fly together. The script runs in avatar’s client. Now the avatar logs out or crashes. I would have the script detect that event and make the creature fly to a roost spot or maybe fly to another avatar. But, what happens next and how can that be made to work seamlessly?

Q. If multiple avatars are in the scene observing another avatar flying around in an entity and that avatar logs off or crashes, are they running a copy of the creature’s script?
Q. If so, how can they know to take over creature behaviors?
Q. If not, then does this imply some funky arrangement where an AC script needs to monitor those kinds of events and somehow shove a script up the posterior of a nearby avatar’s client?


#2

no answers? :pensive:


#3

Great questions! I look forward to the answers also…


#4

I am asking all this because making autonomous things may prove difficult. In SL-style worlds, there is a super observer WRT scripts. Place a script in a prim and it just runs no matter who is there to observe it.

In HF, there is no super observer for general scripting. A script runs in an observing client, either directly started by the user or started up by interacting with an entity. Yes, there is a script engine in an assignment client but it is much more limited presently.

I would like to see the script AC have full physics and be able to observe entities to run their scripts. And, if this happens, I’d like to see that specific AC be different than the AC that runs domain-wide scripts (those authored by the domain owner). Why? Because if a griefing situation were to arise, I’d want to be able to shutdown the AC that runs the entity scripts without stopping the domain owner authored ones. Not exactly sure about all this since I am not certain about the scripting model details yet.


#5

It actually surprises me a bit that we’ve got the scripted system devised so that the scripts are only run by the local client, not something that continues to run when there’s nobody on the sim. There are going to be times where you need to have some scripted object running, and doing things, when nobody is around. Say, you have a fancy alarm-clock sort of device that not only rings the buzzer at a set time, but maybe it also is devised to trigger certain actions every hour on the hour, say for statistical-analysis reasons. You maybe want to place out a device that tracks what the latancy is in your rented apartment, hour by hour by hour, and serves up that statistical information the next time you wander into your apartment. If there’s nothing local to the domain and independent of any wanderers-by that is running that script, then all that information never gets collected in the first place unless you deliberately park a bot client there. oO

Another thing that commonly used to happen in SL was the “magic boxes” that would serve up content remotely to people who clicked Buy on the SL Marketplace. These magic boxes existed in world, and there are actually still some more sophisticated, scripted server-objects in world there, such as the Caspervend server devices. These ones actually keep track of what all was bought on SL Marketplace, and if there’s an update made to a particular product, automatically deliver the boxed update to each user the moment they log in. Without a script-engine that runs independently of the clients, that sort of useful thing cannot happen.

Yes, it makes sense that with some scripted objects, the scripts be run on the client side… it particularly makes sense with stuff meant to be “part of” or be “worn by” the avatar, because that stuff goes wherever the av goes, and it goes poof when the avatar goes poof (i.e. when the user logs out). It does NOT make sense for, say, built-into-the-building-structure things such as doors and elevators, though.

I really do hope we’re going to have a domain-side runs-the-scripts thing, too, and that we each have a choice of which one to use, on a scripted-object by scripted-object basis. And obviously there’d need to be a way to shut off selected scripted objects or groups of selected scripted objects, or to simply set it so only those who have authorization to place out scripted objects that operate at the domain-level can do so, and/or supplying a kill-switch to shut down any already-placed-out scripted-objects not on the authorized list of users or to shut down those from a specific user.


#6

Yes, even more, the fact of knowing about the entity (it could be right behind you) is enough

Yes

It’s a bit more complicated that that, but most of the time yes

I think the main one is grabbing an entity, maybe @andrew and @seth could chip in on that, didn’t work with that code much.

Nope, I don’t think their’s even a way to know if you are the simulation owner of an entity from a script.

The best way to do that would be to have an assignment script managing the entity (consider even making that entity an “avatar”). You could have people riding it run a local or an entity script that sends messages/commands to the assignment script.

They are, everybody is. Also the state of the script might be different.

I don’t think this would be the right way to think or go about it. The assignment script would make more sense.
But you could use some data in the userData to say who is riding the creature, or send messages to the other scripts.

Kind of, it really depends on what you want to do exactly.


#7

This is exactly what AC scripts are and are made for.

I’ll concede that it could use some more design to make it more user friendly and straight forward to use.


#8

@c thanks much. I’m happy my understanding of the model is mostly correct. Yes, I thought about having an AC script do some of the work, but because physics is not part of the AC environment, it massively reduces the usefulness. Also, the other issue (correct my misunderstanding, if any) is that the only way to start an AC script is by manually loading it. So, if someone rezzes my way cool dragon/ikran product in some arbitrary domain, they would not be able to make it work without the domain operator manually intervening.

And yes, having the client scripts poll a common userdata item to see what’s up would work. Then there is the need to determine whether the current user has disappeared, although I guess storing their ephemeral/session ID is one way to do that.


#9

This is turning out to be a fascinating distributed computing project. I just realized that since the script of an entity gets pushed to all the scene clients, it means that things like Roleplay meters and RP effects become far easier to do since the script instances can talk to each other.

Q. Is there a distance limiter to which clients a script in an entity gets loaded?


#10

It is highly depend on your past, so there is no really well defined behavior at the moment.
You can assume that most of the people in the domain are running your script.

In most cases, this won’t matter. Script have no awareness of where the physics simulation is taking place, so even though the simulation is not running on the AC, it’s running on every client in the domain, and this should be all the same to a script.