Profaitchikenz Haiku

Snippet and texture showing a timer display to handle 0 to 5 mins 55 seconds in 5 seconds granularity Snippets for a three-face counter, the 4th face is the timer background and includes the colon separating minute face from seconds faces The eagle-eyed will notice that the offset figures do not follow the expected sequence, I jiggled the values empirically until they looked right, using precise figures resulted in them looking a bit out of line // handle digits display string digits = "timer digits"; // name of texture vector reps = <0.25, 0.5, 0.0>; // texture repeats to access sub-portion of image list texParams = [ -0.35031, 0.22002, // blank = 0 -0.16012, 0.22002, // 0 2 0.10010, 0.22002, // 1 4 0.34031, 0.22002, // 2 6 -0.37015, -0.26005, // 3 8 -0.16012, -0.26005, // 4 10 0.10010, -0.26005, // 5 12 0.34009, -0.26005 // - 14 ]; integer minsFace = 6; integer secsHighFace = 1; integer secsLowFace = 2; setDigit(integer digit, integer face) { // double the digit,. add 2, so that 0 = 2, 1 = 4, 2 = 6, 3 = 8, 4 = 10, 5 = 12, leaving blank -1 => 0 and - 6 > 14 integer ind = digit * 2 + 2; vector offset = <llList2Float(texParams, ind), llList2Float(texParams, ind+1), 0.0>; llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_TEXTURE, face, digits, reps, offset, 0.0]); } blankDisplay() { setDigit(-1, minsFace); setDigit(-1, secsHighFace); setDigit(-1, secsLowFace); } The texture: ( the dashes are used for effect when changing times by momentarily setting the digit to be changed to a dash then too the new digit to give a railwaylike effect)

I was going to post my train timer which does exactly what the OP has asked for, but then I realised I made up a special mesh for it that might be outside the OP's toolset. I'll probably put the script and texture up anyway as an example of a simple minute and seconds timer, but I do like your method of generating the texture. I made mine by putting prims together in SecondLife with a single digit on each, positioning them by script, and then grabbing screencaps looking down vertically with the sun set to midday to ensure even illumination. "Polluting directories with lots of small files" is where Linux scores over NTFS, because there's no minimum cluster size allocated to such small files.

What you are looking at is a prim or several prims with individual faces onto which a set of different textures can be shown. If you create a single texture on which you have the digits 0 through to 9 then by applying a portion of that texture to a particular face you can show any of the digit. If you have the ability to make such a texture, and the ability to work with simple scripts then there are people here who will help you make such a timer. It isn't actually difficult to do if you make a good texture that is nicely proportioned so that the maths for the texture offsets and repeats doesn't require any awkward corrections.

Yes, there's also the inherent problem that only the post-creator could edit the thread. However, a redirection is then moving the seeker-of-knowledge away from the forums. It's a burger whichever way you look at it.

Exactly. And we are therefore losing track of incredibly useful information. That's why I am thinking about a stickied post where there are headings, and a particular thread that ended up with something useful on say, Camera control, get's linked in that topic under a section headed "Camera".

I've begun to notice more and more how hard it is to find a particular topic in the forum, in today's instance I knew the question being asked had only recently been discussed but I went back three pages without seeing any obvious title, and it was just by chance I clicked on "zoom" to find where camera controls had been discussed. And it's even happened to me with my own posts, I've spent ages trawling through my profile listing of posts to find something I remember dealing with but the titles just don't help. the topic titles don't always encapsulate the solutions held within them, which is understandable since the poster raising the query can't be expected to know the nature of the solution in all of the cases. Using search can help, but all too often it's a wall of text that's as tedious to make sense of as going through the pages of topics, and not really any faster. One option is having a way to tag posts once they have been fully answered and are going to lie quietly awaiting the odd necro-poster. Another way would be to have a stickied post containing headings such as "camera control", "Keyframed motion", "Herding cats", and when a particular topic has resulted in some interesting or ideal model answers, link that post under the relevant heading. Both options will require that a regular does the reviewing to properly tag or categorise such topics. As Drop Dead Fred says whilst surfing on the water spout in the sinking houseboat, "What are your thoughts?"

Have a look at some of the posts in https://community.secondlife.com/forums/topic/479145-zoom-script-question/ Basically you are going to take control of your avatar's camera when sitting but set it to a fixed position and focus. Several posters in that thread describe exactly how to do it, Rolig and K T in particular.

Indeed, but mostly they are aimed at the mesh-aware, my suggestion is that since the OP has no knowledge of what has gone on during their absence, the SL starters will be an easier introduction. No need to learn the complexities of appliers or alpha-cuts, just get straight in with BoM.

Have a histograph showing the variations of number of avatars present and duration, most people going by traffic are looking to find other people, often more than one other person, particularly for RP sims, and again, looking for long-stayers, not just three people present for short 5-minute segments. For shopping and adventure sms I'm not sure if traffic is significant as a destination-decider. For sandboxes, possibly the opposite to high traffic is what is desirred?

On easy option is to find your way to where the SL Newcomers arrive and see hat the new mesh starter avatars and clothes are like, it would perhaps be a simple way of trying out mesh for free before committing your wallet.

