SL features for combat gameplay.

[Soap Frenzy]

3 hours ago, Amalia Irata said:

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

I was suggesting some function to not need work arounds for the bullet reporting back to the object that rezzed it. Collision reports in a hud work well enough with tools and functions we already have available. We need things like this to game-ify the combat experience more. It's been almost 20 years with no changes to damage. I realize this is somewhat off topic though. I dont know where else to post it since I cant get into the official discord as it seems no one monitors the google form to apply to join anymore.

Edited October 24, 2023 by Soap Frenzy

[Rider Linden]

5 hours ago, Wulfie Reanimator said:

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? 

I have turned damage on on Leafeon (just south of Jigglypuff) 

Whatever you do, don't stand on the glowing red ❌ and touch the red or green boxes...

 

[Rider Linden]

5 hours ago, Wulfie Reanimator said:

Also, in case it got lost in my my previous post, I think relative REZ_POS should take the rezzer's rotation into account.

Actually that did get lost... even when I quoted it.

REZ_POS does not take the rezzer's rotation into account.

However

REZ_ROT does.  To orient a rezzed object relative to the rezzing object use:

REZ_ROT, ZERO_ROTATION, TRUE

 

[ST33LDI9ITAL]

In regards to llDetectedDamage here is new FR with proposed Damage event:
https://jira.secondlife.com/browse/BUG-234594

[Milleruvex]

i just want to know if this intended to return to the old Gun/weapons of old. and are the big weapon/griefer hugs going to be outlawed and made illegal. since the lots of the huds sold on Marketplace are generally used for griefing. having known a few people permabanned for using them is this a way to Stopping the hud users that Grief? lots of questions here .. or is this just for the select few that Rp western or steampunks? as a MC member i would prefer using the guns again and getting rid of the crashers and worse huds out there. if this is the way LL is going its a good step for Sl and the MC community

 

[ItHadToComeToThis]

@Rider Linden Would it be possible to create a way to only accept damage from certain creators? Iv been wondering about the possibility of creating a closed combat system using linden damage and so far there isn't a way to do it. But it would be neat given that someone could use linden damage on their own sim to create a closed system that uses only weapons for that system. It might be a lot faster than sending, receiving and processing damage messages hud to hud?

It would also be neat if you could retrieve your health data via a script, should someone want to create a on HUD health display bar.

[Wulfie Reanimator]

Small update for now: llROWP is currently intended to have the same forced sleep as other rez functions. My earlier video is not representative.

I've been talking to a bunch of different people (mostly devs) in the SLMC and gathering opinions/feedback/suggestions. I have pages of notes.

There's gonna be a public meeting today (check: second.life/calendar) if you want to come listen or give your own feedback.

I'll try to clean up my notes and post them here in pieces sometime soon, probably not today.

[Vesca Starlight]

16 hours ago, ItHadToComeToThis said:

@Rider Linden Would it be possible to create a way to only accept damage from certain creators? Iv been wondering about the possibility of creating a closed combat system using linden damage and so far there isn't a way to do it. But it would be neat given that someone could use linden damage on their own sim to create a closed system that uses only weapons for that system. It might be a lot faster than sending, receiving and processing damage messages hud to hud?

It would also be neat if you could retrieve your health data via a script, should someone want to create a on HUD health display bar.

The appeal of the in-built linden damage system is how open and easy to use and/or make things for that it is compared to metered systems, even with all the hacky stuff needed to do vehicles currently the barrier to entry is far lower than what you need to learn to effectively use VICE and I imagine other systems which might limit one further. If its a project for only one person or a small group to make things for I feel like that would potentially be a lot of stuff to add on LL's end for what is honestly a better fit and role of a meter being inherently closed source and proprietary.

19 hours ago, Milleruvex said:

i just want to know if this intended to return to the old Gun/weapons of old. and are the big weapon/griefer hugs going to be outlawed and made illegal. since the lots of the huds sold on Marketplace are generally used for griefing. having known a few people permabanned for using them is this a way to Stopping the hud users that Grief? lots of questions here .. or is this just for the select few that Rp western or steampunks? as a MC member i would prefer using the guns again and getting rid of the crashers and worse huds out there. if this is the way LL is going its a good step for Sl and the MC community

