Jump to content

DavidThomas Scorbal

Resident
  • Content Count

    23
  • Joined

  • Last visited

Community Reputation

1 Neutral

About DavidThomas Scorbal

  • Rank
    Member
  1. Costs go up, that happens. But making it a percentage of the amount you're cashing out? That's just greed, pure and simple. LL sees how much people are making, and they just simply want a piece of it. Or am I mistaken? Maybe the system they've implemented requires squirrels to carry $1 at a time over to a wheelbarrow, thus the need for higher fees for higher amounts. Gimme a break - it's a number. Doesn't matter of it's $10 or $5000 - it's one transaction.
  2. That's true. It's a bit of a hack, but it might be good enough for this usage case. I'll have to look into maybe loading the data from the description line at script startup, if it's there. Thanks
  3. Can't use a notecard ... the script contains things dynamically generated by using the prim. Strange that the original is considered the one that you move ... but I guess that makes some sense in the light of how the memory reset ... (err, the memory isn't copied) ... works. Thanks
  4. Checking if this is still The Way Things Are (tm) ... If I drag-copy a scripted object, the original object (the one still sitting in the same position) has its script memory reset, correct? And the new copy that sits where I end the drag, that one now has the script memory of the original object? Is there no way for script memory to survive a drag-copy? (other than the obvious of "don't do that") Thanks
  5. Some additional info on this issue ... I'm 99% sure this has nothing to do with object names, or rezzers. This is a physics issue. Look back at the message posted above by Chavi Skomoroklov quoting TJ Linden. My observations line up perfectly with that explanation. I've had my same homestead for a couple years, and I've never had this issue before. Yesterday I decided to give it a makeover, including a ton of terraforming, and rezzing a lot of new mesh objects, many of which are walkable, and have physics properties. At some moment, I noticed that if I rezzed a new cube using the build dialog, the cube had no physics - I could walk right through it. If I rezzed an object from inventory, it did have physics. I logged on an alt at the same time and confirmed that neither account could create objects with physics. So I restarted the region, and when it came back, objects I had previously rezzed and could walk/fall right through now behaved correctly. This lines up with what TJ was quoted as saying about the physics memory being cleared on region restart. Today I logged on a different alt, and got these errors again, as it tried to attach my mesh avatar shape. I'm certain it's the mesh av that triggered the error because trying specifically to attach it showed the error again. The avatar part names do not exist on any other of my accounts, so there was no "stuck" name involved. That's when I Googled this error, found this thread, and read what TJ was quoted as saying. And sure enough, he said a homestead over about 230MB of physics memory would have this problem, and mine shows 247.5MB in use. And once again if I create a new prim, I can walk right through it. I don't know if this was ever addressed, or has regressed, but it's here now. Second Life Server 15.09.21.305305
  6. I have a customer who uses my ANS extension to record her MP sales on her own server. She has some very compelling evidence that the InventoryName field of the ANS transaction is no longer transmitting the name of the associated inventory item, but now contains the MP listing description instead. This image shows two transactions, back to back, of the same MP item. The first one was executed prior to converting the item to use VMM, and the second one (7 minutes later) was done after the VMM conversion/transfer. http://i.imgur.com/gi4D2Mw.png My ANS code records the InventoryName field. Needless to say, this is a huge regression. This breaks accounting, redelivery, customer history ... you name it. Is this an intentional change? Going to enter a JIRA right now, but wanted to get out some feelers here, too.
  7. Testing these two: Second Life RC Magnum 13.09.27.281745 Second Life Server 13.09.21.281328 I had a report from a customer that my HUD, which stores camera positions, wasn't working on her region. Long story short, she's right. She's on the Magnum version noted above. The same code, in the same HUD instance, works fine if you just TP to a main release channel region. This is easy enough to demonstrate. The problem can be seen by attaching a prim to a HUD position and putting in the following script. It saves the camera position when you click it. It then immediately sets the camera position with the same info. Now, if you press ESC to reset your view, you'll see the camera *move* on a Magnum (also tested Blue Steel) region, but if you try the same steps (after a script reset) on a main release channel region, it's rock solid after you press ESC and (correctly) doesn't move the view. In other words, since the camera position was grabbed, and set as the active view, resetting the view shouldn't change anything on the screen - but on Magnum regions, it does. Different camera zoom levels magnify this anomoly. Zoomed in close to a prim shows it the best. ============================= rotation CameraRotation;vector CameraPosition; MoveCameraTo(vector v, rotation r){ llSetCameraParams( [CAMERA_ACTIVE, FALSE] ); llClearCameraParams(); llSetCameraParams( [CAMERA_ACTIVE, TRUE, CAMERA_FOCUS, v + llRot2Fwd( r ), CAMERA_FOCUS_LOCKED, TRUE, CAMERA_POSITION, v, CAMERA_POSITION_LOCKED, TRUE ] );} default{ state_entry() { llRequestPermissions( llGetOwner(), PERMISSION_TRACK_CAMERA|PERMISSION_CONTROL_CAMERA); } run_time_permissions(integer permissions) { if ( permissions & PERMISSION_TRACK_CAMERA ) { llSetCameraParams( [CAMERA_ACTIVE, FALSE] ); llClearCameraParams(); state Ready; } }} state Ready{ state_entry() { llOwnerSay("Click to capture camera position"); } touch_end(integer total_number) { if ( llDetectedKey(0) != llGetOwner() ) return; CameraPosition = llGetCameraPos(); CameraRotation = llGetCameraRot(); llOwnerSay("Camera recorded at " + (string)CameraPosition + " - " + (string)CameraRotation); // now set the camera to this position MoveCameraTo( CameraPosition, CameraRotation ); }}
  8. Has anyone ever run into a situation where llHTTPRequest did *not* result in a corresponding http_response event being raised? To clarify, I'm not talking about overflowing the event queue by calling llHTTPRequest repeatedly. I'm only talking about a single call to llHTTPRequest resulting in a single http_response event. The wiki says a timeout will generate a 499 response, but I'm wondering if anyone has ever found that to be unreliable such that using a timer to manually check for timeout became neccesary? Thanks
  9. While I would still appreciate any anectodal information anyone might have, what I'm seeking is an official LL position statement on the use of an account that is specifically designed to be used by multiple people. Many of my customers start second or third businesses in SL. A second business is often a partnership between a couple or a few designers. In these cases, it's quite common for them to create a "store alt" which represents the new business. It's not used socially, and therefore seems to me that the spirit of the TOS doesn't apply to this situation, although the letter of it still does. I'm hoping that maybe marking the account as a "scripted agent" will relax the TOS a little? Anyway, this is all speculation, and I'm wondering HOW I go about getting an official answer, so as to be able to advise my clients accordingly. Any ideas? Links? Names? The support ticket submission process is so structured that I didn't see a way to submit an ad-hoc question like this, so I thought I'd start here. Thanks!
  10. >> Where else have you seen people being let to learn by trial and error on >> a live platform with hundreds thousands users? Well, there's this little thing called the World Wide Web ...
  11. "..will require an extended period of region restarts. We expect this maintenance to last at least a week." I'm not clear on the meaning of this ominous sounding warning. Does this mean that each region will be restarted several times throughout the week? Or that each region will be down for longer than normal, requiring a longer overal restart process from start to finish?
  12. The product isn't "overly complex" - if it were, I wouldn't have some of the very high profile SL customers I have. Have you ever adopted/set up a complete vendor system for a high-traffic store? It's an involved process, which consists of multiple steps. There's the inventory server (which comes both as a pre-configured object, as well as scripts-only for upgrading customers), then there are the various vendor types (normal, special event, etc), then there are the various customer-related tools such as redelivery terminals, then automated utilities for checking your store's configuration, and the list goes on. The problem with selling this item in a single prim (or even nested prims) is that they create a flat list of items with zero organization. Even nested prims yields you multiple (top-level) folders, which again, I find sub-optimal, and not acceptable for the level of service I choose to provide. When a customer drops a system they've used for years and adopts mine, when they depend on it for RL income, it's *not* a hands-off process, and I'm there to provide personal assistance, not a good luck wish. What can I tell you? Plenty of people who run high-traffic stores and who have investigated the depth of features I offer have bought the product, so I'm happy with the course I'm on. My hope was that LL would see past the letter of their law and see that purchasing my interest notifier is simply the first step in a complete purchase, not an advertisement. But then again, they don't make any money off a L$1 listing, so it doesn't surprise me that it got removed, despite the fact it's obviously not just an ad.
  13. Any suggestions on where/how/who? I have no idea who's behind the MP these days ...
×
×
  • Create New...