OK, so I could be clever and say "Be confused, be very confused", but every now and then I get the urge to explain myself in depth... MicroOhSosoft has gained a reputation for overly-complex or extremely verbose ways of tackling what should be quite simple activities, so let's have a quick go at seeing what a C# implementation for SL might look like... Public Void StateSytem stateDefault = New StateSystem() { void stateDefault.state_entry() { } stateSystem.addEvent new Event(stateDefault.touch_start(int number_touches)) { // within the inner levels we will find some nice familiar C-style statements that are compact, nay almost terse // so why make the surrounding structures so breedin' voluminous? } } It's like writing a novel, except nobody gets killed or lives happily ever after... I don't know quite what the Msys developers had against Microsoft's implementation of make, but it was obviously a bit more than just "meh" (I appreciate my lampooning of C# isn't going to compile or even get a thumbs-up from experienced coders, but that wasn't the intention here...)

I can only quote the installation process success message when putting Mysy and MinGW onto windows... "Oh Joy, you do not have make installed. Keep it that way"

I fully agree (now), and after a few days of hair-tearing and tracking down the problem I no longer write val = llList2Vector(points, index+3)) but instead declare the offsets into a strided list as integer FROMOFFSET = 2; integer TOOFFSET = 3; and so on, so I then write val = llList2Vector(points, index+FROMOFFSET); It took me several days to track down a mind-bogglingly stupid mistake where I had used an incorrect offset value and because it was just a number and not a named literal, I was blind to it. If you want to use magic numbers, I always go for things like e to the j pi, it adds a sort of mystique to what the code looks like.

If the string being received isn't always going to adhere to a pre-defined format, you can add preceding integers for each sub-component to specify what it should be cast to: string listInMsg = "integerValFloat, 1.00024, integerValVector, <1.0,24.5,2.4>, integerValRot,<0.74,0.0,0.0,0.74>, integerValString, 'I am the name of your successor and you have been fired'" integerValFloat, etc is obtained by using llGetLitentryType(index) when first extracting parts of the list to a string. to break the string up into the required substrings, locate the end of the substring for the required type by searching for , if its an integer or a float, >, for vector and rotations, strings get messy which is why I always encase them in quotes when doing serialisation.

I'd get myself a snail avatar

We didn't need SecondLife before it arrived. We didn't need mobile phones for years, we got along fine with maps before there were sat-navs, many things became desirable against the pundit's pronouncements at the time of their genesis. What people want is one of these elusive quantities that every business strives to answer, and half the puzzle is that we often don't know what e want until somebody plonks it on a plate in front of us.

This is where I think LL would win out over the OpenSimulator devs. Pima-donna technical tantrums are usually quelled by somebody in command wielding the big "business case" stick. Companies do this because their prime objective is for company survival (via profitability/adherence to regulatory conditions...), and technical preferences have to bow to this. There is no such set of controls in the free-for-all of the Openssimulator world.

Expand the developer/resources/new-features workforce by a significant amount. People who haven't spent some time recently in the Opensimulator worlds might not realise how advanced Opensimulator has become. It has some things tht SL doesln't, such as variable-sized regions. But, from my perspective, there are only a few things that Opensimulator has that aren't directly traceable to SecondLife innovations. By and large, when LL introduce something new the OpenSimulator Devs get to work replicating it. I don't see much evidence of a reverse-direction flow. Varregions could be back-ported into SL, as could the ability to write text directly to a prim face, but there isn't much else I have found there that makes me think "SL needs this now" LL developers do seem to do the ground-breaking work that then seems to inspire Opensimulator devs, and Coffee's proposals, which I agree with, would bring a new development phase into the two worlds.

From my previous experience on software projects, the developer documentation is purely for code maintenance. User guides were always written by technical authors. User interfaces were developed by joint efforts between the user representatives and developers to ensure that such interfaces met the user requirements fully and were documented to an adequate level for the users, whilst not causing the code excessive problems. However, my experience was with safety-critical applications, and I suspect game pastime software does not have too meet stringent safety or regulatory criteria.

So the BBC is a sort of anti-hive-mind? Fine by me.

I skimmed the report. I think it was quite good, instead of focussing on bop-till-you-drop clubs he chose a quirky little place that emphasises the uniqueness of SecondLife and the creativity it allows the inhabitants. He does also report that SecondLife does not have typical game-like targets and goals. I think it should encourage a few more people to explore, if only lovers of Scotland and Local Hero.

I had to accept the update (I think LL might consider either allowing a defer-update mode or roll-back-onne-version option for their viewer), but after bazzing around a variety of places, some of which were cached, some not, I haven't seen the problem. I wonder if this is an OS-related issue, along the lines of the speckled screen problem that plagued Windows 10 for a few weeks?

So it's both wrong and clever enough to work out from the values off it's local or region I'll have a play inworld, I need something to do today...

What about the Wiki statement that camera focus is also in region coordinates? Is it wrong, or is it clever enough to work out from the given vector that it must be a relative position?

I'll have to play around in world, but I'll hazard a guess that because you are locking both camera focus and camera position to a local focus and global camera position the camera isn't going to move from that.