Grief HUDs are pretty much universally disallowed in every combat sim I've been to with the exception of the more-or-less-unmoderated ones LL owns and even that might just be a matter of catching people doing it. I don't think the intention of the combat update(s) is to stop people from making/using those HUDs as that wouldn't really be possible without just disallowing making stuff in general. If you as an MC member are having issues with people using HUDs with crashers there is more than likely a larger community issue and people using those need to start being banned from participating by sim admins until changes in behavior are made, there is nothing bad about wanting to protect your physical hardware from damage by a GPU crasher but you need to be willing to use the tools you have.

Edit: Ctrl+alt+shift+9 is your friend if someone uses a GPU crasher, it'll turn off rendering objects in firestorm and possibly other viewers which will make most of them ineffective long enough for you to ban someone. It however does not help from animation exploits or sim crashes but those are rarer/harder to do and LL is often on top of them fast, it just prevents the easiest to make and thus most common grief tool from working.

Edited October 31, 2023 by Vesca Starlight

[Quistess Alpha]

How do people normally figure out how much damage they've taken? IMO a function to directly read an avatar's LL health value would probably be rather useful.

[Vesca Starlight]

6 minutes ago, Quistess Alpha said:

How do people normally figure out how much damage they've taken? IMO a function to directly read an avatar's LL health value would probably be rather useful.

That was brought up during the last meeting, especially with scriptless bullets; as normally people just see if they've been hit by using a collision detector that filters for scripted objects (being that previously all damage sources were scripted) but having to check for unscripted does complicate that as you can't just raw output collisions or every object in a sim build will blow up your chat while you run around. The first suggestion was a function like llDetectedDamage() that would return the amount of damage dealt on collision but there was also some ideas floated of a much better damage event with info like how much, from who, etc. that would function similarly to a collision event.

[Wulfie Reanimator]

30 minutes ago, Quistess Alpha said:

How do people normally figure out how much damage they've taken? IMO a function to directly read an avatar's LL health value would probably be rather useful.

In the SLMC, a standard bullet does 100 damage. Doing anything less is always some kind of special case - like barbed wire, gas, diminished damage from a distant explosion, etc.

Yeah, this means that you die in one hit. I believe (unsubstantiated) that the main reason for this "meta" is the fact that healing hasn't really been a thing for 20 years. It's just way easier to moderate and balance weapons around the fact that any hit will kill your target. (Accuracy, magazine size, fire rate, velocity, type of projectile (bullet/explosion/homing/...), etc.)

Many people are excited about "negative damage," so I'm hoping we'll shift toward more reasonable damage in weapons.

Edited October 31, 2023 by Wulfie Reanimator

[Wulfie Reanimator]

Here's a short(er) list of new-feature suggestions, some of which have been mentioned during the recent meetings. (I'm intentionally leaving out some of the more contentious suggestions.)

I'd love to have all of these properly JIRA'd soon. Some of them already are, and some are planned by @Rider Linden

1. Ability to change avatar health as an estate setting.
   • Recovery rate per second (including 0)
   • Total health (useful for more fine-grained damage values)
      
2. Ability to change applied damage as an estate setting.
   • Maximum limit to applied damage, throttling, etc.
      
3. Scripts should be able to read avatar health.
   • llGetHealth(key target)
      
4. Avatar should optionally be sent to a landing zone on death, instead of home.
   • Multiple landing zones would be ideal, for separate "teams."
   • For example: land-group has one landing zone, everybody else has another.
      
5. Scripts should be able to react to damage. New damage event.
   • Optional damage "type" (numeric identifier, default 0)
   • on_damage(integer damage, integer type, key rezzer, key owner)
      
6. Damaging avatars/objects should be possible without physical collisions.
   • llDamage(key target, integer amount, integer type)
   • Damaging an object should trigger script events in the object.
     • Damage is also passed to avatars, if any are sitting on the object.
        
7. Damaging everything in a large area should be possible.
   • Damage should optionally diminish over distance. (explosion vs gas/lava)
      
8. Seated avatars should be optionally immune to damage.
   • llSitTargetDamage(integer status) - TRUE or FALSE
      
9. Rezzer should be able to know when its projectile hits something. (Needs fleshing out, if possible.)
   • New event, or a flag to pass collisions from rezzed "child" object to "parent."
      
10. llCastRay with travel time. (Needs fleshing out, may need a new event.)
    • llCastRay's options could be extended.
    • This would conceptually be implemented as several calls to llCastRay by the sim.
    • Some kind of "deviation" over time/distance would be nice for bullet drop, fake wind, etc.
      • vector velocity?
         
11. Additions to llRezObjectWithParams:
    • [REZ_SLEEP, float sec] - force the script to sleep for the specified time. Values less than 0.1 will sleep for 0.1 seconds.
    • [REZ_DATA, string name, string value] - pass Linkset Data to the rezzed object. Can be specified multiple times.
       
12. Better first-person animations.
    • Games usually render first-person view separately from the "external" avatar.
    • There has already been some work on this from TPV developers:
    • https://community.secondlife.com/forums/topic/502942-improving-mouselook
    • https://www.youtube.com/watch?v=ttaM7x14DBI
    • https://gyazo.com/6964e720c1b02133d19976d3fa89f60c
    • https://gyazo.com/663db8b4aea704a2ce5207301ea97f40

Edited November 1, 2023 by Wulfie Reanimator

[Amalia Irata]

3 hours ago, Wulfie Reanimator said:

Better first-person animations.

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;
            }
        }
    }
}

 

[ST33LDI9ITAL]

17 hours ago, Wulfie Reanimator said:

Better first-person animations.

• Games usually render first-person view separately from the "external" avatar.
• There has already been some work on this from TPV developers:
• https://community.secondlife.com/forums/topic/502942-improving-mouselook
• https://www.youtube.com/watch?v=ttaM7x14DBI
• https://gyazo.com/6964e720c1b02133d19976d3fa89f60c
• https://gyazo.com/663db8b4aea704a2ce5207301ea97f40

 

This should be standard. As well as the built in animator. Niran doin work!

[Soap Frenzy]

On 10/31/2023 at 2:28 PM, Vesca Starlight said:

That was brought up during the last meeting, especially with scriptless bullets; as normally people just see if they've been hit by using a collision detector that filters for scripted objects (being that previously all damage sources were scripted) but having to check for unscripted does complicate that as you can't just raw output collisions or every object in a sim build will blow up your chat while you run around. The first suggestion was a function like llDetectedDamage() that would return the amount of damage dealt on collision but there was also some ideas floated of a much better damage event with info like how much, from who, etc. that would function similarly to a collision event.

You can still filter for unscripted bullets in the collision event as objects with damage die before you can detect their size. You would just check if the object that hit you was ZERO_VECTOR. This is the method I've used in my hit detectors for years.

[Vesca Starlight]

5 hours ago, Soap Frenzy said:

You can still filter for unscripted bullets in the collision event as objects with damage die before you can detect their size. You would just check if the object that hit you was ZERO_VECTOR. This is the method I've used in my hit detectors for years.

This is true, and Thunder actually gave me an example of similar such things however I'd say an argument against that is overhead. To include checks for scriptless bullets you are now doing even more checks on /every/ object that hits you regardless of if its scripted or not and that adds a lot of function calls and script performance impact which somewhat dampens the positive impact of scriptless bullets to begin with, even if its a minor impact you have to multiply it by your number of actively moving players/combatants to which it does start to add up much like bullets do.

So yeah making one thing more efficient at the cost of having to make other things less efficient isn't an ideal trade, and the on_damage event would be a massive benefit to the current changes being worked on even if we have workarounds currently.

[Gunwald Constantine]

Have never used SL combat. Understand its more of closed system. but if below was implemented,

Quote

 

"Scripts should be able to react to damage. New damage event.

• Optional damage "type" (numeric identifier, default 0)
• on_damage(integer damage, integer type, key rezzer, key owner)"

 

•  

Would be nice to be able to enable combat on sim but just for the event (no health damage) and restrict this event to only experience scripts. (to restrict which weapons take effect)

