Pixels Sideways

Before gachas became a way creators could set aside some of their best and most desirable merchandise and then stuff the merch into slot machines, merchants did just fine selling items to residents who purchased a specific item and did not have to accrue 50 things they didn't want. I've always felt gachas should have had a regular vendor beside then from which you could purchase copy/mod items for 2-3x the gacha price, It's also risky to build a livelihood on an exclusive island like Second Life that could one day go poof.

I have a mesh object with 8 faces. I applied the same texture to the whole object - all 8 faces. To achieve the visual effect I am aiming for, I'd like to animate each face separately so they all animate at different speeds. I modified my "touch faces to do stuff" script and added the animation code to each face section. I removed the touch start and integer and got an error message. Then I added this but it doesn't work as only one face is animated which is face #0. default { state_entry() { integer face = (0-7); if (face == 0) { string oldName = llGetObjectName(); llSetObjectName(":"); llSetTextureAnim(ANIM_ON | SMOOTH | LOOP, 0,0,2,0.0, 1,0.14); llSleep(4); llSetTextureAnim(ANIM_ON | SMOOTH | LOOP, 0,0,2,0.0, -1.0,-0.14); llSleep(4); llSetObjectName(oldName); llSleep(1); } else if (face == 1) { string oldName = llGetObjectName(); llSetObjectName(":"); llSetTextureAnim(ANIM_ON | SMOOTH | LOOP, 1,0,2,0.0, 1,0.1); llSleep(4); llSetTextureAnim(ANIM_ON | SMOOTH | LOOP, 1,0,2,0.0, -1.0,-0.1); llSleep(4); llSetObjectName(oldName); llSleep(1); } Is my integer incorrect - and if so, how do I write it so face = all 8 faces 0-7? I also read some old forum posts that said you cannot separately texture animate different sides of a prim. Is this still the case and does it apply to mesh objects as well?? Thanks. pixels xo

Thank you Luke. That worked perfectly!

Let me start by saying when it comes to rigging, my brain goes even more sideways than normal. My attempts to alter the default sl rigged body always turns into something bizarre when i switch on animesh. So I've yet to tackle all you need to know about rigging. That said... I recently got an animesh figure and was told you can add rigged clothing to it like you do to your avatar. I haven't tried this yet but is this possible? So would it be possible to put a rigged saddle on an animesh cow, for example, and the cow has an animation script & animation in it and your avatar wears an object that animates it and both the cow and saddle attach to the avatar and a script syncs all the animations (like couples dance scripts) so you could ride the animesh cow/saddle combo? And if you wanted the cow to spit sparkles, could you not also use a rigged attachment with a particle sparkle script that is rigged to the cows mouth rigging?

Hola! I have an object with scripted faces and when the faces are touched do a variety of different things. I have two LM's in my object's inventory. My Home #1 and My Home #2 When face four is touched, it should give out the LM for My Home #1 When face one is touched, it should give out the inventory LM for My Home #2 This is what I currently have in my script for face one which is a line of generic script command to give out a LM in the inventory and chat. else if (face == 1) { string oldName = llGetObjectName(); llSetObjectName(":"); llGiveInventory(llDetectedKey(0), llGetInventoryName(INVENTORY_LANDMARK", 0)); llInstantMessage(llDetectedKey(0), "Check your inventory for your LM to My Home #2"); llSetObjectName(oldName); llSleep(1); This doesn't work because it will only give the first LM in the inventory which is My Home #1. How do I have the Give inventory for Landmark items command give a specific LM? Thank you! pixels xo

hi Gman: You may find this three part tutorial (link below) on SL armature rigging in Blender helpful - it's a rather complex process that involves using various resources to fix the armature because of volume collision bones vs the m-bones and certain body templates missing stuff but it is very thorough and also provides resource links for the sl bodies/armatures and other files. I have run into the same deformation issues when importing a rigged body I had altered from a basic rigged sl body template in Blender. We discovered this issue early on with animesh when we tried to shrink the SL avatar in Blender and import in SL then switch on the animesh feature. The body deformed. However, I had some all rigged mesh avatars i had found on MP (Dr. Who, Spock) which were imported with the standard rigging and they worked with animesh. This is a test Artee and I did on the animesh sim. I dropped an animation into the Dr. Who avatar then attached to my avatar center. You can see toward the end of the vid Artee's deformed avatar that was altered in Blender to be a small human basic avatar but got borked after importing into SL when Artee turned on the animesh feature. In a perfect world, Linden Lab would make perfectly complete and properly rigged Bento male and female body templates / armatures available for Blender that could easily be altered and correctly imported into SL because Blender is free vs Maya which is subscription based at around $1600.year. I was going to mention you might be able to fix the issue using Avastar which is a SL add-on for Blender for rigging clothing, etc., but it seems there may be issues there regarding all of this as mentioned in the tutorial but it may be worth looking into. Here is the link for the tutorials. https://adaradius.com/2020/01/16/blender2-81-dae-export-part1/ Here is a link to Avastar: https://blog.machinimatrix.org Good luck.

