How much interest in a generalized version of playereffects?

[Byakuren]

I'm currently working on a replacement for Wuzzy's playereffects, which is a system for keeping track of player status effects, like flying ability or speed, or a combination of different player state. It handles the cancellation and persistence of effects, and also attempts to solve the incompatibility between mods that change the same global state. Currently, I am using it in my magical_realm modpack to handle some spell effects.

These are some reasons I felt the need to write a replacement:

• Effects that affect the same state cannot be combined - In playereffects, whenever a new effect would conflict with an existing effect on a player, the old effect is canceled before the new one is applied. This makes it impossible to e.g. have a weak but long-lasting effect come back into effect after a short, strong effect runs out, or to have speed multipliers multiply together, etc.
• No support for permanent effects - A player might have something that gives them a permanent boost, like an ability that makes them faster. This should be handled in the same effect framework, so that it is possible to have permanent and temporary modifications to player state coexist. Permanent effects would also allow privilege granting/revoking to work in the same framework, if the commands were overridden to use it.
• Effects cannot change while in effect - This is related to the above. If an effect is permanent, it might represent something like a player stat. In that case, you would want to be able to change it in case it changes.
• Effects cannot be tagged for searching - For magical_realm, I wanted to be able to write a dispel spell that only dispels magical effects. It would be nice to be able to tag effects as "magical" and then cancel all of them. This could currently be done if I registered all magical effects separately in some table, though.

What I decided to do was to write my own effects framework that is flexible enough to cover these use cases. I have a tentative API viewable at https://github.com/raymoo/monoidal_effe ... er/API.txt . The implementation is not done, but I already see how I would do it.

Regardless of popularity, I will probably still write it to use in my own mods, but how much interest is there in such a system, and what features would make it easier to adopt?

[kaadmy]

Edit: nevermind

[jp]

:)
https://github.com/kaadmy/pixture/tree/ ... er_effects

Not tired to advertise your subgame wherever you have a small occasion to ?

I'm quite fed up of your swaggering to divert some attention and basically not helping much the original posters.

[kaadmy]

[...]
Not tired to advertise your subgame wherever you have a small occasion to ?

I'm quite fed up of your swaggering to divert some attention and basically not helping much the original posters.

Ok, i'll edit it out.

[firefox]

i would be interested in playereffects, because if i ever finish my subgame, i want to add magic powers that allow the player to fly by consuming mana as long as the effect is active.
so it's like everyone has the fly priv, but using it consumes mana, so usuage is limited to short time periods.
also alchemy crafting to make potions that allow you to breathe underwater or swim in lava are also part of my plans.

i am very happy that trees_lib exists, because otherwise i wouldn't be able to generate new trees.
there should be more of those general API things and playereffects is definitely something useful, so it should get one :)

[twoelk]

would be intersting how this could be used as a classroom tool.
Not sure what a teacher would need to keep the pupils focused and how player effects could be used to herd a group into a desired direction though. I guess a game designer that tries to script an adventure would have similar interests.

What I miss from similar projects is some sort of GUI with an overview who has which privs, abilities, whatever. This would be really handy for any administrator, moderator, teacher or quest-leader.

[Byakuren]

i would be interested in playereffects, because if i ever finish my subgame, i want to add magic powers that allow the player to fly by consuming mana as long as the effect is active.
so it's like everyone has the fly priv, but using it consumes mana, so usuage is limited to short time periods.
also alchemy crafting to make potions that allow you to breathe underwater or swim in lava are also part of my plans.

i am very happy that trees_lib exists, because otherwise i wouldn't be able to generate new trees.
there should be more of those general API things and playereffects is definitely something useful, so it should get one :)

I think this wasn't clear, but this would be separate from playereffects, it would be a new system that would be incompatible with playereffects (if you tried to use both to handle the same effects)

[Don]

I think that it is a great idea. Player effects is a great mod but is limited. It would be great if other mods could use the framework to add new ways to use player effects.
One thing I wonder about is will this be much different then Wuzzys mod? If it is expanding Wuzzys mod then I would suggest that you do a PR instead of creating a new mod. The fragmentation of mods is confusing to players. They get confused as to what mod to use.
If this is quite different then I say go for it.

[Byakuren]

