Profaitchikenz Haiku

You do realise that we're almost next door to the good old days when self-modifying code was allowed? I remember having to track down a problem for somebody when their developed code stopped working when released to production. Turns out they had written a bit of Z80 code that stuffed a value into an address in the actual code segment where the byte they modified was an instruction to either increment or decrement the HL register pair, which was then treated as an address to jump to, so the code would effectively take one of two branches. It worked fine in the development environment where everything was in RAM, but it stopped working when burnt into ROMs.

smart, but why stop at just one side of the expression? if(pointer-- == i++) { // stuff } else if( pointer-- == i++) { // and so ad infinitum }

Yes, and furthermore, to prove it's a viewer effect and not a server one, I see this in several opensim instances, including a couple of standalones on my LAN, so that even rules out network issues.

I hate it when AI's start doing what I do only better; fallibility is my only remaining sphere of excellence and I'm going to resist any attempts at encroachment. Bring on the EMP, that'll stop them in their tracks.

There is another way to guard against edit-slips and that is to chat out the relevant primitive params for the parts you are editing, ie if you are going to be re-texturing, chat out the PRIM_TEXTURE and PRIM_TEXGEN settings for the child prims, and then if necessary you can restore things to before you did the "I wish I hadn't" thing. It does result in stuffing your inventory full of notecards, of course.

In a similar way, I edited one of the XML files in CoolVlViewer to do this. Henri warned about going too large with the font size as it would impact on the numbering to the left of the script content, so I limited the increase to just 2 points, but it does help greatly.

I use LSO when I have scripts with no long lists or strings because they seem lo cause less impact on regions when arriving, probably due to the 16K allocation mention above. I've tried testing for speed differences in things like hinged doors opening and closing and can't see any performance change between the two in terms of speed, neither does there seem to be any changes in KFM and moveToTarget, so as mentioned above, sorting out Mono issues could then allow LSO to be stuffed in the cupboard together with old teddy bears and dolls missing an eye or a limb.

Just a guess, in the viewer stats check two things, the physics memory details (if there's a growing amount of RAM usage you're heading for the "unable to rezz object that has caused problems in this region" message), and then lower down, look at the timings and see what the spare time and script times are. There might be a hint there that your region needs a restart to clear a problem.

Have you tried stopping the animation whilst still seated and then standing to see if the default sit animation is started again?

But neither have Android interests or any (stated) intentions to try and eat Fussbook's lunch. Do I have to post the dictionary definition of "scurrilous" ?

/me starts a scurrilous rumour that Google are going head-to-head with FussBook in the meta-business by forking OpenSimulator and a viewer to Android.

Rorations can be one of the most complicated subjects for several reasons. Have a look in the LSL wiki for llTargetOmega for a simple system first. You can get some quite slow motion that way, in particular look at the examples. If the earing is to just twirl around the vertical axis like a Christmas tree decoration, look at rotating around the Z-axis, but if you are talking about swinging from side to side like a pendulumn then you will need to rotate around an X or Y axis, or even both. This next part won't make much sense until you've started trying the examples, but since you want to rotate an attachment, the wiki stattes that for an attached prim the rotation will be around the attachment axis, so you will have to pay attention to the alignment of something attached to an earlobe. If it's at a strange angle it might be easier for you to attach a tiny prim, but then put the actual earing as a child prim, and then alter the root prim's attached angle until you have an easy axis for the child prim to rorate around. I.e, if the attachment angle for an earlobe is sloping out and you want to make the earring twirl, attache the root prim to the earlobe and adjust it until the earing child prim is dangling vertically so you can rotate the child prim about one single axis. More complicated systems will use llRotate, but for an attachment you might need to look at local rotations.

I had thought about that first but it seemed better to start from a position of something which was working and go forwards rather than struggle to understand something that wasn't working. Thanks for your thoughts on this anyway.

A question for Henri, Coffee or Beq: how much work would be entailed in updating the Radegast 2.12 source to implement inventory via http and the newer login system? If it's a team-week then I appreciate it's probably not worth bothering over, but if it's a couple of hours I'm wondering if it's worth creating a Radegast fork from 2.12 targeting the Raspberry Pi specifically.

Yes, I think the problem with others is likely to be the repositories they are querying. It was my fault for assuming I was running synaptic via a front end that misled Phil earlier. Sometimes I can be wr- wr- wr- - not quite optimal.

Brilliant! Welcome to the club of Cantankerous Old Gits Who Use Old Software.

It's a long shot, but try sudo mono Radegast.exe Just in case there's some permissions issues with accessing shared stuff. It might also be helpful to post the warning and errors sequence, just on the off-chance.

Synaptic-synaptoc- they all look the same to me Greatly embarrassed and apologetic. I said I had installed mono from synaptic thinking that the Preferences->add/remove software choice was a front-end for Synaptic, and now I find it isn't. On my Linux box synaptic, which I use extensively, looks remarkably similar to what the Raspian software package manager looks like. Try whatever software management package you have available to you from the Pi menus, hopefully there is one. That might then do a better job of pulling in the required dependencies for mono.

That's suggesting that there isn't a full implementation for the 64-bit. You could try expanding the error report to see if it gives you any idea what it's choking on. My thoughts are that there still isn't full support in Raspian 64-bits for everything that is in the default 32-bit system. A quick look through some forum postings that search brought up show quite a lot of fairly important things like VLC were not there in the early 64-bit release plus quite a few other things would need to be recompiled with graphics libraries pointing to a different location because a lot of the stuff (I noticed GlibC in there), was being chucked into /usr rather than /lib. Such changes are non-trivial slightly-difficult, as the Japanese like to say. Quick thought, stick your other card with the 32-bit OS back in and try on that? It's easy enough to just swap cards over to get a different OS to play with.

I can't help with the 64-bit issues. Here is what I installed

No. which mono should give you a path, if it returns nothing then the installation wasn't successful. When successfully installed mono --version should give you the installed version. In synaptic there is a load of potential hits when you search for mono, the one you want is one of the earleir entries in the list, the key thing to look for is CLI (Command Line Interface).

I hesitate to suggest this as an option, but...people have installed Windows 10 on the Pi4Bs with 4G and 8G Ram, so you could then get dotNet 4.7 and run Cinders latest code. However, this to my mind is rather like using dynamite to remove an infected tooth.

Summary of the current investigation. An earlier version of Radegast will run on a 32-bit Raspberry PI distro (Raspbian, Buster, etc) using Mono, there is no need to find a linux version. (Mono will run a windows dotNet program by providing the necessary sub-system). Local chat, IMs, friends, nearby objects all work. You can send and receive IMs, see nearby avatars on the radar, sit on objects, and engage in local chat. It is text-only, the world map won't work. I have no idea if voice will work, I'm going to guess it won't. The version in question pre-dates some significant changes (such as inventory via http), and so although all the inventory folders show up, no individual contents show and there is no ability to create or edit notecards, scripts, or see textures. You can accept inventory offers, the blue popup appears as normal, but you can't see or open the item from inventory. I don't have any Pis with 64bit versions of the OS so I cannot at present check if the 64-bit version will run any of the later versions of Radegast. They might, although it may be that there isn't an up-to-date enough mono version to cover the dotNet 4/5/5.0 requirements of the newer Radegasts.

As with PCs. I think the last 32-bit PC linux I managed to get was 18.04 for my Acer netbook. In the case of the Raspberry Pi, though, they seemed to make a firm decision to stick with 32-bits for the main line of the OS, which meant that any Raspberry Pi, even the early PiB+, could still be updated to the current OS, you didn't have to throw it away just because it was a few years old. From what Henri, Coffee and Beq have been saying, the problem with 32-bit programs isn't that they aren't capable of running, it's that many of the support libraries are no longer available in 32-bit versions. Again, this doesn't mean that a 32-bit version of a graphics library is no longer capable of doing the job (what size image would you have to create to exceed the capabilities of a 32-bit integer?), it just means that library maintainers are looking at the hardware trends and concentrating their efforts on the current and forthcoming requirements and simplifying their workload by just doing 64-bit versions. Explaining Computers uses various video display and editing software to evaluate all the new Raspberry PI and other SBCs that come out, and so far, he hasn't shown a single instance where a 32-bit Raspberry Pi OS isn't able to perform any of his benchmark tasks.

Success on a straight Pi. Raspberry Pi 400 - 32bit Raspbian OS Installed Mono from Synaptic (mono core library for CLI 4.5) Radegast 2.12 downloaded from here (get the zip file and unpack it, don't get the installer) open a terminal in the unpacked folder and make sure you can see Radegast.exe mono Radegast.exe connected to SL with some warnings in the console about the mono version (5.18.0) It got me all the tranche of ownerSay messages from the Funiculars where region idling seems to upset KeyFramedmotion, so, a result No 3D world view that the later Radegast's offered. but Phil just wants chats and IM so it's got that, plus objects. ETA This is the last Latifa version, I then looked to see which might be the earliest Cinders version but I found a statement that it would only support 64-bits and required .NET 4.7.2 or compatible mono to run. I guess I overlooked this last year when I was trying to get Radegast to run Further: Inventory won't work, I saw the folders and assumed all was OK, but on a second login tried to see what was in a folder and it wouldn't open, and trying to reload the inventory cased a CTD, so it's chat and nearby objects only. For Monty: don't know if this is fixable, after the initial report that the inventory cache file had been read the console logged a stream of "unrecognized caps exception" with "error getting response stream" at the end of each message, followed by some unhandled exception messages. Logging back in again did not give the message about a successful read from inventory cache, and the inventory button didn't open a new tab.