Vulpinus
-
Posts
545 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Vulpinus
-
-
Thanks for the answes folks. I thought it odd that the view drooped slowly when I moved, rather than simply being suddenly overridden by an existing setting.
Anyway, I solved the issue by reading more about how it all worked and dropping in a simple script to set the link camera settings for the sit link (turned out to be the root). Clearly that's how it was done in the existing script. Provided I made sure that my script runs after the original script gets a reset (which it does in certain circumstances) and before I sit, it works perfectly.
Problem solved
-
Whirly, I've just got a good log a capture of a definite saturation event. I'll PM you the link in a moment. The packet capture was similar to what I mentioned previously.
...
Just to be clear, FS taking a long time to quit for me was because of the ongoing saturation of my internet connection. I haven't (yet,
) suffered generally from the problems mentioned above by wheroangi. -
Thank you both for that clarification. I had never realised that; I always assumed (and we all know what that does) that it worked the same way as the user trying to view it.
It's something to bear in mind. I was more concerned in my case with simply not breeching the terms of use of the textures.
But yeah, no texture is safe from the cache browser. Mine always seems mostly full of people's thumbnail pictures from groups though.
Hmm... now I know how to get all those animation settings from some furniture that I wanted to reconfigure, but it had a locked config nc which made it more work that it was worth.
-
1
-
-
Thanks Whirly, yeah I figured out which concurrency setting it was; the new one for pipelined http. I set it 1, and still got the saturation issue on another trip to Fanci's deep; a good 6-8 seconds of it when I moved a few metres from the tp point I use every time, 12MB of data.
Of course if the server can send data that fast for one http request then one or a hundred makes no difference.
All the textures there should certainly be cached so I doubt it was textures causing the saturation, and my previous wireshark capture showed hardly any texture get requests compared to mesh. I will try setting the texture load concurrency tomorrow and see what happens. I wasn't running Wireshark this time but I will tomorrow.
Something has just now occured to me... Fanci's deep is full of older sculpted things underwater (AleyMart stuff). I just wonder if that's why I seem to get hit so badly by the saturation when there. Would sculpts be retrieved with an http get 'mesh'? (I don't know if prims are treated differently to uploaded mesh.)
That said, I do get it a little in other places too; even going back home.
...
Yes, I still get the texture thrashing, although not as frequently recently, possibly due to a change in my pattern of movement. I had wondered if they were related somehow, too. ETA: Having said that, I have not had the two things happen at the same time.
I agree about the thrashing being odd in those locations with my usual view distance; that's partly why I eventually mentioned it. I've been to far, far worse places and not had it.
I think it is any teleport that stops the thrashing, rather than specifically a double-click tp. Certainly I still do the same trick and it still works. I'm guessing that the tp event causes some change in the texturing process, like restarts it or something.
-
It's just occured to me that there's a mesh concurrency setting in the debug settings. I might try turning that down and see what happens.
Maybe it's because I'm so closely connected to the CDN server... and a dozen other random thoughts
-
I've just grabbed a capture while a good, solid saturation event happened. Only took a minute for it to hit this time.
It seems the CDN server I get connected to is on my own ISP's network! Wireshark revealed most of my traffic for SL is directed to my own ISP's IP range. A DNS lookup confirms that the CDN server's url goes there. That should be a good thing for me!
A good third of all the packets I captured had LL servers' IP addresses, and marked as 'GVSP' protocol. What is LL using that for? I don't think that's anything to do with my problem though from the distribution and size of the packets. They tended to occur in bursts, then none for a while, then another burst.
A tiny fraction of the packets were small UDP packets.
That leaves almost entirely TCP packets between the CDN server and me. A quick count for just one second during the saturation gives numbers that fit, a bit over 2MB per second. Mostly full (1514 bytes) incoming packets and outgoing ACKs.
The vast majority of http headers showed most of the requests and data were for mesh objects, with hardly any for texture (in fact, none in that second I counted over). For example:
GET /?mesh_id=0dbb6642-c6cd-58ae-7f68-b993b17426a0 HTTP/1.1 GET /?mesh_id=1f4bdb20-b7e4-acca-e319-df8a79c4db31 HTTP/1.1
Given that I have been around that area (Fanci's Deep) a lot recently, all the textures should be cached.
I could not see anything in the capture that indicated anything unusual, just loads of data. Over the entire time of the saturation, the capture looked like this. I'm going to go though it in a bit more depth but on the face of things it looks simply like the CDN is suddenly sending me big bursts of data for mesh.
I'm still suspicious about why this can happen in the middle of nowhere, yet doesn't necessarily happen when tp'ing somewhere completely new with loads of new mesh to look at. Sometimes it does happen, in busy places, but not always.
That saturation clearly (on my system at least) causes control input and viewer updates to practically cease, I guess as the different data streams contend for access to the overloaded internet connection. Even trying to quit the viewer takes a lot longer than normal. IF this is the answer to it all, then it's something that needs addressing to prioritise traffic differently.
And why oh why is none of this shown on the statistics panel??? It shows almost no incoming data when this happens.
-
Hmm. I've been trying to avoid having to put wireshark onto it, that's too much like being at work. It has been in the back of my mind though.
I'll wait until I'm in the mood for some packet sifting, and I've had a little more sleep and less rum
-
I have a vehicle, which imposes a fixed but poor camera position when seated. The solution: Override it with my own...
I've never used the camera functions before, but it looked simple enough:
llClearCameraParams(); // reset camera to default llSetCameraParams([ CAMERA_ACTIVE, 1, // 1 is active, 0 is inactive CAMERA_BEHINDNESS_ANGLE, 0.0, // (0 to 180) degrees CAMERA_BEHINDNESS_LAG, 0.0, // (0 to 3) seconds CAMERA_DISTANCE, 50.0, // ( 0.5 to 10) meters //CAMERA_FOCUS, <0,0,5>, // region relative position CAMERA_FOCUS_LAG, 0.05 , // (0 to 3) seconds CAMERA_FOCUS_LOCKED, FALSE, // (TRUE or FALSE) CAMERA_FOCUS_THRESHOLD, 0.0, // (0 to 4) meters CAMERA_PITCH, 60.0, // (-45 to 80) degrees //CAMERA_POSITION, <0,0,0>, // region relative position CAMERA_POSITION_LAG, 0.0, // (0 to 3) seconds CAMERA_POSITION_LOCKED, FALSE, // (TRUE or FALSE) CAMERA_POSITION_THRESHOLD, 0.0, // (0 to 4) meters CAMERA_FOCUS_OFFSET, <10.0, 0.0, 0.0> // <-10,-10,-10> to <10,10,10> meters ]);
Clearly that's taken almost straight from the wiki, with my adjustments for what I want (high, distant view so I can see a lot around the vehicle).
It works at first, but when I move, the camera gradually drops (over ten seconds or so) until it's level with me, behind me, and not at the 60° pitch that it started at. Occasionally the camera will jump back up there though, and if I deactivate and reactivate it (I have the above on a toggle with llClearCameraParams alone when 'off) it goes back up again. Only to droop back slowly again though.
Is this expected behaviour (if so, how do I fix it other than repeating the above on a timer) or is it likely caused by the existing camera position script in the vehicle? The vehicle's scipts aren't mine and are no-mod of course.
-
Qie Niangao wrote:Vulpinus wrote:a (no trans, no mod) notecard
No setting of permissions is sufficient to protect a notecard's contents. Dropping a full-perm asset inside the notecard will help.I think I might have caused a misunderstanding there.I meant copy the UUIDs of the textures into the notecard, so they could be read by the script.
Not to drop the texture itself into the notecard - I had no idea that could even be done, but I do now.
Or do you mean that even copying the UUIDs (or any text) into a no-mod notecard isn't secure from someone else viewing it?
---
I've no idea of the complexities behind the transfer-perms being required in this instance. It seems daft to me the way it works though. I do know it's simply not possible to prevent copying of a texture file, the way things are, so any 'protection' in the system is really worthless if someone wants the file.
I was using some textures (a lot of variations) I had bought with a full perm object, with the usual distribution rights of no-copy or no-trans on the main object. The finished product occasionally needed a texture switch during an animation. Dropping the textures needed into the finished item was the simplest method. There were a lot of similar objects but with different versions of the texture, so coding all the UUIDs into each item's (otherwise identical) script would have been a pain. Making the texture no-trans seemed the simple answer. Clearly not
-
1
-
-
Just thought to mention that those 'MeshStreaming / Unzip" errors don't seem to occur significantly in other logs - probably a red herring.
I do see this a lot in the logs:
llcorehttp/_httppolicy.cpp(441) : 2016-06-23T14:27:07Z WARNING:#CoreHttp LLCore::HttpPolicy::stageAfterCompletion: HTTP request 00000000745241A0 failed after 0 retries. Reason: Not Found (Http_404)
newview/lltexturefetch.cpp(2064) : 2016-06-23T14:27:07Z WARNING:#Texture LLTextureFetchWorker::onCompleted: CURL GET FAILED, status: Http_404 reason: Not Found
newview/lltexturefetch.cpp(1637) : 2016-06-23T14:27:07Z WARNING:#Texture LLTextureFetchWorker::doWork: Texture missing from server (404): http://asset-cdn.glb.agni.lindenlab.com/?texture_id=ba1f763d-7133-28a1-acda-abd4ffede083
llcorehttp/_httppolicy.cpp(441) : 2016-06-23T14:27:08Z WARNING:#CoreHttp LLCore::HttpPolicy::stageAfterCompletion: HTTP request 00000000745233E0 failed after 0 retries. Reason: Not Found (Http_404)
newview/lltexturefetch.cpp(2064) : 2016-06-23T14:27:08Z WARNING:#Texture LLTextureFetchWorker::onCompleted: CURL GET FAILED, status: Http_404 reason: Not Found
newview/lltexturefetch.cpp(1637) : 2016-06-23T14:27:08Z WARNING:#Texture LLTextureFetchWorker::doWork: Texture missing from server (404): http://asset-cdn.glb.agni.lindenlab.com/?texture_id=c0021169-1c14-8547-4132-d0508387afc7But again it might not mean anythig related to the problem. Whatever that is, it causes a sudden and sometimes sustained flood of incoming (and outgoing, probably mostly syn and ack type of stuff) data without it showing on the stats panel.
-
A bit of testing this morning. I went naked (apart from an alpha layer
). Firstly, the event seems hard to catch today. Typical. It knows it's being watched. Still...Fanci's Deep: One brief (few seconds saturation) event after being there about 30 minutes. Might have been linked to an avatar arriving.
Then I turned off HTTP Pipelining (Am I correct pipeliining re-uses http connections, instead of keep closing and opening new ones?)
Took a while, but I eventually had another couple of events. I got logs of all of the events in the middle/end of them. Not really sure if these are the same event, they seemed to happen around region crossings, but I think that's just coincidence because they seemed the same.
The last one, I was practically in the middle of nowehere. I got logs in the middle and a few seconds after it finished, and a screenshot.
The screenshot shows the same as before: almost no activity in the stat's network panel, but saturated internet. Also note the sim ping! My sim ping until this was around 170ms - that seems a typical value for me.
I also got the log off my other PC from when the event happened to both alts simultaneously yesterday. Can't see anything likely in it, but it wasn't set to debugging level. Thinking about it, neither are today's - I forget I had to turn it on every restart.
-----
If anyone would like top see all these logs, I think the best thing is to upload them to a folder on my web server. I don't want to put the URL here, but please ask and I'll PM you the details. I won't just PM it to people without them asking - I don't want to assume.
The screenshot:
-
Exactly as Ruthven said - and I know because I recently discovered the same issue. Apparently it's some legacy problem with permissions that won't be changed and is a real pain in the assets.
To set an embeded texture onto a child prim by script, the texture must be transferable. It's stupid but that's the case.
My solution was to grab the UUIDs and hard code them in a list. Alternatively put them in a (no trans, no mod) notecard and read them into the list at script start.
-
1
-
-
Hi Whirly, just a few quick answers before I head for bed:
Yes to debugging level - I wasn't sure how much the lower level gave. It didn;t make anything worse about the issue I was seeing.
There were lots (hundred or more) of those lines in the log.
I'll try what you suggest tomorrow and see what happens. I had the issue again this evening in Fanci's deep during a battle, but only once. I ended up two sims away in a few seconds.
I do not use an anitvirus; none is installed. I only do out-of-band full scans occasionally if I feel the need, from a safe disk. My personal firewall is Windows 10 Firewall Control (I'm on Windows 7 - ignore the name). It's really good and I've used it for over a year. I might try disabling it temporarily though for some testing, just in case. Other than that my Cisco router is programmes with a stateful firewall and basic filtering. Nothing that would interfere here.
I doubt that 600ms is typical - I've never noticed it that high. I bet that was due to the saturation issue. I'll keep an eye on it though.
Right - bed time
-
The plot thickens...
I've just been doing target practice in Fanci's Deep again. Things seemed to be going smoothly so I logged in my alt to shoot at on another PC (and even a different public IP address, but sharing the same ISP subnet service).
Things were fine for twenty minutes or so, sailing around all four regions and shooting, then the saturation issue suddenly hit again. My alt was static, just a target for me, moored near the middle of all four regions. I had entered the same region (ETA: welll inside by the time the issue hit, nothing to do with the crossing) and just fired a volley, and a moment later I realised I had lost control. The bandwidth monitor on both PC's was pegged - about 9Mbps each, sharing the 18Mbps. Odd that the static alt even got hit by this. My boat was just careering across the region without a care in the world. Exactly the same as before.
I grabbed a copy of the log at that point, before even quitting FS, and I've uploaded it in case anyone cares to have a look. I took an excerpt of it from the point I entered the region before the incident. The log ends when I copied it; it's only about 80 lines. Perhaps ten to fifteen seconds delay from the onset of the issue to actually getting the copy of the log. Hard to say exactly because I had to faff a bit to get the copy.
I cannot see anything in there that looks odd. I did notice what looks like an avatar arriving somewhere at possibly around the time the issue started.
-
Thanks. I don't see those in my three logs though. There is a handful of 404 errors, but that's not going to be sending me data.
I do have a lot of these, as in hundreds by the looks of it in one log especially:
llmath/llvolume.cpp(2417) : 2016-06-23T06:56:57Z DEBUG:#MeshStreaming LLVolume::unpackVolumeFaces: Failed to unzip LLSD blob for LoD, will probably fetch from sim again.
llcommon/llsdserialize.cpp(2203) : 2016-06-23T06:56:57Z DEBUG: unzip_llsd: Unzip error: !Z_STREAM_ENDllmath/llvolume.cpp(2417) : 2016-06-23T06:57:00Z DEBUG:#MeshStreaming LLVolume::unpackVolumeFaces: Failed to unzip LLSD blob for LoD, will probably fetch from sim again.
llcommon/llsdserialize.cpp(2168) : 2016-06-23T06:57:00Z DEBUG: unzip_llsd: Unzip error: -3It's hard to tell where the problem starts in the logs. Tailing it doesn't help because it all flashes past far too quickly to read. All I've been going on is finding my 'quit' notification and going backwards. Also, I guess that the saturation problem could cause a lot of other potential errors, like timeouts, to show. So, what I'm looking at might just be a symptom, or not even relevant at all.
I've just been back again, and tried with an alt, but had no problems at all this time. I did notice that even when I suddenly see a new, built-up area, and my bandwidth use goes up as the data is pulled, it doesn't quite look flat-topped like when I have the saturation issue. Instead it still shows a little movement around the top and I still have some degree of control. When the saturation happens, there's no control at all until it's over and there isn't necessarily any obvious source of new data.
-
Well, I got that to happen again easily. Started at Half Hitch and sailed (then just flew) due East. Nothing in front of me except more, almost empty, water sims. First and third time, the saturation happened after I had crossed into Binnacle heading East (but well after the crossing - nothing to do with that). The middle time it happened as soon as I tried to move from my TP point on Half Hitch (the jetty). I tried to fly up to start off, and just froze for ten seconds. Then suddenly appeared high up in the air near the sim edge.
The saturation happened on three consecutive relogs (I killed the viewer to freeze and copy the log near the point of interest).
On subsequent tries, the issue did not happen, and I could not provoke it again by sailing around for fifteen minutes. Even approaching heavily populated islands with lots of builds and textures didn't raise my bandwidth use much. It seems the saturation really is something odd going on.
I had debug level logging for this, but I've not seen anything obvious yet that is consistent across them all. Not that I know what I'm looking for in 3MB of text.
-
Hmm... interesting, thanks.
The issue has happened every time I've been in Fanci's Deep, over the last four days, except today. Today I had my log tailed so I could spot what was logged when the issue happened. Perfect sailing for an hour now. It knows it's being watched. Grrr.
The thing is the sims are used very regularly for battles etc. If the issue was something that effected everyone the way it does me, there would be a lot of fuss about it. There isn't, so it's clearly just me. Again. It happened twice in a twenty minute battle on Tuesday - everyone else was fine.
I'll keep watching the log - it'll happen again.
Do I need logging set to debug level to catch what you saw, or will info do?
-
I went out to a few more watery places that were failry quiet, and got the same thing a few times. Here are some screen shots of three instances, all in different sims, all with my bandwidth monitor bit inserted. Some were near sim boundaries but the last one was smack in the middle of an empty water sim (I might still have been picking up data from outside the sim of course)
Again, all show very little network usage and yet my bandwidth is pegged at max and everything is unresponsive. All of these were survivable though; after the event I was able to continue despite some jumping around on screen.
Is there something that the stats panel doesn't show, network-wise? Am I looking at an excerpt of what it's actually doing? In other words... where on Earth is that 18Mbps going?
-
Yeah, fair point. I'll go back to the Blake sim tomorrow, when it's quiet again, and grab another screen shot when it happens.
All of what I said though was about the quiet water region I was in. Only me and one other avatar most of the time. I just wondered what the stats panel would show if I went to Cosmo where I knew there was a lot of texture data to load that I hadn't already cached, and that's when I thought of a screenshot.
ETA: Oh yes, I see what you mean about the Pathfinding being another heading. I thought it was the heading for the data below it in the screenshot. D'oh!
-
I've been experiencing this issue for at least six months. No idea if anything changed to bring that about, but I've just discovered that it isn't caused by what I always assumed.
The issue
My internet bandwidth sometimes (often enough to cause problems) gets saturated by SL. I have ADSL and achieve 18Mbps downstream and 1Mbps up. I've just speedtested that and it is almost exact; it's a good connection. By saturated, I do mean completely max'ed out downstream and close to it upstream. I have a bandwidth monitor running. This can persist from anything from momentarily, up to a minute! When it happens, it seems that any control input or positional changes coming back are stalled while whatever is being sent/received.
When this happens, I can hardly move and (if sailing/trying to sink pirates, which is what has caused me to start investigating) I can be on the other side of the sim before the viewer catches up with that and I get control back. Most often that means I'm dumped off the boat. It's happened six times in the last 30 minutes. It is nothing to do with sim crossing; I wasn't, and it's not limited to sailing.
I can quite easily provoke the above, but it's more of a problem when it happens in a place that I'm sure it shouldn't. I spent half an hour this morning walking around the combat area in Blake, filling my cache. Despite that, I got the saturation when sailing over places I had already been.
When it happened before I assumed I had got too close to an island and suddenly got a load of texture data, but no. I was in the middle of a water sim with just a few mer homes beneath! The saturation lasted five to ten seconds, long enough to wreck my sailing. I did notice that on some occasions a new avatar or boat was on the radar, but other than that I was practically alone on the seas. I was practicing with my new boat while it was quiet.
My incorrect assumption
I previously assumed that the issue was the asset servers being really efficient (we can wish) and sending me all the new texture and object data so fast that I was overloaded. If so, then I thought it was a bit of a problem in the system to allow that to override control input and avatar movement etc. but still. I even thought of buying a faster internet pipe.
However... the above does not seem to be the case, now that I have spent an hour watching the statistic panel.
Instead, when I get saturated, the data rate for textures and objects actually drops, and is in any case well below my 18Mbps; barely half that at most, from what I saw. A few hundred kBps each, well short of my roughly 2MBps available.
What I did see rising a lot, in every saturation instance, was under the Pathfinding section.
I've attached a screenshot of the stats panel. It was actually taken when I went to the Cosmo shopping place, a good place to get hit by a ton of texture for testing these things. I was saturated, unable to move, and yet the texture and object data was minimal. It was typical of, if perhaps a touch worse than, the instances of this in the middle of the sea.
I also noticed that I have 1.5% lost UDP packets. My limit is set at 1500kbps. I have never, in all the time I've been here (longer than this account!), seen any dropped packets before.
Concluding thoughts
I have no idea if the pathfinding thing really is anything to do with what's happening. If the numbers there do relate to real network use, then it seems to be.
I need to get to the bottom of this. It's really killing my fun sinking pirates, which I've just got into. I've always put up with the issue before.
Is there anything else I can look at to shed light on this? Or any suggestions?
Points to note
My LAN uses a Cisco 1841 router and 3560G switches; I'm Cisco certified. It's far more capable than what most people probably use on SL and it isn't the problem. I also checked my router log and real-time stats while all of this was happening. It wasn't even getting warm. I have, of course, tried resetting everything, just so I could say I have.
Oh, and I know my draw distance is set quite high (shown below) but I usually have it around 160m.
Firestorm 4.7.7 (48706) Mar 5 2016 00:13:45 (Firestorm-Releasex64) with OpenSimulator support
Release NotesYou are at <redacted>
SLURL: <redacted>
(global coordinates <redacted>)
Second Life RC BlueSteel 16.06.03.316139
Release NotesCPU: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (3392.3 MHz)
Memory: 16368 MB
OS Version: Microsoft Windows 7 SP1 64-bit (Build 7601)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 970/PCIe/SSE2Windows Graphics Driver Version: 10.18.0013.6510
OpenGL Version: 4.5.0 NVIDIA 365.10RestrainedLove API: RLV v2.8.0 / RLVa v1.4.10a
libcurl Version: libcurl/7.38.0 OpenSSL/1.0.1i zlib/1.2.8
J2C Decoder Version: KDU v7.7.1
Audio Driver Version: FMOD Ex 4.44.61
LLCEFLib/CEF Version: 1.5.3.FS6-(CEF-WIN-3.2526.1366.g8617e7c-32) (Chrome 47.0.2526.80)
Voice Server Version: Not Connected
Settings mode: Viewer 3
Viewer Skin: StarLight (Mono Teal)
Font Used: Deja Vu (96 dpi)
Font Size Adjustment: 0 pt
UI Scaling: 1
Draw distance: 688 m
Bandwidth: 1500 kbit/s
LOD factor: 4
Render quality: Ultra (7/7)
Advanced Lighting Model: Yes
Texture memory: 1024 MB (1)
VFS (cache) creation time (UTC): 2016-4-24T5:42:58
Built with MSVC version 1800
Packets Lost: 2,575/239,482 (1.1%) ETA: Just to clarify... when my line gets saturated and the texture and object data rate drop, the connection is still saturated. Something in the system is taking that data, and there's a lot of it (3GB this morning really just to SL), but it doesn't seem to be texture/object data.
When I'm saturated everything in-wolrd is basically stalled. Even HUDs are almost completely unresponsive. At least, it seems that way. When the saturation event is over, I think things suddenly catch up and often go totally haywire if I was sailing. Dumped off the boat, boat upside down or flying, can't move properly as if still seated but can't stand... total nuts. Other times, I just suddenly time-warp across the sim and can carry on. It's like the worst ever sim crossing, without crossing sims (at least not while I'm in control).
-
Funny you should mention crashing there...
I went earlier this morning. It was really quiet, only a handful of avatars per sim. No noticeable lag that I experience when such places get busy.
And yet, Firestorm (64-bit) completely crashed out three times in twenty minutes. I don't usually get anything like that, even in the busiest of faires where it can take five minutes after TP'ing in before I can even move properly.
I gave up. I feel there's something not quite right with this; I could see no reason for such odd crashes.
-
D'uh! Of course, I do know that. It's not like I haven't done it before. I've got myself tied up in knots with this and doing silly things
Thank you once again.
It's all working perfectly now. It's a vehicle-mounted but independently pointable gun turret (think artillery, hence the alt-azimuth stuff), using llCastRay to better determine what should happen at the business end of the projectile.
I've just today realised that llCastRay is limited to within the sim; I've been reading the wiki Talk. That's a real shame because the battles can easily cross sims and the gun's useful range is well over 256m. At least my thing works well inside the sim. Outside... it's more fire-and-hope (as it was without llCastRay).
-
Is there a more efficient way to calculate the corresponding azimuth (expressed as a rotation; should only have components in the horizontal plane) than what I have now? I'm using this:
vector V=llRot2Left(gLinkRotation); // gLinkRotation is the child's global rotationfloat AzAngle=PI_BY_TWO+llAtan2(V*<0.0,1.0,0.0>, V*<1.0,0.0,0.0>); // Fixed offset for child's -y 'forward'rotation Azimuth=llEuler2Rot(<0.0, 0.0, AzAngle);
I can then use the azimuth rotation to project along the child's negative y-axis direction in the horizontal plane.
-
Thank you very much for that!
I had just figured it out myself a few seconds before coming back here, although mine still used my square,square-root,atan method. Yours looks simpler to compute and gives exactly the same results as mine. (ETA: by which I mean yours is better
)My mistake was thinking that using llRot2Left on a child prim was going to be more complicated than on the root prim because the wiki says it gives a result relative to the parent. So, I've been going round and round in circles in my head trying to figure out how to deal with that and having failed attempts.
Maybe I'm misunderstanding the wiki, but it seems to work on a child prim without any further fiddling due to root offset. Hence just using it as above works, as I just found out.
) suffered generally from the problems mentioned above by wheroangi.
Facebook
Instagram
Twitter
YouTube
Flickr
Mesh Body vs Standard Body
in General Discussion Forum
Posted
I tend to think of that as a feature!