Profaitchikenz Haiku

Ok, I think I see the reason why the receiver never gets to the win state. The sender script only sends a "+" once in the move state entry. It then sets a timer of 120 seconds. It then does some moving and shouting but none of those issue another "+", and none of them change state, so the timer will kick in after 120 seconds, send a "-", and the net result is going to be a 0. Somewhere in the move state there needs to be a way to return to the default state without the timer event, or else some thing that sends another "+" and resets the timer again to 120 seconds.

Dam, that's taken half the fun out of scripting.

Pull up the map, wander around, use search, it's much the same as the main grid.

I tried your initial script in world with some llOwnerSay lines to announce what it had heard and what the value of I was just before the test to see if it had reached 6. The script works, and at 6 it changed state. More worrying for me was that a global value declared but not initialised got a default value of 0. I'm not sure how reliable this is, but I do no that not initialising global variables is almost as bad as not initialising automatic variables (which are usually on the stack and so can often get surprisingly sensible values). ETA having read your subsequent script, I'd suggest two things, change llShout to llRegionSay in case you are exceeding the 100m distance, and put some diagnostic lines in the receiver, as I did, to check it gets a + or a - .

It would help to initialise i to 0 before starting.

It might be worth running Firestorm in a window and having the Windows task manager (or Linux LxTask) window positioned so you can keep an eye on the memory usage. I've seen this leap alarmingly when in sims with lots of mesh buildings and large textures and Advanced Lighting enabled. A sudden poof away sounds very like running out of memory. My workaround in Windows is to run the 32-bit version because it seems less greedy on Ram, but in Linux you're stuck with 64-bits unless you build it yourself. My workaround in Linux is to avoid certain places. Once CTD-ed, twice shy.

"In the - Science lab was an Iguana "

The swing I made worked slightly differently. The pivot point was a cylinder laid sideways, and it was the root prim. Attached to each end were two long thin cylinders with rope textures. At the opposite end of these was a flat prim for the seat. The root prim was raised up until it could be hidden in a tree branch. Inside it was a script to rotate it to and fro whenever somebody sat on the seat prim. I had tried particles for the ropes but they were not satisfactory. I had also tried making the root prim a long-sided rectangle with path cuts and full hollow to try and get the swing down to two prims, but it looked awful.

Griefers

I'd suggest looking for Inara Pey's summary of the recent server user group meeting, it was stated there that a new restart system was being trialled the day the script-compilation-fails occurred. It was supposed to make restarting a faster operation, so possibly the new system is now working well enough to be used?

Crash to desktop

I've now got Lubuntu dual-booting alongside Windows 7. It's kinder to my 10-year old tower than Windows 7 Singularity beta installed and ran straight away, Firestorm needed libGLU but then ran fine. I managed to find unison to take the place of windiff, I've got the web-browsers there, storm in a teacup over. One thing I'm really going to miss though is the monthly bloat as more and more windows updates piled up and swallowed up the space on my C drive. (Bill and Ted NOT) Oh, and one other note from the months I've been experimenting with Linux on a much older and lower spec machine: although there are more frequent software updates, they take far less time than windows did, and far fewer restarts are needed after the installation.

No, you need to see how many textures you have in the list, to instead of testing index for 0, try llGetListLength(slides) for being greater than 0. A neat way would be to have a global variable maxSlides, which getSlides sets to be equal to lGetListLength(slides) after it has loaded all he textures, and then all subsequent calls to get the length of the list can be replaced with that variable. It's not saving much in this particular application, but if you start working on systems that run very rapid loops or do a lot of processing, any reduction in function calls is a bonus.

Agree with all of the above, plus ... they had implicit faith that their encryption systems were too complex to be decoded

I thought Vladimir Putin always took his shirt off when demoing manly devices?

