Pew! Pew! Pew! Linden Damage & Combat 2.0

[Thunder Rahja]

5 hours ago, Wulfie Reanimator said:

Just to repeat one thing that's been talked about regarding the on_damage event. There's two concerns about its side-effects.

How do we handle cases where scripts in separate attachments adjust the received damage in different ways? Although llDetectedDamage can give a script the original and currently adjusted amount, there will be unavoidable race-conditions from the script scheduler, and the different workloads in each script. The adjusted damage value can change after a script has checked it.

Perhaps this might be partially resolved by a new type of permissions request, e.g. "llRequestPermissions(llGetOwner(), PERMISSION_ADJUST_DAMAGE)" that, upon (automatic) granting, revokes the same permission from other scripts attached to the same avatar. Scripts that call llAdjustDamageAmount without this permission should shout an error message on DEBUG_CHANNEL.

Edited December 6, 2023 by Thunder Rahja

[Takura Thielt]

I don't personally have anything to add at this time, but thank you for the consideration, and dedication to future efforts at revitalizing this game, and supporting the communities within it! Eagerly looking forward to what's to come!

Edited December 6, 2023 by Takura Thielt

[Quistess Alpha]

9 minutes ago, Thunder Rahja said:

Perhaps this might be partially resolved by a new type of permissions request, e.g. "llRequestPermissions(llGetOwner(), PERMISSION_ADJUST_DAMAGE)" that, upon (automatic) granting, revokes the same permission from other scripts attached to the same avatar. Scripts that call llAdjustDamageAmount without this permission should shout an error message on DEBUG_CHANNEL.

I think we want more than one thing to be ~able to adjust the damage (say I'm wearing both armor and shield, both should be able to decrease damage) but there needs to be a promise for only one to actually adjust the damage, OR, actually, if the specification were adjusted so that llAdjustDamageAmount applies a multiplier to the received damage, (ex. llAdjustDamage(0.8) causing the damage from the event in which it's called to be reduced by 20%)  rather than directly setting it to a new value, there might be less of an issue.

[Love Zhaoying]

In the spirit of the title "Pew! Pew! Pew!", there needs to be a "Stormtrooper Mode" where every shot misses.

 

[Amalia Irata]

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. 

Edited December 6, 2023 by Amalia Irata
Fix an autocorrect error.

[Duckie Dickins]

First off I will say that my combat experience has mostly involved with developing weapons for the old DCS2 system as well as working on the meter system itself. That being said, I love the enthusiasm and the willingness to expand on combat in light of game controller support coming down the pipeline but if I were to give my honest opinion, all of these things are already being accomplished by existing scripted combat meters...for 15 years already. Combat developers have already created their own library of functions to do most if not all of these things proposed.

If I was still a combat developer, the features I would rather have than this is like you said...better hitbox detection and being able to better determine if a hit was a head shot, a body shot, or being shot in a limb. Or programmable client side HUD widgets so we can get rid of the need for some types of button bar attachment huds. Or a type of animation preloading. The best combat system isn't fun when the opponent you're facing has an avatar that is frozen in a pose and sliding across the screen because the animation they are currently using hasn't been fetched and cached yet by your viewer and that immersion breaking.

Sorry if my view point sounds more negative than the others but many of the features I proposed not existing is what has frustrated me with combat in SL for the past 7 or 8 years now. Today if I want to get my pew pew pew on, I just pick up my phone because I know I'll have a better experience on a mobile device and that is what combat in SL is actually competing with.

[Wulfie Reanimator]

1 hour ago, Thunder Rahja said:

Perhaps this might be partially resolved by a new type of permissions request, e.g. "llRequestPermissions(llGetOwner(), PERMISSION_ADJUST_DAMAGE)" that, upon (automatic) granting, revokes the same permission from other scripts attached to the same avatar. Scripts that call llAdjustDamageAmount without this permission should shout an error message on DEBUG_CHANNEL.

This seems like something that would only complicate scripting, or at least it would force all scripts to have some boilerplate in their on_damage event, because permission could've been revoked at any point. At best the function should fail silently, otherwise we end up with this in all cases:

default
{
    on_damage(integer count)
    {
        // do stuff...

        if (llGetPermissions() & PERMISSION_ADJUST_DAMAGE)
        {
            llAdjustDamageAmount(0, damage * 0.5);
        }
    }
}

I don't like the idea of attachments competing for permissions / revoking them from other attachments. Wouldn't people just start putting timers in their script to re-request permission to adjust damage (or request it in the damage event)? If the request is going to give the user a pop-up, that'd be super annoying to accept every time you wear a damage-adjusting attachment (even without the spamming).

 

1 hour ago, Quistess Alpha said:

if the specification were adjusted so that llAdjustDamageAmount applies a multiplier to the received damage, (ex. llAdjustDamage(0.8) causing the damage from the event in which it's called to be reduced by 20%)  rather than directly setting it to a new value, there might be less of an issue.

This sounds good. If the adjustments were only applied as multipliers, there wouldn't be issues with the order of events... unless I'm totally forgetting my math. Though, that would be a little more restrictive on general game mechanics, since it's sometimes relevant to change damage by a flat amount. Is that a valid tradeoff?

 

41 minutes ago, Amalia Irata said:

it may be more useful for us to have it set as a string instead of an int. With its 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.)

Can you expand on this? What do you mean by "comparing strings and ints on the human side"? What data would the string have?

[Amalia Irata]

15 minutes ago, Wulfie Reanimator said:

Can you expand on this? What do you mean by "comparing strings and ints on the human side"? What data would the string have?

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. 

[elleevelyn]

On 12/6/2023 at 3:29 PM, Dread Hudson said:

