Jump to content

animats

Resident
  • Content Count

    2,564
  • Joined

  • Last visited

Posts posted by animats


  1. New Babbage has an official winter season, and residents there are expected to provide snow. In spring, the Clockwinder announces the end of winter, and you have a week to make your snow go away. The look is quite nice, because it's consistent. Do any of the big private landlords have a similar seasonal theme?

    Bellesaria, though, doesn't have seasons that organized.

    A compromise might be some snow on the roof and some piles of shoveled snow around the property. Heavy snow right up to the property line, though, does look a little off.

    Now if you could talk a whole block into going in for a snow theme...

    • Like 3

  2. 12 hours ago, unknown7 said:

    Has anyone seen those mods on SFV where they fit the girls with new clothes?  The skirts and dresses look awesome and move like real clothes.  If SFV can do it, then there must be a way to make clothes like that in Second Life.  Here's an example of what I'm talking about: Street Fighter V AE Karin vs Poison PC Mod.  Mesh clothes in SL move like tinfoil, while flexi is broken up into segments which make them look unreal.  Clothes here would look so much better if the cloth physics were more accurate.  I'm sure designers and merchants would benefit as well.  

    The cloth physics there is good. The transitions between the moves in SFV are as bad as they were in the original. That must be a stylistic decision; it doesn't have to be that bad any more.

    It's much easier to have elaborate graphics in a game with only two hero characters always in the foreground. You know what the worst case graphics load is.

    SL's big problem with avatar rendering is that avatars are almost always in hero mode, even when they're far away. Avatars do have levels of detail,  but the lower levels are usually awful and the viewer doesn't push them down to lower LODs much. Also, all parts of an avatar are normally at the same LOD, so that elaborate jewelry with filigree and engraving doesn't drop to a lower LOD when you're not looking at it in super close up. If SL could drop 20,000 triangle shoes to 200 triangles at 5 meters range, that would help a lot. Looking forward to progress from Project Arctan in this area.


  3. 9 hours ago, SwireD said:

    Thank you very much! I managed to create such a script. works almost - after passing the entire circle, the object stops at one point for 3 seconds. How to avoid it? and also if I add on/off toggle then after stop/start the path breaks and the objects begin to move along a different trajectory. Is it possible to keep the path? and the only way to get all the platforms to rotate along one trajectory for me was possible only by placing all the platforms at one point and adding a llSleep() for each subsequent platform with magnification.

    
    default
    {
        state_entry()
        {
            llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX]);
            llSetKeyframedMotion([<0,0,0>, 3, <1.5,3.5,0>, 3, <3.5,1.5,0>, 3, <3.5,-1.5,0>, 3, <1.5,-3.5,0>, 3, <-1.5,-3.5,0>, 3, <-3.5,-1.5,0>, 3, <-3.5,1.5,0>, 3, <-1.5,3.5,0>, 3 ], [KFM_DATA, KFM_TRANSLATION, KFM_MODE, KFM_LOOP]);
        }
    }

     

    That looks incorrect. The list for keyframed motion is "relative position, relative rotation, time delay" by default. If you want position only, you have to provide KFM_DATA, KFM_TRANSLATION in the modes. And the PRIM_PHYSICS_SHAPE_TYPE info is obsolete; that was for pre-mesh viewers.

    It stops at the end for 3 seconds because you told it to stop at the end for 3 seconds. Change that last time to 0.100 second.

    KFM_LOOP is kind of interesting. It doesn't just do all the steps again. It instantaneously moves the object back to the starting position and runs the steps again. This has its uses; I use it in my escalators.

    • Thanks 1

  4. This looks like it was a fairly routine network outage at a data center. Big data centers are usually tied to several of the backbone Internet providers, and can switch if they have to, but apparently SL does not do this automatically. Routing changes can take a while to propagate as all the players come into agreement on the new routing. For a web site, that just means a few retries and a slow page load. LL has to be more cautious than web site operators -  30 seconds of connectivity loss and everyone is kicked out of the world.

    4 hours ago, Bree Giffen said:

    From what little I am aware of, the problem was because LL bought "SL" from a vendor and it came in a box.

    No, Linden Lab people coded and maintain Second Life. If you go to Server User Group, Viewer User Group, or Creator User Group, you can talk to the people who maintain it.

    • Like 2

  5. npcsystem.png.405c34af428e9dead9464648dfb2347e.png

    With enough 64K programs...

    The end result uses about 3x as much memory as one big program, took about 4x as long to write and debug, and is slower. About a quarter of each program consists of the code to communicate with the other programs.

    I'd really like to be able to get more script memory, even if it cost some land impact. Doing it this way is just too hard.

     


  6. Or, notes on doing a large problem in too many little scripts.

    I've been coding an NPC system to replace SL pathfinding. It's mostly working at this point. Some things I've learned.

    Measuring memory

    Filling the 64K memory space for a script produces a "stack-heap collision" error. So it's useful to know how much you have left. llGetFreeMemory() is helpful but will be an underestimate until after a garbage collection. So the following snippet of code may be useful:

    //
    //  needmem -- need at least this much free memory. Return TRUE if tight on memory.
    //
    integer needmem(integer minfree)
    {
        integer freemem = llGetFreeMemory();                // free memory left
        if (freemem < minfree)                              // tight, but a GC might help.
        {   
            integer memlimit = llGetMemoryLimit();          // how much are we allowed?
            llSetMemoryLimit(memlimit-1);                   // reduce by 1 to force GC
            llSetMemoryLimit(memlimit);                     // set it back
            freemem = llGetFreeMemory();                    // get free memory left after GC, hopefully larger.
        }
        if (freemem < minfree)                              // if still too little memory
        {   
            return(TRUE);
        }
        return(FALSE);                                      // no problem
    }  

    This will reliably tell you if you're running low on memory, without forcing too many unneeded garbage collections. Keeping about 3000-4000 bytes free at the place where the program uses the most memory is a good idea. Remember that you always need enough free space for the biggest link message anyone can send you.

    Link messages

    Link messages are how multiple scripts talk to each other. They go into the event queue with other events for the script, and there's a limit of 64 events on the event queue. More than that, and events are "silently dropped". So scripts can't be busy for too long, or their event queue will fill up. Big jobs may have to be divided into incremental steps run from a timer event. This would be much easier if LSL had objects.

    Again, you get the link messages from everything in your prim, whether you want them or not. Remember that lists are copied when passed as a function parameter, so discard the irrelevant ones in the link message event before doubling their size with a function call.

    Packaging up data as JSON is useful. LSL has built in JSON marshaling, so you don't have to parse anything character by character.

    llMessageLinked(LINK_THIS, PATHPLANPREPPED, llList2Json(JSON_OBJECT,
                    ["target",gPathprepTarget,"points", llList2Json(JSON_ARRAY,pts)]),"");

    The llList2Json function does all the type conversions for you, and handles all escape characters needed. Note that the array of vectors, pts, is automatically converted to a JSON array.
     

        link_message(integer status, integer num, string jsonstr, key id)
        {   if (num == PATHPLANPREPPED)                                     // if request for a planning job
            {   key target = (key)llJsonGetValue(jsonstr,["target"]);  // get target if pursue
                list points = llJson2List(llJsonGetValue(jsonstr,["points"]));     // the preprocessed static path points
                integer len = llGetListLength(points);
                integer i;
                list gpts;                                             // points as a list of vectors
                for (i=0; i<len; i++) { gPts += (vector)llList2String(points,i);}   // convert to list of vectors
                ...

    Here's the receive side. llJsonGetValue will extract one value from the JSON string. That value comes in as a string, and has to be cast to the desired type. JSON arrays come out as a list of strings, and each value has to be converted to the desired type. That's what the FOR loop is doing. This is kind of clunky, but at least you're not parsing strings in LSL.

    • Thanks 2

  7. On 10/27/2019 at 9:48 PM, LittleMe Jewell said:

    I took a look - here's a screenshot.  They were all moving around except for Salli - circled in the pic.

    Thanks. Power back on, internet connection back on, out of hotel. Three of my RL friends in rural areas are still running on generators, but none of them had to evacuate this year.

    Fixed Salli's problem The NPCs are now working well enough that it takes a day or two of testing to find the next bug.

    • Like 1

  8. I wonder if this is related to the bug in llRotBetween. The math there is slightly off for rotations close to 180 degrees. This is documented on the wiki. I've run into this; the error is big enough to put an object at the high-coordinate end of a sim out of position by as much as 0.020m. It's not just roundoff error; that's only about one part in a million, or about 0.0003m. (24-bit floating point, remember. Also, it gets worse for large Z values.)

    If something internal is using the same code...

    • Like 2

  9. The swim problem is kind of sad. A few weeks ago I was in Bay City, and a one-day old couple were trying to use a kayak in the Bay City canals. That's a nice way to go around SL. They were having a terrible time with control, though, and kept hitting the walls. The kayak had them doing a paddle animation, but with no paddles, probably because they didn't know how to attach them.

    Then one of the couple gave up, and stood. She then sank to the bottom of the canal and couldn't get out. I watched her struggle for a while, and then I IM'd "push PAGE UP". So she did, flew upward, hit the underside of a bridge, and couldn't maneuver out of there because she was now trapped by the bridge girders. Finally she got out, but not gracefully.

    This is when you realize that the SL defaults for new users could be better. Maybe the default AO should include swimming. And the Bay City canals should have stairs or a walkway along the sides, like real urban canals usually do. There really is no realistic way to get out of that situation, and that's bad game design.

    • Like 3

  10. 10 minutes ago, Rhonda Huntress said:

    Surviving

    I feel like that today. I live in Silicon Valley and we lost power, probably for a week. I'm OK, but in a hotel with limited Internet access on a low end subnotebook. So I can't go in world. My NPCs have to go on without me. You can check on how they're doing at the Animats workshop in Vallone.. My NPCs IM me for major problems, and Kathi phoned home to report a bug. She should be in the obstacle course with three other NPCs. If someone would post a picture from there, I'd appreciate it


  11. I've backed off to Firestorm 6.2.4, but that's because FS broke the "Stop" feature for region crossings.

    I tried driving around the dirt roads of Bellesaria with a big truck with FS 6.3.2. The roads are not flat, and you roll some. Then, at a region crossing, you roll so bad you think you're going to roll over and try to steer out of it. Then you overcorrect. This is not fun.


  12. On 9/28/2019 at 8:17 PM, animats said:

    The new trailer area from Wilderness Point south is very nice. Isolated, though. It could use road connections to the rest of Bellesaria. There seem to be planned points for the connections.

    wildernesspointfuturebridge.thumb.jpg.7264de843269cc0c194d7f8d204faa18.jpg

    End of the road. Wilderness Point, looking west to SSPE228. Looks like a future bridge site.

     

    wildernesspointbridge.thumb.jpg.97f90bf92000c652998c7e5382b5f660.jpg

    Now there's a bridge at Wilderness Point. (Still under construction; it needs a support prim at the region crossing; you fall through.)

     

    On 9/28/2019 at 8:17 PM, animats said:

    On the southwest side, the traditional road system and the trailer area path network both dead end into SSPE281.

    sspe281connection.thumb.jpg.80c8f379330c3624e6e8422c69cabbea.jpg

    Ready to connect. SSPE281.

    Looking forward to being able to drive all the new areas without off-roading.

    That connection hasn't been made yet. SSPE281 is still vacant.

     

    ssp194connection.thumb.jpg.c71adc737721ee06d7f0e47b396fa8b2.jpg

    Paved road to dirt road connection, SSPE194.

    There are connections between the paved road and dirt road systems in enough places to allow driving around.

    drivingintrailerarea1.thumb.jpg.dab5ac848d3c0c3622c5d1f3ae9fa00b.jpg

    The dirt roads are quite driveable. Drove this around for about fifteen minutes without problems. This is about as big a vehicle as can be driven comfortably there, because of the sharp turns. Motorcycles were easy. A dirt bike, a Jeep, or a short-bed pickup should work fine. Enjoy.

    • Like 7
    • Thanks 1

  13. 21 minutes ago, Apollo7000 said:

    but flying from SNO to Hollywood in the Bingo Strait, I received a message when crossing the same sims I have crossed countless times something like " Your xxxx(plane) is not allowed on the xxxxx region/sim and has been returned by Governor Linden" 

    I just tried flying around there.

    barbarossa2.thumb.jpg.3050cecdcf836e30954d246e032e7fab.jpg

    Over the Bingo Strait at Barbarossa. No problems with the little Duoquito, and the blue helicopter on the right seemed to be doing fine. I was able to land and hear voice chat (there's an info hub there), take off again, and enter and exit that sim from all four sides without problems. Spent about fifteen minutes flying around the area, visiting about 20 sims. No problems.

    I'm quite critical of region crossing problems, as is well known, but I'm not seeing them here.

    • Like 1

  14. OK. I just removed my free motorcycle rezzer, installed the day Bellesaria opened, to be fully compliant. Back then, there were no rez zones and no way to get around, so it was needed and used. Now there are enough rez zones.

    • Confused 2

  15. Part of the idea of Project Arctan is to get people to care more about their avatar render cost. How to make this work without breaking existing content is a regular subject of discussion at Creator User Group. Vir Linden is gathering more data. There's no consensus.

    The viewer has the power to render an avatar at any level of detail, as an impostor, or as a jelly doll. How it should use that power is a big question.

    How do most avatars and clothing look at "medium" LOD? Acceptable as background characters? Maybe the viewer should be dropping avatars to a lower LOD or to impostor mode sooner. This beats dropping the frame rate to single digits. One approach would be that avatars only go to "high" LOD when in hero mode; close to the viewer and occupying lots of screen space. There's nothing wrong with high-detail avatars provided that only one or two are in that mode at a time. What we don't have now for avatars are good intermediate stages between "insanely complex" and "jellydoll".

    I'm very aware of this because I do standalone animesh characters. Those have a high LI cost and object-type LOD handling, so they have to be efficient or they blow the parcel's LI budget. They also have to look good at lower levels of detail, because they're often shown that way. I'd like to see the "medium" level for avis be around the complexity level of a good animesh character - 20,000 tris or so.

    (You can look at things at a lower LOD by opening the Firestorm menu and setting the LOD setting to some very low value. It's instructive to set it to zero and see what's still visible.)

     


  16. 21 hours ago, Therese Tammas said:

    @animats my house on Alloy has river (if you can get down the cliff) and road access. I've struggled with it and ended up hiring a "pro" decorator to help me solve the cliff problem. Stay tuned for pics for that. I am hoping it will be magical!

    That's when you need a pro architect.

    Fallingwater%20in%20the%20Fall.jpg

    Frank Lloyd Wright's Fallingwater.

    Custom designed for the site, of course. One of the most famous houses in such a location. Gives a good idea of how to layer levels to fit terrain. A combination of glassed in levels with balconies on stone supports can fit most hills.

     


  17. 4 hours ago, Fenix Eldritch said:

    This is kinda a kludge, but if you have Copy/Trans permissions on the animation asset, could you send a copy to the NPC via llGiveInventory (along with a chat of the asset's name) ? When the NPC receives the inventory item and name, it can then operate on its own local copy and discard when finished.

    Now that's a good idea. The animesh will need to enable llAllowInventoryDrop. The animesh sends a message to a sittable object that it wants to sit there. The sittable object replies with a sit target, an animation name, and uses llGiveInventory to give the animesh a copy of the animation. The animesh gets a "changed" event with the CHANGED_ALLOWED_DROP flag. Then it has to examine its inventory for new stuff, possibly discarding any unwanted new items. It finds the new anim. It moves to the sit target. It plays the new animation. Now it's sitting on the sit target with the proper animation. Right.

    You don't get the link of a real sit, so it won't work for vehicles. But it's enough for the basics. Thanks.


  18. 8 hours ago, Mollymews said:

    i get what you are saying from a builder's perspective

    if there were to be a change, I think that rather than LL coding up a workaround for what I think is an intermediary situation looking for a temporary fix, when I think also it would be more useful to builders for LL to spend the time working on a animesh sit  (link/unlink to an inworld object) in the same way avatars do  

    Animesh sitting is going to require some cooperation between the animesh and the sittable object. It's not likely to work on existing sittable objects. There's no "Sit" cursor, and animesh can't answer dialogs. It's also a big job for the LL devs, and they're overloaded. If LL wants to take this on, that would be nice, but it seems unlikely right now.

    However, if we had minimal support in LSL, which is what I'm asking for here, open-source AVSitter and similar code could be modified to use it. Then anything which uses an updated AVSitter could accept animesh. Someone has already done something like this as a mod to AVSitter, but the sit animations have to be in the animesh. So it's a short step to making it work in a general way.


  19. When an avatar sits on an object, it becomes part of the object's linkset, and the object can apply animations to it. Animesh can't "sit". So they lack a way to get access to and run a sittable object's animations.

    So, a proposal:

    If an animation has Copy/Mod/Trans permissions, then llGetInventoryKey will return its UUID. But there's not much you can do with that UUID,a as far as I know. With a texture, if you have the UUID, you can set that UUID as a texture anywhere in SL. But for animations, llStartObjectAnimation only accepts a name in the object's inventory. It does not accept a UUID.

    So, what if it did accept a UUID, the way llSetTexture does? Then an animesh and a sittable object could communicate; the sittable object could tell the animesh what animations to run.

    The question is, are there major security objections to this? llStartObjectAnimation only works for animesh, so this doesn't let avatars do anything new.

    My interest is in animesh NPCs. I'm trying to get them to do more of the things avatars can do. They can't sit. With a cooperating script in a sittable object, and this minor change, we can make that possible. Comments?

     

    • Like 1

  20. Some of the problems with mainland builds could be helped with a class, perhaps at Builders' Brewery, on "how to build in difficult terrain". Topics such as:

    • How to build on hills. Most prefab SL buildings are for flat ground. Putting them on hills is usually done either with terraforming or with some huge blockish slab underneath. Some examples of best practices would be helpful.
    • How to connect to a Linden road. This is often hard to do neatly. Some roads have rocks or high curbs or jaggy parcel boundaries. Linden advice on allowable encroachments would help. Sometimes you just have to reach a bit beyond your parcel to make the connection work. Such work needs to look like it belongs there. This is especially important for GTFO hubs, because they will have truck traffic. For the hard cases, it should be possible to pay for mole work and get a curb cut.
    • How to clean up terraforming messes. Where the original moles built rolling terrain, parcel owners have often flattened their lots. A few generations of ownership later, each parcel is flat, at a different level from its neighbors, and there's a cliff at the edge of each parcel. Much abandoned land looks like that.

    If someone good at this gives such a class, I'll go.

    • Like 5
×
×
  • Create New...