Closing Time: suggestions for a low-lag approach

Hello,

This is not a request for scripting help (at least not yet!). Rather it is a request for opinions about the best way to approach a scripting task. Best, here, meaning least likely to cause lag, clog up servers, and so on.

The issue: we have a private island where we are thinking about having opening and closing times. All the shops would open at dawn and close at duck, and all the clubs and other nightlife would do the reverse.

Now I understand how I might make a single building open and close at these times, by checking llGetSunDirection and phantoming or unphantoming a security grille or similar. My question is: what is the best approach for getting an arbitrary number (say 50 or 60) buildings to all do this in the sim? If there is lag at the exact moment that the opening/closing occurs then I can live with that, but I am concerned that there will be continuous lag if all the doors in town are busy checking the time on a loop.

The approach I am thinking of is to have one object that acts like a town clock and checks the sun at regular intervals, and then communicates to all the doors / grilles / etc when it is time to open or close. If the clock shouts to the other objects then they will have to listen which will give me a lot of scripts that are always on for no purpose.

I was therefore wondering about having the clock email all the other objects but that would still require the doors etc to set a timer and poll every now and then to see if mail has arrived, wouldn't it?

Is the email approach sensible or is there another approach? Or is this something that we should forget - an example of somthing that hasn't been done because it can't be done properly?

Any sugestions very very welcome
Mambo

The honest answer is, probably, suck it and see...

Set up a smallish number each way and see what they do to script time...

I'd suggest something with a highly filtered listen ( say llListen(-123456789, "clock", 'clock's key', "change"; ) isn't that laggy.

There is, elsewhere, something about running your timers at different rates, because a timer running every 3 hours is less laggy than one running every minute, that has been tied to day/night detectors before. Since a day is 3h long and a night 1h, you can set the timer to longish runs (2h45m and 45m say) before clicking up to a minute by minute check - which is not that laggy in my experience, and will give you shops changing close enough to together for most purposes I imagine. The balance between slow-moderately slow timers and a listen on a heavily filtered set up, I really don't know that there's an answer. Yet.

I'd have said emailing is the WORST possible option - that's why there's a 20s delay on email when you send them out!

I would suggest having the script calculating how long it is until nightfall/dayrise, and then setting a timer for that, and when the timer fires, it activates or deactivates the security, and then sets the timer for how long until the next change.

However, I believe the general concept is not recommended.. Having nightclubs open for 1 hour, and shops open for 3 is somewhat foolish. Shops should be open all the time, and so should nightclubs. In SL, there's no need to tend the property (usually), so things should be as accessible as possible.

Many thanks Eloise,

The idea of using a counter of varying duration hadn't occurred to me when I was thinking this through.

Doh!

That certainly seems like a very feasible approach, since any lag (if there is any actually noticeable) would occur in the quarter of an hour before dawn or dusk, and I could fit that into the overall narrative.

Bong, the town warning bell sounds the end of the day! That kind of thing....

Cheers
Mambo

At the risk of going off-topic in a thread I started I will briefly answer Keknehv:

I entirely understand what you are saying, and in general you are absolutely right. However we are trying to create a very specific island (we are in fact modelling a virtual culture) and in that context, on a private island which will hopefully be completely coherent, then I believe it will make sense - and if it turns out that it doesn't then we will simply regard it as research under the bridge!

More about all of this soon, when things have developed more on the island - when the theory/practice ration has shifted a bit

Cheers
Mambo

In that case why not do a variation on timer suggestion but vary the timers across the board by a random amount.

That way rather than everything closing bang on at the same time, there could be difference in the closing time.

I would also suggest that rather than having all the shops listen, have the clock listen for a trigger from the shops. When the shops shout they revert to a listening state and wait for a response from the clock. If you know the random max and min settings for the shops then you know what time to start making the clock listen and what time to stop it.

Oooh, this is a good thread. I wish I had a solid answer.

All I can offer is another approach that I've used to help a simowner who wanted something similar. Let me state right up front that we did no detailed analysis of sim load impact, but designed it to not cause the sim to lag suddenly. They don't exist anymore, or I'd ask how well it works today. I think the suggestions others have offered are certainly as, if not more, valid than this one.

We had an object (your town clock for example) that we called the director. It changed its name based on behaviors they wanted from other objects (performers). The director was a simple script, based on sim time, but had some override features too.

Any performer that needed to be cued had a filtered sensor repeat (ping) to seek the director to read it. I think we ended up with a ping of 600 seconds. In addition to store doors being locked/unlocked, they also had performer lightposts, traffic lights, and plans for automated vehicles like a street sweeper and garbage truck.

In application, all the performers pinged at slightly different times, just because they were not all installed/enabled at the exact same time. The effect on the sim was hard to detect with the tools we had. The good news was that the mayor liked this non-simultaneous effect, as he enjoyed watching things shutdown/start up over the timed interval.

The unique thing about this implementation is that the mayor could override the director if they so wanted, an ability you won't have if you put the performers on a long timer to 'wake up' for their cue, or limit their behavior to the sunrise/sunset. The mayor could control his director so that if he declared all shops open for a town selling event - or bars open in the morning for a celebration - he could. The performers were just 5 minutes behind his every command. That said, I think he only did this once - turned everything off for a RL day in honor of a RL event.

At the time we developed this, open listeners were seemingly blamed for all badness, and I was told to do it without listens... it’s just an idea.

And a very interesting idea it is too, since the randomising feature of shops opening and closing over a short period, with street lights switching on and off similarly, is definitely something we would like.

I am not quite clear how the ping worked in practice. Is this an approximate description of the functionality of the system you made?

1. The clock knows the time and listens on a channel.
2. The performers each have a timer, and say "Should I do anything?" on the clock's channel every 600 seconds.
3. The clock replies "yes" when it is dawn/dusk and "no" otherwise.
4. The performers do something (open/close, on/off) if they receive a "yes".

This system (as I have described it) requires the performers to listen for a specified period after each 600 second braodcast so that they receive the clock's reply. Is this correct? If it is, how long did you find they have to listen for?

It may well be that this description is not at all what you had in mind, and I am misunderstanding one or more consequences of your pinging system. I wait to find out with genuine anticipation. (This thread is making me think deeply about how we are going to build the interactive parts of our town.)

Cheers
Mambo

When communication fails, nothing like an example!

Director:

default
{
    state_entry()
    {
        llSay(0, "Director Key:" + (string)llGetKey());
    }
    
    on_rez(integer start_param)
    {
        llResetScript();
    }

    touch_start(integer total_number)
    {
        if (llGetObjectName() != "")
        {
            llSetObjectName("");
            llWhisper(0,"Off");
        }
        else
        {
            llSetObjectName("Director");
            llWhisper(0,"On");
        }
    }
}

The director would be your clock. I use a touch event here to change its name, but you can use any event obviously. Its key and name are important, and you'll see why in this next script.


Performer:

default
{
    state_entry()
    {
        llWhisper(0,"Performing.");
        llSensorRepeat("Director", "815b1e06-b0e9-abbd-5358-037732eeb4ef", 7, 363, TWO_PI, 5); 
    }

    sensor(integer total_number)
    {
        llWhisper(0,"Detected" );
        llSetColor(<255,255,255>,ALL_SIDES);
    }
    
    no_sensor() {
        llWhisper(0, "Not detected");
        llSetColor(<0,0,0>,ALL_SIDES);    
    }
}

For demonstration, I have the rate down to 5 seconds; in practice, I used 600 (5 minutes).

So, no listeners. The performers all do their thing depending on if the Director is detected. Note the name and key are used in the llSensorRepeat - you need both so that nobody can trick your city with a false Director.

Again, this is just an idea; I can't say that this is the low-lag solution you seek. Experimentation is probably the best way to tell. In a private sim, you have the new estate tools to look at scripts and you can monitor behavior over time.

Good luck with your build. Send me an invite when you open!

Oh neat, Leonard, Very, very neat.

I had seen the sensor commands but never ever thought of using them in this way. Now I understand exactly what you were getting at in your previous post.

If my Director is a town clock it can change its name just before dawn and just before dusk. And if it also checks for the date then it can keep the whole town open for 24 hours during midsummer and other public holidays, by simply not changing its name if date = x...

Who knows if this is lower lag or not, or indeed if the lag in any of the approaches suggested is actually significant, until I actually do some experiments? Yours is however a very intelligent system for all the reasons you suggested earlier.

Many thanks and yes, of course, you will be invited to the island as soon as it opens!

And now I have something to think about over the weekend


Mambo

I'm not sure if these have already been considered but I'd be interested in hearing a response. While I can understand the early post about leaving things open at all times, I heartily respect any sim that wants to be a little different. We need not all be identical.

That said...

1) I like the suggestion of staggered close times. It should help with lag, to be sure, but it's also more realistic. Stop by a real mall around closing time. Some will start closing their doors a few minutes early and others right on time.

2) Patrons/customers *in* the shops/clubs at closing time. What happens to them? Will they be locked in? Can you script it so that the store lights start to dim? (fill the room with a huge phantom cube and increase it's transparency a little) Can you turn off the dance-balls at dawn? The slots? Can shoppers who are already in the shop finish their transactions before they get tossed (as most RL stores will allow)?


When this gets done, I would *love* to see the finished sim.

What about a clock that sends an email to your web server. Use a PHP script to read the "status" and send commands using XML-RPC to each store to either open or close using keys from a database or hard coded into the script (depends on what you're comfortable with).

1 timer, 1 email. No listens or sensors needed. No script delays

When 1.9 is realeased, you can skip the email part and use HTTPRequest

Does anyone see a drawback to this?