Vulpinus

Maark Hastings wrote: donkeys. The only thing I can say to that is HEEEEEEEE-HAWWW at least, that's as sensible as your post deserves.

Yeah, just use llGiveMoney() after receiving the payment in the script. If you need a transaction number, there's llTransferLindenDollars();

Thanks for that. I'm still concerned about the continual firing of the event when I'm moving which, if I have the weapon out, I'm likely to be doing a lot. If only the event only fired on a change of key state, instead of continually all the time a key is held. A quick test shows that the event is fired a bit over 30 times per second when a key is held down. That, versus my ten times per second poll with a call to llGetAgentInfo. Hmm... After a good night's sleep, at least I realised that all I need to check for at the start of the event is CONTROL_ML_LBUTTON. All the attacks use that in combination with another key. Since that can only occur in mouselook, I don't even have to call llGetAgentInfo so there's only one simple test to do (and fail) in the handler if I'm not actually attacking. I'm going to try it the first way (not polling) and see how it works out. Might have to do some execution time tests when things are more finished.

Next question, and perhaps more difficult... My weapon script only needs to do something if I'm in mouselook, and then needs to monitor all the arrow keys, Pg-Down and Left Mouse. I have two options: 1. Have llTakeControls active all the time monitoring all the controls (with pass on), and test if we are in mouselook as soon as the script enters the event handler. That's a lot of movement control inputs generating events that might not be relevent most of the time. Is that an issue? 2. Poll llGetAgentInfo for mouselook at a fast rate (0.1s for instance) and turn on/off the active llTakeControls accordingly. I don't think that polling at that rate is a lag problem in itself, but I'm not sure if it can reliably* react quickly enough to go into taking control events when I suddenly go into mouselook and attack. Given that deciding on the above might take a lot of in-world testing to get a convincing answer, I'm hoping someone has already determined it. Obviously I need to cause as little lag as possible, but the script also needs to be very responsive and reliable* or it's pointless. *at leat as reliable as anything can be in SL scripting ;)

Unfortunately I don't think the HUD is that flexible by chat/listen. It does have some chat control which is useful to me (like turning off its own animations) but not to the extent of attack control. Of course, I have no access to the source code. However, a few quick tests confirm that several attached objects can all receive the same control input, regardless of 'pass on' or not. To my surprrise, if only one of them is set to not pass on, then the viewer does not get the control. In retrospect, I suppose that way makes more sense. If something is not passing on controls because it really does take control of movement itself (like your vehicles, or my still-in-beta swimming controller) then that should not be overridden by something else wanting to watch the controls. So at the moment I think I can do what I want without interfering with the HUD functionality, or vice versa.

I'm working on a weapon script, which will sometimes be used along with a combat HUD (SPD-J right now, if it matters). Both the HUD and my script need to use the same control events. For instance, the HUD needs to get an attack (CONTROL_ML_LBUTTON + an arrow key) and so does my script to play my custom animation, or not depending on the arrow key. There's more but basically similar to that. How does llTakeControls work with regards to passing though (or not) the controls, if both my weapon and the HUD use llTakeControls? I know I could do a load of what-if tests, but I'm hoping someone can save me a few precious hours ;) Specifically... Does 'pass on' just refer to passing on the control event to the viewer? ( I guess it must; so other scripts can also get the same control inputs even if my script says not to pass them on) Does just one script have to be set to 'pass on' for the viewer to get it, or would it not be passed on if just one script says not to? Oh, and I so wish there was an 'entering/leaving mouselook' event. It would make things much easier. To make life more difficult, the weapon has both melee and projectile modes and needs to be used while flying (actually swimming) as well as walking.

Yep - easy. When you go to the texture selection (by clicking the texture thumbnail in the edit window), there's a 'local' option. Check that, then you click the 'add' button and you can upload files from your HD to use in world. They are temporary, no one else can see them and they are lost when you relog. But it's free. Be careful not to click the 'upload' button from there accidentally. That uploads the texture normally and charges you for it although there is a 'are you sure' check first. I spent a fair bit of linden $ before I found this myself Another option is to go to the beta grid, where you can upload anything fully and freely but it can only be used there. You cannot transfer it to the main grid. On the beta grid you are given free L$ in your beta grid account to pay for the uploads. You need to take a simple test to enable your account to log in there. There are plenty of posts about the place here if you search. The beta grid is great because you don't need to keep re-uploading your test work every time you relog. You might see me there.