A thought here, in state_entry a listen is opened without the handle being assigned, so that listen is always going to be open? In the touch event, I can't understand why the first thing done is to remove a listen, the best times to do this are in a timeout (as done but commented out) , and also when a "done" command is processed, again, as happens. My suggestion here is remove the listen in state_entry, open a listen in the touch event before calling the multi-dialog, and just keep using that handle until either it gets timed-out or the Done button is pressed. Inside the touch event, I would therefore suggest you have a global variable set whenever processing has started, so a touch only starts a new set of menu dialogs and listens off if there isn't already one in progress. I would also suggest cancelling the timer at the very start of the listen event to avoid it triggering should some of the list processing drag on a bit.

Yes, it is possible to modify it, empty the list, then at startup call a small routine that counts how many textures there are in the object and adds each name to the list. index is the loop counter that chooses the texture from the list. As you can see, it is incremented to get to the next entry in the list and tested so that if it becomes greater than the list it is reset to 0. // at the top, initialise slides to an empty list list slides = []; // then create a function after the line declaring index getSlides() { integer ii; integer iiMax = llGetInventoryNumber(INVENTORY_TEXTURE); string name; for( ii = 0; ii < iiMax; ii++) { name = llGetInventoryName(INVENTORY_TEXTURE, ii); slides += [name]; } } // then in state_entry , before the line setting the timer event, add this line getSlides(); // further enhancements would be to check there are actually some list entries before setting // the timer to a non-zero value, and perhaps adding a changed event to re-read the list if // the inventory changes (adding or deleting slides) Ah, Rolig, what do I have to do to get the jump on you ? @)

Ah, but "Leben" is "living", there's a small but subtle difference, the "Leibstandarte" were the SS life-guards division I do admit however that I got my F and B mixed up in my previous post, rather misleading, I know.

SecondLife would be called ThirdReichLief

Things like Anim8tor and ArtOfIllusion might be another reason for people sticking with earlier OSes, not all of them will run under Windows 10. I'm tempted to try a dual-boot W10/W7 system to try and get the best of both worlds.

Because SecondLife works to 0.01 metres as the minimum, and I need a much smaller resolution. 3DCrafter does an excellent job of resizing an entire object, but the free version doesn't support some of the object intersections that 3Dbuilder does, and I find building in it rather disorientating. Blender's interface drives me nuts, and again, gives a feeling of disorientation. SecondLife offers me the most natural feeling when making things, followed fairly closely by Sketchup, but as that application raises so many people's hackles I'll say no more.

You can make the same argument about classic cars, there's no reason to drive something that doesn't have ABS, airbags, traction control, bull-bars... but some of us still do.

They're going along the NT-based path and I don't as yet see any signs of implementing a dotnet environment, (although somebody could always port Mono to ReactOS). There are some things that linux doesn't really do as easily as Windows, or at least, they do implement things like file-synching between folders on networked machines, but it's so eye-wateringly tedious to get right compared with the clicking-simplicity of windiff. Like Qie, I've got Lubuntu on a machine and it can access SecondLife well enough using several TP-viewers that even give support for Bake-on-Mesh, and if a machine can run Windows7 well enough to access SL, it can certainly manage Lubuntu/Zorin/Mint/Raspberry Pi's desktop with a TPV, so I don't see the doom and gloom picture that's being pushed here. There is, of course, Wine... (Oh, must we?)

In general, the Apps Microsoft want you to look at smack horribly of tablet-based clicky-slidy things that really belong on a surface (oh wait, is that where their roadmap is leading us?), and even worse, many of the bloat-stuff that you laboriously remove or disable comes right back after every "we're making Windows Better" update. I didn't realise it had got sick. In defence of 3DBuilder, I actually found it quite handy. I build something in SL ten times larger than I actually want, export it as an OBJ (or a DAE in which case it has to then go via Blender to get re-exported as an OBJ or 3DS), pass it into 3DCrafter to scale it by 1/10th and re-orient the axes, then put it into 3DBuilder and do any final tweaks such as edge-bevels, and finally send it via Cura to a 3D Printer. Before that, I had to do a lot of fiddling about in Blender and typically made things far worse.

You know you've gone over the top when you're wandering along the street, see something amusing, and say "LOL" or "ROFL" out loud.