Thank you Squeaky. xo

I want back and checked the application and there is no email field or I missed it twice. So wondering how they will be contacting people. Also June 1st is cutting it a bit close.-- SL18B opens on June 17. I recall there being more build, check & fix time for previous SLB's.

Hola Moles! Was wondering when and how those of us who applied for an exhibitors space at SL18B will be notified if our application has been accepted and what the schedule will be. Thank you.

Hmmmmm... Here's a reply on May 5th, 2021 from LL on a Jira request I made in April - the same request that has been made in other Jira's since 2018 on creating separate head and body appearance shapers options. "Thanks! We have this proposal already in our queue for possible future work. Would be useful but not super simple to implement, so I can't say anything about how soon we might be able to work on it." You know what was not super simple to implement? Building an entire new VR platform called Sansar no one wanted to use. Imagine if time, talent, resources and the millions of RL dollars SL residents forked over to LL had been used instead to significantly improve SL with things like separate head and body appearance shaper options. I don't have an issue with fee increases but LL gaslighting users on how increases in fees will improve SL is kinda insulting when you see the return on previous increases was grossly misdirected to Sansar and that there are a lot of SL improvement requests in the Jira that have been languishing for years. I'm not a programmer and undoubtedly some of the fixes and improvement requests in the Jira are challenging but isn't that what increases in fees were/are supposed to cover - redirecting resources and/or hiring people with the knowledge and skill sets to knock this stuff out? https://jira.secondlife.com/browse/BUG-230619?focusedCommentId=652882&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-652882

I'm at the Shop N Hop and I've been experiencing "Cannot create requested inventory" for over an hour.

Hi Lindens and Moles: Could you please define this so everyone knows the correct information: What is the actual conversion rate of a SL meter to RL feet/inches and vice versa? I have looked for this info but have never found the specific and accurate definitive answer - just guesstimates. Having these conversion rates officially defined by LL will be helpful in scaling buildings, avatars, etc. Maybe you could create an official LL/SL scaling grid texture to put on various meter sizes of prims (1, 3, 5, 10, 20, 30, 40, 50, 64) which would be tres cool tool and immensely helpful particularly for peeps who choose to build or size their avatars to to RL scale. Make it available inworld and on MP and perhaps place them in the inventory LIBRARY in a viewer update. Thank you! xo

Thank you PROFAITCHIKENZ! That worked! Yay! And thanks for the explanation, Wulfie. I kind of thought that might be related to the problem because of the prim parameters being called on but still weird that it affected another script. Really appreciate your help! I''m leaving the full script here if anyone wants to use it or tinker with it. // Set the blink time here. 2.0 = It blinks now every 2 seconds float blinkrate = 2.0; // Under this line there is no need to change anything integer isBright; default { state_entry() { llSetTimerEvent(blinkrate); llSetPrimitiveParams([PRIM_FULLBRIGHT,ALL_SIDES,TRUE ]); isBright = 1; } timer() { if( isBright == 1) { llSetPrimitiveParams([PRIM_FULLBRIGHT,ALL_SIDES,FALSE ]); isBright = 0; } else { llSetPrimitiveParams([PRIM_FULLBRIGHT,ALL_SIDES,TRUE ]); isBright = 1; } } }

Hello: Need a little help. I have two scripts in a a mesh text that rotates around an object. One script is for the rotation. The other script is to blink the bright texture on/off. This script has llresetscripr in it. For some reason, the reset script in this blinker script is resetting the rotation script and causing the rotation to reset to it's starting point per the blinker script timer. Why is it doing this as these are two totes different scripts? If I // the llsleep & llresetscrip the blinker script does one off/on timer cycle, stops and stays on bright but the rotation script will works fine. If I activate these commands, it resets the rotation script. again The blinker script works on its own in a test cube. Thank you for the help. ROTATION SCRIPT //Z axis / slow rotate clockwise/toward left default { state_entry() { // when script starts.. llTargetOmega(<0.0,0.0,-0.03>,PI,1.0); // do a rotation movement in z axis. Y and Z is set to 0. } } BLINKER SCRIPT // Set here how quick the sign should blink. It blinks now every 2.0 seconds float blinkrate = 2.0; // Under this line there is no need to change anything default { state_entry() { llSetTimerEvent(blinkrate); llSetPrimitiveParams([PRIM_FULLBRIGHT,ALL_SIDES,TRUE ]); } timer() { llSetPrimitiveParams([PRIM_FULLBRIGHT,ALL_SIDES,FALSE ]); llSleep(2.0); llResetScript(); } }

