You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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:
If I go for the last and first point, the way inherited component work should be remade
The text was updated successfully, but these errors were encountered: