SL features for combat gameplay.

[Vesca Starlight]

On 11/30/2022 at 10:56 AM, Katherine Heartsong said:

This part is cool but that's slow for a real world bullet.

The muzzle velocity, for example on the NATO standard 1980s rifle (in my case, the FNC1A1), is 2,650 feet per second, or over 800m in a second. That means 16m bullets. Are these velocities slowed down because it's SL?

I play mostly simulator type stuff outside of SL so I'm well aware of this fact, most things in SL tend to get "gamified" to some extent due to the limitations of both sim size and projectile speed. If you play ArmA or some other dedicated shooter you have literal kilometers to work with and generally ranges are in excess of a single sim (300m+ usually) with games like war thunder putting those ranges upwards of 2-3km for shots. Usually my thing to factor the dropped max speed and small arena size is to make different bullets have different prim gravity on top of it to include a somewhat exaggerated difference between calibers for gameplay sake ranging from 0 for flechette/sabot to 0.3 for pistol/SMG with LLCS stuff, while stuff like GLs I'll use the IRL speeds with full gravity but if they go over (like the XM25 at 210m/s) I just divide it by two and give it half gravity (so 105m/s at 0.5 gravity). I'll note though that in LLCS bullets are also generally one-hit-kill even to the toe unlike simulators or real world so slowing them down is also helpful for somewhat nerfing that a bit, in systems like VICE I actually find faster bullets on bolt actions helps balance them out of being totally irrelevant/redundant next to SMGs or such, and consequently is why most LLCS raycast guns are bolt action or sniper types.