Howdy: This started happening with the AK mesh head HUD, then various other HUDs and just now with Genus mesh head HUD. I attach a brand new HUD and it is in bright mode which is supposed to be the default setting built into the viewer per the jira from 2012 here: https://jira.secondlife.com/browse/SH-2646 However, when I edit the HUD to reposition it on my screen, the bright turns off. It seems to respond to the sim light source but never gets bright making HUDs difficult to see on the screen. This recently happened with another HUD, however, I could edit textures on that HUD and was able to switch on bright. Most HUDS are not editable because of proprietary scripts, design, formatting, etc. Is there a debug setting that can fix this? It is really frustrating to not be able to read HUDs when they are not bright. Thank you! This is the GENUS HUD - the pop out side bars are bright but the main HUD is dark.

Wanted to update: I figured this out via modifying an old script I had, Thank you for your help and suggestions.

Hellooo Need a little help. I can't figure out the error message I keep getting re: what is not defined in scope. This is my version of a simple blinker script: I have versions with a timer but wanted to adjust the prim point light values and didn't want to use a timer. default { state_entry() { llSetLinkPrimitiveParams (LINK_SET, [ PRIM_FULLBRIGHT, ALL_SIDES, FALSE, PRIM_POINT_LIGHT, FALSE, ZERO_VECTOR, 1.0, 3.0, 0.6]); llSleep (2.0); llSetlinkPrimitiveParams (LINK_SET, [PRIM_FULLBRIGHT, ALL_SIDES, TRUE, PRIM_POINT_LIGHT, TRUE, ZERO_VECTOR, 1.0, 3.0, 0.6]); llSleep (2.0); llResetScript(0); } } Thank you!

Hello: Looking for some script help. So here's what I would like to do. I have a HUD with three buttons that will control the transparency of three different worn objects each comprised of a linked set of prime. HUD Button ONE: Makes OBJECT-1 opaque/visible and OBJECT-2 and OBJECT-3 TRANSPARENT HUD Button TWO: Makes OBJECT-2 opaque/visible and OBJECT-1 and OBJECT-3 TRANSPARENT HUD Button THREE: Makes OBJECT-3 opaque/visible and OBJECT-1 and OBJECT-2 TRANSPARENT So the HUD script in each button is a simple channel chat script that activates the the script in the three worn linked set objects. That part I'm pretty sure I can figure out. Where I am challenged is the script to put in each worn linked set object. I could make three scripts for each worn linked set object but thought it could also just be one script if I can get the listen channel for the HUD button chat to distinguish between the three sets. I haven't been doing much scripting lately so I'n totes rusty on how to do this. Can I have just one channel and have three different chat messages or do I need three separate channels - one for each chat message? Do I replace string name with the name of the object? I'm confused and probably making this far more complicated than it need be. Not sure how to lay out the hierarchy. //HUD BUTTON ONE integer channel=12345 //HUD BUTTON TWO integer channel=12346 //HUD BUTTON THREE integer channel=12347 default { //HUD BUTTON ONE - OBJECT-1 listen(integer channel, string name, key id, string message){ if (message == "ONE“) {llSetLinkAlpha(LINK_SET, 1.0, ALL_SIDES);} //HUD BUTTON ONE - OBJECT-2 listen(integer channel, string name, key id, string message){ if (message == "ONE“) {llSetLinkAlpha(LINK_SET, 0.0, ALL_SIDES);} //HUD BUTTON ONE - OBJECT-3 listen(integer channel, string name, key id, string message){ if (message == "ONE“) {llSetLinkAlpha(LINK_SET, 0.0, ALL_SIDES);} } else //HUD BUTTON TWO - OBJECT-1 listen(integer channel, string name, key id, string message){ if (message == "TWO“) {llSetLinkAlpha(LINK_SET, 0.0, ALL_SIDES);} //HUD BUTTON ONE - OBJECT-2 listen(integer channel, string name, key id, string message){ if (message == "TWO“) {llSetLinkAlpha(LINK_SET, 1.0, ALL_SIDES);} //HUD BUTTON ONE - OBJECT-3 listen(integer channel, string name, key id, string message){ if (message == "TWO“) {llSetLinkAlpha(LINK_SET, 0.0, ALL_SIDES);} } else //HUD BUTTON THREE - OBJECT-1 listen(integer channel, string name, key id, string message){ if (message == "THREE“) {llSetLinkAlpha(LINK_SET, 0.0, ALL_SIDES);} //HUD BUTTON THREE - OBJECT-2 listen(integer channel, string name, key id, string message){ if (message == "THREE“) {llSetLinkAlpha(LINK_SET, 0.0, ALL_SIDES);} //HUD BUTTON THREE - OBJECT-3 listen(integer channel, string name, key id, string message){ if (message == "THREE“) {llSetLinkAlpha(LINK_SET, 1.0, ALL_SIDES);} } Thank you!

