Profaitchikenz Haiku

One thing I have spotted is VirtualKitten trying to do things from the root prim, which is actually a good idea as it means there's one less script, so I revised Puff to show how the root prim can know exactly where the child prim is in the region and what it's region rotation is: using llGetLinkPrimitiveParams(emitter, [PRIM_POSITION, PRIM_ROTATION]); we get the right two values so we can do everything from inside the root prim in the one script. The next problem I spotted was that it is hard to visualise where exactly the emitter prim is casting the ray, so here's a simple technique: build a cube, make it 0.2 metres along X, 0.2 metres along Y, 20.0 metres along Z, and then set Slice Begin to 0.5 The resulting indicator prim is pointing up and down the Z-axis which is where (in this instance) the particles are coming from. Inside it put a script to make it go to a region position and a rotation when touched. // set a prim to a region pos and rot key owner; // <14.90247, 113.65760, 502.84370> rot <-0.54953, 0.54953, 0.44500, 0.44500> vector setPos = ZERO_VECTOR; rotation setRot = ZERO_ROTATION; default { state_entry() { owner = llGetOwner(); } touch_start(integer number) { if( setPos != ZERO_VECTOR) { llSetRegionPos(setPos); llSetRot(setRot); } } } In the root prim, put the following function findLocations() { list params; params = llGetLinkPrimitiveParams(emitter, [PRIM_POSITION, PRIM_ROTATION]); vector emitterRegionPos = llList2Vector(params,0); rotation emitterRegionRot = llList2Rot(params,1); llOwnerSay("Emitter Region pos is " + (string) emitterRegionPos + " rot " + (string) emitterRegionRot); } Now put those two numbers into the script in the indicator prim to replace ZERO_VECTOR and ZERO_ROTATION, and touch it. The indicator prim will now adopt the orientation of the emitter prim along the Z-axis, which is the particle emitter direction, and also the direction along which we are going to ray-cast. Any targets that would be picked up by a cast ray should be touched by the indicator if they are inside the range at which llRezObject can be expected to actually work and not silently fail. I noticed during the tests inworld that the rotation value returned from VirtualKitten's dragon emitter was at ninety degrees to the direction of Puff's vector, and I suspect this is a build issue that will need to be resolved. (I am suspicious that although I saw particles coming out of the emitter along what I took to be the Z+ axis, the rotation value chatted out by VK's script was suggesting that the emitter ray cast direction was at 90 degrees to the particle direction, so I'm betting on confusion in the build, unless some knowledgeable person can step in and say that in animesh, the particle direction is also not as in prims or normal mesh).

So to summarise what was found inworld: Puff was able to find the mesh terrain and plants and rezz an object, proving the script works in a sympathetic build (There were differences in the reported region rotations of the two emitters being compared, so where the dragon was casting it's ray wasn't where Puff was casting his). However, the main stumbling block is that due to the size of the dragon (to which Puff is but a gnat to a horse), the distance from the emitter to the target found by ray-casting is more than the limiting distance of llRezObject. Puff didn't rezz once the range exceeded 12 and a bit metres. The solution to this stumbling block is actually the solution to the other problem, of knowing where the ray from the child prim is actually pointing: Rezz the object just outside the emitter and make it glide along a vector which starts at the emitter and ends at the farthest ray-cast position, then not only will you actually see where your ray is being cast to, but you're almost there with the rezzing the fireball regardless of how far away the incineration point is. I'll try beefing up Puff to have a mightier weapon than his diminutive size would suggest.

If they're sculpts then the hitbox that llCastRay works on is nothing like the visible shape, and they (and possibly many mesh trees) will most likely be set phantom to allow avatars to move. When you say my script doesn't work, what are you testing it in? How far away from it is the land near your house?

There is no point in your pursuing a trig solution until you can master the art of using radians for functions that must be given inputs in radians, not degrees. Until then, I suggest you adopt the simplt method of using rotations to operate on vectors where you do not need to do anything other than Pos1 + (vector*rotation).

in the above, a1 is converted to degrees, (a1 *= RAD_TO_DEG) angle_top is therefore in degrees, (a1.y) llTan(PI_BY_TWO-angle_top) is trying to get the tangent of a value in radians - a value in degrees. This is back at the starting point, after three pages. And it's not the best solution, because as you've said And that's why I showed you how to do it all from within the emitter prim, when it will do it when the dragon is rotated. The emitter child always knows where it is within the region and where it is pointing within the region using llGetPos() and llGetRot(), and you do not need to resort to spherical trig to solve it

This cannot be a location, the Y coordinate is too large, and the Z coordinate is negative.

You have a real mish-mash there of several different techniques, but as far as I can see you are trying to do all this from the root prim. There are three chunks of code in three posts, I don't know what the significance of the blue text is in the first, but I also think trying to do a side-by-side comparison of three variants is counterproductive. My suggestion is to do the rezzing from within the emitter child prim, using the simplified script I posted above. You can forget about the root position or rotation and just concentrate on where the emitter prim is. It might be possible to do all this from the root prim but it's more work. I've shown you a method to do this from within the child prim, if you really must do everything from a single script in the root I would suggest you get the child prim method working first and use that to give you comparison figures of positions and rotations which you then use as the guidelines for adding the similar functionality to the root prim's script.