I think that it is a great idea. Player effects is a great mod but is limited. It would be great if other mods could use the framework to add new ways to use player effects.
One thing I wonder about is will this be much different then Wuzzys mod? If it is expanding Wuzzys mod then I would suggest that you do a PR instead of creating a new mod. The fragmentation of mods is confusing to players. They get confused as to what mod to use.
If this is quite different then I say go for it.

The big difference in API is that effects will be required to be part of one or more collections (I will be calling them monoids) in order to have any effect. I might add a convenience function for registering a monoid and an effect type in it simultaneously though, so that if your effect type has narrow effects that won't interfere with anything, you don't have to go through all the ceremony of registering a new monoid the normal way.

This is not going to be a fork of playereffects.

[firefox]

ok, i didn't expect a fork of playereffects.
just something that can do the same things and is usable by registering custom effects.
similar to how sokomine's trees_lib works to generate new tree types.
it is "easy" to use and saves you the trouble of writing a mountain of lua tables.

[Byakuren]

I have the mod working a little. There are likely tons of bugs, but the basic combining of effects looks to be working.
Here is the thread in WIP: viewtopic.php?f=9&t=13941

[Wuzzy]

I understand your problem.
But none of your suggestions sound like they would be impossible or conflict with the basic goals of playereffects.
The reason why those much-requested features got never implemented were basically laziness from my side. See, I am active in a lot of other projects as well, so Minetest simply does not get my full attention.

But I don't understand why you want to create an entirely new framework for that. You have not made an convincing argument that the playereffects mod could not be extended or modified for that. Also, none of those suggestions are going any of the stated goals of playereffects. I would be in favor of your idea to create a new mod if it would be so significantly different in design and architecture that it justifies a brand new mod. But I simply don't see the real differences here.

So it seems you are suffering from the “Not Invented Here” syndrome.

I'd gladly accept new code if it helps the mod to improve. I am even willing to break backwards-compability for those features, since a) they have been requested a lot and b) I too think those are important additions which would increase the flexibility a lot.

About your ideas in particular:

Effects that affect the same state cannot be combined - In playereffects, whenever a new effect would conflict with an existing effect on a player, the old effect is canceled before the new one is applied. This makes it impossible to e.g. have a weak but long-lasting effect come back into effect after a short, strong effect runs out, or to have speed multipliers multiply together, etc.

This has been long on my TODO list and is really important. There has been a lot of discussion on the playereffects thread (you might want to read it) on that but I totally agree that this feature is a must-have. It might be required to break backwards-compability for that feature but I since this feature is important it might be totally worth it.

No support for permanent effects - A player might have something that gives them a permanent boost, like an ability that makes them faster. This should be handled in the same effect framework, so that it is possible to have permanent and temporary modifications to player state coexist. Permanent effects would also allow privilege granting/revoking to work in the same framework, if the commands were overridden to use it.

I was originally against permanent effects but now I think this does not make much sense not to support them. Also, this feature does not sound complicated to implement.

Effects cannot change while in effect - This is related to the above. If an effect is permanent, it might represent something like a player stat. In that case, you would want to be able to change it in case it changes.

Sounds plausible and certainly not impossible to do.

Effects cannot be tagged for searching - For magical_realm, I wanted to be able to write a dispel spell that only dispels magical effects. It would be nice to be able to tag effects as "magical" and then cancel all of them. This could currently be done if I registered all magical effects separately in some table, though.

Some sort of effect groups? Interesting idea. Also, I am clearly not opposed to that; it would be an useful convenience function.


Of course, you can do whatever you please. But I would *really* appreciate if you work on improving playereffects instead of starting your own mod. Or do you have a reason why you think all that would be impossible with playereffects?
Others have already warned about mod fragmentation and I think this concern should be taken seriously.

[MineYoshi]

In really i will like it,
Wuzzy maybe have his version,
but if you want to do it different, like an alternative, you can!
....

[Byakuren]

I'm sorry for causing more mod fragmentation. I have thought about it, and I think I have a design that would allow adding these changes to playereffects without breaking backwards-compatibility. I will be a bit busy this and next week but maybe after that I will try rereading through playereffects and see where I can start making changes.

There are some smaller issues orthogonal to the stuff in this thread that I had with playereffects. Do you have an issue tracker, or should I just post in your thread?

[Wuzzy]

There is no issue tracker. Just post in the thread.