AttributeService

Feature Requests Engine Features
#1

Similar to CollectionService, I’d like methods and events for Attributes

  • GetAllTags
  • TagAdded
  • TagRemoved

As a developer it’d make my life a lot easier to track Attributes when they are added/removed and get a list of All attributes in the game

I can definitely make my own implementation but it’d be a huge pain and i’d prefer official support

13 Likes
#2

Uh i cant find any use case for this, any examples?

3 Likes
#3

Use Case: Dynamic Player Buff Management

Scenario:

You are creating a multiplayer RPG where players can gain temporary buffs and debuffs during combat. Each buff or debuff is stored as an Attribute on the player character (e.g., "StrengthBoost": 10, "Poisoned": true, "SpeedBoost": 1.5). These attributes can be added, removed, or dynamically updated during gameplay.

Problem Without AttributeService:

Currently, to manage these buffs and debuffs, you would need to:

  1. Manually poll all Attributes on each player to detect changes.
  2. Write custom scripts to handle additions, removals, and updates to these Attributes.
  3. Introduce additional complexity for synchronizing UI changes, gameplay effects, and animations.

This setup is cumbersome, prone to errors, and leads to redundant and inefficient code.

How AttributeService Solves This:

  1. Efficient Real-Time Tracking:
    Using AttributeAdded, you can immediately apply gameplay effects (e.g., increasing attack power) or update the UI when a new buff/debuff is added:

    AttributeService.AttributeAdded:Connect(function(instance, attributeName, attributeValue)
    if instance:IsA("Player") and attributeName == "StrengthBoost" then
        instance.Character.AttackPower.Value += attributeValue
        UpdatePlayerUI(instance, attributeName, attributeValue)
    end
end)

  2. Seamless Removal Handling:
    When a buff/debuff expires, AttributeRemoved ensures effects are reverted without additional checks:

    AttributeService.AttributeRemoved:Connect(function(instance, attributeName)
    if instance:IsA("Player") and attributeName == "StrengthBoost" then
        local attributeValue = instance:GetAttribute(attributeName) or 0
        instance.Character.AttackPower.Value -= attributeValue
        RemoveBuffFromUI(instance, attributeName)
    end
end)

  3. Dynamic Updates with AttributeChanged:
    When the value of an existing attribute changes (e.g., "StrengthBoost" increases from 10 to 15), AttributeChanged allows for seamless updates:

    AttributeService.AttributeChanged:Connect(function(instance, attributeName, oldValue, newValue)
    if instance:IsA("Player") and attributeName == "StrengthBoost" then
        local delta = newValue - oldValue
        instance.Character.AttackPower.Value += delta
        UpdatePlayerUI(instance, attributeName, newValue)
    end
end)

  4. Centralized Attribute Query:
    GetAllAttributes simplifies debugging and allows you to retrieve all active buffs and debuffs for analytics or UI display:

    local activeAttributes = AttributeService:GetAllAttributes(player)
for name, value in pairs(activeAttributes) do
    print("Active Attribute:", name, "Value:", value)
end

Why This Use Case Matters:

  • Reduces Boilerplate Code: Eliminates the need for custom tracking systems, allowing developers to focus on gameplay mechanics.
  • Improves Performance: Attribute events enable efficient, event-driven updates instead of constant polling or redundant checks.
  • Enhances Developer Efficiency: Streamlines debugging, testing, and the implementation of Attribute-based systems.
  • Creates a Better Player Experience: Supports dynamic and responsive gameplay mechanics with minimal lag or desynchronization.

cc @computerph1_DEV

1 Like
#4

Thanks for going into so much detail in your use case. I found this really interesting. As an alternative or potential workaround, I’m curious what you think about this approach and/or why it wouldn’t work for your use case:

  • Whenever a character Model is spawned, create and parent a Folder named “Effects” to it
  • To add an effect, add some simple object (a Folder or Configurations for example) with Name property corresponding to the effect type into the Effects Folder. Attributes (or children) can represent various dynamic values corresponding to the effect type (ex. Slowness:GetAttribute(“SpeedDecrease”) → number corresponding to the percent to decrease base speed by
  • To remove an effect, delete the corresponding child of the Effects Folder
  • To listen for changes to effect types applied, connect to the ChildAdded and ChildRemoved event of the Effects Folder
  • To listen for changes to a particular effect (after it’s initially applied), when a new effect is detected (ChildAdded) connect listening events specific to the effect type (since the components of a particular effect type should likely be consistent and well-defined
  • To get all effects currently applied, you can use GetChildren on the Effects Folder
#5

Would also be cool if GetAttributeChangedSignal could provide a NewValue: number parameter, similar to .Changed events for values.

Also I dont really agree to the idea of an attribute service, yes CollectionService exists because it offers a larger API while for attributes there arent really that many functions.

2 Likes
#6

Honestly - this’s unneeded. Tags are meant to group objects. Attributes are meant to add properties to instances. In use-case with status effects - make a function and assign it to all players on server. It’s not that hard nor time-consuming.
Also in your use case, assume that you change some attributes rapidly. This will just… Blow your server due to constant firing of that event. Checking and firing event costs something…
If you want to make GetAttributes like in your use case, combine attributes with CollectionService, but this one is… so unique needing…

1 Like
#7

An alternative to this is to just store the information in code memory (tables, modules, etc).

2 Likes
#8

This, also its just a much nicer experience to have things just fully in code.

#9

At the risk of sounding non-empathetic to a feature request, I think it’d be better if you used both CollectionService and Attributes for this. Use CollectionService to find everything that needs its attributes tracked, manually listen to attribute changes, and go from there.

#10

i honestly didn’t expect this much attention,

this feature request is more of a “nice to have”. than a “I MUST HAVE THIS OR ELSE!” situation

i am well aware that CollectionService can solve my hypothetical use case, and my rule of thumb is to not hold my breath for Roblox to roll out features so yeah i can implement it myself

i rather not because it’s a pain in the ass to do so but if i really require it then i would

hence this:

image

cc @GamEditoPro @Mauio64 @netheround @iGottic @kalrnlo

#11

I personally don’t like such “it’s good to have this implemented” because this ALWAYS will require additional resources spent on feature. Like, if there won’t be any events firing about positions, cframes on parts while they are moving, parts will move almost lagless in 10k+ quantities.

#12

This is what I am wondering about this feature request too. It sounds like more overhead than setting attributes are meant to have.

This use case doesn’t sound that difficult to make either. It would be fairly simple to make your function that applies status effects also apply a CollectionService tag. The function that removes status effects can also remove the tag after. Have another module with the Attribute → Tag matching so any script can figure out what tag is connected to what attribute if they need. If you don’t have a function for each of those tasks, then that is the source of your problem.

This feature requests feels like a request to turn attributes into CollectionService even though CollectionService already exists. I personally don’t see why we need an alternative to one that is working fine, especially if it’s going to bring more overhead to attributes.

1 Like