Innula Zenovka

TomWCU wrote: Hello, All. My name's Tom. I'm working on a project that may benefit from using an autopath, but I can't seem to find any information on the subject. It sounds as though you've all had some experience with it. Could you guys and girls take a minute to help me out? Here's what's going on: I have a ghost I want to be able to wander the hallways of a maze. Currently, I have invisible prims that detect collisions with the ghost and tell it when to turn. This works fine, assuming no one bumps into the ghost. If someone bumps into him and knocks him off his path, he'll crash into a wall and just stay there. I hoped I might be able to just make linear and angular deflection impossible, then let people bump into him to no effect. No luck with that - he could still be moved by avatars. So, is there a better way to make him stick to his path? If so, how should I begin? Your ghost could use the new llCastRay to see if he's going to run into something. Or he could use a sensor to look for the waypoints. Or if you want to stick with the present system, I'd play around with setting llVolumeDetect(TRUE) and then have him use llDetectedType() to check if he's collided with an avatar or one of your prims. Though you have to be careful, of course, making physics enabled objects, in effect, phantom or they go through the floor.

I guess if anyone does feel concerned about posting something, the Linden Lab comment in the other thread, "Note - If there is a need to post content outside of Linden Lab's content guidelines, there are external forums and blogs, " reminds us that there's always SLU or SCmkII on which to carry on parallel discussions. In the past, after all, people have carried on lively and signficant debates about things like Emerald or Red Zone in multiple fora, saying in other places what certainly couldn't be said here in the Official Forum.

I don't really see what the worry is; off the top of my head, I can't think of anything that was posted in the old private forum (which seemed a bit of a waste of time, as it turned out) or that's been discussed in the Adult Content Users Group -- transcripts of which are posted in the wiki -- that anyone should worry about posting here.

I don't think so. To my mind, both from what's been said at the Adult Content Group and from developments like the simplified age verification proceedure and having Adult Content in the Destination Guide, we're enjoying a lot more official recognition and endorsement than have we done for a long time.

Yep, looks like Viale has done what he planned to.

At the last meeting of the Adult Content User Group, Viale Linden was talking about relaunching it as an open access section, with several sub-forums for content creation, destinations and so on.

