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?