Rick Nightingale

LOL - Stupid spell checker! (and me for not noticing)

Likewise, and not much scares me (not sure anything does for myself any more) but this actually looks quite serious. A friend lives, well, somewhere near some bases and has seen a lot of additional Airforce activity here over the last two days.

I got to log in (that's so I'm on topic ) Yes, Faulty Towers, 'allo 'allo and Blackadder are some of the best TV ever IMO. I've not watched 'allo 'allo for a long time... :goes in search of the DVDs

Another self-reply, in case anyone finds this post researching the issue... It's a bug which has been around for over three years (oh, what a shock!). My JIRA case got closed as a duplicate (along with another, which was describing the very same issue with the physics change) and I cannot view the main case: https://jira.secondlife.com/browse/BUG-5529 @Lucia NightfireThank you for pointing me to that, shame I can't view it and watch it (assuming the bug number is correct?). I get a "It may have been deleted or you don't have permission to view it." note when I try to view it. (Apologies for pinging you here, not there, but I can't add a comment there presumably because it has been closed.)

Replying to myself... It's the physics change! If I take out that line, the other doors don't open. Put it back, they open again. Surely that must be a bug? The other doors are detecting an avatar collision when the physics change happens in another link. More precisely, the other doors (some, no idea why those in particular) receive the same collision event as the really colliding door exactly when that door changes physics type. I can see the delay before the physics is changed... at that point, the other door(s) start to open.

I have some mesh doors I made in my house. I've seen this happpen on several of them now since I built the house. Anyone know why? (Hint: I've not messed up the physics shape ) When one door opens by collision (me walking into it) another door on the other side of the room (10m away in this case) also opens. In fact, other doors, seemingly randomly chosen, around the house also open as I've just discovered by quickly camming around. Yet other doors (in the same linkset) remain closed. There's nothing in the script (my own) to do this; it's the simplest check using llCollisionStart() to start the door opening with a timed, smooth rotation. It does nothing unusual*. The doors can also be opened by clicking on them; this does not cause the other door to open. Colliding with the other door myself does not cause the first door to open. *Nothing unusual except it turns the physics on the door off ("no physics shape") when opening, then back on ("Prim") when closing. Could that be effecting other things in the linkset? (I've checked my script and it only acts on it's own link using LINK_THIS.) The doors are in the same linkset as the rest of the house (no doors are root of course). It's not due to contact with the 'common' wall (not that it should be anyway); I moved the second door out well away from the walls into the middle of the room, and it still did the above. There is no script in the root; each door has its own script. I dropped a second script in to detect collisions in the second door. When I collide with the first door, the second door reports the collision with llDetectedType() of 3, as expected for the first door that I actually did collide with but not for one I'm nowhere near. So checking in llCollisionStart() for what has collided won't help me fix this. It thinks an avatar is hitting it even when it's in the middle of the room, not touching anything and certainly not me. The only thing is, it's still part of the linkset. If I unlink and relink the second door, this behaviour stops for a time. The door then remains closed when I collide with the first. However, unlinking and relinking the first door started it happening again. (I was trying to stop it happening to another door, on another floor.) I've also stopped this previously by unlinking a door, drag-duplicating it and linking the new door in instead. That fixed it permanently for that 'pair' of doors in another room. So, I'm stumped. Again, lol. I can't see any correlation between the doors which are choosing to do this, and those which remain closed, or why it only does it if the first door opens by collision, but not by click (the script does nothing different). What am I missing? Why do some doors detect a collision when the first door does? (no, their physics triangles are not hitting each other, besides they are optimised out I think). The doors are made in the usual way with an offset single vertex to double the size, centered on the hinge location, in every LOD model. There's a triangle in the same place to define the maximum physics size of the door in the physics model. The door itself has a physics cube. Uploaded with Solid/Analyze, it works pefectly and I've checked the physics shape with Render Metadata. When set to Prim physics, that shows just a perfect door-shaped collision volume. Edit: To pre-empt anyone asking, here's the script. No need - I've isolated the line causing the issue. See below and my own reply in next post. // This is the line causing the issue. // When the physics change happens, (some) other doors get an errornous collision with agent event. if (gPhysSwap) if (time>=0.3*gSecondsToRotate) { gPhysSwap=0; llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_PHYSICS_SHAPE_TYPE,gClosed]); }

