BrownBoxStudio

True, that isn't needed now that I think about it. But I tested without that, or at least I thought I did. The working script has it too without any issue. Either way I will test again. Thanks for the suggestion. Edit: Nope, removing both llGetRot()s made no difference.

I am making a game with sound effects. I have the games base script which uses LLTriggerSoundLimited and it works perfectly fine. Although I said the function doens't work and I'm not lieing, this is the only function call I have gotten to work. Nothing else will trigger in any other object. I went as far to put all the scripts from the working game into a new root prim and link that to the build and no sound triggers. It's very odd. It's as if I somehow got the script to work in my one prim and now it won't work in anything else. This is a piece of the working version that includes the llTriggerSoundLimited(); state pay { state_entry() { llSetPayPrice(price, [price, PAY_HIDE, PAY_HIDE, PAY_HIDE]); } money(key id, integer amount) { if (amount != price) { llRegionSayTo(id, 0, "Sorry, you have not paid the correct amount and have been refunded. Please pay " + (string)price + "L$ to play."); llGiveMoney(id, amount); } else if (amount == price) { llRegionSayTo(id, 0, "Thank you for paying. Your game will start shortly. Quit the game before taking a turn to be refunded."); player = id; llTriggerSoundLimited(skeeball_paysound, skeeball_paysound_vol, llGetPos() + (<sound_offset, sound_offset,0>* llGetRot()), llGetPos() + (<-sound_offset, -sound_offset,0> * llGetRot())); //skeeball new game music llSetTimerEvent(4.51); } } timer() { llMessageLinked(LINK_ROOT, 0, "new game", player); state play; } } This is a solo version of the above excerpt that I created to test which I cannot get working in any other object. key player; integer price = 1; //sound settings float sound_offset = 10; float skeeball_paysound_vol = .5; key skeeball_paysound = "3a8add53-8813-33db-3dac-ad60918b9020"; float skeeball_fanhumsound_vol = .14; key skeeball_fanhumsound = "0b9b5a63-2630-f331-8e61-bc39496983c6"; default { state_entry() { llSetPayPrice(price, [price, PAY_HIDE, PAY_HIDE, PAY_HIDE]); } money(key id, integer amount) { if (amount != price) { llRegionSayTo(id, 0, "Sorry, you have not paid the correct amount and have been refunded. Please pay " + (string)price + "L$ to play."); llGiveMoney(id, amount); } else if (amount == price) { llRegionSayTo(id, 0, "Thank you for paying. Your game will start shortly. Quit the game before taking a turn to be refunded."); player = id; llTriggerSoundLimited(skeeball_paysound, skeeball_paysound_vol, llGetPos() + (<sound_offset, sound_offset,0>* llGetRot()), llGetPos() + (<-sound_offset, -sound_offset,0> * llGetRot())); //skeeball new game music llSetTimerEvent(4.51); } } timer() { llMessageLinked(LINK_ROOT, 0, "new game", player); } }

Just wondering if you might be willing to explain what the float code is doing to convert the uuid strings.

Wouldn't reading a notecard leave room for lag too since it's calling the data server? That is why I thought a series of scripts, one for each type of piece, might work with the positions saved in each script. Although if a notecard isn't going to cause any issues it could work. Although maybe we are talking about two different things? Are you talking about pre-loading the whole notecard? I'm considering the possibility that there may be too many vectors for the script to load.

Lol, I'll have to take that chair advice. Doesn't seem like there isn't much to do about server and viewer lag, we can't access frame rate. As long as the system is optimized as well as possible I'd just have to hope for the server to run well too. A system will have to be figured out that can handle all these positions, precalculated like Qie suggested. Wouldn't want to add potential for more lag than SL already adds to itself.

