Jump to content

Nika Talaj

  • Content Count

  • Joined

  • Last visited

Community Reputation

4 Neutral

About Nika Talaj

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. I am amused to see that landscaping in SL has come full circle, and after years of effort, we have managed to get trees to be like they were in 2005. Sort of! There are many mesh trees on the market that are animated; the branches wave around, tho I don't think they do so in response to SL wind. You can make Hayabusa's trees toss like they're in a hurricane, but most creators confine themselves to a gently waving motion that you can turn on or off. I don't know how they do this; it doesn't really look like animated textures on the mesh. But then, I didn't know how the original Linden trees and grasses waved in the breeze either! I'm up for education on this My question: if you put a forest of these trees in a sim, would they lag the server? And/or, do they have the potential to lag clients?
  2. Wow Snickers! That was masterful! Haven't been here in ages, but at least this platform seems more like a forum and less like a blog! I think this is my first Cartel pic, 2008. Get your foot out of that cake, girl!
  3. Deed, I'm about to buy the same laptop. Did you ever resolve the problem?
  4. I went ahead and created a bug reporting this problem (text below). It has been closed - the resolution is that the ability to create a linkset with prims set to different groups (which has been the case in SL at least since I joined in 2006) is actually a bug. SURPRISE! They did not mention any intention to "fix" that, though - they simply said that the bug I reported is expected behavior, given that such a linkset can be created. Maestro was very courteous, but it is discouraging. After I started to script this llSetKeyFramedMotion ferry system, I put it off for a year, fearing that it would turn into a depressing, defeating mess. The system is up and running and very cool, but the PAIN ... I hope I've learned my lesson this time! Thank God I decided not to offer this system for sale, I really want nothing to do with LSL for a good long time. ---------------------------------------------------------------------- BUG - 5037 The change in that causes objects rezzed via script to inherit the auto-return timeout of the rezzer actually has the rezzed object inherit the timeout of the rez PRIM, not object. Therefore, rezzers which rez objects in a different group than the land group (via a child prim set to a different group) no longer work; the rezzed object disappears within a few seconds once the rezzer has been in place for longer than the parcel auto-return timeout. Would it be possible for the rezzed object to inherit the timeout of the rezzer (i.e. root prim), instead of the prim which contains the rez script? Other information The ability to rez objects in a different group than the land group has been around for many years. It may not have been an intentional feature of the platform, but many many scripters have made use of it, for various legitimate purposes. RESOLUTION: Hi Nika, thanks for the report. We talked this over, and agreed that this is expected behavior - parcel return timers are a per-linkset property, not a per-prim property. Object group should also be a per-linkset property - it's a bug that you can temporarily create a linkset with mixed active groups.
  5. ObviousAltIsObvious wrote: I haven't measured this, but the simulator probably compares rez time to current, in favor of separate timers for each prim, that would match some immediate autoreturn surprises after moving things across parcels, even from before the new rez changes. I didn't quite understand this part of your post, but I did do a test which is perhaps relevant. I made a small parcel, set it to the land group with a two minute autoreturn timer, and put down one of my rezzers on it. I set it up to rez the tour vehicle into an adjacent parcel which also has autoreturn set, and waited five minutes. I rezzed an object, and it DID NOT immediately disappear ... as if it did not inherit the expired autoreturn timeout from the rezzer prim. If I instead rez the object into the small parcel where the rezzer is, it disappears immediately, of course. I think this behavior might be explained by your comment ... could you clarify what you meant?
  6. The rezzer (root prim) IS in the land's group., A child prim, containing the rez object script, is in another group, so the rezzed object (a tour transport) is set to the other group when rezzed. This is because the tour goes through a no-script sim. The transport could of course take controls in order to go through the sim, but being in that sim's land group is more reliable, since the tour stops and riders can get off and walk around, then get back on.
  7. ObviousAltIsObvious wrote: .... thinknig more, are you using the linked prims set to different groups hack? maybe autoreturn still ages those linked prims in different groups, even if the root keeps them rezzed? Yes, I am! Thanks for the info about the change, that appears to be the problem. If I link two prims in this sim, the root set to group and the child not, wait 10 minutes, and unlink, the child disappears immediately. People have been using this trick for a long time. It seems to me that it would not defeat the intent of this anti-griefing change for script-rezzed objects to inherit the autoreturn timeout of the object rather than the individual prim, what do you think? I wasn't aware that linked prims HAD individual autoreturn timers! Can't think what use that serves. But thank you.
  8. Two or three weeks ago, a rezzer (that I scripted) which has been in place for months began behaving differently.. It rezzes one object when a sign is touched. The object is rezzed in a different group than the land, and the land has an auto-return of 10 minutes. The rezzed object is not temp-rez. Recently, the rezzed objects are auto-returned within 30 seconds; often immediately upon rez; but they used to return in 10 minutes, as you would expect. It does not matter whether the rezzed objects have scripts or not. The parcel (and sim) have plenty of prims. Land options for Build, Scripts and Object Entry are all set to Everyone. The land owner says she has changed nothing, and the about land menu shows auto-return set to 10 minutes. A box rezzed by an avatar which is set to a different group than the land is returned in 10 minutes; the same box rezzed by a script is returned almost immediately. Has auto-return timeout handling changed recently?
  9. I'm bothered by the comments in this thread about having to email photo IDs to LL. As usual, LL was not clear enough, but just to be very clear, they are NOT asking anyone to email ID to them. They want people to attach the required ID info to your support case on secondlife.com, which provides a modicum of security at least. Please, no one send photos of your personal ID to anyone via unencrypted email! The echosign links seem to work fine for me. The "e-sign" act was passed in 2000, and finally the IRS is inching into the 20th century (they still have a ways to go to catch up to the rest of us here in the 21st) and working with DocuSign, EchoSign and one or two others to allow esigning of specific forms. LL is amazingly late in requesting this info, and less than clear about it, but it is legit request from LL. The tax forms they have to gather; I'm not sure about the circumstances under which they are absolutely required to validate identity. I wish they had quoted the passage justifying that. I also wish they had provided more explicit guidance for non-US citizens.
  10. Yes, these are real deviations reported by GetPos. I haven't actually seen much in the way of updates being lost, but this is all forward motion, no loops or ping-pong. Perhaps that makes it easier for the viewer to track correctly? I'm not surprised at your response, since while KFM is in progress the script is basically just twiddling its thumbs after it prepares for the next KFM command, waiting for a moving_end event. Unless the server performing the KFM is also somehow getting extra time slices and that throws IT off, I can't see how the script getting extrta run cycles would have any effect at all. For the moment, I've worked around the issue by inserting an extra keyframe at the beginning of each KFM command that just stays in the initial position, a throwaway keyframe. That works for the one route I'm working on now, but I have no idea whether it will always work. re: reporting stage of progress of KFM command ... that would be FABULOUS. You get these spurious moving_end events, and one is also haunted by the spectre of missing a moving_end. So you end up with a continuous loop running to check on the command via heuristics like velocity and position and time elapsed. I hope he gives a status flag (e.g. in_motion, paused, done) as well as a keyframe number! It's also vital that he report just the command state, not the object state - that is, if the object has stopped movng for some reason but the KFM command is still in progress, I want to see that the KFM is running, and preferably the keyframe number. I wish there were some way to communicate with him ... even if he comes to the scripting meeting, it's very hard for me to make that. ETA: Well, if Simon happened to have the object's current position and rotation around and wanted to report that as well, it would just be incredibly delicious gravy.
  11. By the way, in case anyone wonders, yes I have grab blocked the object (llSetStatus) and yes I have correctly obtained permissions to take controls before issueing llTakeControls. (Even though the object is not physical and has no touch events, I set Grab Block just to be sure there was nothing funky going on.) I have also monitored events to be sure that the script is not getting a zillion Permissions or Changed events, and it is getting very few. Basically, it gets permissions at the start of a tour, the avatar remains seated, and sooner or later the tour goes off course. Also, the avatars riding the tour do not have authority over the tour object (that is to say, they cannot edit the objects of the tour owner and they do not have the ability to return objects in any parcel the tour passes through). Without the llTakeControls call, the tour stays on course extremely well.
  12. I have a tour system that uses llSetKeyframedMotion (SKM for short, k?). I would like to take controls in order to traverse areas where scripts are turned off, but executing the command llTakeControls( CONTROL_LEFT, FALSE, TRUE); appears to subtly disrupt the timing of frames such that the tour eventually is thrown off course - it looks as if some frames, or possibly entire frames, are simply skipped, because the tour route appears to be basically followed, but is offset.by some number of meters. Has anyone else encountered this? Or perhaps someone understands the below fragment of an office hour from 2011 well enough to say whether it points to a possible interaction between frame stepping and taking controls (edited to remove irrelevant chatter): ------------------------------------------------------------------------------------------------------------------- [09:26] tehKellz (kelly.linden): So lets jump back: Leonel Iceghost: Kelly I read a couple of weeks ago that you made something to improve performance when many people using control events at the same time, can you specify how it works? ... [09:27] tehKellz (kelly.linden): There were a couple of changes made. [09:27] tehKellz (kelly.linden): These are on LeTigre now I believe. [09:27] Leonel Iceghost: how there affect scripts, or sims [09:27] Leonel Iceghost: those* ... [09:28] tehKellz (kelly.linden): We put a cap on the total time the scripts for an agent can trigger. This is the time outside normal script time. ... [09:29] Leonel Iceghost: so script start to fire less times per second? ... [09:29] tehKellz (kelly.linden): When you press a key we give your scripts that have control an extra chance to run. This happens in 'agent time'. To prevent abuse we added a cap per framer per agent. It is pretty large right now. [09:30] Kallista Arliss (kallista.destiny): AHHHHHHHHHHHHHHHH much is explained. [09:30] Leonel Iceghost: how much is large? [09:30] tehKellz (kelly.linden): Let me check [09:30] F L I P (flip.idlemind): Is that why scripts that take controls still run if scripts are disabled? Because it's only scripts that actually use "script time" that are disabled? [09:31] Qie (qie.niangao): *oh*... "agent time" -- yeah, that does explain a lot. [09:31] tehKellz (kelly.linden): Right, disabling scripts on a parcel only stops the script time block. [09:31] tehKellz (kelly.linden): Leonel: 1ms per frame. [09:31] Kaluura (kaluura.boa): So... Taking controls allows your script to work in no-script areas and gives it a boost in speed if you press a key... Interesting... [09:31] F L I P (flip.idlemind): Per agent? [09:31] tehKellz (kelly.linden): Yes [09:32] Vincent Nacon: wait... why? [09:32] tehKellz (kelly.linden): The changes make it so you get at most 1 extra script run per frame. [09:32] Vincent Nacon: not for vehicle, right? [09:32] tehKellz (kelly.linden): Vincent for responsiveness of AOs and vehicles. [09:33] Vincent Nacon: ok but.. only control event? [09:33] tehKellz (kelly.linden): Weapon scripts already take controls [09:33] Liisa Runo: controls give speed boost even when keys are not pressed ... [09:33] Vincent Nacon: or did you mean only script that has control event is allowed to whole? [09:33] tehKellz (kelly.linden): Not only the control event. They get an extra chance to run. [09:33] Vincent Nacon: ok [09:34] Vincent Nacon: still sounds like potential griefing abuse [09:34] tehKellz (kelly.linden): Leonel because scripts are complicated. Anything that adds more data to serialize per script is difficult. [09:34] tehKellz (kelly.linden): There is some potential to use a lot of script time but the recent changes on letigre limit that severely. [09:35] Vincent Nacon: still don't like the sound of that [09:35] tehKellz (kelly.linden): And the 1ms is adjustable and we may drop it later. [09:35] Kallista Arliss (kallista.destiny): I expect that some weapons makers are going to be upset. [09:35] tehKellz (kelly.linden): This is how it has always been. :) [09:35] tehKellz (kelly.linden): Kallista: with what? [09:35] Vincent Nacon: this isn't really about the vehicle and AO, is it? [09:36] Leonel Iceghost: Kelly and can you limit is depending if the object is actually using the event or not? most take controls but don't handle them [09:36] Kallista Arliss (kallista.destiny): I'm sure that some of them take controls [09:36] Kallista Arliss (kallista.destiny): so that they have quicker response under lag. [09:36] tehKellz (kelly.linden): Leonel: That is an interesting idea. [09:36] tehKellz (kelly.linden): It is possible.
  13. Thank you for looking into it! I'll detect collisions and set the sit target up above the mesh's bounding box & physics shape (thanks also for the tip there), see if it makes a difference. Overall, the behavior I see is that even for runs of 100-200 points, keyframedmotion is very very precise. If no one is riding the vehicle, it ALWAYS seems to be precise, and with one or two avatars riding, it is precise about half the time you run a given long course. About half the time (same route, same avatars) it begins to yaw and pitch after a while. I'm not sure, but it looks like it's hitting the position coordinates correctly, but the rotations get wonky. Characterizing this will take some time, but I suspect I'll find that some sort of collisions with the riding avatar(s) is the cause. I'll post results here.
  14. Qie Niangao wrote:The reason special animations are often used in physical vehicles to "fix" avatar collisions is to make the avatar appearto be in a reasonable riding position while allowing the avatar's collision bounding box to be up out of the way. Ah! I was wondering if people used special anims. Just to be sure, you're talking about placing the sit target way up in the air, and using an anim that puts the avatar a few meters below the sit target? I bought an inworld posemaker a while ago, I suppose I could actually try to USE it. *glances dubiously at her inventory*
  15. OK, so I've finally returned to my transport system using llKeyframedMotion, and I have two questions. 1. Do we still need to worry about adjusting times to even multiples of 1/45th of a second? The wiki still says to do it, but I think it may need to be updated. I seem to remember an office hour transcript saying this was fixed so that distances will be precise regardless, and without time adjustments my transports seem to hit their marks quite accurately. Anybody know the poop on this? 2. I notice that if an avatar sits on something that is already in keyframedmotion, sometimes the object is pushed off course/rotation and sometimes not. Before I spend forever messing with anims and sit targets, does anyone know whether avatar collisions are inevitable on sitting? This particular mesh transport is not phantom and has a large bounding box. If the avatar sits within it, could that be causing the problem? Perhaps I should be looking at the transport's physics shape instead? I wonder how to do that .... Once sat in the transport, am I correct in assuming that the avatar cannot generate more collisions if their anim moves a leg, for example? Or does a collision just occur if the avatar's path 'passes through' the transport while getting to the sit target,? Perhaps a carefully chosen sit target and anim can reliably eliminate collisions? Thanks in advance ...
  • Create New...