I've just taken the new Development Viewer 3.2 out for a spin. It comes with a load of known bugs, notable that it crashes if you try to TP anywhere, but it's worth a try for a look at the new UI. No more sidebars. Just a load of buttons which you can move around and customise endlessly. This is what my UI looked like after a bit of a play (that's my AO down at the right hand corner): Other notable changes are the the chicklets and toasts and dialog menus all appear now at the top right, which I find far more convenient. And they've ported over the single click to walk somewhere from the "Basic" viewer, which is fun. More write ups at Living In the Modem World and Nalates Blog. We've also been chatting about it over at SLU. Like I said, it comes with a load of known issues Here's a quick rundown of some of the known issues: The Viewer floater camera views and presets do not work.The Nearby Voice panel does not update to a new call or from nearby voice info once opened.Viewer crashes when updating UI size in preferences.The Speak button is activated when dragging and dropping between toolbars and/or moving back to the Tool Box.Viewer crash when moving the speak button from one toolbar to another when there is an active call request.Teleport history doesn't display visited locations.Viewer crash when double-clicking the mini-map in People > Nearby.Notification and conversation chiclets overlap.WASD controls don't move avatar while the Move floater is in focus.Closing voice controls while a group or p2p call also closes the group call/IM window.Viewer crash after teleport.Hitting back in the 'Create Group' panel or 'Blocked' panel requires multiple clicks for action to occur.The team is busily addressing these issues and will be updating as we plan the next couple of beta releases. If you see other issues, please report them in Jira as always and we'll make sure they are routed appropriately. But, with that in mind, it's well-worth downloading for a look at the shape of things to come.

Are you receiving this message in the form of an IM? If you are, you should be able -- with most viewers -- to click on the object's name in the message to bring up a floater giving a slurl for the object. Then you can click on that to go to the slurl, where you can take the object back into your inventory. As I suggested when you posed this question elsewhere in the forum, it sounds to me as if you dropped the object on the ground somehow, without realising it. So the first step is to locate the object.

Did this outfit include an item called a "Fly body hider"? If it did, I strongly suspect that you dropped it on the ground when you removed the outfit, as opposed to detaching it, or that it's somehow ended up on the ground, and it's still there, and that's what's causing the problem. Can you remember where you were when you removed the stuff?

Thanks, both. By playing with Taeas' suggestions I've been able to get it working pretty well on normally rough ground, but am having problems with small solid obstructions, such as a single step, which an avatar would negotiate with ease. AnneMarie's accelerator suggestion may well hold the answer to that.

No, you can say what you want to on third-party sites, including your own blog. You can reproduce your chat logs there too, if you want to. So long as it's not on LL's servers, the ToS don't apply.

Thanks, Sassy. This looks like something that should be on the agenda for harmonising between the various versions of RLV. In the meantime, I guess it really points up the necessity of testing stuff on a variety of viewers; you and I are aware of that, of course, because we know RLV and RLVa can behave a bit differently, both as compared with each other and across different versions, but Firestorm/Phoenix in particular can now and again be rather quirky in the way ordinary LSL behaves, too.

First, I would try rebooting your cable modem, if you haven't already done so. This should force a new connection to the sim. Then try relogging, and, if the problem persists, try relogging yet again, somewhere else. If you find you can log in successfully in other places, that would suggest the sim needs a restart (which it should get automatically in the next few days, anyway).

I don't quite understand from the description -- what's the central, root, cone doing? Is it pointing towards you, like all the others, or looking some other way? My immediate thought is this would be greatly simplified if you had a root prim -- possibly an invisible one -- that looked the way the follower was going, and it was only the child prims turning to look at you. I'll try to give this a shot when I get home this evening (UK time).

Glad you got it working. I think the issue seems to be the ~ tilde at the start of the folder name. I've just tried it in Dolphin 3 (which uses RLV v2.07.03.03) and I couldn't get it to work while the folder was called "~Boots", but renaming it as simply "Boots" fixed the problem. This might be because, I think, the ~ prefix is has to be used for items you give to the #RLV folder using llGiveInventoryList, so maybe, in RLV, if not RLVa, it should be reserved for that.

There's nothing wrong with the syntax that I can see. I've just tried llOwnerSay("@attachalloverorreplace:~Boots/bax red boots 2=force"); in Catznip 2.8, and it works as expected. What version of RLV are you using, and, if you enable debug output, what, if anything, does it say? RLV is very picky about spacing; that's what I always check first. ETA -- it might be worth checking to see if you're under any restrictions -- perhaps from a relay -- you've forgotten about.

I'm trying to make a very slow moving vehicle, based on VEHICLE_TYPE_CAR, that can nevertheless negotiate bumpy ground by going over large and sudden bumps in the groud without losing a lot of speed or stalling. If it handles rough ground as well as can an avatar, I'll be very happy indeed. What parameters should I be looking at?

I've seen that message a couple of times over the last week when trying to log in at my home location. Both times, I've been able to log in without difficulty at a different location, however. But when I then try to tp to my home, I get a message saying the simulator isn't available. And it remains that way until a device on my sim sends me a message saying the sim has restarted. From this I infer that one reason you might get the message is if you try to log in somewhere that's temporarily unavailable, perhaps because of the rolling restarts. So a possible fix is to try to log in somewhere else.

To make attached objects, such as huds, play sounds that can be heard by people other than just the person wearing the object, you need to use llTriggerSound() instead of llPlaySound()

Since you say you were given the ability to "eject/ban/freeze avatars on a sim," do you mean that you have estate manager powers? You need to be using those from the Region/Estate menu. Remember that, at least at present, parcel bans are only effective up to 768 metres above the terrain mesh (though I think I read somewhere that this soon to be extended), so if you're trying to remove someone from a platform above that level, I'm not sure how effective it will be. There's other things might be happening; a favourite trick, I understand it, is for the banned person to stand just outside the parcel and play a stand animation with a sufficiently large offset to make it appear he or she is inside it. And I'm not completely sure what happens if you're sitting on something when someone tries to eject you. I tp people home before I ban them. That usually gets rid of them.

Assuming it's only supposed to work when you wear it, I'd take advantage of the fact that you can't wear something that doesn't belong to you, and just do something like this: float gfTimer = 1;integer giChan;integer giPressable;key gOwner;default { attach(key id) { if (id) { //check if the HUD has got attached, not detached gOwner =id; giChan = (integer)("0x" + llGetSubString(gOwner, 0, 7)) * -1; //compute a channel number based in the key of the owner } giPressable = 1; }}

It's two related problems, though, isn't it? There's the general problem with the TDR error firing too readily and the specific one that SL's using the deprecated OpenGL calls is pretty much guaranteed to make that happen. Matters are futher complicated by the fact that, under certain circumstances -- and, in my case, this is certainly one of them -- the error, or the circumstances that caused it, seems to damage the Nvidia driver to the extent that not even doing a clean reinstallation using the Nvidia installer fixes things, since that apparently leaves some damaged dlls and registry settings untouched. That happened to me, and after that I just couldn't in with anything. In those circumstances, I've discovered, the only solution is to do a complete uninstall of the Nvidia driver -- I used Driver Sweeper, and followed the walk-through here -- before attempting to do reinstall anything (in my case, I reverted to the 260.99 driver, which seems to have resolved my problems).

This jira seems to cover it: https://jira.secondlife.com/browse/STORM-1635 As far as I can make out, LL is aware of it, and a fix is ready for testing, but, in the meantime, Peggy's advice to use a stable version of the viewer, as opposed to the beta, seems very sensible. Though I notice the report in the jira says "Setting the newly introduced MemoryPrivatePoolEnabled debug setting to FALSE makes the problem go away," so that might be worth a try.

I've just checked my full perms copy of SexGen -- which has been sitting in my inventory, rather than rezzed in world, though I'm not sure if that affects anything -- and it still appears to contain animations by all four animators.