I actually tried asking LL for a function to return what damage a prim was set to so you could effectively moderate partial damage combat while not breaking things meant to one-shot like grenades and tank rounds but they said it was unactionable (though limiting damage values wasn't apparently?) so it is what it is.

[animats]

Written up as a JIRA. This has come up several times at Server User Group, and I said I'd write it up, so I did.

If you're into shooting games and such, please comment on the JIRA.

My pitch on this is that having better shooter capability in SL is good for getting new users started. It's something they can do in the first hour. Before they have to face the problems of getting dressed, building, and subleasing real estate.

[Rider Linden]

Well.  As the warning said, I've taken a moment, considered it and I'm going to bump this thread, darn it!

As I teased today in SLUG I'm looking at the llRezObject function.  

Here is a sketch of the function and event that I'm proposing:

 

key llRezObjectWithParams(string inventory, list params)

Rez an object from inventory and apply the listed parameters immediately. (See below for the initial set of parameters.) llRezObjectParams will return a key, this key will be the UUID of the root prim rezzed by this function in the event of a successful rez.  If the rez is unsuccessful the key is passed to object_rez_failure in the id parameter.

And the new event:

object_rez_failure(key id, integer parameter, integer reason_code)

In the event that llRezObjectParams fails to rez the object in world this event will fire with the key being identical to the key returned by llRezObjectParams and the parameter value equal to the value specified by REZ_PARAM parameter.  If triggered by llRezObject or llRezAtRoot id will the NULLGUID and parameter will be the value passed as param to the original call.

The initial set of parameters that I intend to implement are:

Parameter Name	Values	Description	LSL Function
REZ_PARAM	integer param	On a successful rez, this value is passed to the  on_rez() event in the new object.	llRezObject llRezAtRoot
REZ_FLAGS	integer flags	Flags applied to the object.  See table below
REZ_POS	vector pos, integer rel	The absolute position in world to rez the new object.  This must be within 10m of the object attempting to rez. If the second parameter is TRUE the position vector is relative to the object doing the rezzing. If the rezzer is an attachment then the velocity is relative to the avatar.	llSetPos
REZ_ROT	quaternion rot,  integer rel	The initial rotation of the object when rezzed. If the second parameter is true, the rotation is relative to the object doing the rezzing. If the rezzer is an attachment then the velocity is relative to the avatar.	llSetRot
REZ_VEL	vector vel,  integer loc,  integer inherit	The absolute velocity of the object after it is rezzed in world.  If the second parameter is TRUE the velocity is relative, if it is FALSE it is global. If the third parameter is TRUE the object inherits the rezzer’s velocity.	llSetVelocity
REZ_ACCEL	vector accel,  integer loc	The Force(Acceleration) applied to the object.  If the second parameter is TRUE the force vector is relative to the object being rezzed, if it is FALSE the vector is global.	llSetForce
REZ_OMEGA	vector axis,  integer loc, float spin, float gain	Initial angular velocity of this object. If the second parameter is TRUE then the angular velocity uses the prims local axes.  FALSE uses the world axes.
REZ_DAMAGE	float dmg	Damage applied to an avatar on collision with this object.	llSetDamage
REZ_SOUND	string sound, float volume, integer loop	The name of a sound in the rezzer’s inventory or a UUID identifying a sound. The second parameter is the volume to play the sound at. If the third parameter is TRUE the sound will loop.	llPlaySound llLoopSound
REZ_SOUND_COLLIDE	string sound, float volume	Sound to play on object collision. The second parameter is the volume to play the sound.	llCollisionSound

 

Flags that may be passed for the REZ_FLAGS parameter.

Name	Description
REZ_FLAG_TEMP	Object is temporary (TEMP_ON_REZ).
REZ_FLAG_PHYSICAL	Object is Physical.
REZ_FLAG_PHANTOM	Object is Phantom.
REZ_FLAG_DIE_ON_NOENTRY	Object will llDie if it can not enter a parcel
REZ_FLAG_NO_COLLIDE_OWNER	Object will not collide with its owner.
REZ_FLAG_NO_COLLIDE_FAMILY	Object will not collide with other prims rezzed by the same parent.

 

This is an initial set of parameters and flags. In the future we will be able to expand it as need arises. But on this pass I want to make sure I get the infrastructure to support this function into the simulator first. 

 

[Love Zhaoying]

Yes! Thanks, @Rider Linden! Much needed functionality!

[Rider Linden]

A quick follow up.  I'm posting this separately because I want to make sure that this point is not missed. 

This will necessitate a subtle change in the way damage is handled.  Currently damage is a property of a script, this change means that damage will be changed to a property of the object. 

[Amalia Irata]

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?

[Rider Linden]

1 minute ago, Amalia Irata said:

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?

This function would allow that on the caller's side, BUT you run into an issue with the on_rez event.  It can only accept an integer and we can not change that.

Let me kick the idea of how we could do something like that around in my head for a bit.

[Quistess Alpha]

1 hour ago, Rider Linden said:

Let me kick the idea of how we could do something like that around in my head for a bit.

how about adding arbitrary linkset data keys with your new rez function,

REZ_LSD --- parameters: string key, string value --- the linksetData Key 'key' will be set to have a value of 'value' in the rezzed object---

Bonus points if it can be specified multiple times in the list for different keys/values.

Edited October 4, 2023 by Quistess Alpha

[Quistess Alpha]

Also, on the topic of rezzing objects, how hard would it be to rez something that's ~Not in the object's own inventory? Scripting objects that are inside of other objects is a major pain, so being able to rez a copy of an object that is already in-world would be super helpful for developing a system, even if it doesn't get used in a final product.

Edited October 4, 2023 by Quistess Alpha

[ItHadToComeToThis]

2 hours ago, Rider Linden said:

A quick follow up.  I'm posting this separately because I want to make sure that this point is not missed. 

This will necessitate a subtle change in the way damage is handled.  Currently damage is a property of a script, this change means that damage will be changed to a property of the object. 

Will this update include being able to damage for a negative value to heal team mates for example?

Unless that already exists and I missed the update?

[Rider Linden]

3 hours ago, Quistess Alpha said:

Also, on the topic of rezzing objects, how hard would it be to rez something that's ~Not in the object's own inventory? Scripting objects that are inside of other objects is a major pain, so being able to rez a copy of an object that is already in-world would be super helpful for developing a system, even if it doesn't get used in a final product.

I agree.  It is a major pain, and when I have to do something like update scripts in my objects as a version update I usually spend a couple hours muttering curses under my breath while I do it....

HOWEVER

There needs to be some way of assuring the providence of an object rezzed by a script and the easiest way to do that is by requiring that it be object to be rezzed is in the inventory of the rezzer.

(I just finished a pulp spy 🕵️‍♂️ novel where the bad guys were international art thieves... so I've added the term "providence" to my vocabulary 😀)

[Rider Linden]

1 hour ago, ItHadToComeToThis said:

Will this update include being able to damage for a negative value to heal team mates for example?

Unless that already exists and I missed the update?

I would like to add that change and I think I can sneak it in.

[animats]

Sounds good. I'd suggest consulting with the SSOC people, who have some detailed weapons, and ask if this covers everything they need.

If this works without scripts in the bullets, just about any realistic weapon should work.

[Amalia Irata]

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.

Edited October 4, 2023 by Amalia Irata
Misnomer

[Amalia Irata]

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.

[Sam Huntsman]

11 hours ago, Rider Linden said:

I would like to add that change and I think I can sneak it in.

My only regret is that I have but one like to give.

Seriously dude, thank you for all this. The combat community has waited over a decade for LLCS to get some love. Negative damage in particular will open up some massive opportunities.

[Wulfie Reanimator]

3 hours ago, Amalia Irata said:

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.

REZ_FLAG_NO_COLLIDE_OWNER | REZ_FLAG_NO_COLLIDE_FAMILY 🙂

And yeah, a set of flags similar to STATUS_ROTATE_X/Y/Z (default false?) is the only missing thing, everything else seems to be there and I couldn't be happier to see this.

Edited October 4, 2023 by Wulfie Reanimator

[Bleuhazenfurfle]

On 10/4/2023 at 11:06 AM, Rider Linden said:

 

key llRezObjectWithParams(string inventory, list params)

Rez an object from inventory and apply the listed parameters immediately. (See below for the initial set of parameters.) llRezObjectParams will return a key, this key will be the UUID of the root prim rezzed by this function in the event of a successful rez.  If the rez is unsuccessful the key is passed to object_rez_failure in the id parameter.

 

From what I understood, the rez command was unable to return the key of the new object because the actual rez happens asynchronously.  (Pretty sure that was at one point, actually stated in response to requests for them to return the key up front as this command appears to do.)

If that is no longer the case, can we then immediately use llGOD to inspect the newly rezzed object?  Or does this just reserve a UUID and get the ball rolling, but the bulk of the rez operation still happens ASAP?

I don't see any mention of object_rez?  Will this new command invoke it?  Particularly in the case where a UUID is reserved, but the rez still happens asynchronously, object_rez will still be useful as a means to indicate to the script that the rezzed object actually exists now.

And can the existing commands now be altered to match?  They presently don't return anything, so making them return a key using the same arcane magics this command uses, should not break anything; you can't even return the return of a function that returns nothing from another function that returns nothing — which is much sad — but means those commands can't have been used in a context where this change could cause an issue.

In any case, I am personally particularly glad for REZ_FLAG_TEMP, REZ_FLAG_DIE_ON_NOENTRY, and the existing commands invoking object_rez_failure.

This new family relationship should also be bring with it much new funs to be had.

[animats]

11 hours ago, Bleuhazenfurfle said:

From what I understood, the rez command was unable to return the key of the new object because the actual rez happens asynchronously.  (Pretty sure that was at one point, actually stated in response to requests for them to return the key up front as this command appears to do.)

If that is no longer the case, can we then immediately use llGOD to inspect the newly rezzed object?  Or does this just reserve a UUID and get the ball rolling, but the bulk of the rez operation still happens ASAP?

It's still asynchronous. The purpose of all those rez parameters is to eliminate the need for scripts in bullets. Starting up a script is a reasonably large operation, and doing that for every single bullet slows down pew-pew gaming. Worse, before the bullet's script has started up and is accepting events, the bullet may already be downrange and may have hit something. So the script never sees the collision and can't explode, or make a hit sound, or delete itself, or whatever. So this builds in the basic functions ordinary bullets need.

[Rider Linden]

12 hours ago, Bleuhazenfurfle said:

From what I understood, the rez command was unable to return the key of the new object because the actual rez happens asynchronously.  (Pretty sure that was at one point, actually stated in response to requests for them to return the key up front as this command appears to do.)

If that is no longer the case, can we then immediately use llGOD to inspect the newly rezzed object?  Or does this just reserve a UUID and get the ball rolling, but the bulk of the rez operation still happens ASAP?

The llRez commands will continue to be async.  The ID returned will just be the eventual ID for the object rezzed. A script can not be reasonably assured that the object exists in the world until it receives an object_rez() event. 

 

12 hours ago, Bleuhazenfurfle said:

And can the existing commands now be altered to match?  They presently don't return anything, so making them return a key using the same arcane magics this command uses, should not break anything; you can't even return the return of a function that returns nothing from another function that returns nothing — which is much sad — but means those commands can't have been used in a context where this change could cause an issue.

No.  We can not change the signature on an existing function to return a value. The key passed into an object_rez_fail event will be NULL_KEY if llRezObject or llRezAtRoot fails.

 

[Jessicatz Fairymeadow]

Any chance to add a string parameter field to pass data to the rezzed object right with the new llRez call?

Lots of times where I need to pass some string data or w/e to the newly rezzed object and would ordinarily need to set up a listener/handshake situation. Would be useful for avoiding all that.

[Wulfie Reanimator]

While I agree that being able to rez objects with custom data already in them is very convenient, I still think that the main goal of having totally scriptless projectiles (that can be used by most weapons) is a way more important feature for the new rez function.

[elleevelyn]

about passing a string as a rez list parameter

i think that it would be best to do this now while there is a current project for llRezObjectWithParams rather than maybe one day another day. The project is quite large now and adding another known parameter at this stage is less than deferring it to  later as a second project with other as yet unknown requirements. The string parameter is a known

i think that REZ_LSD (as per Quistess) is the way to do this

also while a goal of this project is to allow the creation of script-less bullets, there is also a goal to reduce the amount of messaging between rezzer and rezzed. And that  these goals do not necessarily have to be exclusive, and I also think that project rephrasing from llRezProjectile to llRezObjectWithParams recognises these two goals

If the project is to be confined to script-less bullets/projectiles then my preference is that it be best to rename it back to llRezProjectile and do llRezObjecrWithParams as a more complete function independently. There is quite a lot of prim properties that could be passed on rez which have nothing to do with bullets, not the least of which are non-physical rezzers as we currently know then but also opens up the ability to re-rez clones of objects that have been modified by other independent processes

example consider being able to pass the same list on rez as is provided by llSetPrimitiveParams

 

 

Edited October 8, 2023 by elleevelyn
typd

[Bleuhazenfurfle]

On 10/6/2023 at 5:39 AM, Rider Linden said:

The llRez commands will continue to be async.  The ID returned will just be the eventual ID for the object rezzed. A script can not be reasonably assured that the object exists in the world until it receives an object_rez() event. 

No.  We can not change the signature on an existing function to return a value. The key passed into an object_rez_fail event will be NULL_KEY if llRezObject or llRezAtRoot fails.

As expected, then.  Would have been quite surprised if they'd become sync…  (And yes, you mentioned the object_rez_fail receiving NULL_KEY from those two in the first post.)

Which leaves;

1) So what will llGOD return prior to the associated object_rez or object_rez_fail event?  (Or is that yet to be decided.)  And is there a definitive means to query if the object is rezzed yet?  (Thinking, as in communicating the UUID to another script/object — ie. one that won't be receiving the event — and then the object for some reason takes a weirdly long time to appear.)  At least, please just nail down one parameter of llGOD as returning a value useful for this purpose, and document it in the Wiki.

2) Can you explain any more about why you can't change the existing signature to add a return value from a command that does not presently have one?  I'm honestly curious, because I can't see any problems syntax-wise.  My best guess, is that it'd cause a stack crashing issue with existing scripts, or something?  Is a shame…

3) We need a REZ_FLAG_USE_CENTER, so it totally covers the existing two commands.

Edited October 8, 2023 by Bleuhazenfurfle

[Wulfie Reanimator]

1 hour ago, Bleuhazenfurfle said:

1) So what will llGOD return prior to the associated object_rez or object_rez_fail event?  (Or is that yet to be decided.)  And is there a definitive means to query if the object is rezzed yet?  (Thinking, as in communicating the UUID to another script/object — ie. one that won't be receiving the event — and then the object for some reason takes a weirdly long time to appear.)

From a "keep it simple and consistent" perspective...

llGetObjectDetails would behave as if you gave it llGenerateKey(), and the object_rez event is where you'd communicate the UUID to other scripts.

I don't see any great benefit for "preparing" other scripts for the future UUID, since they can't do anything with that information and would later have to query it themselves (with no possibility of determining whether it will/did ever rez).

Edited October 8, 2023 by Wulfie Reanimator