Jump to content

Profaitchikenz Haiku

Resident
  • Content Count

    519
  • Joined

  • Last visited

Community Reputation

265 Excellent

About Profaitchikenz Haiku

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. One other possibility is texture animation, make up a 512 by 512 texture divided into 16 frames, each frame has progressively more alpha, then use the smooth parameter. This will only work if you don't need a lot of fine detail, of course, but it's a good way of faking something like cobwebs fluttering or ghostly haze.
  2. Try llGetObjectDetails(, id, [OBJECT_OWNER]), if the id refers to an avatar, the returned key is the avatar UUID which is therefore the same as the id you passed in. So if the key differs, it can't be an avatar.
  3. You can only have one listen event, usually when several channels are anticipated the value of the channel parameter is checked for specific values. Since you have a specific channel your simplest option is then to look for the substring in the message using llGetSubString, and then use a set of ifs to look at what is following that substring and process them accordingly. An alternative is to have a list containing all the commands that follow "config:", and use llListFindList to find a match for the command, the resulting integer will be -1 (not found), or 0,1,2... and you can then process the command accordingly. If the sender of the messages will always be the same person or object, the LLlisten event when set up can be told to listen for messages from a specific name or specific uuid. (Qie beat me to it
  4. If you visit the LL download page now on a 64-bit linux machine it offers an I686 download. This then fails to initialise on a 64-bit linux system because it cannot find the libraries needed, which I am assuming will be 32-bit. The thread above gives more detail on the loss of 64-bit linux support and some comments on having to use 32-bit libraries to make the LL linux viewer run.
  5. The reason I queried was because the official LL viewed is only available for download as an i686 file. I've heard this is because of difficulty with some of the 64-bit libraries, and wondered if the TPV's offering 64-bit downloads were also having to fall back on 32-bit libraries. It might be worth you asking the Firestorm people if they can help?
  6. Are you using a 32-bit client for SecondLife in Linux, or 64-bit? My thoughts here are that a 32-bit system might not be able to properly use 6GB of video memory? From some ebay postings I have got the impression that some GT1050 cards are actually GT 520 cards with extra memory, just wondering if your GT1060 could be such? I have experienced something similar using Firestorm 64-bit in Lubuntu 18.04 with a GT1050, but unlike you I've also had it slow to a crawl and then crash to desktop in Linux after visiting several Opensim regions. On Windows 10 no problems. I tolerate Windows 10 but I have seen that CPU loading is 30-40% higher than on Windows 7 for the same regions (but not the same graphics card, see following). In my Windows 7 box I have had exactly as you describe in SL, crashing in regions with several avatars or lots of mesh buildings when I was using a GT 710 card with 1G Ram. I repaired my much older GT 520 512M card and put that back in and I no longer have any problems in SL (even to the point of attending the server user group meeting without jelly-dolling anybody), though I haven't used either OpenSIm or booted into Linux on that card. Yet.
  7. Yes, it's annoyed me for a while, but it isn't just the LL viewer does it. It does stop you shooting objects indavertently into adjacent regions though
  8. You can preload on as many faces as the prim has less one, so on a cut hollowed cube you will have faces 0 to 7 to play with. Make a small script that you drop in a prim that tells you what face number was touched using llDetectedTouchFace() so that you know which face is which, and assign these numbers to integer variables at the head of your script. Preloading a texture is exactly the same as showing it, except that it hasn't happened before (That's just reminded me of a Robin Hitchcock song). There is, however, a complication to consider in the values of the prev, This and next variables because none of them must go outside the valid range of textures found in the prim. Set the count of textures numTex as already done in your snippet. integer maxTex = ... integer this = 0 integer prev integer next Inside a function which you will be calling regularly set prev to this - 1 BUT if it is less than 0, then it must be adjusted to the number of textures -1 set next to this + 1 BUT if it is equal to or greater than the count of textures set it to 0 On your main face you show texture number (this). on the face you chose for the previous texture, show texture number (prev), and on the face chose for the next texture, show texture number (next). When you adjust the number of the texture to be shown by either incrementing or decrementing it, you have to first adjust it if it is outside the valid range, then you calculate new values for prev and next and likewise adjust them.
  9. Will it not work if you don't specify an actual animation to be played but rely on the sitter's AO to pose them properly? (Not that many of the seated poses can actually be described as 'prim and proper') The scripting is not actually very complex, it requires a knowledge of using llGetLinkPrimitiveparams, llSetLinkPrimitiveparamsFast, and lists.
  10. You can still sit several avatars on a single prim even with a sit-target defined. Each time an avatar sits on the prim they will initially get assigned to the default sitpos. You then interrogate the children in the linkset, any child with a number greater than 1 is an avatar sitting on the prim, and by interrogating their local pos and rot you can then determine if they have just arrived on the link target or are an already-seated avatar. For the newly-arrived avatar, adjust their local pos and rot to move them to where you wish them to appear to be on the object. I find keeping a list of UUIDs together with local pos and rot is actually better for implementation but obviously harder to set up first of all. I'm not sure what your dislike of the Casper Simple Sit is, are you saying it will only remember the positions of the last six avatars it seated? Unless you're hosting banquets six on a prim seems acceptable.
  11. I get some deja-vu here from past experiences when software I was working on was shifted from 16-bit to 32-bit systems, and sometimes actually performed slower on the new and supposedly superior platforms. In the end we learned what to do to get things running again. (And the Ariane rocket program also learned about integer rollaround taking far far longer when twice as many bits were involved
  12. This was my experience exactly, in February the train on my parcel was juddering along, there had been no gradual deterioration or any warnings that things were deteriorating. I am concerned that this has been given so little attention by the Lindens who attend the server user group meeting. (Or they actually know full well what was the reason but for various reasons cannot discuss it with us). My worry is that it is a step-change that cannot be reversed, such as shifting to different servers, so the challenge now is to find a way to restore performance on a new and relatively unknown system.
  13. Agreed. But what Animats and some others are pointing out is that 'pointless' scripts consume far too much resource, these are idle scripts, prims with a particle-setting script or sitpos script still in them, scripts with event-handlers for events they will never receive. There needs to be some mechanism to avoid them consuming resources.
  14. There is a Russian plane?? that uses ground-effect exclusively on water, it never flies above a few metres, I can't recall the name of it now but it was something like dragon. A seaplane in SL could end up getting very complicated if you tried to replicate all the physics, I have a feeling that the simplest solution is to treat it as a fast-moving balloon.
  15. It won't help you find this particular prim but for future use, whenever you rez a new prim, the first thing to do is change the name from Object to something more appropriate for your particular build, it makes it so much easier to find when you do what you (and thousands of us) just did. Area search can return a frightening number of "Objects" all over the place.
×
×
  • Create New...