Wulfie Reanimator

You can't assume it would be that simple to change how the database is operated on or how anything outside of it might be connected. Development (especially for systems this old) is rarely even remotely easy. You don't need the viewer to download anything related to names. The avatar name inworld is just a string that's sent to you just the same it always has been.

I understand why the distinction between "bot" and "scripted agent" might seem weird or unnecessary, but I fully agree with Phil on it. Bot is the umbrella term. "Scripted agent" is a term specifically for avatars registered as such. Not all bots need to be registered. I think that sums the whole thing up nicely.

What DO you like, Klytyna? @everyone else, can we stop debating about definitions and categories? SL exists in a grey area. If someone calls it a game and you disagree, don't get stuck on that one word and focus on the whole sentence instead and the point they're making. @cykarushb Smartphones are about as standardized as PCs (more so in some ways). There are a few major operating systems and a wide variety of hardware, except users can't generally swap out components on a phone.

While llCollisionSound does change the sound made by a collision, in my experience the sound isn't made unless the collision is hard enough. You should use the collision_start event for doing stuff on any kind of collision with anything BUT land. Also to change the float height, change VEHICLE_HOVER_HEIGHT from 0.1 to something higher.

After a quick skim (don't have enough time to get in-world to test), on line 63: if(world) openRot=llGetRot()*llEuler2Rot(<openingAngle,0.0,0.0>*DEG_TO_RAD)/llGetRootRotation(); Your angle of rotation is around the X axis (which points from West to East, meaning that your bridge's "hinge" is either on the North or South side as it rotates. Changing that to <0, openingAngle, 0> would allow the bridge to rotate the other way. You could also change it to: <1, 0, 0> * openingAngle * DEG_TO_RAD Just for future reference if you want to write a new function instead. Pro-tip: Clarity is your future-you's best friend. Leave some comments explaining why you do things the way you do, and pick more specific names for your functions/variables. I have no idea what the difference between "go" and "go2" is until I follow the cycle of calls and read exactly how the functions are implemented. Trust me, you don't want to come back to a 150-300+ line script after weeks/months and having to re-learn what your thought process was. Consistent coding-style is also something you should probably work on.

The parameters definitely need to be explained. I'm not smart enough to know what is wrong with the function just by looking at it, and seeing the input values would be helpful. Another thing I would probably do (to make it easier to understand even without context) is rewrite the function to take a starting rotation, and a vector to rotate around by X degrees. Return the new rotation based on that. Unless that's what's already going on?

Search for "display name" in your settings.

Simplest thing to do is what Rolig suggested. Something like (and this is just very basic incomplete script): float RPM = 300; // Rounds Per Minute integer firing; default { state_entry() { RPM = 60.0 / RPM; // Convert to delay between rounds. llSetTimerEvent(RPM); } control(key id, integer held, integer click) { if(click & held) // Key was just pressed down. { firing = TRUE; } else if(click & ~held) // Key was released. { firing = FALSE; } } timer() { if(firing) { //llPlaySound //llRezObject } } } Depending on how fast you want to fire, you will need to move outside of a single script. Rezzing an object forces the script that rezzed it to sleep for 0.2 seconds, which effectively limits your RPM to around 300 (sometimes more, sometimes less, it's fickle.)

The script is very simple / uninteresting for experienced scripters. All it needs is a collision event with a velocity check (bullets tend to move at 100m/s or more), and all of the rest are very basic functions. You would have to provide the particle textures as well. Designing the particle effect is not hard, just tedious. If somebody is charging you for that, you're probably getting ripped off.

Can you give us some examples of subscription-based games that don't offer you a way to change your name for a fee?

Additionally, if you ever wanted that function to be more flexible/general purpose, you could add multiple parameters to it instead of just one. One parameter: string MyFunction(list TheList) Two parameters: string MyFunction(list TheList, integer Index) Now you can choose which one you want at any given point in the script, if you think you might need to.

Blizzard (BattleNet) account - I changed once. League of Legends - I've changed 3-4 times across 2 accounts (different servers). Warframe - Changed once. Almost every MMORPG (which I think SL could be put under): Final Fantasy XIV - Changed my race once (and plan to do it again, but you can pay for name change too). Also has a mandatory monthly subscription fee to play. World of Warcraft Elder Scrolls Online Guild Wars 2 ArcheAge TERA Vindictus Maplestory Everquest ...

Self-expression, experimentation, freedom.

You being out of the loop and opting to not look into things at all and only reading posts in a vacuum is not their fault. I would link you the announcement and related articles but being on mobile is too cumbersome. Please do the work.

You are just flat out wrong about that. For a relatively long time now, we've known you'll be able to change your full name. First and last. But I will agree about this not being helpful to brand new users who want their preferred name on signup like we used to be able to do.

If you just "sit there" for donations, it's begging no matter how nice and quiet you are. If you make a Patreon page and don't want to beg, you'll need to promise to do something for the people who do pay. Nothing wrong with that. But if you don't follow up, they'll probably leave because you're undeserving.

What you could do (and what I plan to do) is pay for premium and whatever additional fee there might be for a name change, and then cancel premium. You could consider it one payment that you just do in two parts. The total will be the real consideration. Realistically, it would make no sense for LL to revert your name because you've cancelled. That has too many hurdles and pitfalls for them and especially the user. Like.. 1. Your login name changes, this is confusing. 2. Your old names don't become available again once you change your name. This also means you couldn't change your name to one you've had before.

Don't worry, I keep the Resident part visible for you.

But to be fair, Germany (understandably) cracks down extremely hard on anything even close to white-nationalism or anti-semitism. Pointing out that they've been "declared a criminal organization in Germany" doesn't really support any argument unless they have actually done (or plan to) harm to somebody. TLDR: Art and beliefs alone are not a criminal offense or even make someone a bad person, in my opinion. Now, before anyone jumps at that, I'm not saying all beliefs are good. You can disagree with beliefs but still get along and be a good person, but once you start treating other individuals poorly, that's the instant you become a bad person. The separation is important. Edit; Sorry I missed an entire page of posts.

I wrote a long explanation of the concepts involved, but I messed up and lost the whole thing, so I'm going to do a TLDR with some over-commented script that works as-is. Things you need: A loop and some kind of counter (like an integer variable) for how many loops have passed. Look up "for loop", "while loop" and "do-while loop" on the wiki. They all do basically the same thing, just pick the one you prefer. llSetLinkPrimitiveParams to change the attachment's position without delay. The wiki page for that can be pretty overwhelming at first. Alternatively you could use llSetLocalPos, but it has a forced delay of 0.2 seconds after it, which can make it too slow. llSleep to slow down the loop, otherwise the attachment will move erratically. Here's a working example (it's simpler than it looks at a glance): float distance = 0.1; // How far (in meters) to move up/down. float time = 0.5; // How fast (in seconds) to move from top/bottom. integer steps = 10; // How many steps to take between the top/bottom, more is smoother. default { state_entry() { // Convert the distance and time to a per-step value. // One pass of the loop is one step. distance = distance / steps; time = time / steps; while(TRUE) // Start an infinite loop that just repeats the up/down loops. { integer counter; // This counts how many steps have been taken. while(++counter <= steps) // Up loop, repeated by the amount of steps. (The ++ means "increment by one.") { // Move the object to its current location plus one step. llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_POS_LOCAL, llGetLocalPos() + <0, 0, distance>]); llSleep(time); } counter = 0; // Reset the step counter for the next loop. while(++counter <= steps) // Down loop, repeated by the amount of steps. { // Move the object to its current location plus one "negative" step (down). llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_POS_LOCAL, llGetLocalPos() + <0, 0, -distance>]); llSleep(time); } // Now the infinite loop repeats and the two loops start over. } } } One downside of this (infinite loop) method is that the script can't do literally anything else because it's busy in a loop that won't exit/stop. One way to have a repeating loop like this without being stuck with it is to use llSetTimerEvent and do the up/down loops there. That way the script has a chance to be interrupted, but the bobbing will temporarily stop as well. Another way is to use a separate script, or an actual animation like @OptimoMaximo is suggesting.