Okies... >>>> Got it to work, reattached HUD. Picked up the Swaginator HUD, added/attached, got the clue on the HID and in local chat + SLURL for the first gift, TP'd over, picked it up and the clue for the 2nd gift appeared on the HUD but not in chat with the location SLURL. So how does this work? Thanks.

https://community.secondlife.com/blogs/entry/2573-meet-the-lindens-moles-this-week-in-second-life/

If Linden Lab doesn't include a hoe with every home, that would be a travesty. 😀

One last time. Nowhere in the the promotion and info re Premium Membership and free Linden homes does it say the homes are "subject to availability." It also does not explain the limited roll out of the new Linden homes nor does it explain premium members must compete for these homes and if they don't secure their free home they are entitled to as noted in the Premium Membership benefits, they will have to wait for another roll out of Linden homes and go through the competitive process again. By intentionally leaving this info out at every turn, LL is misleading Premium Members and especially new Premium Members. At the very least LL should fix this and be specific on their website about the limited availability of the homes and the actual process of getting a home. And announce on the login page a week prior to the roll out of the new homes - how many homes are being released and the date and time they become available along with a link to the updated Linden Homes page explaining how the process actually works in the correct context of competing for a limited number of homes with the 60,000 or so other Premium Members. This info regarding the release of new homes should not be exclusive to the forums. That at least shows a concerted effort to make this a more fair and transparent process.

My OP was never about the layout or aesthetics of the new Linden homes. I respect the work the moles are doing. The new homes are a vast improvement and the sim layouts are much more appealing. It's the process of how premium members actually get a home that I first noted is inequitable. And the misleading info that every premium member is entitled to a new Linden Home which is in the links to the info in my post upthread. There is no info upfront about the actual process of how a premium member gets a home.. Finally a LL mole said what hasn't been emphasized by LL regarding the homes that come with a premium account: subject to availability. However, that should be expounded upon: "Subject to availability when LL decides to create them and then you'll have to park yourself on the forums to find out when we will release them and when we do release a limited number of homes, you'll have to compete with thousands of other premium members to get one and if you don't get one in that release, you'll have to wait for the next release and go thru the process again and there ae still no guarantees you'll get a home." It's called truth in advertising.

In response to what folks have said: I was using 48 as a max number re: the number of home parcels on a sim. Reduce that to 24 as a high average and the sim count doubles. Beach front is doable if the sims are terraformed so they are split in ways that there is waterfront with a beach - of course not everyone will get a sea only view but lagoons, islands, etc., combined with houseboats -and higher elevation parcels inland with great views can easily be done. And yes, premium members are entitled to a Linden Home per the SL website which generically states: Linden Home or 1024m² tier allotment for use towards a parcel on the Mainland This links to a more info page and that page links to another more info page here: Perhaps LL should clarify that only a few premium members will get one of the nice new homes they use in their PR pics. "You may not get a nice new home or houseboat as represented in the photos and text but instead you'll get funky old prim home on a fugly sim while you wait a year or more for new homes to become available for which you'll have to park yourself on the net and play new home roulette..." If they had done the new home form database from the beginning, LL would have been better prepared to handle this massive new home undertaking and allotment and could/should have been a lot more forthcoming about the process of getting a new Linden home. This reminds me of when LL had a big promotion for homestead sims at $75 a sim and hundreds of people signed up only to find out LL didn't do any pre-planning and accounting on the costs so everyone got immediately hit with increased tiers which is a classic bait and switch maneuver. A LOT of people left SL because of that. LL is a highly profitable company because of SL which is the cash cow LL milks to excess to fund that VR brick Sansar. Who creates a massive online multiplayer VR world that shuts out their customers and new users because it is not compatible with Apple computers and devices? Thanks for trolling me on my typo. Those snarks were rather funny. Anyway, enjoy your Linden homes. And be nice to the moles. Based on these numbers they will be toiling away for years to come before there are enough homes to go around. Hopefully SL will still be here.