Rolig Loon

Not much. This is a personal dispute, so LL isn't going to pay attention. You're going to have to work this one out yourself. Sorry.

Handy, yes, although I have to wonder how many people worry about whether SL and RL are on the same sun cycle. Personally, I always treat my time in world as if I had teleported to another spot on the RL globe that happened to be in a different time zone. It rarely occurs to me that the RL sun shouldn't be up while my own is down. The only thing that's mildly annoying is the length of the day, but I've become accustomed even to that. As for "easy" ..... I'm not sure that it would be possible to change the 4-hour SL day to a 24-hour one for one sim at a time. Too many scripted functions (like llGetWallclock or llGetTimeOfDay, which drive many SL timekeeping scripts) depend on the "standard" definition of time.

I remember when you asked this question before, Jo. The answer's still going to be the same, though. The SL day is 3 hours long, followed by a 1 hour night. There's no way to change that cycle, and since a full RL day is 24 hours, there's no way to match RL and SL. Even designing a bot, as Ceera suggests, would be a hopelessly dificult job because the number of daylight hours changes all the time. Your only decent solution is to get a corps of vounteers who are willing to reset the sim's fixed sun manually a couple of times a day. Even then you'll only match sunup and sundown.

Void Singer wrote: EnCore Mayne wrote: [...] it's not like it's being rezzed inworld. heh, actually that is exactly what's happening... it's the only way for the script in the hud to run and ask to attach. if it's for a personal item, no big deal... but yes, it's a major pain for commercial products... those pretty much tend to fall back to making the user attach them both Exactly. That's why I said yesterday that "If you want to avoid that business, then you need to create a dialog, which is what most people do, actually." You asked whether it was possible. It is, and it's quite easy to do, but it's not a popular idea.

