![]() We won't go through general information about using debuggers here, you can find it elsewhere on the net. In general, OpenSimulator is a difficult system to debug due to its high concurrency, complexity and the lack of good tools for Mono on the Linux/Mac side. ![]() 4.2 Problems after connection established.I am not saying it is impossible, but any proper solution of this issue will not adhere to the KISS principle that should be the basis of any design.Īs for the question in the title: it seems spraying llOwnerSay over the code is the only way of debugging, if the term "debugging" is even applicable in this case. Neither do the events have knowledge about other events waiting in the queue, or can manipulate them. The problem is that all events have so little context at runtime that they must operate on global data structures, which is intrinsically dangerous in an event-driven concurrent environment (luckily the events are serialized in LSL but it is difficult enough). I have in fact implemented a reaction to a dataserver timeout in the timer event, but ultimately I will only print an abort message. ![]() However, it doen't quite explain the freezes I had experienced because the script should still react to touch events in the case of an outstanding dataserver event. Regarding timeouts: that also is a valid point. It now runs successfully with the given data volume. In the end I refactored the code to make the data structures smaller. Thanks for all the advice and suggestions. Transitioning between different states for each of these lists may make your debugging code easier to write and less error prone. If you couldn't fill the second list (by looping through the first list), then there'd be a problem with one of the keys, which one could be easily determined with a LLOwnerSay((string)keyInQuestion) being called each time through the "extended loop". ![]() That is, if you can't fill the first list with the avatar keys, then you'd know there's a problem with the notecard itself. This would make it easier to pin point exactly where/what was causing the hang up. Once you've isolated the problem line(s) (there may be more than one!), then you just need to identify what it is that causes the hang up.Īnother approach to this would be to split the strided list into three and attempt to fill each one at a time. To ascertain which, try removing the lines from the notecard before that point, removing the line itself and, finally, making a notecard containing just the line. It may be the line in the notecard itself, it may be in the key obtained from that line or it may be a coding error that is somehow stopping execution at that point. If you find the hang up happens in the same place each time it then becomes simply figuring out what is causing it. To correct that, add a timer of (say) 10 seconds that gets bumped up every time a data request is made and, if triggered, resends the last data request. If you find it hangs at a different place each time, you're failing to account for the possibility of lost data transmission. So, to see if the hang up occurs in the same place each time, add the line llOwnerSay((string) lastKeyObtained) directly before each llGetNotecardLine(), with lastKeyObtained being set as named. To debug this, you need to first determine if this hang up occurs in the same place each time and (if so) then figure out which of the three actions is hanging and why. Your problem is you have an extended loop with three actions it performs through each iteration and one of those actions at some point is hanging. If it's the data volume i could probably make the lists smaller by moving from key indices to integer indices, but I would really like to understand what is going on first.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |