Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-233439] Per-generator particle limit #10535

Open
sl-service-account opened this issue Feb 21, 2023 · 1 comment
Open

[BUG-233439] Per-generator particle limit #10535

sl-service-account opened this issue Feb 21, 2023 · 1 comment

Comments

@sl-service-account
Copy link

How would you like the feature to work?

A user-settable particle limit per-generator, that would exist alongside the current overall particle limit, and would control the number of particles from a source that can be visible at any given time.

It would be a single integer number value, set like the overall limit, that would apply to all objects (not individual ones like a blacklist), that would set a maximum number of particles produced by a source that can be visible concurrently, stopping the rendering of more particles once at limit until the current number falls, much like the existing overall limit does, but only for individual sources.

Why is this feature important to you? How would it benefit the community?

With the existing overall limit only, particle spam from an inefficiently scripted generator can quickly hit the particle limit, stopping all particles. In this way, a crappy wave engine, spammy fog generator, or even a stuck griefer tool in the distance can drown out useful, even needed, particles when in view, with no recourse.

Being able to set particle limits for sources would prevent this drowning out effect, and further mitigate the effect of particle griefing, as such tools would not only no longer pose a risk to viewer performance, but wouldn't even drown out legitimate particle effects anymore.

Adding more control over particle rendering and generation may also facilitate the safe raising of the overall particle limit's maximum value in the client.

Original Jira Fields
Field Value
Issue BUG-233439
Summary Per-generator particle limit
Type New Feature Request
Priority Unset
Status Accepted
Resolution Accepted
Reporter Iexo Bethune (iexo.bethune)
Created at 2023-02-21T19:05:07Z
Updated at 2023-02-22T20:00:30Z
{
  'Build Id': 'unset',
  'Business Unit': ['Platform'],
  'Date of First Response': '2023-02-22T14:00:30.470-0600',
  'How would you like the feature to work?': 'A user-settable particle cap per-generator, that would exist alongside the current overall particle cap, and would limit the number of particles from a source that can be visible at any given time.\r\n\r\nIt would be a single integer number value, set like the overall cap, that would apply to all objects (not individual ones like a blacklist), that would set a maximum number of particles produced by a source that can be visible concurrently, stopping the rendering of more particles once at cap until the current number falls, much like the existing overall cap does, but only for individual sources.',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': "With the existing overall cap only, particle spam from an inefficiently scripted generator can quickly hit the particle cap, stopping all particles.  In this way, a crappy wave engine, spammy fog generator, or even a stuck griefer tool in the distance can drown out useful, even needed, particles when in view, with no recourse.\r\n\r\nBeing able to set particle caps for sources would prevent this drowning out effect, and further mitigate the effect of particle griefing, as such tools would not only no longer pose a risk to viewer performance, but wouldn't even drown out legitimate particle effects anymore.\r\n\r\nAdding more control over particle rendering and generation may also facilitate the safe raising of the overall particle cap's higher limit in the client.",
}
@sl-service-account
Copy link
Author

Kyle Linden commented at 2023-02-22T20:00:30Z

Thank you for the suggestion. we may implement some version of this at a future date.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant