SL features for combat gameplay.

[Quistess Alpha]

2 hours ago, Wulfie Reanimator said:

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).

If your script rezzes more than one type of thing, I think it's pretty valuable. Either you store the UUID in a global to check which of the things you might have tried to rez actually got rezzed, (imagine simultaneously rezzing 2 things with the same name, and being able to tell which is which!) or sleep until some sanity check tells you the thing is finally rezzed.

[Love Zhaoying]

Knowing the UUID seems useful if you want to add a "Gimme back my bullets!" option.

[Wulfie Reanimator]

27 minutes ago, Quistess Alpha said:

If your script rezzes more than one type of thing, I think it's pretty valuable. Either you store the UUID in a global to check which of the things you might have tried to rez actually got rezzed, (imagine simultaneously rezzing 2 things with the same name, and being able to tell which is which!) or sleep until some sanity check tells you the thing is finally rezzed.

Are you talking about doing that in the script/object that called the rez function? Of course that's useful.

Bleu's question was about communicating that non-existing UUID to another, external object. If you do that, you've lost the ability to immediately detect rezzes and rez failures. You have to either use a fast timer to repeatedly check "is it rezzed yet?" and manually time out, or you can use a slow timer and end up with an even bigger delay between rezzing and stuff happening... and manually time out.

To me it seems like added complexity for no pay-off. Continuing to script external objects the same way as before should work just fine, unless there's some specific use-case I'm not seeing. Is there one?

Edited October 8, 2023 by Wulfie Reanimator

[Quistess Alpha]

1 hour ago, Wulfie Reanimator said:

Bleu's question was about communicating that non-existing UUID to another, external object. If you do that, you've lost the ability to immediately detect rezzes and rez failures.

Oh, I seem to have missed that somehow. The wiki says the object_rez event happens in other scripts in the same object, so another script ~should be able to detect an object rez, unclear whether the new event will transfer to other scripts in the same link.

[Wulfie Reanimator]

43 minutes ago, Quistess Alpha said:

Oh, I seem to have missed that somehow. The wiki says the object_rez event happens in other scripts in the same object, so another script ~should be able to detect an object rez, unclear whether the new event will transfer to other scripts in the same link.

The wiki page for object_rez event clarifies that the event is only triggered in the same prim/link. 🙂

[Rider Linden]

Some quick edits.  

I've removed inherit and impulse from REZ_ACCEL.  

• It doesn't make much sense to inherit your parent's acceleration... 
• impulse is redundant with REZ_VEL.

I've also removed REZ_FLAG_DIE_ON_COLIDE since objects that deliver damage already die after their first collision. 

[Amalia Irata]

31 minutes ago, Rider Linden said:

I've also removed REZ_FLAG_DIE_ON_COLIDE since objects that deliver damage already die after their first collision. 

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.=

Edited October 9, 2023 by Amalia Irata

[Rider Linden]

All right then... back in it goes!

[Bleuhazenfurfle]

On 10/9/2023 at 12:07 AM, Wulfie Reanimator said:

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).

I'm inclined to agree on llGOD's return generally just acting like it doesn't exist yet…  it's what I would assume, too.  Still.  Figured it a question worth asking.

I do think there may be value in being able to query the "rez progress", though…  That was a contrived example, but those are the kinds of examples that often have to be considered — if one of us can easily contrive an example, someone else will undoubtedly run into it in actual practice.  So, if it's easy to slip in somewhere…  could be handy, and you may well wish it had been some day.

Was also mildly hoping there might be enough constructed early, that it can be put within sight of llGOD, in which case that would come along for free by virtue of the object only having been partially constructed.  Most likely a vein hope, but…

Edited October 10, 2023 by Bleuhazenfurfle

[Rider Linden]

The wiki page is online.  I'll try and get some regions on Aditi up tomorrow so people can try it out.

https://wiki.secondlife.com/wiki/LlRezObjectWithParams

 

[Quistess Alpha]

2 hours ago, Rider Linden said:

The wiki page is online.  I'll try and get some regions on Aditi up tomorrow so people can try it out.

Things I might test/ would like to see in the wiki: What happens if certain parameters (REZ_POS and REZ_ROT specifically) are not specified? I.E. What are the default values?

[Wulfie Reanimator]

Another super interesting thing I'm going to test is the rate of rezzing multiple projectiles.

These days, most weapons use at LEAST one separate script that does the actual rezzing - because of the forced sleep from llRezObject. (Often there are multiple "rez nodes," depending on how high of a fire-rate you need, but there are other limiting factors beyond 700-900 RPM that affect the "stability" of rezzing things at a consistent rate. Weapons can go as high as 1200-1400, but it inherently varies.)