@tomm55Sorry for the late reply - I'm not getting reply notifications on my threads! I thought no-one had answered. Hmm... I'm not sure about that. How do you create an item that can be next owner transfered, with a next owner, no transfer script? (except by it being mod perms thus letting the next owner remove the script, leaving the object overall as transfer but lacking the script, which is cheating, lol). I guess you're missing the point of my post - I know I can create and sell things with a no-transfer script in them. Anyway, I've discovered a very odd behaviour in the perms... I really think LL has fiddled with something. For the above: The object in question is a rezzable (should have copy/transfer perms) prop in some furniture. The creator made a simple mistake of setting the AVobject script no transfer, so it cannot be transferred to any user other than the owner. Fine... but the object still shows up in the furniture's inventory, and mine if I take it out, as Transferable! It's only when rezzed in world (by the furniture, or by me) that the object then gets the (delayed) No-Transfer perms on itself as a whole. If I don't rez it, I can give it to other avatars from my inventory, so it really is transferable up until it's rezzed. What I can't figure is how you could put a no-transfer script in something, or set it no-transfer after dropping it in, and not have the object itself immediately pick up the No-Transfer. The other thing I saw, which seems related but was on something I was doing myself is... I had made a lot of mesh items that I was putting on the MP. I use an alt account to list them, so I passed them to that account as full perms, in a box. On the alt, I rezzed the box and changed the permissions on the objects to no-trans by using the permissions button in the edit/contents box. Fine so far... When I (the alt, that is) took the contents of the box into inventory to list them individually, they showed up as next-owner no-trans as expected and no restrictions were shown for my alt. As soon as I tried to put one in a vendor though, or rez one on the ground, its permissions changed to No-Transfer for my alt! Yet, they were passed to my alt as full perm I checked this so many times thinking I was passing them on with the wrong permissions - my mesh is set to full perm when I upload it with the viewer so I usually don't even have to think about this. tl;dr: Objects passed to my alt definitely as full perms, changed to No-Trans for that alt if the alt changed them to next ownner No-Trans while in a box, and then rezzed them out. Weird! Note that rezzing them out first (the alt that is), then changing permissions to No-Trans individually worked as expected. They remained full perms for the alt. Also note that I've been doing things this way for ten years, lol.

RIP Meat Loaf RIP.... what am I saying... wherever you are Meat Loaf... ROCK THE PLACE!!!

This! So much this! That requirement is just downright mean.

@AishagainYou tried to help, no need to be sorry It was worth a try; not your fault it didn't work. I do wonder what file it was causing it for all of the accounts, but sometimes I just want to get on with stuff and not spend my time troubleshooting. Today was one of those days, lol.

OK, having realized the lack of all Library files, I took drastic action and wiped my entire cache folder (except textures; kept that subfolder). That worked... after reloading my inventory the Library folders are back (along with the Environment files). Clearly the problem was with a file other than the inventory cache file, but since I don't know which file could have caused the problem to happen in all the accounts' inventories, simultaneously, wiping everything seemed a quick way to fix it. So far, so good. Shame it came to that though.

Yes, I cleared inventory cache specifically, as I said. I've never, in 12 years here, known rebooting my modem or router to fix anything other than a dead PPPoE or dropped line to my telco/ISP, both of which are a bit obvious. I run a business class connection with both an IPv4 routed subnet (all my PCs have static NAT to an individual public IPv4) and /48 IPv6 prefix. There's no overloading of my router which is capable of 4Gbps NAT speed and is always one of the first things I look at if anything is going wrong. Every other PC here is running Firestorm as expected; it's just the installation on this (my main) PC that's lost the plot. It's not my network or modem. Thanks, I tried that expecting it to work, but no. After copying my account's file from today's login with the LL viewer to Firestorm's folder and overwriting the one there, I still only get empty Library/Environment* folders in Firestorm. But then... I do not get the missing environment files on any account logged in on this PC; three of mine and two of my wife's. That would point to it not being an issue with the account's cache file, but something more fundamental in the viewer. Have you wondered why my profile's subtitle here is "Bugfinder General"? 🤣 Edit to add: Actually, I've just realized that I'm missing almost the entire Library contents. All the textures are missing, as are things like Linden Trees - they were there a week ago; I used them!

Yes, clearing the inventory cache is part of the troubleshooting steps. I did that. Via FS's menu, and manually. The Settings folder is as empty as the Library/Environment folders, because the database is missing/not loading/whatever. In fact I followed the link to the "missing library" troubleshooting from that fs_eep page. I have already discovered the MP set of old Windlights. Putting one of those collections into Settings does make them then appear in the Quick Prefs, so at least I can set a windlight envrionment again. Somthing is clearly very wrong here though... I still have nothing in the Library where these things should be. If they were not in the Official viewer, I could file a support ticket with LL as per the troubleshooting page. But they are... they are just missing from FS so, I'm stuck now.

Edit to add: It's not just the environment folders... almost all the Library folders are empty, on any account I log in on this PC. The contents were there a few days ago; I use it! None of the troubleshooting procedures for missing inventory or missing libraries (or whatever) has had any effect. A few days ago I tried to select a different windlight from my usual "9am" (environment - whatever they are called today) from Quick Prefs. None of the list was there... I clicked one of the only two things, "Shared Environment". My lighting changed, but I got an error message like "this cannot be selected". I also get another error message when I try to use the next/previous buttons there on Quick Prefs: "Could not load settings for 00000000-0000(etc) from the database". See screenshots at end. Every account I try on this PC is the same now. The Library/Environment folders are all empty folders. They work if I log in on another PC, but not here. I've been through the troubleshooting page, right to the end, twice, here: https://wiki.firestormviewer.org/fs_missing_library Nothing. I get the folders in the Official viewer (see screenshot, just to show I know where to look) but not in FS still. The troubleshooting leaves me hanging at the end with that result - nowhere to go. Suggestions?