There is no function like llTargetOmega to smoothly move an attachment back and forth (You could do that with a rezzed object.), so you'll have to make a loop that moves the object up and down bit by bit.

You don't even have message handling for the transmit_channel in the first place. You need an additional check in the listen event like you have for channel zero, except instead of "id == llGetOwner()" you need "llGetOwnerKey(id) == llGetOwner()". The difference is that the first way checks for messages from the owner avatar only, while the second way checks for messages from the owner's objects as well. Also please work on your identation, this kind of code is painful for others to read and kind of difficult to follow.

Weirdly enough I didn't get notified for that @, I just stumbled in. Thanks for mentioning me though! But, sadly I don't think the script I demonstrated there would help here. If he's manually editing the roads to begin with, he has the grid/subgrid available which should make it pretty easy to align the road pieces if they are made to align. If their sizes are inconsistent so that the origin doesn't end up in a "neat spot" (all origins "fit" on the same grid) the script I have is useless. For objects like Orwar described (4x4x4 or even 4x4x1), it would work perfect aside from linkset distance limitations. They grow up so fast, I feel like a good mom.

I think this is an important detail to highlight.

Simply put; you must convince them that the requested feature is more important than whatever they're currently working on, as in, important enough to dedicate the time of at least one developer on it (who is unavoidably working on something else already). Compelling arguments, attention (votes/watches), etc. are all things that contribute to them being convinced. You're way more likely to get a feature accepted with a good argument for why it should exist. Votes/watchers alone most likely won't be enough, but they might help. You must also keep in mind that everything -- no matter how seemingly simple to the end-user -- has its own costs associated with it. Resources (people/time/performance), complexity (incl. architecture changes) and so on, which will affect how hard it is to convince them.