Rolig Loon

The best place to ask is the Building Forum. I have never used ProDesktop myself, so I cannot say. I suspect, though, that the answer is no, or at least "yes, but it will be difficult." Sculpties are very peculiar beasts. They are basically flat surfaces with a fixed number of cells that are folded into a limited number of topologies. Programs that are specifically designed for making scuplties or ones, like Blender, that have plug-ins or other support for sculpties, can handle them easily. If Pro Desktop doesn't have that support, you might still be able to make a sculpty, but it might be frustrating. Oh, and uploading is simple. You don't upload the sculpty itself. You upload its UV map, which is a TGA file, and you apply it to a prim in world to create the actual sculpty.

File an Abuse Report (AR). Be sure to include specific details with times of specific incidents if you can. Include photos or anything else that might support your report. Read THIS KNOWLEDGE BASE ARTICLE to see how to do it.

Let me try to be even clearer........... LL uses the same word, "BASIC", to mean at least three completely different things. This is confusing to newcomers in Second Life. First, the Basic account level is a free account that lets you do almost anything in SL except own land. I have had a Basic account for 4 years and have been able to rent land and run several businesses. Second, the Basic level in the new official viewer (2.6) is a beginner-level mode for that viewer. It is designed to give newcomers a first-time experience without the potential confusion of "extra" features like inventory. Third, LL's Getting Started guide refers to "basic" skills like flying and teleporting, distinguishing them from other skills like building and handling L$. Personally, I wish LL would find a different word for each of these three concepts. You are not the first SL newcomer to be confused.

No. If you select Premium membership, THAT costs money. The Free membership is ... well, free. All of this has nothing to do with whether your viewer is in its Basic (beginner-level) mode or its Advanced (normal) mode. The viewer will work fine in either mode, whether you have the Premium or free membership.

You can store information in any variable that can be read with a LSL command. A prim's name and description fields are obvious choices, as are the names and description fields of child prims. Also, you can store numbers in integer, float, or vector quantities. For example, if you want to store a floating point number, record it as the alpha value of a prim face in the linkset, scaled as appropriate. Or store it as a value in a color or size vector. Store a string variable in a floating text, set to alpha =0.0 so that it's invisible. Once you start thinking, there are dozens of places to store information and keep it safe from reset.

Landowners can ban you for any reason, or for no reason at all. You could get banned simply because he doesn't like your hair. Who knows? Anyway, SL is a big place and there are thousands of places that you haven't been banned from. :smileywink: Wander off and put this one out of your mind.

If you have to keep rebaking all the ime, start looking carefully at your internet connection. Bake failure is almost always a symptom of a flaky connection. If you're on wireless, get off it. Move to a direct cable connection. A lot of people have bandwidth loss and interference from other sources, making SL problematic for them. Then, be sure that the drivers for your modem and router are up to date, and reboot both of them. Just unplug them, take a long walk, and plug them back in. Finally, check your statistics bar in SL to be sure that you don't have any packet loss. If you do, try readjusting your maximum bandwidth setting in Preferences.

Do be sure that you paste the URL for your music stream into the box on the Audio tab in About Land, not the Media tab. Also, a valid music stream must be in mp3, mp4, or ogg format. You can't stream a site that is coded fo RealPlayer, for example, so that rules out BBC Radio an others that only encode for RealPlayer.

Unless you want to have the underside of the roof exposed, it's trivial. Just make your two intersecting roofs and set them at 90 degrees. All done. You can do it with two cut prims total, or 4 if you want to be fancy about it.

Hehehe.... Phrased more gently, the Scripting Forum is intended as a place for scripters to share ideas, challenges, and insights about scripting. It's a place for new scripters to learn. It's a neutral ground where more experienced scripters aren't competing with each other for scripting clients. We don't tout our own services, nor are we a clearing house for free scripts or a public billboard for posting job opportunities or advertisements for nifty scripting tools. We will often post a partial script as an example while discussing a challenge, and occasionally post even a complete script, always with the understanding that this is not a commercial site.

