Bellimora

And that is the core benefit of the beta grid and its EEP/Animesh Testing zone, having it on a parcel so you can play with elevations and others can see. On the main grid I just apply the windlight locally and work from there.

I know off-hand that denby and Longfellow are eep-capable. You gotta be on a Snack RC sim. That's why all those skies I made as of late seem to be from Rider Linden's parcel on Longfellow. He has an awesome pyramid next to another neat pyramid so it inherently makes nice horizons while being a place I can build skies. Of course you can't slot any of these skies in a parcel you own, unless you're a linden or something. However you can stash them in your inventory for later use when the ability arises. Be careful though. Weirdness can happen. If you are in a non-Snack sim with an EEP viewer and you try to copy a sky, it won't appear to copy but the folder you dumped it in will report having one more item. I'd JIRA that but it seems like one of those bugs that'll fix itself once it hits the full grid in full force.

Well yeah. Including big warnings about that. And the handout includes a notecard saying "You need an EEP enabled viewer to even see the contents of this folder" and the stuff on the market is all free. Gotta figure out a good time to throw the stuff with actual price tags on the market.

https://marketplace.secondlife.com/p/Katamari-Sky/15972100 And there's the listing for a free copy of the katamari sky. Tempted to work out day cycles for the slithering and bloodshot skies and sell those for something like 250 a piece since they look kinda fetching. SO, which linden or where do I JIRA/suggest to get a marketplace item category for environmental enhancements?

Ok, you can definitely marketplace skies, because I threw the cat-sky up as a free item, have fun. It includes a static sky with both ceiling and basement cat visible and a day cycle where they stay opposed. https://marketplace.secondlife.com/p/Catastrophe-Sky/15971840 Today I learned that putting the word "*****" in your marketplace listing keywords forces it to adult rating. That's ***** as in a 5 letter word beginning with p that refers to felines and a slang term for a specific location of the female anatomy.

Since we be doing JIRAs I made one of my previous request for a light projector source change. https://jira.secondlife.com/browse/BUG-225785 If you want to be really fancy, on top of the options "moon" and "sun" add a third option "auto" and have it just default to sun, unless sun is below the horizon and moon is above it, in which case moon. Currently EEP is making night-cycles awfully dark since the moon no longer casts light like it does in non-eep-land.

While not as profound as my other skies, this was a thing that needed to happen.

