Wulfie Reanimator

Fascism has laws and regulations to protect itself from people who threaten it. What you think and what you say is your business, but if you threaten fascism by words and actions you outlaw yourself. No mercy. Fascism does not include surrender.

Context: https://www.niramyth.com/daenotaur-the-dust https://www.niramyth.com/developers If you look at what kind of content people have made for the Daenotaur, you'll see that it's all unrigged clothing. There are also no texture mods for the body. This implies that there was never a "dev kit" for the body and it was all made by hand, which is not that difficult considering all the sizing/position adjustments can be done directly in-world.

Hold Ctrl while dragging it. If the HUD is rezzed on the ground, the object you're hovering over will be highlighted in red. If the HUD is worn, it won't be highlighted, but the dropped script will stay not-running.

What kind of CPU do you have exactly? Every SL viewer is written fairly inefficiently; single-threaded and so on. If you have, say, 16 core CPU, your per-core performance is generally lower which makes things even worse for SL. There may be some settings that could be adjusted (VBOs and such) and you could try different viewers (Black Dragon, Alchemy, etc). The sad reality is that there isn't much you can do. The viewer itself needs to change.

Double click does add objects rather than wear them. That is the default behavior. That's how I've worn everything for years.

You're absolutely right, but at the same time, the point at which this issue becomes relevant is pretty unrealistic. If you were to increment the counter every second, it would take you almost 70 years to reach the point where it becomes negative (and obviously breaks for another 70 years). This is basically the Year-2038 problem but I don't think anyone's going to reach 1 touch per second on an object and I guarantee SL won't be here in 70 years.

The XML file you (probably, depending on viewer skin and language) want to edit is: [viewer install folder]\skins\default\xui\en\menu_inventory.xml In there, you will find a section like this, for me it begins on line 885: <menu_item_call label="Wear" layout="topleft" name="Wearable And Object Wear"> <menu_item_call.on_click function="Inventory.DoToSelected" parameter="wear" /> </menu_item_call> Delete it, restart the viewer, and voilà, it's gone. You can still wear skins (and other non-addable things) by double-clicking them. You can still also use the Wear and Replace options in the Appearance window (where your outfits are saved). Disclaimer: I know nothing about how the viewer handles XML files. If something blows up, you did it to yourself and I won't help you. Make backups and prepare to reinstall your viewer. That said, I think this is completely safe (as long as you don't break the XML format) since these are Viewer Skin files we're editing. They are designed with changes in mind.

Yes, but for that reason I think you should leave the texture itself white, and only add color to it in-world. Uploading separate color textures is both limited and inefficient, of course assuming that we're only talking about flat colors. If you have a more complex color system going on (for example, many shades of purple in the same texture), you can adjust the colors in Photoshop.

For emissive mask, the alpha (greyscale) determines which parts glow and how much. The color being emitted comes from the regular RGB channels. If you have the files and you want to change the color, all you need to do is not touch the alpha. Similarly, you could simply have the white emissive texture and tint it with the in-world editing tools.

When it comes to media on SL, I couldn't tell either. What I'm trying to say is that uninstalling Flash doesn't break *everything.* Only some (relatively few) things are going to break, and those things deserve to break. Yeah, it sucks when stuff breaks, but you should still move on to a new product instead of trying to salvage whatever just broke.

The death of Flash only affects things that actually use Flash. Flash is not required for media nor to watch videos on Youtube. If your TV has stopped working after you uninstalled Flash, the only solution is to find a TV that doesn't use those old Flash-based media-sources or (god forbid) reinstall Flash if you can find an installer.

Black Dragon has highly customizable keybindings. The defaults don't match what you'll find in other viewers, but they can be rebinded to be exactly the same.

*Still wobbling 3 minutes after all other motion has stopped.*

Keep a global variable (integer) and increment it every time the object is touched. After the increment, use a modulo (counter % 3) to get a number in the range [0, 1, 2] and check which one of the three it is. Then do that action. integer action = ++counter % 3; if (action == 0) {;} else if (action == 1) {;} else if (action == 2) {;}

A cross-region message can be sent with llInstantMessage. It will show up in your local chat. The "per instance" part has already been explained. Keep a list of known instances, and only send a notification if the instance detected by a sensor is not on the list.

In times like this, I tend to debug things visually: The red/green/blue lines are the world axes. The black prim matches the camera's rotation. The orange prim tries to be the compass (its rotation is calculated from the black one). In the above video, the orange prim's rotation is calculated exactly as you did, which is how I would've also done it for something simple. This demonstrates the problems with looking straight up/down (and even upside down). Particularly, you'll notice that the euler Z angle doesn't correspond to "rotation around the Z axis" when the camera's Z axis doesn't match the world Z axis. (When looking up/down, the camera's "up" axis is more parallel with the world's X/Y axes.) In an attempt to fix that, I figured we could move into the camera's local space to change the euler angles before converting back, but this doesn't work: rotation rot = llGetCameraRot(); vector euler = llRot2Euler(rot); vector local = euler / rot; // Negate the camera's rotation local.y = 0; // Remove the Y (pitch) angle local *= rot; // Return to original coordinates rot = llEuler2Rot(local); llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_ROT_LOCAL, rot]); After doing some googling, I found this question: https://stackoverflow.com/questions/5782658/extracting-yaw-from-a-quaternion "If you want to create a quaternion that only rotates around the y axis, you zero out the x and z axes..." The only difference is that in Second Life the Yaw axis is Z. So this leads us to... rotation rot = llGetCameraRot(); rot.x = 0; rot.y = 0; llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_ROT_LOCAL, rot]); This works "perfectly," it's entirely aligned with the camera reference, the only problem left is that when the camera is upside-down, the left/right directions are inverted. Checking for that should be pretty simple.

I listened to it (Fear Of Domination - Sick And Beautiful), not a fan of the song as a whole (not my style) but that chorus is a banger.

Your back will remember this.

I see you're a man of culture as well.

You still can. No it doesn't. The permissions you have for the object won't change. When it comes to permissions, your inventory shows the most restrictive set of permissions on an item, which includes the restrictions on the object's contents. If you have a full-perm object with no-modify contents and take it into your inventory, it will be displayed as "(no modify)" even if the container is full-perm. The permissions (when rezzed again) have not changed. If you have a full-perm object with full-perm scripts inside and you take it into your inventory to change the permission of the object, the permissions for the scripts inside of that object will not change.

Good thing it was created in July and not today.

Torille!

Well, they did make a standalone announcement about the acquisition in the past. I imagine most people who read it assumed that it was guaranteed to happen soon, or practically did already. That's definitely how it was being talked about. It's very tiring to see people assume malicious intent in everything.

God Mode is the "admin mode" only accessible to Linden Lab employees.

I wasn't aware. However, the current IEEE-754 standard has been in place for 35 years.