Innula Zenovka

  • Content count

  • Joined

  • Last visited

Community Reputation

2,138 Excellent

About Innula Zenovka

  • Rank
    Advanced Member
  1. Camera Problems

    I can understand that if you try to sit on a child prim without a sit target, the simulator will seat you on the first available sit target (particularly if that's the root prim. Check, though, what happens if you try to select and sit on link2 when no one else is seated. I'm not sure what will happen, which is why I suggest testing it.
  2. Camera Problems

    I can think of a couple of solutions to people sitting on the wrong seat. I'm assuming you want the driver to sit first. The simplest one -- it's not necessarily the best, but it's considerably simpler than the alternative, so try it first -- would be to have the script store llGetNumberOfPrims() in a global variable, iNumberOfPrims, when you rez the object (reset the script on rez, maybe). Also, in the script in the passenger seat, call llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_SCRIPTED_SIT_ONLY,TRUE]); That makes the prim impossible to sit on unless a script uses llSitOnLink to seat them. Then, have the script check, in the changed event, on llGetNumberOfPrims() each time someone sits or unsits. If llGetNumberOfPrims() == iNumberOfPrims + 1, that must mean there's now a driver, so set PRIM_SCRIPTED_SIT_ONLY to FALSE for the passenger seat. If, on the other hand, llGetNumberOfPrims()==iNumberOfPrims, then that means there's no one sitting, driver or passenger, any more so set PRIM_SCRIPTED_SIT_ONLY back to TRUE for the passenger seat. Give that a go and see how you get on. As to the fix for the camera problem not working, I really can't suggest much more without seeing the relevant sections of the scripts (at least, if not the whole script) -- trying to diagnose and fix the problem based on snippets and brief descriptions is simply a guessing game. There may not be a solution -- as I said, the viewer does sometimes get buggy when it's trying to adjust the camera to keep up with sudden violent movements like avatars being unsat or thrown around. ETA Or what Rolig said -- she posted just as I was posting.
  3. While you're completely correct that keeping open listeners when you don't need to is generally discouraged, I don't think it's an issue in this particular case. The reason is that what really hits the simulator's resources is having to decide which messages to send to which object when there are several objects on the region listening on the same channel, and then each of the scripts that receives the message having to decide what, if anything, to do about the message. So in this example, if you're using a long negative channel then nothing else on the region will be sending messages on it, so the simulator won't need to decide which objects should receive it. If you were listening on -1 it would probably be a different story, but if it's -3258485 then there shouldn't be anything to worry about. Furthermore, when an object sends a message on that channel using llRegionSayTo the simulator doesn't do any checks involving other objects -- it simply checks who or what the uuid corresponds to and, if it's an avatar on the region, what the avatar is wearing or sitting on that's listening to that channel. So I really wouldn't worry about using timers and things. I understand what you're trying to do, and applaud it, but in this particular case I don't think it's necessary and, in fact, I think you'd probably use more simulator resources trying to solve the problem than by simply ignoring it.
  4. I would take advantage of the fact that if you call llRegionSayTo(id, channel, message) and the id is the UUID of an avatar, then that message will be heard by a script in any article that avatar is wearing (or sitting on) that is listening on the right channel. So choose a long negative integer that nothing else on the region is going to be using and have the articles simply use llRegionSayTo(kOwnerUUID, iVeryNegativeChannel, strMessage). That way nothing else is going to hear them. If you want to be really sure, you can, in addition, do something like listen(integer channel, string name, key id, string message) { if(llGetOwnerKey(id)==llGetOwner()){ //the object sending the message belongs to the owner of this script //so process it } //else it doesn't, so ignore it } That way it's only going to hear your objects.
  5. Looking For A Teacher

    In addition the excellent suggestions already provided, I'd suggest browsing these forums to get a feel for how people tackle scripting problems. Then find a simple project that interests you, try to tackle it, and keep on asking for help and advice here. That's how I got started all those years ago, and I'm still learning things from what I read here. The problem is that most experienced scripters don't have the time to give private lessons but many of us do hang about in this forum and help people out as and when questions come up. Similarly, you might want to join the College of Scripting's inworld group, which is very friendly and helpful to people who want to ask questions where they get stuck on a script (also it's very helpful simply to lurk and watch what questions come up, and then try to solve them yourself). Other groups I can recommend are Scripts and Script Academy (for the sake of transparency, I'm a moderator in one and an owner of the other) . Builders Brewery is often pretty good for scripting questions, too.
  6. Animation Script.

    Sorry, I misread the question. It's about a hug/kiss animation thing, not furniture (it was the reference to poseballs that threw me). You need two scripts, one to animate each avatar, and it involves several operations for each avatar, which you need to keep coordinated. It's a bit fiddly to get right. The only readily accessible example I can find are the two scripts in OpenCollar, coupleanim1.lsl and coupleanim2.lsl. They make it look a lot more complicated than it is because they have to integrate with all the other scripts in the collar, but they should give you an idea of how these things work.
  7. Animation Script.

    Most people don't write their own code for what you describe -- they use either Avsitter or Npose, both of which are free and open source, and have support groups. Even if you want to write your own code rather use either of those two poseball-free systems, I'd suggest you start by studying the scripts for one or both of the systems. The basic principle is simple enough -- they treat the avatars as components in the linkset on which they are seated, and move them round with llSetLinkPrimitiveParamsFast -- but the the execution can be rather complex. Put it like this; I can write similar code, and have done for some applications where we didn't want to use either of those systems (and to prove to myself I could do it), but I'd normally use one of them since there's no point in trying to re-invent the wheel.
  8. Seems a very narrow definition -- does anyone actually use it? For what it's worth, here's the definition the British legal system uses (both in prosecuting discrimination cases and some types of hate crime). For these purposes, racism is defined as hostility towards people based on their membership (actual or presumed) of a racial group. A racial group, for English legal purposes, is:
  9. For me it's not a question of expense -- I make plenty from my scripting and things my alts have made and a mesh body doesn't seem to me a major expense (particularly after I convert the price to cups of decent coffee, which is my usual comparison). However, I've spent the last 10 years, on and off, tweaking my system shape and experimenting with various skins to get things how I want them, and I'm not going to junk that in favour of a mesh body that I'm going to have to spend ages setting up with new outfits. I have neither the time nor the inclination to do that.
  10. Walkable object

    Rolig gave a link to her library example earlier in the thread: If you use that, you need only change the names of the animations in state entry to match what you are using. It's not a vehicle script but since you're not a scripter and are -- perfectly reasonably -- more interested in getting your object to behave as you want rather than in learning how to script ground vehicles, it's what I'd use as an out of the box solution.
  11. Patch Script to convert land-based plane to seaplane

    I've not tried it but a quick Google search led me to a reply by Dora Gustafson in this thread. Anything Dora writes is well worth serious study, and her suggestion here would certainly be worth trying.
  12. Copy object location & rotation?

    Use llSensor("Name of Object 1", "",ACTIVE|PASSIVE, 20.0, PI); to find the first object , The 20.0 is the radius of the scan -- it can be up to 96 metres but it's best to keep it as low you can -- if the object you're looking for is not likely to be more than 20 metres away (a figure I picked out of the air, of course), there's no need to make the scan radius more than that. Then, in the sensor event, the object's key will be llDetectedKey(0) (assuming there's only one object of that name in range of the sensor). Once you have that, you can use the method Rolig demonstrates to get the object's position and rotation.
  13. Need help with List

    If you want the username it's llGetUsername, not llKey2Name. llGetUsername will return "teresasama" and "Innula.zenovka". llKey2Name will return "teresasama resident" or "Innula Zenovka".
  14. Need help with List

    @teresasama Take a look at the userfunction ListXandY in the wiki: Sounds like what you need. ETA: I would, though, make one small but important alteration to that example. Where it says for (x = 0; x < llGetListLength(ly); x++) { I would put integer n = llGetListLength(ly); for (x = 0; x < n; x++) { The reason is that the length of ly isn't going to change while the script is running through the loop checking its members, so it's a waste of resources (and it slows down the script) to keep on counting the number of items in list y every time you check an item from list x against it.
  15. Camera Problems

    I would clear the camera params, let the script sleep for about 0.1 or 0.2 seconds to give the viewer time to register that, and then eject the passenger. It can't hurt to try that, anyway. There are all sorts of problems associated with the camera and sudden violent movements and the root cause seems to be that the simulator and viewer sometimes have difficulty keeping up with what's going on.