Skip to content

Rework status effect integration #32

Description

@guerro323

As for now, status effects must have the same variables as the base component, which restrict in how some status effects could work.
The problem is that it make stuff much more complicated to work with and to replicate onto the Unity client. (a status effect is an inherited component, but it's working weirdly)

Proposed solutions:

  • Keep the way it work, but simplify the component itself (the variable Type shouldn't be in the component since we can already tell the type from the component itself).
  • Convert all status effects into a buffer. This may make it a bit more complex to work with, but it's easier to replicate it. Mods that require a different way to work with its own status effect could just implement a new buffer.
  • Convert status effects into a big component. While easier to work with and replicate it, it's a problem if an entity shouldn't have that status effect. For mods it would work as the previous point.
  • Make a mix of 1 and 2. Status effects components can have a freedom of variables, but there would be a buffer that contains the read-only state.

If I go for the last and first point, the way inherited component work should be remade

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions