Scripts ruined with update?

Has anyone had any scripts gone bad after this update?

I had someone make me a rental to door lock script a few days ago and it worked fine.( Then today I get on and notice peoples doors open (When they are scripted NOT to unless on access list) and peoples paid rent has been lost by 5 days.






Quadruple thumbs down, I assume this was the updates fault?

Or the guy gave you a bogus script..

I think one should be careful jumping on the "the updates broke this" bandwagon, without the appropriate research behind it. (Not a criticism, just my thoughts)


- d.

Well, since he stated that it worked before the update, we can rule out that it is a "bogus" script.

a few of my scriots went bananas after this last update..........infact it was lost.....asset server problem?!

The hypothetical script I just wrote that ceases functioning after 10 days so I can extort the (new) owner for more money (think licensing) would've worked fine before the update as well.. But maybe not after the update, depending on when the 10th day ended..

The original poster's script-knowledge-level might not be as high as you think.. It is of my opinion that if you have to outsource for a scripting gig, you don't understand scripting enough to verify that what you outsourced for, won't have any tricks in it..


- d.

I made the script, and I was honestly puzzeled to see that -5 days had been taken from the timer, how could this happen?

I had script problems not with the recent update but the one last week. A number of my scripts had crashed despite containing no expanding variables (e.g lists or strings) or having limits on list-size (e.g max 10 entries, no entry bigger than 64 characters, 8kb of free memory should be plenty there).
It was very annoying as I had to go into my transaction history, catalogue exactly what people had paid in recently and pay it back, add in the ability to reserve rooms so that when I reset them people would be able to get their room's control back without any further issue. Very annoying.

Hmm... that makes me wonder. I have a script that now and then ends up with a wierd timestamp value too. I never checked to see if it always happened after an update. But the most recent time it happened, was right after an update. Now I'll see if there's a pattern there in the future.

My project is multiple trains going round a track, so there's a 'gatekeeper' that tells the trains to stall for some time, if needed, to ensure even spacing between them. Every now and then the math goes wrong, and the train gets told to wait for 1 billion+ seconds. I've checked and re-checked zero rollovers, and I think I've covered the possibilities, but of course it could just be a bug in my script. But now I'm wondering if a timestamp call can return a bogus value sometime after an upgrade.

Well I'm not sure if this applies to the recent batch of updates, but I had a poll taking script at my store and I set the question/choices up about 2 months ago. I never had to touch it but it recorded votes just fine. Today, however, I went in to change the question out and reset the results, and it's not working. The script works -except- it's not actually writing in any of my options for choices. They all come up blank. sigh.

Naturally I bought this poll off of SLX and the guy who wrote it no longer plays the game, and isn't willing to allow me access into the code either, so doesn't look like this is a fixable thing for me. GAH

E

UNIX timestamps tend to wonder a little after an update. Maybe as much as two minutes in my tests, but 5 days?

I'd suspect a major mess somewhere in the script rather than the update specifically breaking it - although if there's a lot of reliance on xml-rpc the channels certainly used to be reset over an update, and maybe they still are? That might have broken it if there's a push data value for time?

It dosnt use UNIX time anywhere in it, it simply counts down.

Unless Timer events are knocked a little after an update ive been testing this for quite a while and havent been able to bring the same situation up again.

You were using a timer, and a counter? Thats crazy for long term transactions. On an update LL stores all assets on the sims back to the asset server, including scirpts. But to make sure things go nicely they probably increase the LSL clock frequency so that events that are yet to be processes do so before the check-in. Storing un-triggered events would take up alot of space. It would save LL GB to just run the events before check-in.

I think this is the right behavior.

A more sane approuch would be to use a timer and compare UNIX timestamps.

Can't speak for what Ginge is doing My script uses some combination of wallclock and Unix timestamp. I know I pulled in library functions from the Wiki to do math (i.e. diff) on the string timestamp format.

Anyway, not a big deal for me, because I have a simple solution. If I detect a crazy wait time, I have the train kill itself. Since trains can go off-world when attempting to cross over to an adjacent sim during an upgrade (probably because the adjacent sim is temporarily down), I have other code that detects missing trains and rezzes new ones, so that just kicks in and creates a new train.

:| *sigh*



Okay well, apparently LL *did* do something with the time because some transaction times were inaccurate as well.


I hope to get a script that is safe for the next update because i cant have this happen with every update- this is a 2 simd residential community that harvests in several hundred USD a month. "It`s serious business"

We are calling LL today to inquire, then we need a script that will survive an update.


I am happy ginge is very good with customer service. So ginge if the above is the problem and you could rewrite the script to function this other way mentioned that would be great- if thats what we need to do

I mean, this is no problem ill rewrite it. But why the hell is it not documented on the wiki or somewhere?

I`m just glad this was caught early lol