Jump to content

Why has LSL after all these years not sorted their arrant stupid code logic?


steph Arnott
 Share

You are about to reply to a thread that has been inactive for 1923 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

2 minutes ago, Estelle Pienaar said:

OK, then it was a misunderstanding. The title "Why has LSL after all these years not sorted their arrant stupid code logic?" made me understand something different (a flaw at the core of the concept of LSL) than what you meant.

Can you shortly tell us how the problem has been sorted? I haven't seen a solution in this thread or in the "Inter sim catchup". And now I am curious.  🙂

The script captures all the info into a strided list on entry and then it does a comparison from each stride. It has to do four. That comparision ended up haveing to be done a specific order due to the timer and animation event. The script is seperated from the rezzer script due to code conflicts. The  "Inter sim catchup". was because the script was lagging behind getting the info, that is not now the case. All the info needs grabbing before testing and not tested one after the other by getting information in each test.

  • Like 1
Link to comment
Share on other sites

  • Moderators

Say you know scripting
or recognize my glitch

Say that LLTakeControl()
Runs before it's switched

Knee deep in the hoopla,
sinking into fights

Too many forum posts
Eating up the night

You can file a Jira
Or troubleshoot with those helpful
But don't you remember
You build your rezzer
You build your rezzer with LSL

We built this rezzer
We built this rezzer on L S L
Built this rezzer
We built this rezzer on L S L

It took us quite a while to get to the topic at hand, so this thread has been heavily curated. It's now only playing the Greatest Hits, so it gets right to the meat of the issue.

So rock on, and remember to keep this thread civil and on topic, else we'll need to break up the band and cancel this tour

-Jagixson StarLinden

 

  • Like 3
  • Thanks 7
  • Haha 5
Link to comment
Share on other sites

On 1/26/2019 at 3:14 AM, Love Zhaoying said:

Gee..maybe the solution is to just wait a specified amount of time after the changed (teleport) event. What say ye to that?

This is one of the big frustrations of LSL. Many of the requests start an operation to be completed at a later time. The operation might not complete at all, or may take a while. You have to check back later. The language doesn't have much support for "later" - there is no support for callbacks, promises, futures, or async events. The timer mechanism is very limited. From dataserver requests to permission requests, finding out that something didn't happen requires extra work.

Pathfinding is especially difficult in this way. Pathfinding operations can take any length of time. There's supposed to be an event delivered when a pathfinding request finishes or fails, but in practice, those events fail to show up for many errors. You have to check frequently for "are we stuck", "are we someplace we're not supposed to be", and even "are we just ditzing around but getting nowhere?" I've submitted two bug reports; this works worse than it should.

Programmers who've coded software that's connected to real-world hardware, such as machine control, robotics, or device drivers, are familiar with this sort of thing. You write lots of state machines and timers, and code in a paranoid style. You write more code for the error cases than for the main case. Sometimes you have to write LSL that way. It's not really much fun, but it is possible.

Link to comment
Share on other sites

In cases like this, why not set a global variable to show an event is expected, and in a tight timer, count down and either cancel the timer and reset the global when the event succeeds, or else when the timer count decrements to zero. try a second time to request permissions or make the vent get queued? I admit I have not had to handle the teleport issues but I have had this sport of thing with slow-moving trains and boats where moving_end was supposed to occur but sometimes didn't, and that's exactly how I worked around it.

Link to comment
Share on other sites

@animats , @Profaitchikenz Haiku 

The issue being described isn't that an event doesn't happen, but that the event is supposedly interrupted prematurely mid-event or "from the event queue." Steph explains this in her second post in this thread.

But there is no way to inspect the event queue in LSL, so she must have noticed that it does trigger, but doesn't pass her conditional.

Qie and I have already provided code to demonstrate that it can be tested, but nobody has managed to replicate the "broken event" Steph is talking about. 

Edited by Wulfie Reanimator
Whoopsie
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1923 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...