Then can be used in custom, health and huds. I assume this would be lot faster than current razzing of projectiles.

I read somewhere in this post that script less combat objects, have priority in collection detect on avatars (might have read wrong)

 

Edited November 4, 2023 by Gunwald Constantine

[ItHadToComeToThis]

@Rider Linden on a separate note. One thing i think would be great for combat systems in SL would be if you could take more controls using llTakeControls. There are numerous unused keys that the viewer could make use of. Even if the only key that was added was shift or control, it would give us 8 new controls that we could use for weapons, vehicles, actions.

Yes, i know that we have gestures but they don’t  give the same level of flexibility that having different actions on key press, hold and release does. 

Q R Z X are also unused on their own, as are numerous others.

Is there no way something could be implemented? I have tried submitting Jiras before but they never get accepted.

[Rider Linden]

2 hours ago, ItHadToComeToThis said:

@Rider Linden on a separate note. One thing i think would be great for combat systems in SL would be if you could take more controls using llTakeControls. There are numerous unused keys that the viewer could make use of. Even if the only key that was added was shift or control, it would give us 8 new controls that we could use for weapons, vehicles, actions.

Yes, i know that we have gestures but they don’t  give the same level of flexibility that having different actions on key press, hold and release does. 

Q R Z X are also unused on their own, as are numerous others.

Is there no way something could be implemented? I have tried submitting Jiras before but they never get accepted.

That might be better tackled as part of @Leviathan Linden's game controller project.  I know that he's looking at a number of changes to the way controls are handled. 

[Quistess Alpha]

6 minutes ago, Rider Linden said:

I know that he's looking at a number of changes to the way controls are handled. 

If that could (somehow, magically) include variable movement speed (depending on amount of stick tilt, and/or direct change of movement speed with LSL) I think that'd make movement feel a lot better and 'modern'. Adding some kind of support for variable strength blended moment animations on top would help too, but that's more of a pipe dream.

Edited November 17, 2023 by Quistess Alpha

[arton Rotaru]

19 minutes ago, Quistess Alpha said:

If that could (somehow, magically) include variable movement speed (depending on amount of stick tilt, and/or direct change of movement speed with LSL) I think that'd make movement feel a lot better and 'modern'.

I don't think it's magically, but it is what you would expect on how a game pad would work. And that's what it does. Works pretty well so far. My only gripe with it currently is that it drops inputs on region border crossings. And sometimes button presses don't make it through reliably.

Anyhow, It will revolutionize vehicle handling in Second Life, that's for sure.

https://wiki.secondlife.com/w/index.php?title=LSL_Game_Control_Beta

https://wiki.secondlife.com/wiki/Game_control

[Quistess Alpha]

14 minutes ago, arton Rotaru said:

And that's what it does.

That looks awesome for vehicle control, but doesn't (as far as I can see) include a way to change the movement speed of an avatar not-on-a-vehicle. There are currently "hacks" for making an agent move at a given speed from an attachment, but they all have devastating caveats (If you directly set the avatar's velocity without pass-through, then walking up stairs becomes a problem; if apply a force in the reverse direction of the avatar's regular movement, you run into many scenarios where the avatar's movement isn't what the script might naively think it is.)

[arton Rotaru]

Right, it just is an event that makes controller inputs available to LSL. It doesn't add universal game controller support.

[ItHadToComeToThis]

On 11/17/2023 at 10:31 PM, Rider Linden said:

That might be better tackled as part of @Leviathan Linden's game controller project.  I know that he's looking at a number of changes to the way controls are handled. 

Could you pass it along? I would submit another Jira but they always tend to get turned down whenever I request this. Which is mad given how much better it would make llTakeControls

[NiranV Dean]

On 11/18/2023 at 12:27 AM, arton Rotaru said:

Right, it just is an event that makes controller inputs available to LSL. It doesn't add universal game controller support.

For those buttons to be detected, specifically the D-Pad which is currently not possible with what we got, they would have to implement something that can detect these, so clientside there has to be some extended support too, which means i should probably joink this as i've been wanting to support the DPad for a long time