I did some testing with a function I found, link below, and there isn't any stuttering. As long as the camera is following the avatar it doesn't stutter. I am pretty sure it works the same for anything else, like rolig was mentioning. Rolig Loon wrote: Yes, certainly. Conceptually, there's no difference between placing physical waypoints along a precalculated curve and placing them along a curve that you have parameterized as a set of splines in your script. I know a few LSL scripters who have the math skills to do that, although I am not one of them. And you might be able to do the whole thing without keyframed motion too -- or someone might. Well, your totally right cause I found a function that someone already wrote to interpolate between vectors for a spline. http://wiki.secondlife.com/wiki/Interpolation/Spline/Vectors So now the question becomes optimization. The script does take a list of preset vectors but it calculate the interpolation between the vectors on the fly. It moves the object X distance defined by the "t" float. That could cause issues with lag and such. I didn't think about regular movement being server side. Qie Niangao wrote: I will just add: Avoid calculating motion in real-time if it isn't absolutely necessary. It can be necessary if the path itself is dynamic (e.g., avoiding unpredictable obstacles, or non-repeating), but otherwise it's always a win to have the motion all pre-calculated, pre-sampled, and ready for playback, whether that playback is by KFM or something else. (In those cases where the path must be dynamically computed, I think the physics engine will do best, except maybe when motion is so very, very slow as to obviate the inherent speed disadvantage of scripted calculation.) How would that be done with potentially hundreds of vector positions? I can't imagine the script memory having the capacity to handle all the positions needed for proper splines in SL. A rollercoaster is preset so it makes sense to precalculate but depending on the size of a rollercoaster the script isn't likely to have the memory for it all. Are there ways that this can be done? Maybe using an outside server? But even then would requesting another server cause the same amount of lag as a calculation? Actuall I can think of one way but it stats to get more advanced, a system instead of just a script. If there were premade scripts for specific pieces that held the preclaculated movement, to cut down on how much memory the vectors use. Then you have a base script that triggers pieces in the proper oder/configuration. That way there is enough memory in each script just for it's own piece. Although is there a limit to how many scripts can be in an object?

What about a system that only works with cubic splines, disregarding keyframed motion? Maybe I am not understanding keyframed motion well enough but I always thought that each keyframed movement had to be setup within script before hand with it's own "llSetKeyframeMotion". At least that is how I have seen the function used. Could those keyframes be setup on the fly based on what is previously calculated through the splines? Although if the specific points of momvent were already calculated out does keyframed motion still have a use? Edit: Just saw your edit and I have considered the work vs effort a bit. I think in this case the average user would be able to tell the difference. Although whether or not the difference matters to them is another topic in itself. But really this would be along the lines of, as you said, a creative exercise. It just happens to fit alongside the other projects I am doing and would get my foot into learning more math, which I need to in the long run for game programming. LSL happens to be a really easy to get into language for learning basic concepts so it is what I've been learning on. Also I don't really see the velocity aspect being much work if I can figure out the pathing. It'd just be a lot of testing of paramters until the speed vs height feels right and even that can be eye balled. Even SL physics system at times feels a little eye balled. 2nd Edit: I have noticed on other rides I've created, using PRIM_POSITION, a stuter between each movement; despite the movement being miniscule. Is that what keyframe motion is meant to fix?

Ah, had to check that one out again. It was closed the last time I was there. I see what you mean about smooth but I'd like to think it could be better. While keyframed motion is extremely smooth the movement of the vehicle itself is odd at a handful of sections. It seems that is a side affect of interpolation. Or is that the fault of how the keyframing was setup? I've not messed with keyframing much. In a way what I am thinking of is similar to keyframing but instead of being interpolated the movements would all be calculated out. Are custom paths with curves and such not possible? The one bonus I can think of would be the ability to create "physics" of sorts that couldn't be done with keyframing. Such as gravity through limits to speed based on height. If car goes down a hill that is 30 meters it will have a certain speed. When going up hill the car could lose speed the closer it gets to a percentage of that 30 meters. Or adding things like friction so if the vehicle stays on the same height it will slowly lose speed.

