Amalia Irata

It's already there, if you change the projectile gravity.

@Rider LindenIs there going to be native support to pull owner info from group-owned objects, or will we still need to jump through hoops like we do now?

I mean so we only need to know "fire", "bullet", "explosive", or [insert type here] instead of having to look up what integer any of those correspond to.

Just curious, what damage type would legacy llSetDamage content default to? 0? Going off of that, it may be more useful for us to have it set as a string instead of an int. With ints we need to have community-specific lookup tables. (I recognize this would be a requirement to some degree anyways, but we'd only have to compare strings instead of strings and ints on the human side.) This could also allow us to optionally allow legacy content to work with new content. If a legacy llSetDamage prim defaults to a type of null string, we can set on_damage to check for it without worrying about if 0 really is legacy, or if it's actually something else. This would also prevent us from having to rescript a massive number of assets.

I get what you're saying, but even as an optional feature this could cause interoperability issues if used improperly.

Along with recent chatter of adding min/max damage settings to the estate menu, can we have those values accessible to scripts as read-only data? It would be great if items could dynamically scale to a percentage of what's allowed in a region.

As long as you've got the angles made for your animation files, there's a relatively clean way to do this. The gun containing the script I'm about to paste has twelve animation files with numbers at the end, ranging from "0" to "11" in sequential order. 0 indicates the lowest angle, 11 indicates the highest. (Side note - why is there C# syntax highlighting, but no LSL?) integer holster = TRUE; vector fwd; integer angle; integer file =4; integer lastFile =4; string newAnim = ""; string lastAnim = ""; integer slingOnce = 0; integer chooseFile() { if(angle<=-67) return 0; else if(angle<=-52) return 1; else if(angle<=-37) return 2; else if(angle<=-22) return 3; else if(angle<=-7) return 4; else if(angle>=7) return 5; else if(angle>=22) return 6; else if(angle>=37) return 7; else if(angle>=52) return 8; else if(angle>=67) return 9; else if(angle>=82) return 10; else if(angle>=90) return 11; else return 4; } stopAll() { integer i = 12; while(i--) { llStopAnimation("Minnow Aim "+(string)i); llStopAnimation("Minnow DualL "+(string)i); llStopAnimation("Minnow DualR "+(string)i); } llStopAnimation("Minnow Draw L 3"); llStopAnimation("Minnow Draw R 3"); llStopAnimation("Minnow Hold 2"); llStopAnimation("Minnow Hold HIgh 2.1"); llStopAnimation("OfficerPistol DUAL Aim 2"); llStopAnimation("OfficerPistol DUAL Hold HIgh 1"); newAnim=""; lastAnim=""; } default { on_rez(integer a) { llResetScript(); } state_entry() { llRequestPermissions(llGetOwner(),PERMISSION_TRIGGER_ANIMATION); stopAll(); llSetTimerEvent(.5); } changed(integer c) { if(c&CHANGED_OWNER) { llResetScript(); } } link_message(integer sender, integer num, string msg, key id) { if(num == 21) { holster = TRUE; stopAll(); } else if(num == 22) { llStartAnimation("Minnow Draw R 3"); holster = FALSE; } if(num == 35) { if(!holster){ llStartAnimation("Anim - Melee");} } if(msg == "Reset") llResetScript(); } timer() { if(!holster) { integer status = llGetAgentInfo(llGetOwner()) & AGENT_MOUSELOOK; slingOnce = 1; if (status) { fwd = llRot2Fwd(llGetRootRotation()); angle=llFloor(fwd.z*100); file = chooseFile(); newAnim = "Minnow Aim "+(string)file; } else { newAnim = "Minnow Hold HIgh 2.1"; } if(newAnim!=lastAnim) { if(lastAnim!="") llStopAnimation(lastAnim); llStartAnimation(newAnim); lastAnim=newAnim; } } else { if(slingOnce) { stopAll(); llStartAnimation("Minnow Draw R 3"); slingOnce = 0; } } } }

True, but the idea of it being unscripted is somewhat moot to begin with in these cases. Even explosives typically have some sort of seeking system for their killprims to account for rez delay.

If it's a bullet, then it will also be physical 90% of the time - no velocity check required. For anything non-physical however (IE: Raycasts, explosions, etc), you're right that there's a reason to check that the object is also at least scripted.

@Soap Frenzy - @Vesca Starlight's response is correct for if you need the damage recipient to read bullets. Traditionally though, in a sim with basic llSetDamage functionality (which this would assume), the recipient would still be able to use collision_start to read the prim. Otherwise, if you need the person shooting the bullets to get a hit registration, without the recipient's scripts being able to communicate back, you'll still need to use a workaround.

Alternatively, soft-link rez a bullet with a slightly longer volume detect prim around it that has a collision filter set to ignore the actual damage prim.

At present, unless something has changed very recently, anything using llSetDamage will only die on collision with an avatar that can accept damage (IE: In a damage-enabled parcel). If damage is off, or if the prim hits another object or land, the projectile does not de-rez on its own. Having this flag in is still useful.=

Also also, can we pre-configure a collision filter? Typical usage is to filter any collisions with an object of the same name so bullets don't knock each other out of the air.

In addition to the outlined rez flags, can we get the ability to disable x/y/z rotations? Likewise, if there was a way to either add a flag or modify DIE_ON_COLLIDE to disable physics on collision, that would be fantastic.

I know there's talk of versioned LSL in future. With that in mind, is there a plan for this to (hopefully) expand to allowing for more than just an integer to be passed to a rezed object?

Yep. Simulators clamp anything over 200 back down to 200.

Devil's advocate here, but what's to stop people from attaching a megaprim either by their own intent or by a potentially malicious experience? There would need to be limits to the collision box modifications, certainly.

This relates to SVC-5716, SCR-213, SVC-6641, SVC-1606 and SCR-191 which were all opened over a decade ago. Most of them, rather ironically, were also closed at the start of this same month. These have been long-requested features with a plethora of partial workarounds. If LL is going to finally take action, that's great, but it's confusing to see related function requests closed almost immediately before this came up. In order to accomplish having a truly no-script projectile, it seems clear that a large number of settings need to shift towards being primitive parameters. At that point, it would be extremely useful to expand upon the options in a prim/object's build menu to let us set these options without needing to use script functions in either the projectile or the rezer. That being said, while everything in this thread would apply perfectly towards rapid-rez projectiles like bullets, there are other edge-cases like projectile explosives which will still require having a script. While these are typically only rezed in smaller numbers and tend to have larger delays between projectile dumps, we need to ensure that there's still compatibility going forward. The major differentiation from a standard bullet is the usage of a series of commands on collision. For example: Disable physics, rez child object(s) for damage and/or visual effects, llSensor, llCastRay, llParticleSystem (for a duration rather than a single burst). While you won't typically see all of these in the same projectile, you'll certainly see various combinations. The child prim(s) that are rezed may also use similar combinations. Even then, this assumes the projectile in question is dumb-fire. There are a number of munitions (such as missiles) that may employ functions on a timer to change the rotation/velocity mid-flight, or to continually get the position of a target if it's locked on to something (like a jet). As far as viewer enhancements, you're likely to spark a rather lively conversation as to what's considered "fair". A great example is the evolution of the "Combat Features" options currently available in a number of TPVs. In the early days, this would render arrows over all avatars within a certain distance, regardless of their position relative to you. This quickly led to having markers that told people precisely where to shoot at to hit people through a wall. It was eventually changed so that arrows would only be rendered for people outside of your current FOV; arrows will show around the edges of your screen while in mouselook to indicate that you need to turn. If someone comes into the screen space (even if while behind a wall), their arrow goes away. Another example of a combat feature that came and went, was in the form of automated mass-teleports. Someone could keybind a teleport offer command to send teleports to any number of people simultaneously, but the viewer would also automatically send a teleport request to anyone who sent an IM simply saying "tp". I think a lot of people would like the ability to set a custom crosshair in the viewer, though. Doesn't need to be anything more fancy than supplying a texture UUID or a local file path. I can see applications for this outside of the combat community as well.