Yeah, it's sort of awkward. You can discuss generic services ("Wouldn't it be nice if ....") and troubleshoot specific problems ("Why can't I seem to get my product to show up on Marketplace?"), but you can't say, "Hi! I'm Bob Smith and I have a terrific product named Bob's Hair Remover. on sale now". You can get very close ("In answer to your question.... Yes, there are solutions to that problem. I sell one on Marketplace, in fact. "). You just can't add "Look for Bob's Hair Remover at this Marketplace address or at my shop in world at WXYZ sim."

It turns 90 degrees at the start and end because of the llSetRot(ZERO_ROTATION) function in the state_entry event. That's just there to give it a default rotation to start with. If you don't want it, remove it. It should only need to be touched once, at the start. The problem may be that your offset vectors ar VERY small (less than a meter of movement at each step). I'll be able to test it in world soon and will try to contact you later.

Perhaps Inworld Employment, if you're offering a service. There's really not a good spot in the forums. The old forums had a classified section for such things, but LL seems to expect people to pay for advertizing in Marketplace instead now.

We have this same discussion about every 6 months. It seems to be a popular idea. :smileyvery-happy: Take a look at this particularly rich and infomative thread from last year to see the many reasons why the idea never goes anywhere.

No exile. I'm babysitting, away from home and my desktop. :smileyhappy:

Sorry. I was less than pefectly clear. In order to move from one waypoint to the next, you need some way to tell that the car has arrived. That's what the at_target event does, and that's where you need to update the variable new_target , change the car's rotation, and issue the command to move again. When I wrote that set of schematic steps in my last post, I meant you to put them into an at_target event. I have put those actions into a user-defined function (move()), which gets called at the start of each leg on the journey, including the very first one. Notice the logic...... The first thing that happens in the move() function is that new_target updates, calling a new offset from the offsets list. Which value? The one whose index in the list is equal to the current value of count. Once new_target is calculated, the rest is straightforward and the car moves to that new waypoint. When it arrives, the at_target event is triggered, count increases by +1, and move() is called again. The loop repeats itself over and over until count is >= the number of elements in the offsets list. Then everything stops and the script resets. The only caution is that I have not been able to get in world to test this script. It compiles, so there should be no LSL errors, but I can't guarantee that it will work perfectly. (I'm keeping my fingers crossed.) integer target_id;string SensorTargetName = "turning90";float scandistance = 11.0;float scanangle = 0.8; // Radianslist offsets = ["<0.0,0.0,0.0>","<0.1363,0.8127,0.0>","<0.3611,0.8920,0.0>","<0.6719,0.8259,0.0>", "<0.8365,0.620,0.0>","<0.9889,0.3995,0.0>", "<0.9527,0.2249,0.0>" ];integer count;move(){ vector new_target = llGetPos() + (vector)llList2String(offsets,count); llRotLookAt(llRotBetween(<1.0,0.0,0.0>,llVecNorm(new_target-llGetPos())),1.0,0.4); llMoveToTarget(new_target, 4.0); target_id = llTarget(new_target, 1.0);}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(SensorTargetName,"",ACTIVE | PASSIVE,scandistance,scanangle); } sensor(integer num) { move(); } at_target(integer tnum, vector targetpos, vector ourpos) { if (tnum == target_id) { ++count; llTargetRemove(target_id); if (count >= llGetListLength(offsets)) { llStopMoveToTarget(); llResetScript(); } else { move(); } } }} BTW, the reason you had an execution error was that your offsets list was full of vectors, but we were telling the script to look for a string variable. ( I never trust llList2Vector.) Just be sure that you put " " marks around the elements in offsets and it should work fine. As an afterthought .... The script really should have a no_sensor event that does nothing more than say an error message and reset the script if the sensor can't find its starting point. I didn't put that in, but it should be there to keep the car from stalling. Also, I'd suggest using a scan angle of PI instead of 0.8 radians. You're more likely to find the target that way. ETA: I don't know how I missed looking carefully at your offset list. The very first element is <0.0,0.0,0.0>, which ,means that the offset for the first leg of the journey will be ZERO. The car will not move. You should start instead with the second element, <0.1363, 0.8127,0.0>. (Those are very small offsets, BTW. :smileytongue:)

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.