Since the new function returns immediately, I'm hoping/wondering if we can potentially get rid of "rez nodes" entirely while keeping the same rates. This would obviously further reduce the number of scripts required for typical combat. There's no explicit throttling in the function, is there? (Rezzing is throttled in general, we know it as "grey goo" - the SL wiki could use some updated details.)

I imagine we'll still need that one extra script for rezzing at a consistent rate during automatic fire (due to how control events behave, and timers being.. timers), but it'd still be an improvement from 2-3 extra scripts for the same purpose.

Edited October 13, 2023 by Wulfie Reanimator

[Rider Linden]

Fall Colors is now live on the beta grid.

Server version is 2023-10-13.6514087432 (I may update again later today.)

Jigglypuff, Leafeon, Mauve, and Cloud Sandbox 1 & 2 are all on the new version.

[Wulfie Reanimator]

Just had the opportunity to sit down and try out the new rez function and let's just say I'M REALLY EXCITED

My plan was to make a really naive gun as a reference, then convert that to llROWP and see what the differences are before messing around with rez nodes for testing the potential rez-rate. Well...

This is a single-script gun that rezzes scriptless bullets from the control event "if (level & CONTROL_ML_LBUTTON)" The rate of control-events changes depending on what the avatar is doing,  that's why the bullets "rez faster" while I'm walking around. (This is why I mentioned that we may need a rez-node anyway for consistency.) No big deal.

I was optimistic before, and still somehow really surprised by how well it works in practice as a starting point! This is a huge improvement from the jerry-rigged weapons we'd normally have to make.

A single loop-based rezzer seems to be able to reach a consistent 1150 (+- 30) RPM with llROWP. That's almost twice as fast as anything timer-based, and almost thrice as fast as rezzing with the forced delay. Moving while using control events (with that single script) somehow reaches 1350 (+- 10) RPM very consistently.

 

Rez-queue is of course still a thing if the sim is having trouble. There was a random moment in Jigglypuff that caused my gun to not rez anything at all for about 5-10 seconds. After that, all of the objects rezzed at once in one big shotgun-blast. It didn't happen again, and this is not how the grey-goo fence works, so it wasn't that.

 

One little thing about REZ_POS and locality. Usually we want projectiles to rez relative to the camera, or at least its rotation, like this:

vector position = llGetCameraPos() + ( <2,0,0> * llGetCameraRot() )

(Alternatively just llGetPos/llGetRot for mouselook-based weapons. Rotation will be the same, but position will be lower.)

In the video, you can see I'm using REZ_POS as a local offset. It works, my bullets are rezzing from 2 meters in the Y-axis from my avatar, but it doesn't respect the rotation of the rezzer/avatar and the projectiles always rez from the same spot even as I look around. If I look toward the X-axis, the bullets will rez from my left. (This applies to non-attached rezzers as well.)

This can be easily fixed by just doing the calculation as usual, but I feel it might be more beneficial if the "relative position" would take the rezzer's rotation into account. At least if the rezzer is an attachment? Thoughts?

A really cool thing about the parameters is that all of the values can be potentially static values and the whole list could be stored globally. I don't know if there's any measurable difference between rebuilding the list for every call instead of just copied from a global variable, or appending the manually-calculated position data to it.

Edited October 22, 2023 by Wulfie Reanimator

[animats]

More dakka at last! The pew-pew crowd likes it. That will get more gamers into SL.

Now this can get an upgrade to a higher and more realistic rate of fire.

[Soap Frenzy]

Would it be possible to add some functionality that says something on a debug channel or some such on collisions that can be read by other scripts so that we could do "kill confirm" messages? As it stands if you want to do that now you have to have the bullet rez a damage prim on collision or it dies too quickly to send a message when using llSetDamage.

Edited October 23, 2023 by Soap Frenzy

[Amalia Irata]

3 hours ago, Soap Frenzy said:

Would it be possible to add some functionality that says something on a debug channel or some such on collisions that can be read by other scripts so that we could do "kill confirm" messages? As it stands if you want to do that now you have to have the bullet rez a damage prim on collision or it dies too quickly to send a message when using llSetDamage.

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.

[Vesca Starlight]

