Jump to content

Vulpinus

Resident
  • Posts

    545
  • Joined

  • Last visited

Everything posted by Vulpinus

  1. This one made me scratch my head for a while (actually bang it on unexpected invisible physics). Is this expected behaviour? I uploaded all the doors for my house separately from the rest of the house, so I could use Solid/Analyse to get the hinges to work with the usual outlying triangle. All the doors were exported from Blender and uploaded together. Most of them worked; four didn't. All were made in an identical fashion (and were duplicates of one that did work). The physics on those four looked almost reversed. If I uploaded the failed doors individually, the physics was as expected. I checked this multiple times to make sure I hadn't missed a step or anything silly. Below you can see what I got. The first and third (from the left) were the failed doors from the linked export; I can walk though the doors but not past the hinge. 2nd is the same door as 1st, and 4th the same door as 3rd, exported and uploaded individually. Now the doors are solid and past the hinge is not, as expected. All were uploaded with Solid method and Analysed, and set to Prim.
  2. Hmm... I wasn't going to mention this, because it's the weirdest thing yet, and I haven't been smoking anything funny. But I will... (mention it I mean, not smoke something funny)... After it not reproducing in RLV viewer, I copied the files from the new place that I had moved them to for RLV viewer, back to where they were originally for my HUD. The issue would not reproduce in either Catznip or FS, at first. Follow this carefully!: I installed RLV viewer, and found I needed to make changes to get my system to work. I Moved the F26 and F27 folders from #RLV/.FAST_Demon/ to directly under #RLV, for RLV viewer. (and created individual subfolders for the items and moved the items into them, but I don't think that is important). The issue did not repro in RLV; I tried using the simple script (modified for the moved folders) above. The objects attached and detached as expected. Went back into Catznip. Copied the items from those subfolders back to F26 and F27 under #RLV/.FAST_Demon/ The issue now would not reproduce (tried 12 times) in Catznip or FS, with that F26 horse folder. The items in it were copies of the originals. The issue did reproduce (in FS now) on another folder set I was testing earlier, F25, which just had a different version of the linked horse in it that had not been moved or copied. I deleted the copies in F26 and F27, and moved the original files back into those folders. The issue immediately reproduced again, on every one of ten attempts. Does that make sense??? I promise I'm not smoking anything, although I have had a large glass of home-made mead. Anyone seen Mulder and Scully about??? Anyway, it is now reproducing as before. Go figure
  3. I take that back... wasn't that much to do. I had to rename the folders and move items about, but I'm attaching and detaching the same set of objects. The issue does not seem to happen in RLV viewer.
  4. My HUD (and the simple test script in my OP) do not seem to function in RLV viewer. It's quite different I guess. A brief look at the site shows I need a lot of changes to make it work, and I haven't even found the command protocol yet. Might take some time.
  5. hmm... does seem sort of similar, but nothing in that about how to reproduce that is needed here. Interesting that it mentions Water Horse avatars though. I use an Aesthetic body normally, and I've just tried reproducing my issue wearing another mesh body, and a naked system body. All reproduce my issue exactly when I detach the horse and attach another folder quickly. Everything happened exactly the same. So it points towards the horse causing it. Only when the horse is linked with it's accessory parts and attached/detached as one object, but not when they are all attached as separate parts. Then it does not happen. I only got around to linking the horse the other day, and the issue happened almost immediately. ETA: I will get Catznip and try...
  6. Ahh - not seen those before. Nope - doesn't work. Just tried it and still 1m in the air.
  7. Do you mean from the Avatar Health menu, Stop Avatar Animations and Undeform? Those have no effect. First thing I tried
  8. Nice idea, and I do use that in the HUD to move the horse to the ground (-12cm) when attached. I disabled it during troubleshooting the above issue. However, when the floating-in-the-air issue happens, if I try to use adjustheight to prevent the issue by putting me back on the ground (with a -115cm setting - I tried it), it will bury me in the ground when the issue doesn't happen. There's no way to know if it happens or not, not in a script anyway. It's obvious looking at the screen of course. ETA: Oh yes, I forgot that since the hovering effect is local to my viewer, anyone else sees me properly on the ground. So if I used the setting to lower me, they would see me buried, lol. I tried that too on Saturday. All that adjustheight does is the same as using the quick prefs hover slider (or the debug setting).
  9. This is a complex one due to what I'm doing, and probably hard for someone else to reproduce. I have reproduced it over and over, all weekend. I cannot yet reproduce it with my alt (who also has the horse) although we don't have all the same items otherwise. The Issue When I quickly detach a bento horse attachment and reattach something else, using RLV commands to do so, the hover height from the bento horse gets stuck and the avatar then stays a metre in the air. Video Link Long-winded Description I use the Water Horse Bento Riding Horse (an attachment, not vehicle) and I also have my own HUD that uses RLVa to attach/detach folders from inventory. While my HUD does a lot internally, the relevant things are that it sends @attachallover and @detachall to the viewer to attach/detach the selected folder full of items, and sends these in rapid succession if I let it automatically detach one folder before attaching the newly selected one. I have also reproduced the issue with a very simple script which is at the end. It just detaches one folder, then attaches the next and reproduces the issue exactly as my HUD does. Also relevant is that the issue only appears to happen if I have the horse parts linked together (horse body, tack with the scripts in, tail, mane) as is often recommended in their chat group. It does not (yet) seem to happen if I have all the horse parts in the folder unlinked. When the @detach (horse folder) and @attach (other folder without the horse) commands are sent quickly, the hover height from the bento horse body gets 'stuck'. The only way to reset that hover height is to attach the horse again, and detach it without immediately attaching anything else. Or to relog, although I even saw it survive a relog twice! (I did have another viewer instance opened up though, with an alt logged in). The hover is only in the avatar's viewer; my alt logged in on the same PC saw the main avatar on the ground when expected. Salient points The hover issue seems local to the viewer. Other than the linked Bento horse, no items in the folders seem especially causative. I have reproduced it with only the linked horse in the horse folder, and nothing in the other folder, albeit rarely (see next point). The folder contents are relevant: the more I have in them (and possibly the more complex?) the more likely the issue is to reproduce. With the folder contents as shown in the video, it reproduces almost every time. With fewer items it becomes intermittent and might or might not reproduce on successive attempts, to the point of only rarely happening with almost empty folders. Timing between the @detach and @attach seems critical. If I let the script send them quickly (around 0.1s between) the issue happens. If I put a 1s delay in-between, it does not happen. I cannot reproduce the issue in any other way than sending the two RLV commands as above. It does not reproduce if I manually add/remove the folder contents from inventory, even as quickly as I can. Nor if I use my HUD but just detach the horse, then attach the other folder, rather than letting the HUD do the two operations together. The viewer's hover height adjustment in the quick prefs is never changed during any of this. Nothing to do with it. Only reattaching and removing the horse, or (usually) relogging, remove the stuck hover. TPing, stop animations, undeform, change outfits... none of those remove the hover. Regarding my HUD: It has buttons, each pointing to a folder in the #RLV folder tree. Press a button - it attaches that folder, or detaches it if already attached. It can also automatically detach the attached folder if another folder's button is pressed, before attaching that newly selected folder. This is when it happens quickly and causes the issue. The RLV debug output shows that the @detach is always executed before the corresponding @attach, so they are in the correct (sent) order. Video Sequence and Notes Video Link Press the 'Horse' button on the HUD; the orange bar lights on the button to indicate 'attached'. You can see the folder F26 contents attach, and the RLV debug in chat. The @getinvworn is just the HUD doing housekeeping. Ignore the horse hovering a little... it always does that. Nothing to do with the issue. Press the 'No Horse' button, which will automatically detach the Horse folder then attach its own folder (F27). Observe the @detach then @attach debug output. Observe that the avatar stays up in the air. The hover height belonging to the horse attachment is 'stuck'. Repeat the above, just because I can. Attach the horse again, and then (I did this a bit quick, but...) This time, instead of pressing the 'No Horse' button, just press the currently attached 'Horse' button again which will only detach the folder's contents. Observe that the avatar is now on the ground again. Ignore the animations still running. It's not an animation issue. Finale So, there we have it. Whatever is causing the issue to happen in how I am doing things, I think it is something that should not happen regardless. Good luck to anyone else trying to reproduce it though Simple repro script integer attached; default { touch_start(integer total_number) { if (attached=!attached) { llOwnerSay("Toggling F26 On, F27 Off"); llOwnerSay("@detachall:.FAST_Demon/F26=force"); llOwnerSay("@attachallover:.FAST_Demon/F27=force"); } else { llOwnerSay("Toggling F27 On, F26 Off"); llOwnerSay("@detachall:.FAST_Demon/F27=force"); llOwnerSay("@attachallover:.FAST_Demon/F26=force"); } } }
  10. ETA: Sorry I just wrote a load of rubbish. The bottom line is that the prim will move with its attachment point, because it isn't rigged. If you want particles at that attachment point, it will work. If you want them rigged to another bone, that isn;t exposed in the viewer as an attachment point, it won't work. The (unrigged) prim will move with the attachment point, not the bone you want it at. OK if you stay still, not when you move and animate.
  11. True. Clouds, linings, and all that. I'll have to think of something else to do with my newfound power That's two things I've learned today, including what a haiku is.
  12. Aye, unfortunately adding a child prim won't work for me because it won't move relative to the bone I need it at. I thought I had such a good idea, that I hadn't seen done before, and I even learned about rigging to make it happen, lol. I was so disappointed when I found out why I hadn't seen it done before
  13. I've just spent L$10,000 on Avastar for just one project, only to find that the particle source on rigged mesh attachments is avatar centre, and this is expected behaviour!!! It's killed my wonderful idea stone dead. What idiot decided that? Seriously, I rarely whinge about SL (since I learned how things work here) but that is just stupid. Especially now we have Bento with loads of new possibilities... think what we could achieve without this ridiculous limitation. Arghhh! /rant.
  14. Whirly, what program do you use to make the video you put in the JIRA? I've tried some in the past but they never worked well for me. I could show you exactly what I'm seeing here...
  15. Thank you Whirly. I've added a comment that it has just reproduced much more easily for me. I'll keep an eye on the JIRA
  16. Yep - it reproduced. I've sent the file. Thank you once again for your help.
  17. Yes, that does seem to have stopped it. Wonder what it could have been in the settings?
  18. Thought for a minute there it might be my firewall... I disabled it and suddenly the issue stopped, but no, false alert. I just got a couple of times then back to flicking/reverting again. The Firewall has not been changed in ages, and I don't run any AV. ETA: I'll try the above now...
  19. I wonder if it started when I installed the new FS version when it came out... it could be around that time. I have both versions installed on this PC, although they are different 'types' (old=OpenSim, new=havoc). Could that be a problem? 'About' text pasted at the end for both. I haven't changed any settings in a while, and always recover my settings from a backup when I install FS. I've not changed those settings you pictured. (never even seen those, lol). The issue does not happen on another PC, with the latest FS. It does not happen on this PC with LL viewer. It happens almost all the time on both FS versions on this PC. I think my way forward here is simply to wipe both FS from this PC and reinstall just the new one. Hopefully that will fix whatever is going wrong. Firestorm 5.0.7 (52912) Jun 13 2017 03:57:58 (Firestorm-Releasex64) with OpenSimulator support Release Notes You are at 219.0, 192.9, 501.3 in Sandbox Wanderton located at sim10790.agni.lindenlab.com (216.82.56.80:13005) SLURL: http://maps.secondlife.com/secondlife/Sandbox%20Wanderton/219/193/501 (global coordinates 254,683.0, 255,681.0, 501.3) Second Life RC BlueSteel 18.03.05.513046 Release Notes CPU: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (3408.22 MHz) Memory: 15785 MB OS Version: Microsoft Windows 7 SP1 64-bit (Build 7601) Graphics Card Vendor: Intel Graphics Card: Intel(R) HD Graphics 530 Windows Graphics Driver Version: 21.20.0016.4551 OpenGL Version: 4.2.0 - Build 21.20.16.4551 RestrainedLove API: RLV v3.1.4 / RLVa v2.1.0.52912 libcurl Version: libcurl/7.47.0 OpenSSL/1.0.1i zlib/1.2.8 J2C Decoder Version: KDU v7.9.1 Audio Driver Version: FMOD Ex 4.44.61 LLCEFLib/CEF Version: 1.5.3-(CEF-WIN-3.2526.1347-32) LibVLC Version: 2.2.4 Voice Server Version: Not Connected Settings mode: Viewer 5 Viewer Skin: StarLight (Mono Teal) Window size: 1600x1138 px Font Used: Deja Vu (96 dpi) Font Size Adjustment: 0 pt UI Scaling: 1 Draw distance: 56 m Bandwidth: 1500 kbit/s LOD factor: 4 Render quality: High (5/7) Advanced Lighting Model: Yes Texture memory: 768 MB (1) VFS (cache) creation time (UTC): 2017-6-22T0:38:37 Built with MSVC version 1800 Packets Lost: 0/2,891 (0.0%) March 11 2018 05:51:54 SLT Firestorm 5.0.11 (53634) Jan 9 2018 18:51:07 (Firestorm-Releasex64) with Havok support Release Notes You are at 219.0, 192.9, 501.3 in Sandbox Wanderton located at sim10790.agni.lindenlab.com (216.82.56.80:13005) SLURL: http://maps.secondlife.com/secondlife/Sandbox%20Wanderton/219/193/501 (global coordinates 254,683.0, 255,681.0, 501.3) Second Life RC BlueSteel 18.03.05.513046 Release Notes CPU: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (3408.24 MHz) Memory: 15785 MB OS Version: Microsoft Windows 7 SP1 64-bit (Build 7601) Graphics Card Vendor: Intel Graphics Card: Intel(R) HD Graphics 530 Windows Graphics Driver Version: 21.20.16.4551 OpenGL Version: 4.2.0 - Build 21.20.16.4551 RestrainedLove API: RLV v3.1.4 / RLVa v2.1.0.53634 libcurl Version: libcurl/7.47.0 OpenSSL/1.0.1i zlib/1.2.8 J2C Decoder Version: KDU v7.9.1 Audio Driver Version: FMOD Ex 4.44.61 LLCEFLib/CEF Version: 1.5.3-(CEF-WIN-3.2526.1347-32) LibVLC Version: 2.2.4 Voice Server Version: Not Connected Settings mode: Viewer 5 Viewer Skin: StarLight (Mono Teal) Window size: 1600x1138 px Font Used: Deja Vu (96 dpi) Font Size Adjustment: 0 pt UI Scaling: 1 Draw distance: 56 m Bandwidth: 1500 kbit/s LOD factor: 4 Render quality: High (5/7) Advanced Lighting Model: Yes Texture memory: 768 MB (1) VFS (cache) creation time (UTC): 2018-1-25T8:42:56 Built with MSVC version 1800 Packets Lost: 0/1,215 (0.0%) March 11 2018 05:53:52 SLT
  20. Well that was a quick result. It does not appear to happen in the LL viewer. ETA: I've made about 20 changes in LL viewer, the issue did not happen once. In FS it happens nearly every time.
  21. Local textures, no. LL Viewer, don;t have it installed but I'll try. No other data connection available. I'll try on my other PC. Report back later This issue is starting to drive me nuts, lol. And I'm wearing out my Enter key.
  22. I'm not sure if this would be a server or viewer issue, or a local one... but before I dive into wireshark, has anyone else seen this happening? I'm editing a texture, and trying to change the various mapping parameters, any on them. For instance setting horizontal scale to 0.5. When I press enter on the new number, the face flickers briefly to the correct mapping, then reverts after about half a second to what it was before. Sometimes the number also changes back, often though it stays as what I entered but the face clearly has reverted to what it was before. So, I then press Enter on the number again, and again... I've just had to press Enter 20 times. Every time the face flickered to what I wanted and back again before it eventually stuck. Similarly, I've noticed for a while that trying to set a whole linked object to the same texture or mapping, some parts get it, some revert back to what they were. This has been happening for a few weeks I think, in both the previous and very latest Firestorm versions. It also happens in the beta grid. I know it might be a local network issue, but I have not noticed anything else wrong at all. Just this. So I'm asking before I take drastic troubleshooting steps here.
  23. Ahh, thank you Whirly. I hoped you might have something for me when I posted. My search didn't turn that one up. Moral of the story: Don't recycle TPs
×
×
  • Create New...