Lilly Kiyori

After reading the first page of this thread, I was silently sobbing and asking myself why nobody told animats yet that it all is because he had the wrong thing for dinner.

Did that, but the support decided to send me down a different route: "As a troubleshooting step can you please try the following: Go to Advanced > Show Develop Menu, then Develop > Avatar > Character Tests > Test Male or Test Female. This should turn you back into a normal default avatar. If the issue persists while your avatar is a default avatar please let us know." I'm sitting here having to push my chin back up repeatedly while reading. With some troubleshooting requests ... a little bit more explanation about the purpose of the test would be neat. This does feel like a homeopathic treatment

I'm mostly surprised by what that application does when it is lowered or "in the background" and shouldn't have to render anything..

I am quite affirmative that a big part of the solution is to tell Google Chrome to stay off the GPU that the game client is on. Not just memory-wise Google Chrome appears to have a tendency to think it is alone on the machine (I think they call that "grabbing whatever resource is left is good for efficiency"). They just forget to let it go so others can use it too.

I am suffering from that weirdness myself particularly during connect phase. I sometimes have to connect a couple of times, or do something idiotic like clear the caches just to force some timing changes during the first seconds after connecting. Otherwise my avi just gets stuck in place, I can turn (client side), but not move and time out after a minute or something. Sometimes it sucks to connect from Europe, because with 180ms signal travel time you're constantly at the "beware pings over 200 are troublesome" limit. It's standard case for me, and that makes anything that needs a handshake a bloody pain (talk about having 50 objects in an inventory, good night). But I still would rather have some graceful handling of that on the UDP connection, like the server saying "this person is from a galaxy far, far away, I need to handle the gawddam timeouts differently". If Layer3 and 4 don't do it for you, the client-server communication has to take care of it. I mean .. if two morse code amateur radioists write at each other, and one side doesn't hear anything in a while, or gets something that is far off, then the other side says 'please repeat everything after ...'. But if Monty has to lowly sob when looking at the UDP code, two morsecodeists may be more reliable ...

I rather have an occasional UDP packet hickup than stalled TCP connections piling up

As soon as my ping times come down to around 200ms-ish, and the cache hit rate is constantly at 100%, the fps climb to like 50. I'll try another RAM chip next week.

On second thought ... the swap values are high at times. But I don't see that translated in disk activity. This gets weirder and weirder.

Hi guys, it's Silly Lilly again 🙂 Right now I'm chasing a weird frame rate issue. I have limited my graphics frame rate client side to 20fps, because I mostly don't want my fans to go nuts when everything goes fine. In my quarter sim (in which I am aware I am not alone), however, I experience drops down to like 9-13 FPS-ish (as registered by my client). The point is ... I have not the slightest clue how this happens. I have collected and attached a couple of statistics, and mostly cannot find anything wrong there. The server side FPS are fine, there is ample spare time, the graphics card doesn't appear to be at its limit whatsoever ... Maybe somebody of you can find something that looks suspicious. The only thing that I can find is that I have somewhat large ping times to the server (which occasionally provides me with reconnect problems, avi gets stuck). Standing at the same spot, facing the same direction, however, I've already also seen frame rates that are much higher (see attached). I'm not wearing any HUDs. The draw distance is limited to 96m. What bugs the hell out of meis the variabiltiy of it, when I don't see anything in the values that actually varies, except the apparent display. Walking around is stuttery because of the high ping times, but moving the camera with alt-mouse feels quite smooth. Is it just firestorm that's playing a trick with me here? Best Lilly

There really must have something gone wrong, as it did not make much sense to me either. Now that I do it again, it comes down to 0.720. Maybe I analysed the original model instead of the 2 prim physics after having played around with too many versions.

Well. It fixed it, but the resulting object hilarously has a LI of 17, considerably more than the prims. For a stupid row of windows, just because the server thinks "small" is one-dimensional. Adding a Linkset of two transparent prims to do the physics manually over the original object which is set phantom appears to be the solution with the smallest footprint, which - honestly - is a shame, just because the uploader has a one-dimensional virtual brain.

Thanks all. Analysing the physics worked fine and fits the purpose in this case. I will check adding in a small 3rd dimension on an additional surface that can be made transparent at a later time. That may be interesting for some places where there's space so it doesn't get in the way. But as you wrote above: if you don't know this you're just puzzled, and even doing a little bit of search I didn't find the proper postings. Perhaps because there are just too many postings out there that say "switch to prim", and at some point you just think "yea, I read that.", but don't really have better terms to narrow the search down until you already know what's wrong. Thanks for that warning message, that sure helps.

Hi all, I've recently tried to upload a simple mesh that was done with Mesh Generator (for convenience, I've done models with Blender in the past). But I'm currently stunned because of a weird problem. It's a simple row of windows on a mount with an opening for a door. I've made a separate physics model. When I upload the model and the physics, it shows perfectly well in the preview window. The physics is where it is supposed to be. Then I upload it, set it to prim, but the physics all of a sudden has become solid. Why does it behave differently inworld than in the preview? What is firestorm's checker doing well what second life is doing bad? I'm at a loss here ... Best Lilly

Same behaviour if I wrap the names in the llStopAnimation calls with llGetInvontoryKey().

Well, this is the most awkward workaround I have yet coded, it looks ugly (because the avi starts to assume the root position), and it is a blatant race condition, but it's the only thing I see that can be done right now. I've made a small hack into [AV]sitA. If there already was a sitter on this script id and the pose is known, this restarts the animation without popping the menu back at the user. Unfortunately, 90075 does that, and I didn't find another link message that did. integer RestartOnly = FALSE; .... default { ... link_message(integer sender, integer num, string msg, key id) { ... if (num == 99998) { if(MY_SITTER != NULL_KEY && MY_SITTER == id) { RestartOnly = TRUE; llRequestPermissions(MY_SITTER, PERMISSION_TRIGGER_ANIMATION); } return; } ... } --- run_time_permissions(integer perm) { ... else if (!MTYPE) { ... else { if(RestartOnly) RestartOnly = FALSE; else llMessageLinked(LINK_SET, 90005, (string)animation_menu_function, llDumpList2String([CONTROLLER, MY_SITTER], "|")); // 90005=send menu to user } --- } } } } A second small script listens in the same prim as the [AV]sitA scripts, and relays any detached message: integer BraindeathChannel = -66996690; integer Listen = -1; string AKey = ""; default { state_entry() { Listen = llListen(BraindeathChannel, "", NULL_KEY, ""); } listen(integer channel, string name, key id, string message) { AKey = message; llSetTimerEvent(1); } timer() { llMessageLinked(LINK_THIS, 99998, "", AKey); llSetTimerEvent(0); } } On detach, the glasses broadcast their holder's UUID on that braindeath channel. All [AV]sitA X scripts get a linked message by the second script that prompts them to see whether they have the avi seated that just detached something, and if yes they restart the current animation. That's the minimally invasive hack I could come up with. It still sucks when the original position of the animations is far from the adjusted position, because for example the AVIs start floating in the air and then get pushed back down, but at least nothing breaks to the point that the user has to stand up and sit down again or do an annoying manual interaction.

Probably, yes. It's a huge bug that has apparently been ignored for almost 4 years now. It makes even halfways basic functionalities that involve animations impossible. You can't even have a sitting avi pick up and drop an object that comes with an animation without the sit to break. It's plain nuts that this isn't being fixed. It's like selling a car, but when you take in food at the drive-in the tyres go flat. I currently can't imagine a productive way to work around this, except that all wine glasses have to somehow broadcast to all seats on detach, where a script somehow tries to get AVsitter to restart the current animation. Which would be sort of a big pain.

I'm not aware of a way to start animations via UUID. Can you enlighten me? Best, Lilly

I've just had this problem with one of the lelutka default shapes. What's an eye setup for when all it really works with is one particular slider setting so the eyes don't pop out? One should be able to adjust the sliders for style. If everybdy walks out with 3cm thick lids ... what's the rigging for?

This breaks with Firestorm, Catznip, and the SL viewer (current versions).

I've also seen it break in the attach phase, as llStartAnimation() in the glass magically makes the sitter's animation disappear (at least in an AVsitter case).

I have a very weird problem that I'm trying to hunt down. I have created wine glasses that can be "picked up" from the table by clicking it. Basically there's a giver on the table that looks like the glass. If you click the glass on the table, it rezzes the glass from inside. The giver and the glass communicate with each other. If you press the giver a second time, the glass gets a message to detach. As both look the same you get the impression that you can by clicking the same spot pick the glass up and put it back down again. Case 1: The glass has a code to play a holding animation when attached, and to stop playing that animation when it gets detached. I can stand in the room, and click the glass, picking it up and putting it down over and over. No problems whatsoever. The animations start and stop as they are supposed to. Case 2: Now I do the same when sitting on a prim. Again, I can click the glass over and over again, everything is fine. Case 3: I do it again when sitting on a prim, but the prim loops a sitting animation when the avi is sitting down. When I then start clicking the glass, things go down south fast. At some point, pretty randomly, the llStopAnimation of my glass will cause the sitting animation of the prim to disappear. It's called by name in the llStopAnimation call, and the glass knows nothing about the sitting animation. It appears like the llStopAnimation sometimes stops the wrong animation when an avatar is sitting on a prim, and the prim has a looped animation playing. I wanted to blame it on AVsitter first, but then decided to make a small sitter script that launches the animation. It still breaks. This is the sitter script: Here's the only part of the code of the glass that handles animations: Notes: CalledFromListen: Means that the glass has received a message that requested it to report its status and detach itself (the giver has been clicked while the glass was attached). That code then calls llRequestPermission(PERMISSION_ATTACH), and in turn I call llDetachFromAvatar() after having the permission. CalledFromDetach: attach(0) called llRequestPermission(PERMISSION_TRIGGER_ANIMATION), stop the animations that we started CalledFromAttach: attach(>0) called llRequestPermission(PERMISSION_TRIGGER_ANIMATION), start the holding animation CalledFromSip: sipping subroutine called llRequestPermission(PERMISSION_TRIGGER_ANIMATION), trigger the sipping animation. clearCallStats() simply sets those CalledFrom* back to FALSE. No other place in the code of the script has any llStartAnimation() or llStopAnimation() call, they are only started or stopped from within run_time_permissions. I have to add that this behaviour is not 100% predictable. I'd say on average 2 out or 3 times the code works exactly how it is supposed to, and the sitting animation remains functional. So I'm quite at a loss here. The attached screenshots demonstrate the behaviour. (And forgive the awkward looks of the avi, I detached everything else that may start animations so the debug output animation list is easier to read. 🙂)