Profaitchikenz Haiku

And the way to win it is to ---- ignore the posts

I seem to have been trying to answer this question in the build section. As mentioned above, nothing in the right-hand section of the features tab for lighting is available as a prim parameter. I'm guessing that because the effects are not shown on the prim but on whatever faces the projected light strikes it falls outside of the range of things on/in a prim you can script?

Interestingly, there is no way to specify the texture, FOV, Focus or Ambience other than by using the edit floater. Nothing on the right hand side of the point light section appears in the list of prim params that can be set by script. GIF's aren't going to help here because SL doesn't support them. Animated Gifs have to be converted outside of SL into a single image comprising sections that a script then animates. I think you might have to raise a Jira on this and ask Linden if there are plans to make these elements of the features tab available to scripting.

You can manipulate the PRIM_GLOW value easily enough using llSetLinkPrimitiveParamsFast with the link number of what happens to be the bulb or light-emitting surface to simulate flickering, and most of the other items accessed on the features tab can also be set in this way. Play around on the features tab with different values until you know what you want to do with the values, then have a look at the function I described in the LSL Portal page of the wiki.

Whoever gets to own all the for-sale mainland wins?

There might be a simpler way to do this, which doesn't need sensors, only whispers and listens. A key is created which is an object with a specific name, such as "front door key", or "master key". The key is scripted so that when it is attached it whispers it's name on a specific channel. If rezzed but not attached it stays silent. The door is scripted to listen on that channel. It is programmed to respond to the key name by allowing the door to be opened only when it is hearing the particular name on that channel, so it might allow both "front door key" and "master key" but it would not allow "back door key". Assuming the channel is chosen so that it is a large negative number the chances of a snooper eavesdropping and learning the door key names are small, so there is some security. Whispering will limit the range to 10 metres.

I've seen this same issue grow over time on the train-simulator sites I used to frequent. It got to the point where the content creators began to identify a certain class of user as "Gimme-pigs". My view though is that, when you do something for free, this is only to be expected because people who have got something for nothing do not have any value associated with it in their minds, unlike their PC or their OS.

Read Cryptonomicon by Neal Stephenson, there's a section in it where a perl script is used to crypt and decrypt messages. Although it's a novel and not a textbook on encryptionm it does have some interesting bits about using machines to code, decode and break messages. It would be fun in SL to try implementing an enigma machine using LSL

Edit the house, make sure you haven't selected "edit linked", and raise the linkset by adding 10 or 20 metres to the Z figure. This will raise the linked parts by a known amount, leaving all the unlinked parts behind. One by one, edit each of the low parts, link it to the house above, then choose "edit linked" and click on the newly-linked prim, add the same figure to the Z position as was earlier added to the house. This will pop the piece back up into the proper position. Once each prim has been re-linked and raised, lower the house back to the start position by subtracting the required amount from the Z position.

I like to think outside the box. A sphere might be harder to make the initial texture for, but it will look better inside. However, if your skybox only had windows so the person inside is always going to be looking through what is effectively a viewport, you can simplify things a bit by working out what is going to be occluded from the viewport. For example, they are not going to be able to see down beneath their feet or up over their head because of the floor and ceiling, so you ,might get away with a texture on the inside of a hollow cylinder.

So are you asking how to put a large sphere prim all around a skybox and texture the inside of it with a panoramic view of a city so that inside the skybox whichever way you turn you see a part of the city, ground, or sky? (A box will be much easier to texture but harder to actually hide the seams where the sides meet). The easy part will be making the large hollow sphere, but the texturing is going to be complicated, because you are going to have to stitch together three separate panoramic views obtained as described by previous responders, ground, city, sky, and then get them onto the inside of a sphere. My suggestion is you get one of the many texture grids available and put it on the inside of a large hollow sphere, then work out from there the divisions into which you are going to paste the panoramas for the ground, city and sky. You will need an image processing program such as Gimp, paint,net or Photoshop that can handle layers. The base later is the grid you have put into the inside of the sphere, and on three separate layers you add the ground, city and sky, using whatever distort transformations your graphics program supplies to get each panoramic view aligned with the areas on the grid that correspond to the right places on the inside of the sphere. Some pf these programs do not allow you to distort an individual layer (paint.net for example, where I usually end up copying the layer to s separate image, distorting it, then copying it back into a fresh layer and turning off the original layer).