Applying damage via llDamage is concerning though because it doesn't seem very secure at the moment, at least with sending a prim out to someone to bonk them with damage doing anything beyond firing said prim from a gun requires an entry level of know how on communicating target key to damaging prim, i'd be concerned that making it as simple as rezzing a box, and doing while(0) { llDamage(person i'm mad at, 100, 0) } could lead to bad actors ruining the fun even more so than they already do. While yes, a sim admin can look at the combat log, the ease of griefing somebody with this may outweigh the benefits to simplifying damage passing.

i been thinking about this, as is a concern. Is what made regions like Rausch back in the day unworkable. People parked up and just while loop blasting at everyone who crossed onto the arena

the proposal at the moment has a Health metric/mechanic to determine how much damage an agent can receive - which iseems is to be a region setting . Maybe an additional region setting that regulates Energy - the total amount of damage an agent can inflict at any one time. Energy like Health expending/regenerating according to the region settings

Energy could also be applied to defense - like a shield/armor.  Like I make a shield/armor. I script it with say llSetDamageEnergy(float percent) so that the player can nominate how much of their current Energy they want to apply to the shield. Say 50% Energy to my shield and 50% to my sword to start with. If my Health gets too low and I need to run  for the safe zone where I can regen wiithout being killed then I (user) can divert 100% of my remaining Energy to my armor, knowing that my sword is going to be useless - has no energy

when it takes Energy to defend, maybe llAdjustDamageAmount subtracts from my Energy the same amount of Damage being inflicted

while Energy and Health can be seen as one continuum, I think that having Health and Energy as two separate region allocations makes it more flexible in terms of the diversity of different games

this might also help solve/ameliorate the cheaters. To negate Damage costs Energy. Run out of Energy then the viillain is doomed even when their Health is 100%

edit add: I think this also works well with Healing. Like if I give Health (negative damage) to another player then it comes out of my Energy

 

add note: Energy is a standard property in many games to regulate damage infliction, so I don't think would be a step too far to enable this from the outset

Edited December 7, 2023 by elleevelyn

[Jeriko Aurelia]

I don't have anything to add at this time, but I want to say that all of these changes look really great so far and  thank you for starting this process and giving our community some attention. We appreciate you so much!

 

Edited December 7, 2023 by Jeriko Aurelia

[Quistess Alpha]

2 hours ago, Wulfie Reanimator said:

since it's sometimes relevant to change damage by a flat amount. Is that a valid tradeoff?

Disclaimer: I don't really do weapon scripting, but I think it is. you can still emulate an additive offset with something like llAdjustDamageRelative((oldDamage+offset)/oldDamage); just that might not play nicely in a race condition.

Some more off-the -top-of-my-head ideas/thoughts: maybe there could be a function that returns the number and keys (and possibly other info) of other attachments which have running scripts with a on_damage event? or possibly on_damage could work more like listen: only feed scripts damage events with damage type numbers they are interested in.

How hard would it be to make damage types strings rather than integers? Integers leave a lot of room for different creators to accidentally or not-so-accidentally overlap (Creator A uses type 27 as "magic damage", creator B uses it as "slash damage") OTOH, integers do make it easier for a single creator to block out different "categories" (ex. 100-149 are 'medieval era physical' types of damage (slash, pierce, burn. . ), 150-199 are 'modern physical' (bullet, chemical, gas), 200-299 are magical (elemental, arcane, divine, ...) ) ETA: Oh NVM, that's basically what @Amalia Irata was asking about.

Edited December 7, 2023 by Quistess Alpha

[Cesar Goland]

I have a RPG system with some combat features on an experience (and other damage dealing features, like hunger and diseases, that would also benefit from this framework), but all usable weapons are specifc for the sim, I would love to use this, performance wise it would be awesome, but I think that being able to limit stuff to a specific experience would be needed, like preventing a on_damage event from even triggering if its damage source is not from a experience (not filtering it in the event, but not even triggering)

An example that I can think is that even if we can use on_damage and llDetectDamage to filter out some damage sources the event itself would still be triggered, like spamming the on_damage event enough to prevent some damages to enter?, lets say, If I overload someone with llDamage(...,0,...) preventing other damage events would that specific person be Immortal?

Honestly I got so interested in this framework that in almost 15 years of Second Life this is my first post on the forum

(English is not my main language, sorry for anything)

[elleevelyn]

36 minutes ago, Cesar Goland said:

I have a RPG system with some combat features on an experience

[ ... text about what would be good ...]

Honestly I got so interested in this framework that in almost 15 years of Second Life this is my first post on the forum

 

you are the person (and people like yourself) most needed by this project. Welcome to the forums and I am happy that you are enthused

36 minutes ago, Cesar Goland said:

An example that I can think is that even if we can use on_damage and llDetectDamage to filter out some damage sources the event itself would still be triggered, like spamming the on_damage event enough to prevent some damages to enter?, lets say, If I overload someone with llDamage(...,0,...) preventing other damage events would that specific person be Immortal?

on this point, it may be that a simulator throttle is needed Throttles are a standard Linden method so I think we can pretty much expect this to happen

 

Edited December 7, 2023 by elleevelyn

[Rosa Hexem]

This might be a bit beyond scope but I gotta say it because all my experience with combat in SL tells me it's almost equally as important as the damage system itself, at that's avatar movement in combat areas. There might be scripted solutions for this in SL already, but then the same could be said for making scripted combat meters for damage and whatnot so I'm going to shoot regardless.

This post is going to get a bit rambly, but I really want to spare no detail on why this is important.

Just as my case here I think combat features and movement are inextricably linked to one another in terms of gameplay. It determines how you design game environments, how effective certain kinds of weapons can be, the entire gamefeel of the moment to moment experience. The difference between moving from one place to another in Quake vs Call of Duty vs Zelda TotK are so critical to the gameplay they are practically core to the identity of the game, never mind the combat gamefeel within said games.

 

First off we already have flight and teleport restrictions, and I imagine that those are there at least partially in anticipation of how they might break an experience as heavily focused on movement as, say, a swordfighting or shooting combat game. Now anyone who's been around the block long enough knows that even the default jump in SL lets you jump effortlessly over walls that would otherwise serve as obstacles in many other games, as well as the myriad movement quirks such as "primjumping" which let you invalidate terrain obstacles even further. I assume only so much can reasonably be done about the nitty gritty of how jumping in SL works but some way of controlling maximum jump height for avatars in a region would actually be a gamechanger for the viability of combat experiences in SL.

There is also enabling/disabling prejump. It's a clientside thing right now and it can lead to some really weird behaviour, but it's also another mechanical thing baked into SL that greatly affects how movement works. If that was something we could fiddle around with more it'd be appreciated as I know many users in general are just somewhat confounded by why their jumps seem unresponsive and sluggish until they turn off prejumps.

 

Secondly we have the speed at which avatars can move laterally at, as in walking and running. Scripted movement boosters for "sprinting" and such have been made to alter this but they are unreliable in circumstances where you don't want them to be extreme enhancements to basic movement. It's easy enough to turn your avatar into a million mile an hour comet but it's hard to just have an avatar move slightly faster on normal terrain without hiccups like colliding on said terrain and killing your avatar by running into a molehill. Just like jumping even adjusting the basic movement speed can be the difference in making a sim feel much bigger by making travel slower, or making combat high speed and intense like in so many beloved arena shooter games. Not to mention the benefits of if speed boosts or such could be applied to avatars for temporary periods of time.

 

I'm open to more input on this from scripters and such, but I think it's pretty easy to intuit for anyone who plays games how these things can be intrinsic to combat. I'd be remiss not to mention them as we're all talking about other features like adjusting hitbox sizes (consider this also: hitbox size when avatars crouch? The tradeoff isn't just hitbox size being smaller but movement speed being slower, just saying) and being able to manipulate how much damage can be dealt per hit in a combat area.

[Cesar Goland]

One feature that I would love to see would be the ability to stay dead, not forcing instant respawn on reaching health 0, like, what If I want the possibility for being rescued or take a first med kit? making more use for healing effects. Maybe an event on_revive() that triggers when health changes from 0 to anything else. Here the players needs to rescue others and take them to hospitals

 

(I am assuming here that after on_death() health would go back to 100)

[Love Zhaoying]

I am glad the focus is occasionally brought back to focusing on a "universal system".  

Being able to use "any old weapon" to join a "game" would be a lot better than restricting functionality to only those who bought or use a specific 3rd party system.

 

[JeromFranzic]

15 minutes ago, Love Zhaoying said:

I am glad the focus is occasionally brought back to focusing on a "universal system".  

Being able to use "any old weapon" to join a "game" would be a lot better than restricting functionality to only those who bought or use a specific 3rd party system.

 

I mostly agree with this. It may be necessary to use specific weapons for some games, especially ones with strong RP/story specific elements.

[Rosa Hexem]

45 minutes ago, Love Zhaoying said:

I am glad the focus is occasionally brought back to focusing on a "universal system".  

Being able to use "any old weapon" to join a "game" would be a lot better than restricting functionality to only those who bought or use a specific 3rd party system.

 

28 minutes ago, JeromFranzic said:

I mostly agree with this. It may be necessary to use specific weapons for some games, especially ones with strong RP/story specific elements.

Yeah, broad compatibility is cool but Bring Your Own Blaster still leads to a need for local rules enforced by local referees in combat areas to keep things sane. I applaud the ideas to make combat systems mutually compatible and things such as max damage capacity regardless, it's just there are circumstances where I understand why gated third party systems are a thing.

Third party systems usually mean arbitration by whoever runs that system on what is mechanically acceptable down to a systems level, which ironically leads to a lot less headache for people who want to buy weapons but don't want to have to worry about said weapon being banned for breaking combat area rules. It also means that the developers who own the system are the ultimate authority on how the balance of their game should work, and that there's less endless bickering about different groups of people trying to push their own preferred standards within an open system.

Even with max damage cap in the proposed Combat 2.0 it's not accounting for some creator deciding that having a gun that spawns damage prims on a hit target until they die too ensure 1 hit kills regardless of damage cap would be a really marketable feature to sell their weapon as "more powerful than any competing weapon!" or "a game winning advantage!". Meanwhile when someone has a fairly closed system where only pre-approved weapons work, then the people running that system can catch out people who want to sell users the promise of being game-breakingly overpowered.

[Love Zhaoying]

9 minutes ago, Rosa Hexem said:

but Bring Your Own Blaster still leads to a need for local rules enforced by local referees in combat areas to keep things sane.

...just go out and shoot each other...

 

[Rosa Hexem]

8 minutes ago, Love Zhaoying said:

...just go out and shoot each other...

 

Oh my sweet summer child. That works really well until the first time someone decides to shower the sim in instakill damage megaprims that render combat impossible, or when someone desires to not be in a combat area where people shower the sim in instakill damage megaprims.

That being said if you want that experience right now you can go to any of the damage enabled combat sandboxes and just start randomly shooting at people, nobody was stopping people from doing that ever it just hardly appeals to most people looking for an actual game to play with a structured experience.

Edited December 7, 2023 by Rosa Hexem

[Love Zhaoying]

17 minutes ago, Rosa Hexem said:

Oh my sweet summer child. That works really well until the first time someone decides to shower the sim in instakill damage megaprims that render combat impossible, or when someone desires to not be in a combat area where people shower the sim in instakill damage megaprims.

That being said if you want that experience right now you can go to any of the damage enabled combat sandboxes and just start randomly shooting at people, nobody was stopping people from doing that ever it just hardly appeals to most people looking for an actual game to play with a structured experience.

You missed my point. That's ok, I just wanted to let you know. I won't reply further. Thanks!

[Lucidius Flanagan]

Howdy, ready down several posts
 

Seems the damage threshold/throttling is kinda contentious and dread raises a good point. Could have a damage rate aka a maximum threshold for "hits" or a regional "invulnerability" phase once you take damage? Make it so you can only get hit once every second if a region wants it, paired with the above or on its own as another means of tailoring combat.

 

The other thing I thought of is your statement regarding "when your health drops to 0 and dies it is then restored to 100%" Why not make the start value after death a region/parcel setting too? I can picture some one making a survival style game or some RP meters presently do it, where when you revive you start with very little health and you have to use ingame resources to heal up. A reduced healing rate would mean in this system you would be encouraged to wait a long time in a HUB or safe zone to get back to 100 or consume healing magic or items to get back into fighting condition. This could be better suited to slower paced games or RP systems.

 

Another concern could be if teleport on death was disabled and a death animation plays, controls are seized to the user can't move around. Could have a death "grace period" that is also region set to allow invulnerability after death for RP systems that have mid combat reviving so they dont get dropped immediately? I could picture this being a thing for a battle royatle team styel game mode where the sim owner may want like the first second or two after a revive to have invulnerability or something. IDK just spit balling.

 

Last one was having a faster raycast that just checks line of sight to an avatar or something? Anything to reduce the amount of congestion with making Line of Sight checks to avatars to confirm if damage can be applied. We use this in the SL Combat sims to see if a sensor has detected an avatar (usually a grenade). It then checks line of sight via raycast to confirm if the target is within line of sight. Something like a llRaycastFast that just returns a TRUE/FALSE if the ray hits the specific masks so we can make stuff like raycast guns that dont return massive lists that need to get parsed every .013 seconds or something. Raycast guns have made it easier for newer people to transition into SL combat but they are rather laggy when spammed. Any enhancements to LOS checks would be appreciated by most people. I can guarentee most people hate being killed through walls and ***** unfairly lol.

 

Anywho just tossing thos in, gonna follow up on thread later and if you don't like my ideas, most of them are just that it's NBD. Just thinking of features that may be helpful for NEW styles of combat entirely or to replace a lot of the clunky jankyness of RP meters.

 

[Lucidius Flanagan]

 

4 hours ago, Cesar Goland said:

One feature that I would love to see would be the ability to stay dead, not forcing instant respawn on reaching health 0, like, what If I want the possibility for being rescued or take a first med kit? making more use for healing effects. Maybe an event on_revive() that triggers when health changes from 0 to anything else. Here the players needs to rescue others and take them to hospitals

 

(I am assuming here that after on_death() health would go back to 100)

I like this idea, a ghetto around would be my suggestion of having health start at whatever the region value is and having the region dictate what the starting health is (have it set to 1 then so the are easillllllllllllllllled) but I dont quiet like that. I think having this bundled in an experience would be a good idea, or having it so the region can set you to negative health (-5 HP) and you come back to life once you regen back to positive health points (region has regen rates built in) or you get healed (negative applydamage).

the negative health may be the best solution but I suspect health cannot go negative and it may be a buch of back end work to do so? I really like this idea tho for RP meter deaths Could be abused obviously (-100 hp on death with 0 regen).

8 hours ago, Cesar Goland said:

I have a RPG system with some combat features on an experience (and other damage dealing features, like hunger and diseases, that would also benefit from this framework), but all usable weapons are specifc for the sim, I would love to use this, performance wise it would be awesome, but I think that being able to limit stuff to a specific experience would be needed, like preventing a on_damage event from even triggering if its damage source is not from a experience (not filtering it in the event, but not even triggering)

An example that I can think is that even if we can use on_damage and llDetectDamage to filter out some damage sources the event itself would still be triggered, like spamming the on_damage event enough to prevent some damages to enter?, lets say, If I overload someone with llDamage(...,0,...) preventing other damage events would that specific person be Immortal?

Honestly I got so interested in this framework that in almost 15 years of Second Life this is my first post on the forum

(English is not my main language, sorry for anything)

Could you make it so your system gives immunity to all damage types that arn't your own with the proposed string based damage types? Have it so damage reistances apply to everything that isn't "YourMeter_fire" "YourMeter_slashing". Might be missing somehting but just a thought I had! Need your input greeeeeeeeeeeeeeeeeeon this stuff.

 

18 hours ago, Duckie Dickins said:

... but if I were to give my honest opinion, all of these things are already being accomplished by existing scripted combat meters...for 15 years already. Combat developers have already created their own library of functions to do most if not all of these things proposed...

Sorry if my view point sounds more negative than the others but many of the features I proposed not existing is what has frustrated me with combat in SL for the past 7 or 8 years now. Today if I want to get my pew pew pew on, I just pick up my phone because I know I'll have a better experience on a mobile device and that is what combat in SL is actually competing with.

Based on past conversations and such the goal is to reduce the amount of ***** meters need to keep track of to bake it in to combat so that meters arn't needed to handle the combat but may be needed to layer OVER combat. Should hopefully free up sim resources so meters can be less impact or focus on other things

[Wulfie Reanimator]

6 hours ago, Cesar Goland said:

One feature that I would love to see would be the ability to stay dead, not forcing instant respawn on reaching health 0, like, what If I want the possibility for being rescued or take a first med kit? making more use for healing effects. Maybe an event on_revive() that triggers when health changes from 0 to anything else.

2 hours ago, Lucidius Flanagan said:

The other thing I thought of is your statement regarding "when your health drops to 0 and dies it is then restored to 100%" Why not make the start value after death a region/parcel setting too?

All custom on-death and "revive" functionality could be done by setting the sim's Death Consequences to nothing, like Rider's proposal described. You could play death animations, disable controls, keep the avatar where it is, set their health to a specific starting amount, etc.

I wonder what should happen to health regeneration and on_damage events if an avatar's health is at 0... It would probably make sense to (optionally?) disable health regeneration for avatars at 0 health. Then again, someone had the idea of interpreting avatar health as "mana/energy/stamina" and not having deaths at all. I can't think of any real benefit for disabling on_damage events at 0 health.

Edited December 7, 2023 by Wulfie Reanimator

[Lucidius Flanagan]

16 minutes ago, Wulfie Reanimator said:

All custom on-death and "revive" functionality could be done by setting the sim's Death Consequences to nothing, like Rider's proposal described. You could play death animations, disable controls, keep the avatar where it is, set their health to a specific starting amount, etc.

I wonder what should happen to health regeneration and on_damage events if an avatar's health is at 0...

It would probably make sense to (optionally?) disable health regeneration for avatars at 0 health. Then again, someone had the idea of interpreting avatar health as "mana/energy/stamina" and not having deaths at all. I can't think of any real benefit for disabling on_damage events at 0 health.

I suppose you could have an experience/script on_death set a timer to then apply a damage after the user "revives" so they go from 100 to whatever you wanted, but i think the idea is to give levers and controls to region owners so the scripting isn't required and it can be handled quickly yea? I dont see an llsethealth call just llgethealth but I may be missing something. Either way we will find a work around but I think having these levers be something you can just enable easily and have more control over "default behaviors" is a good goal for improving the amount of games that can be made using combat as a base.

Liking the conversation of disabling regen at 0, seems like a good control. At default it means you stay at 0 for 6s until you tick up to 1, x seconds at region regen and 0 if dead means "dead dead". Good suggestion