Kyrah Abattoir

Your version of cinema 4D is out of date.

Me: What is that place you where at it looks amazing. Them: Oh it was just a backdrop. Me: *sobs*

Not a huge fan but there is a reason imvu was so popular.

From my point of view, I'm just wondering what are the steps to ensure no one inherits my stuff >_>. I know, I'm weird.

Clickaction is just a convenience thing from a UI standpoint, it's just the same as setting payprice, it's just an UI convenience.

So without a will, does this means no one can inherit your account?

I hear you, and kinda take it personally, but you're also right. I'm not a good teacher, and I don't have a lot of patience, or tact. I'm probably not what you can consider nice, but when I'm replying, I genuinly want to help. Even if it's not delivered in the nicest manner. That being said... any criticism is good criticism, yes it hurts, but it's also invaluable. It's not possible to truly get better solely from a strictly subjective point of view, we all become blind to our own flaws eventually and we need others to remind us what isn't right in our work. Otherwise you end up like one student I was in class with who got absolutely obliterated by the teacher at the finals, when he revealed his project for the very first time since we started (6 months ago). It was so wrong the teacher didn't even know where to even begin telling him what the issue was. So yeah criticism hurt but it's probably better to risk a few little stabs along the way (and survive!) than a giant takedown at the end.

Some people in SL have this approach to life that they won't get hurt by others if they hurt them first.

It's nice, do you have access to multiple algorythms for the reduction? That and a preview of each, if that's possible, would probably be nice? You might also want to make those tickboxes per lod specific because sometimes a solution is better than another at a lower lod.

Hey sorry @OptimoMaximo Unfortunately I don't use Maya so I felt that whatever I would say would have be misguided, at best.

Precisely, the idea is to tie the auth to the fob itself and not the avatar carrying it

Yeah I agree that having scripts on the fobs itself is less than ideal, but i can't think of a way to make a fob unique and consistently detectable, yet and the same time being a duplicate of the original object, without inheriting the privileges of the original. Fobs also can't set their name or description to something unique unless they are nomod (tamper proof but frankly not ideal in SL in general), unless the script sets the fob identity right before self destruction. Or something like that. You also can't spoof a fob's identity if it's completely static, (while it's not really a requirement, it can be fun).

The issue with creator/creation timestamps is that it's pretty inflexible if you want multiple fobs that don't all carry the same access.

Manji's stuff is kind of cool, but the reverse gear always feels "weird" in my opinion. That and the whole "nomod" aspect but well that seem to also be a big thing with many vehicle creators. I also got myself a Lusch Hermes truck recently, not cheap but pretty nice, fine controls too.

Yeah I thought about that but unless using multiple links and scripts (not that great in itself), the door can't have a volumedetect AND also prevent you to just go through it.

I only want what's the best for SL and its Residents as a whole, you want what's the best strictly for yourself. It's the tragedy of the commons allover again.

How is that relevant? I'm merely demonstrating that your judgement shouldn't be taken as face value by anyone with a brain and a pair of somewhat functioning eyes.

I like how you where unable to start this topic without trying to skew the results in your favor. From the guy who thinks this looks realistic: And that this doesn't: And there was other examples in that other thread but you HAD to bring that one, despite the fact that it was brought up as a demonstration of good mesh design, and not hyper realism.

I tend to really prefer vehicles that have some form of speed controller. Script wise it's probably not the best, but i really like how most SCS vehicles tend to do things: PageDown switches between high and low gear, low gear has a tighter turn radius. Left/right keys make you steer but the steering angle is progressive. Hitting forward/back moves you up/down a "gear", your vehicle keeps going at that gear until you stop. Holding back when going forward and forward when going in reverse will drop you back down in neutral and apply brakes. Holding forward/back when in neutral will take you to the highest "gear" available and keep you there. Going back into neutral without "braking" lets you coast a bit. The gears all appear to do some kind of torque management, so that it's not just a fixed power, but constantly adjusts power to get you to the desired speed. To me it solves a lot of lag related problems that vehicles have by reducing the required input count from the user, low gear is also great to negociate those tight turns that are sometimetimes required to park, do a 180. Also finally i really prefer slow driving (same for planes really) to give me a chance to actually load the region i'm going through. I know other creators have equally nice driving simulations, but this is just my prefered system at the moment. The huge drawback of the SCS stuff is that it's all absolutely gigantic and, despite being mod, doesn't handle being resized too well.

