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.