Wulfie Reanimator

I'll echo what Qie said -- the resolution is the size of the viewer window. I would bet that their window is maximized the screen resolution is 1680x1050. (The Windows task bar is the reason for the missing height.) Most likely we're talking about a laptop, or a very old monitor.

As Love said, it runs in a browser. I use it all the time in a browser and it costs nothing at all. But I thought I'd check if there is any cost when using the phone app. There was no cost to download it from Google's Play Store. I am logged in with the app now and, like using it in the browser, there was no cost anywhere along the way. So it's totally free in both the browser and the app, unless you want to pay for the Gold level. But the Play Store isn't available on iOS, right? That's what the person you quoted was asking about. (Obviously ignoring the part about the browser version being free anyway.)

I think a claw machine would fall under the Skill Gaming Policy (which means the machine would have to be approved by Linden Lab and only exist in Skill Gaming regions). However if there's no cost, I don't think there's any problem with any policies. There are a couple stores I know of which have had this exact thing in their stores for years.

The forum will prevent you from uploading files it doesn't like, so don't worry about it. 🙂

Edit: Rolig's first post in that thread explains exactly how you could do it. 🙂

The data is saved in the memory of one of the many scripts. Scripts can't write notecards, only read them.

Exactly. 🙂 There is quite a bit of shared desirable behavior for all basic damage bullets (or even arrows, throwing knives, etc.), which could be standardized into this purpose-built function. The main problem with bullets is generally not the speed at which they rez initially (we don't need to get into the topic of rez-queue), but rather that the objects won't de-rez on collision (because the script which calls llDie takes a while to start up, and can only execute code when the script scheduler allows it).

A projectile should not be able to collide with its owner in combat, or other projectiles (especially those rezzed by the same source). For that we have to use llCollisionFilter in the bullet, but even that function it can't prevent collisions with projectiles and the owner at the same time. A high rate of fire is meaningless if the projectiles cease to exist when one is rezzed on top of another. A projectile should not be able to turn into a boomerang when it bumps into something, like another projectile (whose collision is filtered). For that we use llSetStatus with STATUS_ROTATE_X and STATUS_ROTATE_Y and STATUS_ROTATE_Z set to false. llSetStatus is an object property, so you'd have to put a script into the projectile and then delete it. Having this set by llProjectile would be a convenience.

Yeah, it was a pretty big info-dump on the what/why. That's why I added a summary. llSetDamage is not a prim property and requires a script, so llProjectile must be able to handle that. And when a damage prim hits an avatar, it never exists beyond that frame. Getting that behavior for any collision is ideal. There would still be a need for scripts in bullets, but this would reduce a lot of jank from common bullets.

When are the next couple SUGs scheduled, or where are the schedules listed? I could try to attend, if not get some currently active developers to come as well. This sounds interesting and maybe worth iterating on. A standard bullet does a couple more things, here's an example: (specifically a bullet, this script does not apply to special cases such as low-velocity throwables, missiles, or projectiles with special effects at the point of impact such as visible explosions.) default { state_entry() { llCollisionFilter("", llGetOwner(), FALSE); llParticleSystem(bullet_trail); // bullet trail (ribbon particle) llCollisionSound("", 0); llSetDamage(100); llSetStatus(14, FALSE); // status_rotate_x/y/z llLoopSound("whizzing in the air", 1); } collision_start(integer total_number) { llSetStatus(STATUS_PHANTOM, TRUE); llSetStatus(STATUS_PHYSICS, FALSE); llTriggerSound("impact", 1); llDie(); } land_collision_start(vector no) { llSetStatus(STATUS_PHANTOM, TRUE); llSetStatus(STATUS_PHYSICS, FALSE); llTriggerSound("impact", 1); llDie(); } } The state_entry event is triggered before the projectile is put into a weapon. It does not trigger again when the projectile is rezzed. Projectiles in SL will often run the risk of hitting the person who created it, especially when running forward while firing. (Always Run is the standard in SL Military Communities (SLMC)) Bullets are rezzed a few meters in front of the avatar, because bullets must be fairly long (usually 5 meters) due to high velocity and low physics framerate. They can't be too far, otherwise you can't hit someone close to you (and that's why melee weapons are also worn as a backup). When there's significant sim lag, the avatar may end up bumping one end of the projectile and hit themselves. Sometimes, in high-fire-rate weapons, bullets will filter each other instead, so they don't detect collisions with other bullets rezzed at the same location. Projectiles can't ignore collisions with both, the owner's avatar and other projectiles. This is not ideal, since two people firing at each other can block each others' projectiles. Many projectiles use a particle system as a visual indicator of the projectile, not all projectiles are very visible on their own. The same goes for sound, it's more conductive to combat when you can hear you're being fired at, but only a single "impact" sound should be heard. The default collision sound is disabled because it's client-side and the projectile may collide multiple times before disappearing. Some projectiles use a different sound for hitting an avatar instead of something else. Physical rotation of the projectile is disabled to prevent it from becoming a "spinning blade of death" or wildly bouncing around after colliding something. That's why the script also enables phantom and disables physics on collision. These may not happen immediately due to sim lag and event overhead. There are so many more bullet points (pun not intended...) I can keep adding about physical projectiles, but those are the reasons for the lines in that script. To summarize, if the goal of a function like llProjectile is to enable scriptless bullets, I think these features are absolutely essential before anyone would consider it a viable option in the LL Combat System (LLCS), in order of priority: Set a damage value. Cause the object to be deleted on collision, while allowing a sound to be played. Disable physics/collisions after the first collision, if deleting the object can't happen in the same frame. Disable physical rotation of the projectile. Doing just those things alone might not get us to a "scriptless bullets for most" situation, but if llProjectile used a list of properties (similar to llSetPrimitiveParams or the Vehicle Functions), it could be expanded over time with more configurable values (such as everything in the above script's state_entry). This may be unrelated, but rezzing is still required for mostly the same reasons even in the case of raycast weapons. Improvements to this would definitely help, since the SLMC have been really hesitant to adopt raycast weapons due to balance issues and how difficult they are to implement due to llCastRay time budgets and actually damaging the target. (There's no "remote damage", we can only rez prims with llSetDamage.) If a raycast weapon hits an avatar, a "kill prim" must be rezzed, which is usually rezzed somewhere out of the way, and has to find out which avatar was hit by the weapon. This is usually done in two ways: The on_rez parameter includes the beginning of the target's key. The bullet will then llGetAgentList and search for the first match and set its position to that avatar's location. This is usually done in a loop to ensure the prim collides with the target, because sim lag may let the target move out of the way if the prim is too small (and if it's too big, it may hit someone else near the target). The prim has an open listen channel, and receives the full key of the target so it doesn't have to search through every avatar. I prefer this method, since it's simpler to implement and there is a technique which ensures the rezzer does not send the key until the prim's script is ready, without two-way-communication. If a raycast weapon doesn't hit an avatar, there must be some way to indicate your shot, because it's not fair that you get to shoot at someone without them knowing about it. An invisible, non-physical, phantom prim is rezzed in front of you. This object uses a ribbon particle (and emits the first particle where it rezzed). This object is very large (64m for example) because particle visibility is based on the scale of the source. This allows people far from it to see the particle effect. This object moves to the point of impact of your shot via llSetRegionPos, plays the impact sound, and stays there until a timer event triggers llDie in a few seconds. The result is a visible ribbon particle stretching across the entire path of your shot, acting as a visual and aural indicator to the opponent. Another thing that's sorely missing is support for negative values for llSetDamage. There's no way to apply healing without custom scripting, so 100% damage is the standard for LLCS.

If you want to create a gacha vendor that's compliant with the new gacha policy, you have to display what the next three items will be. There should be no guessing from the customer, like the previous (now banned) gacha machines that only had a list of everything you could get. All the details are here: https://wiki.secondlife.com/wiki/Linden_Lab_Official:Gacha_policy What I explained above is also specified on that page. Also: https://community.secondlife.com/blogs/entry/8586-policy-change-regarding-gacha/

Does it have to create an actual landmark, as in the inventory item? In that case -- no. But if you'd be fine with a clickable link (opens a viewer window for the destination), then you can use viewer URI links in chat. You'd get the name of the region by llGetRegionName, and your current position with llGetPos, do a tiny bit of formatting, and send that to chat. It'll act very similarly to a landmark, and you can even copy/paste it to others.

20 second sleep, and "the entire message (including the address, subject and other miscellaneous fields) can't be longer than 4096 bytes combined."

What kind, how much, how often? If it's just a little bit, dumping to local chat is probably the best option. Even if it's a lot, chat might be more convenient. If it's A LOT or very regularly, a web server for logging is probably more useful. Sadly scripts can't write notecards or really do anything besides chat or make HTTP requests.

Just to test this to be sure, I created a one-sided plane in Blender and used that as the physics model while raycasting against it. The ray won't hit the backside of the plane, but it will hit the "solid" side. llCastRay works by doing a "line-triangle intersection" check against the physics model of objects in the ray's path. This generally involves calculating the normal of the triangle, and optionally ignoring backfaces (which llCastRay does). Could you share the script you used? Just so we can confirm it's nothing simple like trying to call llCastRay(llGetPos(),<0,0,-5>,[]) for a downward ray. Also make sure that the status code is actually zero instead of one of the error values. Ruling out all the sane cases... I recall @Fenix Eldritch and @animats investigating a particular object whose physics shape seemed to be "full of holes" despite the physics shape being solid (as in it was totally random whether a raycast would hit it, even when the position was adjusted by a fraction of a fraction). Could that be happening here?

To see the object's physics shape, you can also select the object and click the little eye-icon in the Build Tools window, next to the physics type.

Another thing to consider is how your script could be written to not rely on LinkSet Data. LSD is a convenient cache so your script doesn't have to spend time doing extra work, but if the value is not there (or it cannot be written because there's not enough space), your script should have some way to generate that info from scratch. (Assuming it's not a multi-script system, but even then, good to design a backup.)

It's called God Mode.

I think the cheapest way is to just buy lindens: https://secondlife.com/my/lindex/buy.php The minimum spending amount is $2.50. That means you'd have to spend $1.01 on top of the $1.49 transaction fee. Currently you would get either 243 lindens instantly, or 254 lindens within 10 minutes. Edit: Oh yeah, I forgot about the two different stages of "on file" and "used."

While you can use BOM for all of the bodies/heads from Uti (or literally any modifiable object, even prims), any SLUV skins won't be compatible because Kemono/Avatar2 uses totally different parts of the texture for different things. You'd see things you're not meant to see. 😄

You reminded me of how I, by some miracle, managed to recover the account I made originally... 13 years ago. With a very simple one-word username too, so it's actually a pretty valuable to have if I ever care to create any content on that platform. Good for Krankhaus though. They started so small and came far. They deserve any success they get, even if that means moving to bigger audiences.

At least the LindeX is a controlled economy, LL will keep the price within a certain range (and is very stable).

Why exactly do you need to rewrite a lot of code to move from HTTP to HTTPS? You said you're using a form and have your own web server, which POSTs data to another page, from which you send data to the LSL script. When I recently tried/checked, you can't display any HTML content from LSL scripts unless they're visited exclusively from the in-viewer browser. You don't seem to be doing that if you can see security warning. How is the form served?

When you add someone to the "ignored users" page on this forum (found in the top-right menu, under Settings), you can select what you'd like to ignore, and then you won't get a notification from them: Posts mean regular posts like this one (including replies). Mentions mean these: @Wulfie Reanimator Either "posts" or "mentions" includes reactions too, I just don't know which. Messages mean private messages on the forum. Signatures are included at the end of every post, and are off by default. Blocked posts in a thread will show up as collapsed items which you could click to open and read, or hide completely with browser extensions like an ad-blocker.

That's a cute idea! Easy to make, too.