A big problem is that there is a conflation between quality and quantity in SL, and probably a certain amount of misinformation about how meshs are created. A lot of creators in SL are hobbyists, and that's fine, but it also means that they struggle with ideas like: How does my work compare to others? Have I added enough? It's not hard to add more polygons, most modeling programs have tools that allow you to programatically smooth models by adding intermediary faces & vertices, you can iterate those steps as much as you want (or as much as your computer is capable of doing), and it will turn a basic 6 sided cube into a million polygon sphere if you want it to. It's not special and it's not quality, it literally takes seconds. The workflow for modeling an object is typically a two stage process: Design: Use any tool you want and as much or as little geometry as you need to create the object that you want. Retopologize: Now that you have your design, you remodel it in an optimized fashion (typically in magnet-mode so the new object clings to the reference), making it one single cohesive object. That's where you also take decisions on how you will unwrap it, what should be kept in and what shouldn't. Some creators kinda 'conflate' both steps, they don't really make complex models anyway so they hardly need to retopologize anyway. But a sizeable amount of SL creators will go through step 1 and simply skip step 2 because it's a lot of work, their design is "complete" at this point and they want it in SL by now. That's where they end up dumping lods so it will fall under acceptable LI/complexity. Or they will just tell you to suck it up and that "uncompromised art" isn't "low cost" And now for the required pompous quote: Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery

I had this idea to implement some kind of RFID tag/fob system and started wondering about way to do this with the least possible amount of script usage. I figured I'd share with the class and we could discuss implementation (no I'm not telling you to do my work i figured it would be interesting) The basic idea involves a door, and the RFID tag/fob. The fob can be worn, rezzed, physical, it doesn't matter. The door unlocks when a fob with the right ID is less than 2 meters away. The door re-locks when there is no fob in proximity. Users shouldn't have to interact with the door at all. I can thing of many ways to do this, but I dislike most of them: Option 1 The fob has a sensor scanning for door names and llRegionSayTo to all found doors in proximity. Pros: no script time when there is no fob around. Cons: sensor polling, requires doors to be specifically named. Option 2 The fob announces itself constantly on the door channel through llWhisper(). Doors filter out fobs with wrong ID and fobs that are too far away. This is the "more realistic" option. Pros: Anything can be a door, the fob is as dumb as possible, which is usually a good thing, no script time when there is no fob around. Cons: constant message sending is bad. Option 3 The fob announces itself with a region wide message when attached or on region crossings, doors then regularly poll for the position of the fob in relation to themselves, if the fob stopped existing, it is removed from the check queue. When no fobs are in the check queue, polling stops. Pros: Again, anything can be a door, the fob is as dumb as possible, no script time when there is no fob around, no sensors or listeners are solicited, but you'll still have to poll. Cons: All doors are polling for all valid fobs if there is any present in the region. Other possibilities?

Electricity also takes the path of least resistance. That's why we invented resistors. Unfortunately shame doesn't work otherwise solving the problem would be easy.

I tend to assume that there is a good reason behind a limit that has been put in place by programmers that are a lot smarter than I will ever be. But I'll ask around and see if i can get a definitive answer on the matter. If course they aren't always bad. They exist for a reason. As for your example: It depends. Oh absolutely! We are gonna take all your toys away and there is nothing you can do to prevent it! Seriously tho, voluntary solutions have all failed because the market doesn't care about things that don't lower costs and increase income. It doesn't care about ecology, safety or ethics in the real world, why would it care about a smooth SecondLife??

I have this payphone made by a creator i will not name: Uses 24 1024x1024 textures. 8 faces, diffuse + normal + specular. The UVs are dreadful and clearly look auto unwrapped, Some parts of the texture are extremely blurry because they have been sourced from a photo and enlarged before adding it to the diffuse map. Most, if not all of the specular maps contain barely any information and i was able to replace most of them by some of my generic 16x16 specmaps. A good half of the normal maps again, barely contain any details, so i was able to strip them or replace them by generic (16x16) noise. Some of the diffuse could probably be reduced too but I did not test that since I don't have access to the textures. Overall I can relatively easily drop the texture usage by 50% and all the people I've shown the before/after to have been unable to tell which is which. But that's a worst case scenario. Also, this is a payphone. It isn't scripted, it doesn't do anything. So it's really just a background prop, it exist to be there, and forgotten.

Because there would be no degradation if it was done properly to begin with. Most content I inspect can easily be slashed in half if not to a third and you will be unable to tell the difference. And before you reply: I'm not calling you blind, it's just that badly optimized.