Profaitchikenz Haiku

To save too much wasted time, I've just tried to get the latest Radegast from Cinder's bitbucket to install under wine without success (annoyingly it's referring me to a log file for the errors that just will not open), so linux looks the best bet.

I should have made it clear above, the viewers I was able to run under wine are on linux 32-bit and linux 64-but PCs, I haven't bothered with wine on the Pi400 (yet).

The OS is 32-bit, as was in all the Pi's until a few months ago when the experimental 64-bit OS version arrived. Raspberry Pi OS with desktop Release date: September 22nd 2022 System: 32-bit Kernel version: 5.15 Debian version: 11 (bullseye) Size: 894MB The hardware is 64-bit, as was mentioned earlier. SoC: Broadcom BCM2711C0 quad-core A72 (ARMv8-A) 64-bit @ 1.8GHz

I had a look at on on the Pi400, which gave a segmentation fault, I am guessing this is because the Pi400 is a 32-bit system but Ubuntu and most other linux distros expect to be on a 64-bit system? I had to alter the edition value in cargo.toml from 2021 to 2018 ETA the segmentation fault occurred during the build, by the way.

I just checked back through the Radegast builds I had been running on Linux, the last version that worked under Linux (using mono) was 2.25.134, which loads but won't connect to SL and I believe that was the connectivity issue that hit most of the viewers and needed to fast footwork to get round. All the subsequent versions I got from Cinder's site have failed to run under Linux with mono 4.6.2, claiming an assembly issue which suggests to me that they have something linked to them that can only be satisfied by dotNet, or by upgrading mono, but I am reluctant to tinker with mono for risk of upsetting my standalone. If Linux had something as easy as Acronis to allow snapshotting and rolling back to an earlier state I might be less worried, but one session with Clonezilla was enough for me. They do all run happily under Windows 7 though. All that to say that there might be more issues to be solved with running Radegast on a Raspberry pi than just the OpenGl issue. There is, however, one other path you might consider, and that is using wine on the Raspberry Pi. I have been able to get Alchemy Beta and Singularity to run quite happily under wine after Animat's tip about giving the disk a serial number, but I do recall now that I wasn't able to get Radegast running under wine, though I can't recall exactly what it didn't like (possibly dotNet?).

As your original stated intention is to reduce your power consumption, there are a couple of other options you might consider. 1. Solar/Lead-acid Battery. My earliest PiB+ runs off a 12Volt old car battery that is charged by a 30Watt solar panel, with a buck-boost PSU to give a steady 5.1Volts from whatever the accumulator drops to, (running any lead-acid battery down below 9Volts isn't a good idea but when you've had to remove it from your car because it's barely keeping up to 10Volts what have you got to lose?). The workbench Pi4B that runs the camera so I don't have to peer intently at spinning cutters with swirling metal swarf runs off a bank of NiMH C-cells charged from another 30Watt solar panel through another buck-boost converter. 2. Solar/Lion battery. To run a tower PC off a solar-charged battery required a bit more current than the Pi, and the cheaper buck-bost converters aren't up to the job. Get a 24Volt/240VAC lorry inverter, and get some of the Makita power-tool batteries with two of the shoe adaptors, run them in pairs to avoid heating a single battery too much. But, (but but but...) Unless you're trying to live off-grid, the 300Watts that your typical Tower PC (well, my typical antiquated tower PC) consumes isn't really going to do anything noticeable to your electric bill, unless you're running it 24/7 for a series of bots going round seeing who lives where in SL Switch the PC back on. If you want to save power, run Radegast on it, turn the monitor off, and use VNC to look into Radegast from your solar/battery powered Pi.

Don't forget to check that your partition(s) are correctly aligned to optimise for the SSD writes. There's a couple of free-download checkers that will do this and adjust the partition alignment.

This is the missing library that causes the current 3D-printing slicer programs to fail to install. I didn't go any further after realising my Pi400 and Pi4B are both running the 32-bit OS, and I'm not yet ready to go through the pain of un-breaking the things I do actually need running on them.

I don't want to dampen all the enthusiasm, but there are some limitations with the System-on chip technology used by not only the Raspberry Pi but most of the other Single-board -computers. It is very unlikely that in that small a size they are even going to get close to the early Intel Integrated Graphics capability. But even that standard should do for something like Radegast. However... There are two people who have posted a lot of interesting things about them on Youtube channels, Explaining Computers, and Jeff Geerling are the two who have delved the deepest into what you can and can't do with them. Jeff Gerling in particular spent a long time trying to attach graphics cards to the Pi and get them recognised by the software, having to add to the OS in order to properly detect a card, but even then he was unsuccessful mainly because there was no OpenGL support to actually do anything with the GPU he had finally got the Pi to recognise in the list of attached devices. That was a year and a bit ago, but I haven't seen any further experiments. What I tried myself was to use VNC to run the display, keyboard and mouse on a Pi400 looking at a tower PC running SecondLife, in order to see if the onboard HDMI graphics were even capable of displaying it. They were, which does make sense when you consider the Pis can handle full HDMI video. (However, throwing that much information across a wireless network to the Pi was obviously slowing things down as well). I have tried quite a few other apps, even building from source, to see what graphical displays will run on the Pis, especially for the CNCs and laser cutting controllers, and the success rate is not exciting, two out of eight programs I tried would run on the Pi, and then, with limited results. For example, a controller for the small CNC milling machine would display the GUI, accept and stream commands, but wouldn't update the isometric view showing the tool position in realtime. All attempts to get slicing software for the 3D-printers to even load failed. Most of those programs do rely extensively on OpenGL and so it wasn't surprising where I couldn't get a result.

The main problem you'll encounter with the Raspberry Pi is there is limited OpenGL support for it, which is going to be a bit of a hindrance to even low-Graphics programs like Radegast even when built from source. There are reports from people like Jeff Geerling about workarounds for this, and I also believe that the Dayturn forums might have some advice on implemtations. The newer Pi4Bs are offering a 64-bit OS and there might be openGL support on the way for that.

Just to point put that in the ones I am seeing, the opposite is the case regarding age, none of them are older than a few months. But your other observations about empty profiles is correct, and no picks either.

I still have three PDP-11s and a Microvax that in an emergency can be plugged in and used as room-heaters Going back to the original point though, I've played around with the new Firestorm quite a bit now and am happy with it. I haven't looked at the FPS figure (I never do), there is no sense of sluggishness as I move around, which is to my mind the critical measurement, albeit a subjective one.

I'm not sure how we could even test server load: There is no basic server load measurement akin to the Windows CPU/RAM usage. The Ctrl-Shift-1 stats available to us aren't precisely defined to the point we can understand fully what is going on. Many of the timing figures such are averages over a 30-minute or so period. Some of the figures are also more affected by network behaviour than by server activity. Things like packets in/out are rapid but are responding to transients like position change/ avatar arrival/departure. The physics memory seems to be a catastrophe/cusp figure, it's happy at 80-90 Mb until something goes wrong and then it shoots up to 100M and nothing works (failed to create object that has caused problems in this region...) Things like streaming cost that we see when we upload a mesh are not available to us in real-time and so we cannot do a prim -> mesh comparison. We have an objects used / objects remaining count but that is just a housekeeping function and nothing to do with any actual pain the server might be feeling. Comparisons between SL and Opensim servers are also tricky because of significant differences, for instance SL implements a time-slicing function for scripts., Opensim doesn't; OpenSim doesn't give top-collider measurements and shows script times in a different form. There are a few possible things to try, for example, timing the rezz-time for a prim build and an equivalent mesh build, moving both objects around using KFM/Puppeteering/Move to target and seeing if one is faster.

I'm with you there. I always hum to myself, and people often ask me "How come you're so happy?", and I used to flippantly say "I'm too stupid to be miserable". Then one day, I realised, it was true.

So, it might come down to this: are prims/sculpts easier for the physics part of the server than mesh? Personally, I'm coming to the view that this whole LI issue is a case of a man-made problem. For some reason LL implement a 15,000 LI limit to a region. OpenSim does not. In SL, then, the need to reduce LI counts is more pressing than in Opensims, but the fact that some Opensim regions can offer up to 45,000 prims suggests that there is no hardware/software limitation that caused LL to set this limit. if it had been a power of two for the maximum Prims that would have hinted at software. The comparable case I recall was on Vax VMS where there was a maximum limit to the number of files a directory could contain (10,000 or 12,000 I think?) but there was no obvious reason why this figure was chosen. It may well be that this was a figure established pragmatically that has to do with server loading, but I wonder whether it is now well out of date and the upper limit could be increased? That would then reduce the number of people trying to mesh up their prims to fit them all into the limit.

Packets in / Packets out I've spent a short while inworld watching both the stats floater and what's happening around me. A very quiet mainland region, only one other avatar besides myself who was some way off and apparently not moving, I was sitting during the first tests. Packets in/out figures were 25/40 approx when nothing else was happening. When the train or funiculars started to move, the counts both shot up, in some cases to 80/160, but then dropped away again. However, this was not always the case, several times the train would come and go with no change. When I stood up and moved around, both figures increased, and then dropped back as I came to a halt. The in/out count would seem to be something to do with moving objects in the region. So in the case Chin posted, there might have been somebody way up out of sight testing their new Himars missile system?

As far as I understand the process, sculpts and prims have a default LoD behaviour that is built-in, whereas mesh, as we know, either needs specific LoD models crafting or a default process during upload creates them. Sculpts also have a fairly basic physics shape. Leaving aside the tricky subject of trying to texture them, I find they are most useful because you know they're just 1 LI per map with predictable LoD behaviour and so require far less work to use. Ages ago, I remember reading a post by somebody explaining that sculpts are turned into the collection of triangles by a process that was admitted to be "a bit of a hack", but I haven't been able to locate this. The main point I take away from this is that prims and sculpts are more "native" to the SL object rendering methods than Mesh, but whether this is because they are older, or because they are essentially simpler and easier to implement that mesh I don't know. All of my explorations regarding efficiency have been to do with puppeteering prims/sculpt/part-mesh objects and as such I have always been focused on the script load, not any other server loads such as physics. Partly this is due to my trying to achieve smooth motion. but also it is laziness on my part in that many of the stats and metrics available via the stats floater don't seem to mean anything obvious to me. The increase in packets in/out Chin showed on the beta grid is a prime example, I would not usually have paid much attention to it, and it may well be that it is one of these "doesn't matter" (*) cases where a stat that is available has no real meaning as far as our experience in-world goes. When I made mesh wheels and axles to replace the 8 sculpts with three meshed items in one of FollowMeI'mThePiedPiper's engines, the total LI of the engine increased by 18 because of the need to make mesh models that would not degenerate into triangles at 8 + metres, however, the time taken by the script to move the engine around and also rotate the wheels and move the coupling rods more than halved. It's a subjective assessment, but the result didn't seem to adversely impact any other items in the region, so I assumed there was no extra loading put on the server as a result of having three mesh parts rather than 8 sculpted parts to deal with. (*) "Doesn't matter, Vic" "Doesn't matter, Bob" DC Al Capo

Why not just put cling-film over the keyboard?

The main advantage in that case comes from build-simplification for the purposes of scripting items to be moved around. For example, when puppeteering a railway engine, a single set of driving wheels built from prims comes out at about 60-odd prims (spokes, wheels, flanges, crank pins...) so rotating those around the axle is a lot of scripting, but meshing those 60-odd prims into an 11 LI mesh object means only a single item to be rotated. And of course, railway engines will have two or three such sets of driving wheels... So the next test to try and make is to see if it is easier on the server to move a linkset of mainly prims, compared to a linkset of mixed mesh, sculpts and prims? I'll see if I can get some metrics on a couple of my in-hand projects.

I'm intrigued by the great difference between packets in and packets out on the SecondLife Beta test. I can't work out the significance of it, but it's a big change. The only real advantage I can see to using all mesh or mostly mesh for things like houses would be to try and reduce the drift or creep that happens at high altitudes, in that it would perhaps result in fewer items having to be teased back into place.

I'm seeing this with a pair of KeyframedMotion objects that for the past four or five days have spates of failing to reach the target, they send error IMs when they time-out. I have a feeling this is due to region idling. ETA With a couple of extra checks added I am seeing the KFM failures when region FPS is low and there are zero avatars in the region, so it is caused by region idling. Identical scripted objects in another Grid (outside of SL) do not show any similar errors. If the scripts are your own, or are modifiable, you can try testing for region idling and not initiate actions in those circumstances. (llGetEnv and llGetRegionFPS). However, given that region idling must have happened many times in the particular parcel I have, I can't really think of any reason why the objects should suddenly start throwing up lots of errors. I don't recall seeing anything in the recent release notes saying changes were being made to region behaviour in these areas.

I just tested it inworld and the script behaves as it claims, the prim is invisible during the rising phase, then becomes visible when it returns to the original position. If you stand up partway through the ascent there is a short pause before the prim re-appears in the original position. Regarding your other question about having two poseballs for both climbing and descending, this is how you would alter the second script, it is a straightforward change where you subtract instead of add the change to position required.

As far back as I can recall, the LL viewer has used web-based profiles, and it was the lengthy wait until the profile appeared that drove me back to Catznip where they give you the inworld profile. I don't think there is any way to specify where the viewer should go for the profiles.

Take a closer look at Ferd's script, in particular the climbup() function, at the end of which he resets to the original position. Before doing that he checks to see if there is anybody still sitting on the child prim. He unsits them if so, and then calls some code, but I suspect the changed event occurs and maybe interferes. Scripts from Opensim are not necessarily going to work straight away in SecondLife because there are some implementation differences.

else // avatar is NULL_KEY in this condition, reset anything such as the pose ball to the starting point. It's important to realise what is happening in the changed event here CHANGED_LINK will be set whenever the number of child prims increases or decreases. Testing AvatarOnSitTarget returns a key which will be NULL_KEY if there is no avatar on the sit target, so you can (with some caveats) assume that the avatar has left the building and put things back ready for the next one. One caveat here is that if the script is running and you edit the object to link or unlink child prims, the event will be raised.