I've just found a JIRA case which is the exact opposite of mine; force not being applied to move forward unless move up is pressed. Seems there is something fishy going on with llSetForce that causes it to fail when hovering. Typical!

Yes thanks, I've tried using llApplyImpulse over the last few minutes for the above-altitude correction. I used a sliding scale based on the difference and that works well so far for a quick return without overshoot. I was using llSetForce for speed control so it seemed obvious to leverage it for the altitude control as well. Adding the impulse adds a little extra to the code and I was trying for a really quick timer function. I'll have to work on optimising things more. I'm still really puzzled why it simply fails like this. I've tried several permutations of applying the force when above the ceiling, but it never works unless I move. Weird! ETA: (I'll have to stop doing that)... I still use llSetForce for altitude correction within the main speed control and that works perfectly. As long as I don't stop... then I need the additional Impulse method.

I'm trying to use llSetForce to maintain a maximum altitude when flying. Simple enough it would seem, and it works well except when I'm not moving horizontally. What I mean is that if I stop still, I can then move up using pg-up, above the set altitude, and the llSetForce does not push me back down. I can sit there all day at 110m when it's supposed to kick me down to below 100m, unless I just move a touch forward. Then I plummet as expected. This is the relevant script excerpt: timer() { float MaxAlt=100.0; vector p=llGetPos(); if (p.z>MaxAlt) { llSetForce(<0.0,0.0,-50.0>,FALSE); llOwnerSay("Yep"); } else { llSetForce(<0.0,0.0,0.0>,FALSE); llOwnerSay("Nope"); } }Yes, there's more code than that but I've narrowed it down to this in testing. When I'm at 110m, as confirmed by the viewer coordinates and debug output of p.z, my chat is screaming 'Yep' at me. But, I don't move down until I twitch forward a little. Then I drop to 100m or just below depending on when the timer catches me and removes the force. I'm flummoxed. This is killing what I'm trying to do. Is this a known bug? ETA: I'm not using TakeControls and there are no other forces interfering with things. I really have isolated it all down to the above testing modification of the script with most stuff commented out. Everything else is working (speed control and altitude control using llSetForce) as expected. Just not when I stop. Also - is there a way to determine flying vs hovering? I'm guessing it's just done by detecting velocity in the script since I can't find any function for it.

Ha - yeah. Or at least put most of them into 'No IM' mode, which I have. Trouble is there are a few I like/need to keep an eye on and the other day all of them were hit, mutliple times. People just can't resist answering the bots with the same witty comments every time. One of the interruptions (after I posted this in a moment of 'Arghh!') ended in an amusing conversation though. As someone pointed out, at least it got people in the group talking.

Hmm... 8x8. That's 256 bytes vs. 4K. Interestingly, JPEG2000 gives me a file size of 738 bytes for both sizes when set for compressed maximum quality. With no compression it's only 608 bytes for both sizes. I don't know anything about that format other than SL uses it but clearly it is tiled or something with minimum sizes. So in terms of server load and bandwidth, both sizes are equivalent. On the GPU I would guess that it's the uncompressed size that gets stored, so the 8x8 is better. I'm of the mind that every little helps so it's worth a try I've made some bigger savings over the last couple of days though... ...I made my own mesh body hair (chest and arms so far, still working on other areas)) and saved over 20,000 on my ARC compared to the old sculpt hair I was using. The sculpt hair looks a little better I think (but then, I always thought it was the best body hair on the grid). I'm struggling to get mine not to look like obvious multiple flat planes where it goes into the body. But still, it only shows when zoomed right in and it's a great ARC saving. It'll get better as I play with it. Same principle as making mesh grass planes and the same problems as when I tried that. I guess my brain just doesn't do random orientations very well.

I think what you mean about the 'single file' is you not realising that the body alpha layer (for the system avatar) contains 'slots' for upper, lower, head, hair and eyes all in one file. If an alpha layer is just covering part of the upper body, made from whatever template, then it is only using the upper body slot. For a mid length dress you would use the upper and lower slots - it would still be one alpha layer file although you might have to upload two textures (upper and lower) to make that alpha layer. Is that what you meant? When you say mesh body alpha - you mean an alpha layer to hde the entire system body? (rather than making an alpha to hide parts of the mesh body) If so, same as above, with all the 'slots' ticked and no textures used. So, it just goes full alpha on everything. Wear one, right-click it in inventory or outifts and edit it. You'll see what I mean.

I have had issues with doing that; lining up two non-connected faces in a single object. When uploaded to SL, from just the right (or wrong) angle I got feint, shimmery lines (single-pixel width no matter how close I zoomed) at the boundary between the faces. The faces were flat like yours and aligned as accurately as Blender allows. It happened to me every time I tried to do it this way and was noticeable enough that I gave up on the idea. I ended up reconnecting everything and living with the increased face count. Alternatively, depending on the topology, embedding one face slightly into the other works but if you want the faces planar, that's no good of course.

It's not just me then! I have the same, yesterday and today I noticed it. I can't wear or rez my mesh body, which is a bit annoying since that's what I'm working on making things for. None of my recent outfits would work. By chance I tried with an older (unworn for a while) copy of and could wear that one. I've added a brief 'me too' to the JIRA. It's exactly what I'm experienceing.

...when I still get another ten group chats ping up as people respond to the begging bot! People are idoits! /rant.

I tend to think that if you ask a question like this, there will always be a few takers, for reasons that might be similar or nothing to do with what's causing your problems. Still.... Me too For about a week I've had textures loading really, really slowly. It can take a full minute for what would normally take a few seconds after TP'ing in. Even then, some don't ever seem to rez unless I TP around again. I get missing textures, and materials maps so end up with flat, boring wallpaper and grey trees etc. I don't normally get this (I get texture thashing, as Whirly knows, but this is different) and my own system and internet connection are good. I was suspecting a problem somwhere in the internet pipes, or maybe even with the CDN server(s). Might or might not be something to do with LL's kit. (Yes, of course I've reset my router etc). I don't use any real-time antivirus (shock-horror). I prefer common sense, out-of-band scans, isolated virtual machines and a real firewall. If it carries on much longer I'll see if I can track down what's happening with some traceroutes etc. So... yeah.

...I really need to put my glasses on! You're spot on of course, and I misread the second line of vertices as +.25,+.25 and didn't spot the collapsed triangle. D'oh! Thank you

Hmm... I didn't know about the degenerate triangle highlighting in the uploader view. I did look all around it though when I got the problem in case I could see anything, and couldn't. It's a big house. Nice to know though, thanks! I wondered about the assignments getting messed up too. I'm careful to use hierarchical naming so it didn't take long to go through my objects. They seem correct. Anyway, after scratching my head to the point of baldness, I decided to cut my losses half an hour ago and drop back to the last-known-good (i.e. successfully uploaded) revision; only a few 0.01 points back so probably nothing significant. I have just discovered one thing... The uploader absolutely cannot be relied on to triangulate complex faces, like those made in a wall for multiple windows using the boolean modifier. I had Blender set to not triangulate because a lot of my objects have custom normals, and my upload had most of the windows filled in. Manually triangulating (which I usually do anyway, but for some reason hadn't on this file) and reuploading fixed it. Good thing we have the beta grid!

I'm trying to upload a large, multipart model. I've uploaded it before with no problems whatsoever, but coming back to it after a few weeks (and no significant changes that I can recall) it has suddenly developed Degenerate Triangles. I'm trying to figure out exactly where, without going to the extent of removing it piece by piece and trying to reupload until I hit the culprit. That would take days. Is there a way for me to correlate the data in Firestorm's log with the collada file and ultimately my model in Blender? I can't see one so far... An excerpt from FS's log is: error[0]: BlockName: 'physics_mesh' Context: 'validateDecompressedPhysicsMeshData' ErrorCode: i21 FaceIndex: i0 MeshIndex: i77 TriangleIndex: i0 Vertex0: [r-0.250000,r-0.250000,r0.250000] Vertex1: [r-0.000004,r0.250000,r-0.250000] Vertex2: [r-0.000004,r0.250000,r-0.250000] message: 'MAV_FOUND_DEGENERATE_TRIANGLES' This is repeated five more times, identically apart from different MeshIndex numbers which are consecutive. Oddly, I can't recall or find anything of exactly those dimensions that is repeated six times in my model. Nothing is repeated six times. Eight, four, two yes, but not six. I have no idea how FS generates the indices, but counting from the first instance of <mesh> or <geometry...> tags in the collada file doesn't seem to give anything conclusive. It puts me in the middle of a subset (a window which worked perfectly before and hasn't changed) which is repeated nine times identically, and still doesn't have anything of those dimensions. So much for just quickly, finally uploading a finished version of that model... ETA: Found it! ETA2: No I haven't

I took a few screenshots when it happened. In between each, I waited until the thrashing subsided, then just moving my cam around a little provoked it again. After tha last screenshot I did the TP trick. Everything stopped thrashing and I could not provoke it again by moving my cam around. 

I've been busy for a while, but have been online for about 12 hours straight today. Still seeing the odd issue and it still seems wrong the way it happens. @Whirly, I PM'd you the links; don't know if you've had chance to look yet. No worries if not. While the issue is irritating, at least it doen't happen as often as it used to. Today, twice, seperated by a few hours, I was standind in my garden about half a minute after TP'ing home. Suddenly the textures started to thrash. I loaded the console. The loading textures list fulled over half the screen (on a 1200 pixel high display) and both GL Total and Bound bars were jumping around and high. Only the GL Total bar was going red thougth. That seems to be the pattern, with the Bound bar mostly staying green or yellow but the Total bar hitting the roof every time I see an issue. The Bias was at 5. After TP'ing, everything settled down with at only half or so of the limits on those numbers. My double-click TP trick worked again, but I'm wondering if it's just because I'm TP'ing (in itself) which causes another change/event in the system, rather than it being specifically a double-click TP. I guess it is. I also wonder how long it takes the viewer to clear the now-uneeded textures from the graphics memory when TP'ing, to make room for more. I do know that I never got any thrashing with Black Dragon, with the higher memory limit. I prefer FS though overall. Question: If the Bound limit is hit, which (I think) would then cause the texture resolution to be lowered and the Bias to go up reflecting this, does the Bound reading then drop because of the now-lower memory use by the lower textures which (by the time I check) makes it look like it's not that high even though the Bias is reading high? If so, then my comment about the GL Total being high but not the Bound is irrelevent. Another time I was back at that shop again, and a similar thing happened to the above. Several times in fact. That place does seem to suffer more badly than others although it's difficult to pin down why. Sometimes it's really full of avatars but I get problems even when it's quiet there. Again, as above, it's the GL Total bar which seems to mostly hit the roof, along with the Bias at 5 and again TP'ing seems to trigger it to calm down more quickly that it otherwise would. One event at the shop was really obvious. There were aroud five avatars there plus me, and I was just fixed on the chairs. Another avatar arrived which I guess triggered some more textures to be loaded. The thrashing started with all textures in front of me flickering like mad. Double-click TP - all fixed. The GL Total and Bound again dropped down to sane levels, around 1/2 to 3/4 of the limits. --- Anyway, I'll leave this for now. Whirly, if you do get time to take a look that would be great. Since there aren't loads of people jumping in and saying 'yeah, I get this', but just a few, I understand there are probably more pressing matters. I would hate to waste your time if it turns out to be a local problem, although I can't really see that being the case given the reinstalls and duration its survived.

Right, I'll note my current findings before I forget. I logged in today, having just restarted my PC so no other programs had run, and turned on the texture console. My texture memory slider was set at 1GB. It took two TP's between home and yesterday's shop to see the texture thrashing start at the shop. I could see even before the thrashing started that there was going to be a problem as the Bias was jumping around between 3 and 5, and the green Total and Bound bars were jumping up too. The thrashing started after a few seconds, with Bias at 5. I let it continue for a good few seconds like that; it didn't stop. I did my TP trick and immediately the thrashing stopped and the Bias dropped to zero (well, within a second anyway, as quickly as I could look at it). Textures that were not loading finished to load at full resolution and everything was fine. After that, I TP'd several more times home and back to the shop, with no problems and the Bias only once went above zero momentarily, to 0.25. After about five minutes of doing this, everything was still fine with the Total and Bound bars less than half way and Bias at zero. ... After that, I tried dropping my texture slider to 256MB. My home is texture-heavy so I knew that would cause issues, and it did. After spinning around a few times I managed to provoke some thrashing, again the Bias was at mostly at 5, although not 'stuck' there, like before it jumped around a little. The double click TP seemed to work there too, with the Bias dropping to zero and thrashing stopping. At least until I turned around again and looked the other way. I could not get the TP trick to work again like this though; it did not subsequently seem to stop the thrashing. So, inconclusive there really. ... I get the feeling that the TP trick works when really there should not be a problem in the first place, as I have often thought when I get this rapid texture thrashing and I'm pretty sure (sometimes absolutely certain) that I haven't been anywhere 'heavy'. ... After typing the above, I moved my texture memory slider back up to 1GB, relogged and started TP'ing between home and that shop again, watching the texture console. The thrashing so far hasn't happened again and not once has the Bias gone above zero and both Total and Bound use have stayed below the thresholds. Only once, briefly, did the Total bar turn yellow. That's about ten minutes now and no problem. Again, It feels like sometimes (often enough to be a problem) something goes wrong when TP'ing to a new place, and causes some failure in the texture loading. That is when my TP trick works every time. ... Whirly, I'm happy to PM you my home location and the shop I've been using, although it is in no way limited to those locations. The shop is a moderately 'heavy' place, nowhere near as bad as some where I can visit and spend literally five minutes waiting for all the textures to download at 20Mbps. Even those places don't usually cause problems like texture thrashing for me. ... ETA: A while later now, a different account logged in for about ten minutes. I've been moving around a little, nowhere busy, and just had the texture thrashing again when I TP'd back to the shop I used above. I didn't have the Texture Console open (I wasn't doing testing) but when I opened it the GL Total bar shot up and went red (I didn't see the number) but the Bound bar was only at about 15-20% and green. It didn't get any higher. The Bias was jumping around 3 to 5. There were far fewer avatars about, only two (earlier there were eight to twelve as people popped in and out). I didn't get chance to try my TP trick as by the time I had checked the above, the thrashing actually subsided on its own and everything went back to normal (this is a very rare occurrence - it usually stays thrashing once it starts). It lasted perhaps ten seconds after TP'ing in. At the end, the GL Total was reading around 800-ish/1280, Bound was 360/1024 (both varying slightly as people moved around) and Bias was zero again. I think it knows I'm watching it... (Quantum physics - try to measure something, it changes on you and hides) ... Another five minutes, I stayed in the shop, and suddenly the GL Total bar shot up and went red, the Bias shot up to 3+ and I got texture thrashing again. I was just standing there, and only one other person was in the place. Bound stayed low at around 300ish. I cammed around a little (thinking at first a load of people must have just arrived, but no) and GL Total number and bar jumped around all over the place, but keeping up hiigh (almost max). After a few seconds this stopped, the texture thrashing stopped, and everything calmed down again. The GL Total though stayed quite high at around 1100/1280. This is weird - is it normal? If it is, I'll go away and stop bothering people, but it really feels wrong and has for ages. At times I can get the thrashing started just by TP'ing from my build platform down to ground level at home. The double-click TP trick stops it every time.

Thanks for the link Perrie, I've just read through that thread. Clearly I'm getting a great rate of data from whichever CDN server I get connected to. I did the Pheonix speedtest earlier and get 8.8Mbps download; less than half of the rate I actually get regularly from the CDN server. I could really do with finding someone on Plusnet, with 76Mb fibre and on SL, to see what they get. I might jump on PN's forum later and see if I can find someone. I think I've mentioned it there before though and no-one answered. Like here, only a small fraction of the userbase uses the forum.

I'll have to check later when I'm back on my main PC and see if I can provoke the issue. I've used the texture console before when I had an unrelated problem that turned out to be a failing NIC. I know the double-click TP fix seems odd. That's actually why I've not mentioned it before, assuming it was just coincidence for a while. I know about holding the cursor over a texture to give it priority and often move it around to do so, but this is definitely something different. I just double-click on the ground a few paces in front of me to do the TP, and it works almost every time like I said. It is an instant fix for all the thrashing textures. Eventually, I have to conclude that it cannot be coincidence. The only unusual thing about my setup is that I use a spacemouse and frequently use flycam mode to look around followed by having to press Escape to get my cam back to me when I TP somewhere else. So, more often than not the issue happens while I'm doing that but I'm fairly sure it happens when not and my cam is 'attached' to me. I'll make sure though. This might be nothing to do with it anyway. I'll report back when I have an answer on the bias. ETA: Regarding running out of texture memory: I used to get thrashing more often before FS got the increased memory limit slider. I never got it with Black Dragon which has an even higher limit. In the incidence in my OP though, I had only been to my own parcel and the one shop, nowhere else, in that 20 minutes. I actually was using blender*** instead of doing anything in SL. Sometimes I get the texture thrashing when I've obviously been to texture-heavy places, but sometimes I'm quite certain that it really should not be the case, like today. ***ETA2 - yup - I've just realised that Blender was probably using some texture memory itself, although it was only a small model and I do have 4GB on the card. Hmm.