Jump to content

Lucia Nightfire

Resident
  • Posts

    3,471
  • Joined

Posts posted by Lucia Nightfire

  1. 1 hour ago, Ardy Lay said:

    And this line of thinking is what brought us Viewer 2.  Do not forget that Viewer 2 was what happened when Linden Lab hired outside design and development companies to "update" the viewer user interface.

    80/20 Studio

    Product Engine

    Focus groups that are NOT familiar with Second Life determined what was and was not needed by Second Life Residents.

    User interface was rearranged to try to make it familiar to the focus group participants.

    UI Visual aspects and in-world highlighting were changed to resemble games the people had played.

    The importance of text chat was lowered relegated to something that resembled MS Comic Chat.

    Product Engine still holds major influence and continues to dictate development/feature implementation behind closed doors.

    Sadly, most of the people making policy/development/feature decisions are not users of the platform at any level, recreational nor enthusiast.

  2. 8 hours ago, Rolig Loon said:

    A good movelock script should automatically disable the movelock function during a teleport and then re-enable it a few seconds later.

    Sadly, no script can anticipate a teleport without remote communication/interference before the teleport happens as once a teleport process begins, all script scopes are frozen until the teleport completes/fails and scripts are loaded again.

    llMoveToTarget() is a script bound property so once set, it doesn't have to be called again to remain active. The script just needs to remain loaded in the region and running.

    Most times once a remote teleport has occurred and the script using llMoveToTarget() loads in the next region, the property auto-activates before any changed event can trigger fast enough for it to be stopped.

    Firestorm's Movelock is also susceptible to this.

    • Thanks 1
  3. Even with public build and public object entry off, people can still "drive" objects onto your land, stand up and leave them.

    It's always a good idea to use a short autoreturn time if you're not using public building and a moderate autoreturn time if you are.

  4. On 5/27/2021 at 2:24 AM, RohanaRaven Zerbino said:

    unless you EXPORT your animation with Bone Translations setting. Then, and only then Location Bone will have an impact on avatar deformations.

    I think this is what everyone was referring to, otherwise it should be understood that location keyframing in an animator itself is essential with most animation creation.

  5. 1 hour ago, Coffee Pancake said:

    That's not the suggestion .. how UE5 enables creators to basically dump zbrush content straight into engine is of interest

    Yeah, but animats said implications for Secondlife. When/Where/How would that come to fruition?

    Management and developers don't exactly have a track record for even keeping up with industry standards, let alone new tech.

  6. 16 hours ago, animats said:

    This has implications for Second Life. Second Life has a huge collection of high-quality content with terrible lower levels of detail. With this new approach to automatic LOD, it may become possible to use all that great content without so much degradation at lower LODs.

    Implications in what way? It's not like LL would move the render pipeline onto Unreal's engine if the licensing was affordable anyway and if it's not affordable and patented it's not like LL is going to brew/roll their own.

  7. 1 hour ago, Quistessa said:

    if we're getting this maybe someone can petition for functions to manipulate inventory in other linked prims

    The developer that implemented this function seems to be interested in making newer inventory functions.

    I suggested offering link access to offer greater flexibility over what we're limited with currently.

    This feature request covers most cases.

    • Like 1
  8. 12 hours ago, Quistessa said:

    I like it. Although I think the workaround for the specific case in which you want to know the most recent inventory (that being placing all 'old' inventory into a second linked prim and using a separate script in that prim to manage it) can be somewhat better practice depending on the circumstances.

    Also thank you for bringing it to our(my) attention, I'm not really sure how we(I) would learn about things like this otherwise.

    Yeah, but when you move an inventory item to another link a new acquire time is created for it there, so if you then delete the original inventory item and reset the script tracking things, you've lost that record whereas if you've kept the inventory items together, their acquire times would not change and a reset script could still figure out which are the oldest/newest item(s).

    I still feel the most common use case will be knowing if something is original or was replaced. Acquire times can be hard coded into scripts for checking. Acquire times can be used as identifiers the same way prim/mesh creation times can be.

    • Like 1
  9. So this function was implemented recently and is available on the beta grid for testing in the region Jigglypuff.

    The implementation stems from the feature request BUG-227663 where the benefits & use cases are listed. I'm sort of surprised it got any priority.

    It currently does not offer millisecond precision yet, but is available in ISO format so that it may hopefully be offered at some point in the future.

    For example, you will see 2021-05-25T21:18:36Z instead of 2021-05-25T21:18:36.976645Z

    I'm bringing attention to this function early to get opinions and will probably do the same for any new functions I'm made aware of in the future.

    • Thanks 5
×
×
  • Create New...