Thoughts after toying around: could use the ability to make the sun/moon rotate. Either just pointing off at some arbitrary direction (like a lunar phase always pointing it's bright-side sunwards.) Or just making something rotate continually (like a glare-sun texture rotating). Filed a JIRA for it if it interests you. https://jira.secondlife.com/browse/BUG-225780

Hmmmm mind was still on tendrils after poking around I found that gimp had a lava filter that when set to a black and white gradient looked like a pile of worms. Just what I wanted. Created a texture using that. Smacked it with the "make seamless advanced" filter for gimp (google that, install it, you won't regret). Figured I'd need a new sun. Eyes in the sky never fail to creepo so I googled some animal eyes, settled on a frog one and behold

Experiment time. I wanted to see how tendrils would work in the sky. Had a hard time finding a good texture I could work for the clouds. After some searching I found something that looked almost veiny. Slapped it in the sky. Now I had this eye I made for a demon look that was designed to be used with emissive masking for the iris to make just my irses glow, but I figured I could throw it on the sun to make it a little more creepy bloodshot. Results are this: It's trippier when you see it animate because the veins in the cloud layer cause like these ripples to roll across the sky highlighting veiny patterns.

You cannot grasp the true nature of Bellimora's sky!

The region Denby is currently running RC Snack so it's EEP enabled on the main grid. This means you can head over there with the EEP viewer, make some custom skies and stash them in your inventory. A not-EEP viewer will not be able to handle that inventory and just hide it. So my Alchemy Viewer can not comprehend the true nature of cat-sky so it conceals it from me for fear of what might happen if I unleash it. So if anyone wants a freaky sky I made pester me, Bellimora Resident.

Weird question: ON the thought of a switch to flick the light source from sun to moon: If we were able to flick off the projector light in the sky would we get ourselves the ability to have another shadow-projecting light source on the scene (like 3 light projector prims on an object). Or is that something that's too involved to do easily? Either way it would be nice to be able to shut off the sky-projector for in-door windlights and focus on ambient and point lights and save us some FPS spent not rendering all that sunlight shadow we are blocking out

After playing with the tools some I think we need a means of changing the light origin from sun to moon in some fashion. For static skies you can always hide the sun and align it against the moon. However when you are doing a day/night sequence all the skies are interpolated so you need to do fancy sleight of hand to somehow slide the sun over the world swiftly enough to pop up under the moon as it comes up without it looking weird. Some sort of switch or something in sky settings.

I IMPROVED IT! Also, A NEW CHALLENGER APPROACHES!

I was tinkering. Weird popped out.

I was playing with the EEP viewer in the main grid. I found out it had a XML importer for skies and I was like "OH! I can import all these skies in the firestorm folder" so I started doing that. As I did that I would get errors occasionally as it failed to save the asset to the SL servers. I didn't think much of it until I logged in the next day on a not-eep viewer. I had a texture in my Settings folder for every failed sky. I also have a folder fulla firestorm skies and a heap of sky redundancies because that's how firestorm do. Over 600 of those darn things! I filed a JIRA, here: https://jira.secondlife.com/browse/BUG-225754

Alex made a JIRA https://jira.secondlife.com/browse/BUG-225727 and i'm relinking it here to make sure it doesn't get lost between the sofa cushions.

The sun moon positioning thingamajiggers need number boxes to display and allow for the typing in more precise coordinates then what I can do with dragging or using arrows. That said dragging the sun around the sky in wild and crazy loops and watching all the projected shadows dance is kinda fun. Otherwise I'm going to have to make repeat LSL script calls to figure out precise sun positioning and that's going to be a hassle.

Something Practical: A product update system. The key of the update server is saved to persistent storage along with the current version information of all products in the system. That way when an update client is activated it first pings the database to find where the server is, and if an update is needed. If yes then it e-mails the server for the update request and the new product is then shipped. Of course there's a lot of systems in place like that already, but they lean on a web server. By removing the web server from the equation I can ensure the updater stays up as long as LL offers their service. In fact I have an update system that will break if I ever change the UUID of the update server because the web service it uses to update the server key no longer works, fortunately all the update clients have the server's original key and default to that when the web server is down.

Here I am replying a month late. Long story short, we are using our experience to add some QoL features to our combat meter, MCM for playres playing in our region. We've avoided using the persistent storage, as convenient as it may be for a large number of things because some people don't boot up on our sim. They boot up someplace random with rez permissions and throw down in their mecha there. We don't want to break the game for that crowd. We are debating continuing support for those players at diminished capacity and going forward with additional experience enhancements on our system, but if we had a gridwide experience we would remove that issue.

Bites me now and then. I'll be working on some attachments or the HUD for a game system I work on. Detach, and then WHAM, scripting reverts. What I end up doing now is after saving the script I drag an drop a copy of that script into the project folder I have going for my attachment in question in my inventory. A lot of my preliminary scripting for MCM projects is generally done in notepad++ so it doesn't cost me a ton of work, just refining bugfixes I didn't catch on initial write, still, a nuisance. Either way, if the attachment reverts, i got a copy of the script on file, potentially in two places. This also means if I start up on a new MCM attachment and I know I got the script I need from another previous project I just open the folder and yoink the script I need rather then having to rez the attachment and prying the parts out. Easier book keeping.

Glad it helped, little general pointer with a big old ladder of if statments: use if/else Kind of like this: if(ani == "Walking"){ myState = 1; } else if(ani == "Flying"){ myState = 1; } else if(ani == "FlyingSlow"){ myState = 1; } else if(ani == "Falling Down"){ myState = 1; } else if(ani == "Jumping"){ myState = 1; } If one of the if statements checks out TRUE on your little ladder there, it will still test against all those other words in that code. By adding an else to all those ifs it won't check it if one checks true, makes it duck out of the whole chain. This sort of efficiency is good when you got code that's being executed over and over, like what you got on a timer event. it's better to work through llGetAgentInfo though like what I did because the animations can be changed via llSetAnimationOverride, you can figure out what you should be checking for with llGetAnimationOverride but that adds an extra step in the process, besides, it's faster to test an integer over a string. Hopefully I haven't overwhelmed you with information, and good luck.

A number of things could be improved on that script. The first if gate with all that ||, if I'm reading that right, the first check would be either true or false, but then all the subesquent checks are merely a single non-zero integer, so they will all return true, meaning that that net if statement isn't going to work out right. What you seem to be angling at is: if (buf == AGENT_FLYING || buf == AGENT_ALWAYS_RUN || buff == AGENT_AUTOPILOT || buf == AGENT_WALKING || buff == AGENT_IN_AIR) However, that still isn't going to produce what you want. Agent info returns a bitfield, which is a variety of yes/no states which comes together to form a single integer. To properly check against those statues you'd do this: if (buf & (AGENT_FLYING | AGENT_ALWAYS_RUN | AGENT_AUTOPILOT | AGENT WALKING | AGENT_IN_AIR)) That creates a composit state of the various things you want to check for, and tests it against the agent state. Also, set link alpha works on a number from 0 to 1, with 1 being 100% visible, 0 being fully transparent. Do NOT go to 100.0, you are overshooting the maximum by a factor of 100. However, a huge problem with this code is buf is only reporting the state of the agent at the code bootup. You want to reset it every run of the code. Sooooooo... here's a completely rewritten version of your code because I've naught better to do. integer FLOATER_PRIM = 2;integer TOP_PRIM = 3;float TICK_LENGTH = 0.2;key OWNER;integer TRIGGER_STATES;default { state_entry() { OWNER = llGetOwner(); TRIGGER_STATES = (AGENT_FLYING | AGENT_ALWAYS_RUN | AGENT_AUTOPILOT | AGENT_WALKING | AGENT_IN_AIR); if (llGetAttached()) llSetTimerEvent(TICK_LENGTH); } changed(integer change) { if (change & CHANGED_OWNER) llResetScript(); } attach(key wearer) { if (wearer) { llSetTimerEvent(TICK_LENGTH); } else { llSetTimerEvent(0); } } timer() { integer status = llGetAgentInfo(OWNER); if (status & TRIGGER_STATES) { llSetLinkAlpha(TOP_PRIM, 1.0, ALL_SIDES); llSetLinkAlpha(FLOATER_PRIM, 0.0, ALL_SIDES); llOwnerSay("Avatar is in motion"); } else { llSetLinkAlpha(TOP_PRIM, 0.0, ALL_SIDES); llSetLinkAlpha(FLOATER_PRIM, 1.0, ALL_SIDES); llOwnerSay("Avatar is stationary"); } }} I've done a few things here on top of reorganizing it. First off I renamed a few variables for my own convenience. I tend to ALL_CAPS immuteables, stuff I set once and leave. I set up the core initialization stuff in state_entry, i added a check for changed owners, with the script resetting if it sees that so OWNER will never be incorrect. An attach event toggles the timer on and off as needed. I took all the states you needed to check for and slammed them all together into something known as TRIGGER_STATES. Now if you draw your attention to the timer event, you'll see I dump the agent info into a local integer; status. Then I can test status against the TRIGGER_STATES I built in the state_entry event. If it triggers then execute the code, else execute the other code. No return statements needed since the if/else design means I'm only testing once. Hope that helps.

I mentioned trying an HTTP pipeline compatible viewer to a few people and they asked me how it was working with CDN. My response was generally "It's faster until it isn't." It's an interesting effect. Things load in with blazing speed and the experience is altogether better. But as you wander through areas, particularly batteries of sims with a lot of high resolution textures (anything with a lot of shops is a major offender, shop keepers love their banks of 1024X1024 texture) you'll hit a brick wall. The viewer just loses all will to load any additional texture beyond the most base of blurriness, and you need to adopt plan "rub pointer all over it to indicate to the viewer that you want to view that texture". Since I tend to roll in first person view that adds the annoyance of having to pop in and out of first person (I would rather like the crosshairs in First person mode to have a similar effect as drifting the pointer over something). I believe this effect may be tied to the fact that everyone loves their ultra-high-resolution textures. SL has unique woes compared to triple A games in that Triple A games have designers that have efficiency on the mind. They use real low impact meshes they use preciesly the amount of texture required to get the point accross, they recycle assets, they get the most out of their KB of ram. SL builders are a lot of people who haven't had the same background and training. You see a lot of tendancy towards trying to get the highest detail possible out of the closest LOD at the expense of other LODS, real high resolution textures. The later has got to be adding up and killing texture ram by accretion. I'd love to allocate more ram to SL, but the viewer seems to be capped at 512. Some investigation into this found a Jira from 2008 stating that this was due to the fact that higher limits caused issues with some video drivers. I wonder if this is still the case in the year 2014. However, for the MCM Combat sim I hang out in the textures may not be the most optimized, but it's under the bar enough that I generally don't see any blurry textures in it and it all loads up fast whenever I visit, so long a I stay out of the vendor-rooms. Vendors are the devil for texture memory! I was getting some oddness in projectile loading in the latest Firestorm viewer in the MCM Combat sim I code for. I swapped off to Alchemy though and evyerhing is working perfect with it in that regard.