Looking at the function as listed on the wiki and from whats said here (having issues with beta grid so I can't play with it myself yet) I'm definitely liking what I see but one concern I have is that of detection.

As it currently stands the routine way to detect damage prims is a check for whether an object is scripted, often times with no other checks as raycast damage (grenades, snipers, etc) often reports as 0m/s. The advent of script-less damage prims does introduce some new issues on detection which so far the only solutions I've been able to think of that don't add too much overhead is a name-prefix check like if(llGetSubString(detectedname,0,3)=="DMG.") which requires third party cooperation in naming the projectiles or an additional velocity check as suggested by a fellow scripter which I still need to test and find potential caveats for (whether being part of a linkset IE in a vehicle causes report spam, etc).

It might be that some sort of detected damage function could be needed at a later date otherwise the overhead of detecting damage prims may negate at least some of the benefits of scriptless bullets. Do keep in mind that as its shown so far I actually really like the new function, I'm just trying to figure out how things may change and adapt with its implementation.

[Love Zhaoying]

7 minutes ago, Vesca Starlight said:

is a check for whether an object is scripted

I have not needed to check if an object is scripted, now I see it is in the results from llGetObjectDetails().  

Please let me know if you check some other way besides using llGetObjectDetails().

Thanks!

 

[Amalia Irata]

@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.

[Vesca Starlight]

@Love Zhaoying As Amalia clarified the concern is for the damage recipient. Randomly dying with no indicator of who/what killed you can be extremely jarring and detracts from gameplay aspects while also allowing for some less-than-fair things to go unnoticed. The issue is that using a raw collision event with no way to differentiate between a damage-enabled prim and say, the sim build or normal movement collisions is going to lead to some rather extensive chat spam for any sort of reasonable hit reporting; the workaround solution of checking name and/or velocity has its own caveats as well specific to linden damage combat or hazards. User made diagnostic tools essentially become the barrier to bad faith actors of which its guaranteed to encounter no matter what you do online, on top of anything even vaguely competitive such as games or SL combat.

Due to how damage interacts with an agent (IE immediately deleting the prim) any sort of hit reporting on the sender's side is going to require a scripted projectile regardless that impacts the avatar before sending data back and deploying a damage prim on the target or enabling damage itself for that purpose.

[Love Zhaoying]

1 minute ago, Vesca Starlight said:

@Love Zhaoying As Amalia clarified the concern is for the damage recipient. Randomly dying with no indicator of who/what killed you can be extremely jarring and detracts from gameplay aspects while also allowing for some less-than-fair things to go unnoticed. The issue is that using a raw collision event with no way to differentiate between a damage-enabled prim and say, the sim build or normal movement collisions is going to lead to some rather extensive chat spam for any sort of reasonable hit reporting; the workaround solution of checking name and/or velocity has its own caveats as well specific to linden damage combat or hazards. User made diagnostic tools essentially become the barrier to bad faith actors of which its guaranteed to encounter no matter what you do online, on top of anything even vaguely competitive such as games or SL combat.

Due to how damage interacts with an agent (IE immediately deleting the prim) any sort of hit reporting on the sender's side is going to require a scripted projectile regardless that impacts the avatar before sending data back and deploying a damage prim on the target or enabling damage itself for that purpose.

Right. So, you'll have the "name of the object" that collided / damaged you, and the name of the object's owner (who created it)..

[Amalia Irata]

52 minutes ago, Vesca Starlight said:

...The issue is that using a raw collision event with no way to differentiate between a damage-enabled prim and say, the sim build or normal movement collisions is going to lead to some rather extensive chat spam for any sort of reasonable hit reporting; the workaround solution of checking name and/or velocity has its own caveats as well specific to linden damage combat or hazards. User made diagnostic tools essentially become the barrier to bad faith actors of which its guaranteed to encounter no matter what you do online, on top of anything even vaguely competitive such as games or SL combat.

Due to how damage interacts with an agent (IE immediately deleting the prim) any sort of hit reporting on the sender's side is going to require a scripted projectile regardless that impacts the avatar before sending data back and deploying a damage prim on the target or enabling damage itself for that purpose.

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.

[Wulfie Reanimator]

51 minutes ago, Vesca Starlight said:

Randomly dying with no indicator of who/what killed you can be extremely jarring and detracts from gameplay aspects while also allowing for some less-than-fair things to go unnoticed. The issue is that using a raw collision event with no way to differentiate between a damage-enabled prim and say, the sim build or normal movement collisions is going to lead to some rather extensive chat spam for any sort of reasonable hit reporting; the workaround solution of checking name and/or velocity has its own caveats as well specific to linden damage combat or hazards.

llDetectedDamage springs to mind... I'd assume that's been Jira'd at some point, can we revive/remake a ticket?

42 minutes ago, Amalia Irata said:

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.

Non-physical damage prims are used in things like raycast weapons and explosives, pretty common occurrence.

 

Speaking of damage! @Rider Linden I found one damage-enabled parcel in Aditi, but I can't rez in it. Did negative damage make it in? Also, in case it got lost in my my previous post, I think relative REZ_POS should take the rezzer's rotation into account.

[Amalia Irata]

33 minutes ago, Wulfie Reanimator said:

Non-physical damage prims are used in things like raycast weapons and explosives, pretty common occurrence.

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.