I'm not very math minded, mostly due to a lack of math knowledge, so I thought I might start a conversation about this subject and see if anyone can point me in a direction to learn. Recently I've been working on movement of theme park rides and in turn I've been considering the possibility of a smooth rollercoaster in SL. I've seen rollercoasters before but they aren't up to par with what is made outside of SL, relying on poor SL physics. I would like to step away from relying on SL physics to make a coaster work. Other engines have tools for creating paths, splines?, that allow for smooth movement along the line of the path but SL doesn't have that. Considering that at the root of the tools is math for calculating the lines I am wondering if similar results could be achieved in SL. I have in mind calculating the curves, or straight lines, and merely stringing them together, of course it would be more complex than that. Has anyone messed around with stuff like this before? Am I off base in what I'm considering? Any thoughts are appreciated. Merely wanted to start a conversation and see what anyone else here had to say on the subject. Maybe I need to go take some more math classes.

Are you wanting to be able to say the transparency % in chat and then have the object change to that percentage of transparency? Or do you specifically want only two states of transparency?

I see , well then another thought for OP. A gesture is just a combination of chat, sound, and animation, right? Couldn't the "gesture" be turned into a script?

Seems there may be multiple LSL add ons for sublime. I've always used this one which has great instructions. The instructions are near the bottom of the page. https://github.com/Makopo/sublime-text-lsl

Can't scripts trigger gestures with chat commands? I guess that's not technically the script playing the gesture but it is the same effect.

So what if the truck and the turret were seperate objects and the turret just followed the car around? Lag could cause some issues but may be better than control conflicts.

Aside from what Rolig suggested, what are you aiming to accomplish? Maybe we can suggest another way to do the same thing?

SOLVED EDIT: Sorry, always asking these questions too soon. I forgot to add the child prims rotation to the root prims rotation. I'll leave this here incase anyone wants to ever do the same thing. The working code is as such. It allows you to have a raycast from a child prim, at any rotation, while the room prim is also at any rotation. vector ray_start = llGetPos() + ((childprim_pos + < 0, 0, .05>) * llGetRot()); vector ray_end = ray_start + (< 0, 2.5, .05>*(childprim_rot*llGetRot())); list results = llCastRay(ray_start, ray_end,[RC_REJECT_TYPES,RC_REJECT_PHYSICAL,RC_DETECT_PHANTOM,TRUE,RC_MAX_HITS,1]);_____________________________________________________________ I am trying to create a raycast that starts at a child prim and goes X meters in a direction relative to the child prims rotation relative to the root rotation. The child prim is an aiming device for a game and can be rotated by controls so I need the raycast to stay in the same orientation relative to the child prims position and rotation. I thought I knew how to do this but so far it has not worked. Basically I am rotating a vector around a child prims position around a root prims rotation. I think the child prim aspect is messing me up. This is my current code; arrow_pos and arrow_rot are the child prims params. vector ray_start = llGetPos() + ((arrow_pos + < 0, 0, .05>) * llGetRot()); //arrows adjusted position based on root rotation. vector ray_end = (ray_start) * llGetRot())+(< 0, 2.5, .05>*arrow_rot); list results = llCastRay(ray_start, ray_end,[RC_REJECT_TYPES,RC_REJECT_PHYSICAL,RC_DETECT_PHANTOM,TRUE,RC_MAX_HITS,1]); To get a child prims global position, ray_start, I thought you adjust the child prim position by the root rotation and then add that new position to the root position. Then to get the ray_end I took the new vector, modified that by the child prims rotation and added that to the child prims position. So far this has not worked. Any suggestions of where I have gone wrong would help. I am finding this extra hard because I cant think of a way to visual the ray casting. I have no way to see how off I am. Is there an easy way to see the ray that is cast?

Rotation and or Move are used pretty often.

Thank you so much for explaining rolig! I got it working I guess GIFs don't run on the forums so here is a link for anyone curious to see what I was trying to do. http://i.imgur.com/HQ57vCu.gif

Well thanks for mentioning. If you noticed I am looking for beta testers so hopefully I can find out about effects like that. Though if it is a problem I'm not sure there is an alternative solution. Unless I can have one child prim detect collision with another child prim? Edit: Got a suggestion, in a script group, of doing some manual math to track the location and intersection so may have a better alternative to ray casting. I can track the prims corners and see if they go past the edge of the lane.