Rather reminiscent of an obfusticator for C source code I saw once.

I see that but just leave it and after 60 seconds or so it does indeed close down. I'm usually doing other stuff at exit time so it's less fraught than when I'm TP-ing around.

I saw stuff in the log file suggesting timeout, but what I am puzzling over is, did the region I was trying to TP to not get the message to say "incoming!", or did the region I was going from not get the message "trade for you!". I couldn't tell from what was there (and ther's masses of stuff to wade throuh). It would be useful for debugging if it were possible, when stuck like that, to force a re-transmission of the whole TP-request thing in case it can be resolved by a second bout of messaging.

"I wonder if it will be friends with me?"

I can confirm this, (with Catznip, usually the most reliable of the viewers I use) - the screen goes black as expected but then no further progress bar change occurs. It is possible sometimes to cancel the TP attempt but this results in being unable to move or perform any other activity, after some period the " you have been disconnected...." message appears. Without cancelling, he black screen can last for several minutes before being shown the greyed out scene with the disconnection message. On reconnecting, the location is the first login location, not the point from which the TP attempt was made, and the inventory floater is no longer opened. Upon clicking on the attempted destination before the crash, an immediate and successful TP occurs. Also, going back to the location from which the TP attempt failed and trying it again also invariably succeeds. When tying to TP and failing, there are no precursors to warn of a probably failure, textures are all fine, moving around is fine, no rubber-banding or chat lag, this applies to the whole sequence of successful TPs up till the fail point.

Poor old Mr Chamberlain, he tried this so assiduously and had his hopes dasheed. SL allows us to explore pretty much the whole gamut of human interactions (bite, touch and smell obviously excluded), and that's a valuable asset. Why not explore the more dangerous emotions such as anger and conflict in a safe environment instead of bottling them up until they emerge unchecked in the real world?

/me raises his hat

I suspect this is a challenge to debate via emoticons.

B-b-b-but, we're in virtual reality, so different rules apply?

Are you using it in realtime protection mode or just for regular scans? I think the former is the problem.

Can't quote the heading from the post, but would "requirements for believable agents" cover fantasy characters? One or two of SL's residents sort of fall into that category.

Seems to start up quite Ok, like I said, I depend on this behaviour in scripted objects given to people clicking on things. Such objects then attach to the new owner or rezz, and function exactly as expected with no need to do more than just reset the script to get the new owner (and according to some posts elsewhere in this forum even a reset is not always necessary to do that, just close any listen channels previous open to the old owner, grab the new owner and open the listen again). What I think Nova is referring to is when you want an object to give a new, or updated script to an object owned by somebody else, or to one of your own objects rezzed or attached; where the script arrives in the target in a stopped state and has to be explicitly started by the object owner with an edit operation, or else it has to be transferred running with the PIN operation. Provided the OP's Hud script has a changed_owner section I don''t see why there should be any problems, unless as I've said there is some quirk to Huds I am unaware of.

I've seen some of what you mention, especially the TP-crash and subsequent loss of floaters opened, increasing more during the past couple of weeks, but I don't think it's necessarily the cloud, nor even LL's code. The cloud move took place some time back and the recent increases can't therefore be attributed wholly to it. I think it's showing network traffic on some routes is causing delay in your viewer and the region communicating and then a time-out forces a disconnect.

Before Temporary Textures were turned off (for ALM I think?) I used to fake mirrors with a cropped snapshot stuck on the mirror face with the horizontal offsset given a negative amount. Given that Black Dragon can already do local poses, what are the complications involved in getting the current camera view into a temporary texture (which I suspect happens as part of the process of taking a snapshot), applying a surround masking of the mirror frame, and slapping it on the surface with the horizontal reversal?

I've also found myself stretching my areas of knowledge, I'd never done raycasting before this week. It's interesting that it isn't just the OP who gains through the forum advice process, those responders who actually get into some research also benefit. For those who know Anathem, there is an analogous situation described in the early part of the tale, when Erasmus realises that in mentoring Barb he himself is filling in large gaps in his own knowledge where he had skipped topics because they were not in his immediate requirements list or he was in a rush to get something done.

I agree with the need to reinstate something like this. It would also help to minimise the "new-user-feels-alone" reaction that there are strong hints of. There is also an added benefit to the helper and mentor I have recently become aware of: the learning experience extends to the mentor as well You can never know everything, and being taken out of your familiar territory by somebody's odd request leads you along very interesting paths.

Now I'm confused: I regularly create scripted items, put them into a giver prim, and when somebody touches the prim they are given the items either singly or as a folder, and they just put them on and everything is working. The state of the scripts in the items when I putt them in the giver is saved and wakes up again when rezzed or attached. Are Huds somehow different?

Yes, Quistessa's suggestion is putting the Container into the container so it is available as content