Jump to content

Timothy McGregor

Resident
 View Profile  See their activity

  • Posts

    43

  • Joined

  • Last visited

 Content Type 

Posts posted by Timothy McGregor

    Server performance statistics, time dilation and spare time

    in Second Life Server

    Posted

    I've had a couple people tell me upon entering my home region (Samoa) that it is really laggy. I've experienced lag here and there that I've concluded is mostly related to my machine and not necessarily server lag.

    Stats wise, time dilation is consistently 0.9 or better. I'd love to see real time there, but honestly I don't recall ever seeing a mainland region running consistently in real time. Sim and physics frame rates are extremely close to being a solid 45, occasionally dipping down to 44 and some change.

    This is what has me curious though. Spare time is consistently around 10ms. At the same time, time dilation is consistently less than 1.0. Isn't this somewhat contradictory? Are the numbers even accurate?

    Viewer 3.3.4 (264214)
    Server 12.08.14.263480

    PRIM_COLOR vs CHANGED_COLOR.. how to stop the infinite loop?

    in LSL Scripting

    Posted

    Is there anything preventing you just deleting that original script that you can't modify and re-implementing its functionality in your own original code? I am thinking that the most elegant way to deal with this is using llMessageLinked, and explicitly setting the needed alpha states on or off, with a logical flow that you're entirely in control of. You can group like pieces of the linkset together (buckles and locks go visible/invisible together) with the llMessageLinked function's second integer parameter. It's an arbitrary integer value that can be used to target messages to specific objects in the linkset without explicitly sending to those link numbers. 

    PRIM_COLOR vs CHANGED_COLOR.. how to stop the infinite loop?

    in LSL Scripting

    Posted

    When using the settingLocks variable, where are you checking it in the changed event?

    integer settingLocks = false;

    DoMyStuff()
    {
         settingLocks = true;
         some code to change alpha on a child object (triggers change)
         some more code to do this (triggers another change)
         etc
         settingLocks = false;
    }

    default
    {
         changed(integer change)
         {
              if (!settingLocks)
              {
                   if (change & CHANGED_COLOR)
                   {
                        DoMyStuff;
                   }
              }
         }
    }

    This check in the changed event should always work, so something in your iteration through the linkset triggering it isn't keeping the state of settingLocks consistent. Hard to really get my head around it without seeing some actual code.

    DNC Streams in SL

    in General Discussion

    Posted

    That is not a helpful answer in the least. It is a judgment, and while you're entitled to determine and judge for yourself what content you bring into your in-world experience, I'd appreciate it if you would respect that other people have different desires and intentions for theirs.

    What to do about content theft?

    in General Discussion

    Posted

    Actually, not even Linden Lab can really solve the copybot issues, or the issue in general of copying textures from in-world, which is what this product, being a skin, primarily is. The problem is that there are no underlying security mechanisms in OpenGL which provide for protecting against this kind of theft, nor is there any practical way to detect, track and ban unauthorized clients from saving these textures outside of the grid once they are downloaded for rendering. 

    The lack of security is inherent in the OpenGL platform, not in Linden Lab's product. As has been often pointed out during these discussions, which have taken place now close to ten years, in Second Life, because of the nature of the OpenGL environment itself, if you can see it, you can steal it. There is nothing Linden Lab can do to stop it. 

    When technology gets to the point where we can encrypt everything "to the glass", content theft will be orders of magnitude more difficult to achieve. Until then, legal process is the only remedy.

    Direct Delivery Launching March 21, 2012

    in Merchants

    Posted

    I guess I'll just sit tight for a few days before I migrate my small store. The process is simple and straightforward, and I cannot believe that anyone would say the "payoff" is small. This is a HUGE step in the right direction for Marketplace, one that I wish they would have taken when they first acquired the property. 

    Yeah, if you've got hundreds of listings, it's going to be a pain in the ass. There isn't any way around that, and it isn't the developers' fault. There is no way to make this migration just magically happen with minimal effort. There is no way to make boxed items magically turn into foldered items. There is no way to do this in a way that's hands-off for the merchants.

    But what you get in return, and what I suspect you'll be very happy about once the madness is done, is the ability to offer your customers multi-item products in a folder, or a nest of folders if you please. It streamlines the process of moving product to Marketplace. Right click on an inventory item or folder, done in a few clicks and keystrokes.

    This is one of the most significant improvements to commerce in Second Life since.. I dunno.. the beginning?

     

    Direct Delivery Launching March 21, 2012

    in Merchants

    Posted

    It looks pretty straightforward so far. I successfully created a test listing.

    One thing that is not particularly apparent is how to go about updating items already listed. It used to be that I could just replace that item in the magic box. Saving updated product to the original folder I sent to the outbox, and re-uploading that folder just creates a new, unassociated item on the Marketplace side. It would be very disappointing if I had to delete current listings and create brand new ones each time I needed to roll an update. What am I missing? 

    Are lindens ever going to fix the transparency texture overlay issue?

    in Building and Texturing Forum

    Posted

    This is not a direct reply to Void - I don't see any way to do a general comment on the thread. I don't like this forum software much so far.

    -

    I have all but eliminated this issue in my scenes, and oddly have done so by using MORE transparency, not less. My specific case is a house, with primitive based plants adjacent to a window. The windows have two textures - blinds open and blinds closed. Both are 32 bit, and the closed version has some alpha in order for some of the outside scene to bleed in. With the "closed" texture applied, looking out from the inside, certain plants sorted first, and I could see almost the entire texture bleed through. With the "blinds open" texture applied (more alpha) the glitch was more difficult to repro, but still there. Changing the plant texture to one with maybe half of the opaque pixels as the previous one seems to have eliminted the glitch entirely.

    I doubt very much that this issue will ever go away for good. Myself NOT included, a relative few of us in Second Life are professional 3D scene designers, and even fewer of us understand the underlying z buffer issue. My very narrow understanding is that for a scene to be entirely free of the problem, some rather tedious work needs to be done in prioritizing how and when opaque geometry is rendered vs alpha geometry, when the z buffer is written to and when it's not, all at a significant cost in frame rate, gpu and memory resources.

     

     

×
×
  • Create New...