Thanks very much Rolig, helps me understand a bit better. Although I am still a confused on the list rules returning the information. How is item 0 of "results" the TargetUUID if the first list item is RC_REJECT_TYPES? @Steph: Is it enough to worry about?

Hi Guys! I'm trying to learn about, and use, llcastray for a game. I see rays are quiet capable but the wiki seems a bit sparse compared to what I seen other programs shows is possible. I can setup the ray I want but the list options elude me. I'd like to get the uuid/key, or link number of a collided child prim but am not sure how. Also the point of collision but did not see any rules to do so. Is that possible? To give some background I am finishing up a skeeball game. You shoot the ball by moving and rotating a child prim with arrow keys to throw the ball in the prims direction. I'm seeing about using raycast to setup another child prim to act as an aim line such as in the Wii Bowling image below. In Wii Bowling when the line collides with the edge of the lane the line shortens which is why I need the ray cast in the first place and the collision point, to set a proper line length when colliding with the skeeball lanes edge. I don't usually ask for so much help but llcastray seems to be very capable but I can't find much information on it. Any help or suggestions are appreciated! Thanks ahead of time!  Also, a side note. When I have the program finished and mesh created I will be looking for some beta testers. Anyone interested? I would have some questions and in return you would get a copy of the final game, plus future updates, and one or two that can be shared with friends. If your interested, let me know. Thanks Again!

@Rolig: That does it, exactly what I've been trying to do. Thats an amazing script. Thanks so much. Now I just have to study and figure out why that scripts works. I came to realize it was more complex than I thought. @Dora: You seem to have it right but in the script rolig linked to the ZERO_ROTATION is taken away and then added to the local rot. If I at least understand that correctly. Thanks for all the help! Edit: I'm actually a bit confused. Maybe someone would care to explain? The only different I see in the script solution vs what I did was setting the rotation angle to be (angle = (zero_rotation/angle)) What is the zero_rotation adding into the equation that I was missing? It doesn't even need a second llSetLocalRot to change the door angle back which amazes me even more.

Still only acting upon the sims axis and not local axis. In testing I'm not seeing a difference between PRIM_ROTATION and PRIM_ROT_LOCAL or llGetRot() and llGetLocalRot() when used on the root prim, at least in my current use. Edit: So I noticed the cavaet that PRIM_ROTATION is always the global rotation and it says to use PRIM_ROT_LOCAL but as I said that doesn't work either. Z is always up despite the prims Z up not facing up. Is there an issue with using llSetLinkPrimParams on a root prim?

So I am working on creating a door script that will have a prim rotate around it's local axis despite it's initial starting angle. Except I am having issues with getting a single prim or main prim to rotate around it's local axis. The script works for child prims works beautifully but I can only get a main or single prim to use the sims axis. This is what I am using for the child prims and it's successful. I have tested many combinations of llGetRot, PRIM_ROTATION, llGetLocalRot, for a main or single prim, to no success. I am either missing a combination or have done something wrong. Any suggestions on what I can try? Thanks for your time. Any help is appreciated. if ( touch_count == 0) { llSetLinkPrimitiveParamsFast(llGetLinkNumber(), [PRIM_ROT_LOCAL, llGetLocalRot()*open_rot]); llPlaySound( open_sound, volume); touch_count++; } else { llSetLinkPrimitiveParamsFast(llGetLinkNumber(), [PRIM_ROT_LOCAL, llGetLocalRot()/open_rot]); llPlaySound( close_sound, volume); touch_count = 0; } }

I've not run into this problem before and I am not sure why. The normal map for my mesh seems to have extra compression than the usual. Is there any fix for the compression? In the example below the sides of the mesh should be smooth like the top. Due to compression the normal map has turned out just the slightest bit rough. Are there any fixes or possiblities to make the normal map at all smoother? Thanks for any suggestions. The normal map is currently a 1024x1024 jpg.