Oh! I'd always thought it was the Linden Moles burrowing and causing subsidence.

Somebody's already mentioned that you do maths in Fortan, which isn''t strictly true, but the method I've used for years (and it was insisted upon by the standards I was having to work to) was to have a declared constant MIN_VALUE, and the test for a float being Zero was IF( ABS(testVal) .LT. MINVAL) instead of IF(testVal .EQ. 0.0). And you can do that in almost any language, for example if (llFabs(testVal) < MIN_VALUE) ... You can probably even do it in Klingon Probably way too far back on topic for this thread

Scripts figures seem fine (now), and all the other things here are working perfectly, and were working perfectly when I saw this probkem. What it reminds me of was something I noticed in the sandbox recently, when the highlighting on an object remained for nearly a minute after I'd stopped editing it, but this seems slightly different from that.

I have just experienced some strange behaviour in an island running SecondLife Server 18.12.05.522294. I have a parcel monitor prim that when touched should give me a dialog menu. I logged in and touched it but got no dialog. I logged out, logged back in, touched it several times, and still had no dialog. I used a right-click on the object to open it and reset the main script, which then caused the other scripts to chat out their stored contents, showing that they were all still functioning and receiving link messages. When I went to the work area and right-clicked the job and selected edit, the missing dialog menus appeared, and had to be dismissed one by one. The last time I was logged in was before the Tuesday/Wednesday rolling restarts, but it is the same server version that was deployed on the 18th of December. mDoes anybody have any similar experiences?

That script fragment is incomplete, and won't work as pasted above.

Yes, if you have been given an entire script that has the default section, and plan to change a script in an existing prim, edit the script in that prim, delete all the script, and paste in your new script, then save it. Alternatively, you can create a new script in your inventory, and do the same there, and then copy that script to the contents tab of the target prim by drag and drop.

I have noticed some delays when generally editing whilst in a premium sandbox: when I highlight an object, edit it, then close the edit floater, the highlighting remains for several seconds. I have also noticed a delay when dropping a script into a prim to do tasks like replacing the plywood and blanks with my own textures, the start time for the script is long enough for me to sometimes think the script is in a stopped state. I looked at the ping sim time but it was no different to island where I rent a parcel, so it isn't internet delays. I also hadn't noticed this issue anywhere else. However, I don't know if the premium sandboxes are effectively isolated mainland or private islands, and I would also expect this sort of behaviour in places like sandboxes where there is a lot of editing and updating going on. Maybe the next restarts will cure the problem?

The terminally stupid tend to be short-lived, you can suffer them for short periods and hope that nature takes it's course

Have you dragged a system folder or default item into the trash?

There is a function key2Chan that is somewhere in the LSL users library that takes as input the key of the user, and returns a negative number generated from the key. Working along those lines, you could generate a random channel for the lights by taking the date and turning that into a large negative number. integer key2Chan(key ID) { return 0x80000000 | (integer)("0x"+(string)ID); } So if you get the date into a string in the form yyyymmdd that would also convert to a number. Yout function date2Chan would obviously have a string argument to it but otherwise would work exactly as the code above does.

I just found that the Builders Brewery version of the context LSL highlighter is more up to date than the official context site -Github page I had to view the file as RAW and then copy and paste it into a new lsl.chl file, but once ConText was restarted llSetLinkPrimitiveParamsFast was indeed highlighted as a function.

Same-name, different content There is one life-saver I have found: When you copy or move an inventory item from one folder to another, the date_acquired field in the properties is amended to show the date it went into the new sub-folder, thus losing the inherent order_by_date that persists when in the original folder. But, for scripts (alone?), the description field shows the date the script was saved back to inventory, and so you can order several identically-named scripts into chronological order by looking at their descriptions. Of all the OSes I have worked with in the past, the one I loved the most was VMS, with the version number after a semicolon. Why nobody else has implemented that I do not know.

I just had a look and the highlighter file in ConText is plain text, so adding new functions to it is possible. It doesn't have the LSLEditor ability to syntax check and test run, but as a general purpose editor it's very good, and has a built-in function to compare two files and show the variations in them side-by-side, which I find invaluable.

I just tried in Context and it doesn't have all the newer functions, for example , llSetLinkPrimitiveParamsFast is not highlighted as a library function, but this raises a point, how do the other editors manage to update themselves when LL add new functions?