We cross posted. Yeah... I guess the images are there, but I cannot see them. Sometimes. It's the sometimes that is confusing me. On multiple PCs and multiple browsers! Thank you for helping - I wish I knew what was going on.

Hmm... I just cleared my Firefox profile, cleared all cookies and history, and my images immediately showed up on the MP. Without having to re-upload them. So why did it not work, then work, two days ago? Why did it *not* work in a clean install of Brave, or on another PC? Why did I have the same issue years ago on compeltely different setup, and used to get around it with the image converting circus? Somethinig is odd with the MP, but I don't know how.

They don't show up on the final advert if I finish it. The product page looks like it sort of knows there should be pictures, but no main image shows and if I click the 'more pictures' bit, I get a bit of a dialog box but nothing in it. Certainly no pictures. This is what it looks like if I finish the advert and click Zoom/More:

Doesn't work ina clean install of Brave. I'm at a loss here... The other day I was putting an advert on, and I went around in circles converting my pictures but eventually they worked. Thought I had figured it out, but the same conversion sequence today does not help. Not a single image will show up when uploaded to the MP. I'm hardly a beginner here. CCNP, HP Enterprise Wireless Expert, decades of experience designing embeded electronics and firmware... and I can't upload a simple png image, LOL!

Nope, no adblock; some picture have words in, some not. There's nothing installed on this PC that could interfere. Nothing strange in the names. I've just fired up another PC and tried from there... same. No images. I'll give Brave browser a try instead of Firefox, but really, there shouldn't be anything to stop this working. Like I said, it did this years ago and I had a completely different PC and software (and ISP, and browser...)

If that would actually work I would do it... but they still don't show on the MP even if I upload as a texture, lol.

I've just recently got back into selling stuff; I had this problem years ago and it's still happening now (different PC, different photoshop etc). I've made my advert pictures, 700x525, in photoshop. Saved as PNG. Sometimes, they will upload to the MP fine. Sometimes... not. All I get then is, well, nothing as an image. Right now I have six pictures in the MP advert I'm trying to place - every one of them actually shows no image. If I upload to SL as a texture, it works. I've tried saving as jpg and png. I've tried converting the file in MSPaint from one format to another and uploading again... no image. I've tried converting in XNView and Irfan... same. Even saving as BMP (where the file cannot have any metadata, transparency or anything 'clever') then reconverting to png or jpg... no image. This is driving my up the wall... again! Yet another thing here that just doesn't work. Anyone any idea why this is happening and what I can do? Right now I can't get any image to actually show an image on the MP. Argghhhh!

Aye, thank you. I've just had a note put on my JIRA report to that effect. Good news - it's already fixed. Yay!

@Fenix Eldritchthanks for replying. I've just taken a video with FS and LL viewers side by side showing the issue. Thanks for the tip about using just one call to llSetTextureAnim(FALSE...), that makes perfect sense now I think about it Here's the video: ETA: Ha - my JIRA account has gone. Well, it has been a long time since I logged in.

After a tequila-fueled powernap and some further investigation, this only seems to happen on Firestorm. I have one account logged on with LL's viewer... that cannot see this offset happen. It works as it should. Another account logged in at the same time on Firestorm sees the offset every time. Hi Ho, Hi Ho, off to the JIRA I go...

Edit: Seems this is Firestorm specific. See the video a few posts down. I'm trying to make a product that needs to animate two faces on a mesh; one at a time not together (I know you can't do that). However, every time I start the animation on the second face, the previously animated face suddenly gets a texture offset, I guess from where it was up to in the animation when I stopped it on that face. I've tried resetting the face offset, but since it's clearly a viewer side thing that has no effect (editing the face shows no offset of course). This is ruining what could be a neat little product. I've also tried putting the texture back on the stopped face, again it still has the offset. So... anyone know a reliable workaround for this? The following code reproduces the effect, animating faces 1 and 3 alternately on a rezzed cube and stopping them in-between, each time you click the cube. When you click it for the third time, face 1 suddenly jumps to the offset while face 3 animates and vice versa. integer mode=0; animate() { if (mode==0 || mode==2) { //stop animations on both faces llSetTextureAnim(FALSE, 1, 0, 0, 0.0, 0.0, 1.0); llSetTextureAnim(FALSE, 3, 0, 0, 0.0, 0.0, 1.0); llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_TEXTURE,ALL_SIDES,"d613e970-1ab5-98dc-e16c-318c4136e5f3",<1.0,1.0,0.0>,ZERO_VECTOR,0.0]); } else { // Animate the face given by mode llSetTextureAnim(ANIM_ON | SMOOTH | LOOP , mode, 0, 0, 1.0, 1.0, 1.0); } } default { touch_start(integer total_number) { mode=++mode%4; animate(); } } I guess this could go in the Viewer subforum, since it's clearly a viewer issue. Note also that someone seeing the cube for the first time will not see the offset face, even though the person clicking it does. On subsequent clicks though, both will now see the offset (you have to have seen the animation, to then see the offset).