You can write a short script to do this, using llGetInventoryNumber llGiveInventory llFrand If you are looking for someone to write a script for you, the best place to ask is in the Inworld Employment section of the Commerce Forums (http://community.secondlife.com/t5/Inworld-Employment/bd-p/InworldEmployment). If you are looking for a script that already exists, try the Wanted section of the Commerce forums (http://community.secondlife.com/t5/Wanted/bd-p/Wanted).

So, Void already gave you the answer. Just use llFrand and add +1 to the result.

You put the HUD in the necklace. The script in the necklace has an attach event that says llRezAtRoot("My_HUD".... etc.). The HUD has a script that I described in my first post. The owner wears the necklace and its script rezzes the HUD, and ITS script attaches it. You have to request permission to attach an object with a script, or it won't attach, even though you are the owner ETA: If you want to avoid that business, then you need to create a dialog, which is what most people do, actually.

Try using llAttachToAvatar() in the script you put the HUD. You'll have to request PERMISSION_ATTACH in its on_rez event and then put the llAttachToAvatar function in the run_permissions event. Specify the HUD attachment point and you're all set.

In your Estate/Region tools, look under both the Estate tab and the Terrain tab. Be sure that the Fixed Sun box in both tabs is unchecked.

It's more than a little arcane, but I'm assuming that D4 means a four-sided die (a trigonal pyramid) and D6 means a six-sided die (a cube). That's the only way any of this makes sense, and I think that's what Void was assuming in her response as well.

Oh, I think I see why you want to do it that way. If you move your car to another sim, you want it to follow exactly the same path that it would have followed on the old sim, relative to its starting point. Yes, you can certainly do that. In fact, that's only a minor variation of what I suggested in my last post to you. Remember that I was suggesting that you create a list that contains all of the target locations. That list could instead be a list of offset vectors. In that case, you begin the path with // First position llSetRot(ZERO_VECTOR); vector new_target = llGetPos() + (vector)llList2String(offsets,0) ; llMoveToTarget(new_target, 5.0); llRotLookAt(llRotBetween(<1.0,0.0,0.0>, llVecNorm(new_target - llGetPos()), 1.0, 0.4); // Second position new_target += llGetPos() + (vector)llList2String(offsets,1); //This replaces the first target with a new one llMoveToTarget(new_target, 5.0); llRotLookAt(llRotBetween(<1.0,0.0,0.0>, llVecNorm(new_target - llGetPos()), 1.0, 0.4); // Third position new_target += llGetPos() + (vector)llList2String(offsets,2); //This replaces it again llMoveToTarget(new_target, 5.0); llRotLookAt(llRotBetween(<1.0,0.0,0.0>, llVecNorm(new_target - llGetPos()), 1.0, 0.4); and so forth........ Each position is calculated from the last one, plus an offset.

Ah, OK.. I was close. Yes, I can see that it would have to be llVecNorm(next_pos-llGetPos()) . After all, you want the destination vector to be figured relative to your current position, not relative to regional <0.0,0.0,0.0>. It's a PRIM_POS_LOCAL, if that existed. Thanks, Void.

I never use Voice myself, but it sounds to me as if the default device setting for input (your microphone) has somehow been messed up. I suggest that you look at THIS PAGE in the SL Knowledge Base to troubleshoot your system. Good luck.

Hehehe... And I will have to finally devote some time to making llRotLookAt work consistently for me. It would be nice to have both functions in my toolbox.

Gertrude Babenco wrote: Why would I need a more complex system, using the both methods you described in your first message? Because, since the pieces of the road (it could be train tracks) would have the same size, it would be less fastidious (you don't have to fit correctly several prims-targets) and would coast less prims. I mean Target2, 3, 4, etc. would be "virtual" and calculated from the position of the position and rotation of the Target1, set as the (invisible) root of the "turning piece of road". That's correct, Gertrude. You do not need to use both methods. That was my point. My script illustrates one method, but you could just as easily write a script that uses waypoints that are coded internally (or on a notecard). If you do that, you do not need to use a sensor. After all, the script already knows where the waypoints are, if they are in a list. If you want to use that other method, then you need to put the positions (vectors) of the waypoints into a global list instead of the names of the waypoints. You do not need to calculate anything from the first target -- just enter the positions in the list as vectors. Then, instead of triggering a sensor, you simply use llMoveToTarget( (vector)llList2String(waypoints,count), 5.0) at each step. To keep the car pointed toward the next waypoint, use llRotLookAt(llRotBetween(<1.0,0.0,0.0,>, (vector)llList2String(waypoints,count), 1.0,0.4) . (I am fairly confident about that last statement, but I cannot get in world to test it right now. :smileywink: ) The rest of my example script is essentially the same.

Try it. It worked for me in world as I tested the script. I was mildly surprised, but it did work. Besides, I still don;t like llRotLookAt. It does wierd things for me. :smileysad:

You are trying to make your script too complicated. There are two ways to make a path follower. One method is to store the positions of each waypoint in a list (perhaps hard-coded into the script, or perhaps read from a notecard), and then tell your car to go from one waypoint to the next. The other method is to put a named prim at each waypoint and tell the car to use a sensor to find each prim and move to it. You don't need to combine both methods. As an example, here is a very simple path following script that uses the second method. All you need to do is put four prims, named "Target1," "Target2", "Target3", and "Target4" on the ground, drop this script into another prim that will be your car, and click on it. The Car should move from one prim to the next easily. Notice that I am only using llLookAt to aim the front of the car toward each waypoint prim. The variable named "count" looks for the next target name in the list each time your car reaches a waypoint and triggers the at_target event. integer target_id; list targets = ["Target1","Target2","Target3","Target4"]; integer count; default { state_entry() { llSetStatus(STATUS_PHYSICS,FALSE); llSetRot(ZERO_ROTATION); count = 0; } touch_start(integer total_number) { llSetStatus(STATUS_PHYSICS,TRUE); llSetStatus(STATUS_ROTATE_X | STATUS_ROTATE_Y, FALSE); llSetBuoyancy(1.0); llSensor(llList2String(targets,count),"",ACTIVE | PASSIVE,20.0,PI); } sensor(integer num) { if(count == 4) { llStopMoveToTarget(); llResetScript(); } llLookAt(llDetectedPos(0),1.0,0.4); llMoveToTarget(llDetectedPos(0), 4.0); target_id = llTarget(llDetectedPos(0), 1.0); } at_target(integer tnum, vector targetpos, vector ourpos) { if (tnum == target_id) { ++count; llTargetRemove(target_id); llSensor(llList2String(targets,count),"",ACTIVE | PASSIVE,20.0,PI); } } } Edit: I modified the original posted script to reset it at the final waypoint and disable physics until touched. Might as well save some stress on the sim's physics engine when it's not being used. :smileywink:

Hehe.... That's why I said "dorky, insensitive". "Smart dorky" can be cool, but I 'll pass on "dorky with the personality of a turnip."

Yay, George! If I have to cast my vote, I'd recommend a personality upgrade for a lot of guys. Skin and a decent set of clothes help, but they can't hide a dorky, insensitive personality.

You mean those green things that say "VOTE"? No, they haven't counted for well over a year. There are still a few of them kicking around, but they don't factor into LL's calculations, as far as I'm aware. On the other hand, many sim owners maintain their own vote boxes so that they can collect stats, and of course there are hidden traffic counters on most commercial parcels these days.

Find the watch in your inventory, right click, select Attach to >> and then choose L Forearm instead of R Forearm. You'll still need to do some adjusting with your editing tools to get it placed exactly where you want it. Once it's there, though, it will remember the spot from then on.

I have no experience with that myself, not being an animator, but the SL Wiki says "Animations can have no more than 30 seconds worth of unique frames. Linear animations can potentially be 50 seconds long if ease in and ease out are set to the maximum of 10 seconds," so I'm guessing that the answer is a very limited yes. I suspect that the OP has something more than a total of 30 seconds worth of unique frames in mind, however, so in his case the answer is probably no. Not a bad question, though. :smileyindifferent:

Je ne suis pas sûr que je comprends. Êtes-vous inquiet parce que quelqu'un a acheté la même peau et les vêtements que vous avez acheté? Cela doit être un compliment à votre bon goût, je crois.

Phoenix (977) temporary uploads have been working fine for me too. You have a local problem.

The behavior of flexi objects is all controlled client-side. That is, the movement all takes place on your own computer, not in SL's servers. What that means is that several people watching the same flexi object may see it differently, depending on how their own computer's graphics card handles the information. I suspect that your computer is having a little harder time rendering images with the latest upgrade of the viewer than it had with the previous one, so flexi objects aren't responding quite as fast as you are used to seeing them. "Gravity" doesn't pull your hair back down quite as fast when it's been toussled. You could try compensating by dropping your draw distance a bit and moving some of the quality sliders to the left so that your graphics card doesn't need to work quite so hard. Or you could try another viewer. Or get used to the flyaway look.