Why not combine ECS with inheritence. Keep everyone happy. Make certain attributes a component and keep others in their own classes.
That sounds great.
I’m not sure there is a design pattern like that but I’m sure if it was planned out it would work. It would also allow for scalability in both ways in the future
Thanks for the update, the project looks promising. Get the API released ASAP so us plugin devs can have a happy programming session
if you guys are going to make playerquitevent and playerkickevent, make sure to make them separated because they end up being triggered both even if the player was kicked, and that is bad for plugins like combatlog, thanks
Maybe a PlayerLeftEvent with a reason code of “Kicked”, “Logged Off”, “Disconnected”, etc.
cant be disconnected you see, I need something like this PlayerKickEvent, he got kicked, so I dont kill him, now PlayerLeaveEvent, he disconnected so I /kill him, this is for combatlog
the problem with this current api is that when the playerquitevent gets executed it runs playerkickevent too, but if I run playerkickevent it just runs itself now if they disconnect there is no way to kill them, because they got kicked
The issue is that there are multiple event types for a player no longer being connected to the server, and the underlying server logic fires a bunch of them thus muddying the real reason why the player is no longer connected. So it seems that two things would be needed:
-
What I mentioned above - a single event with a reason code. In the example you cite you would check the reason code of the PlayerLeftEvent to see if it is a kick, and if so the logic would ignore. Otherwise a /kill.
-
Refactor the underlying logic to only fire a single event instead of multiples.
that is a good option too
Keep up the great work, glad to see you guys chose to continue even with the whole Microsoft nonsense
My only question is, what about Forge? Lex seems really unmotivated and stressed, a sooner update of Forge to 1.8 is actually the best step, we can go before Sponge.
That’s apparently the plan
I agree with this decision, 100%. You’ve provided great rationale, you’ve communicated very effectively, and you’re doing a great job of trying to be as transparent as possible. I don’t mean to sound like a sycophant, I genuinely feel this way.
Keep up the good work. I’d like to suggest you appoint someone to think about some of the more business and human infrastructure side of things so you can get started on that aspect of the project soon, also. I’d like to nominate @TnT, mostly because he doesn’t want to be nominated.
So far… It is looking to be awesome.
@sk89q,
I’d like to help with the website. I’ve already filled the form for that, but will there be another one, as the form for devs is now also renewed?
Is ECS also Dependency Inversion? They sound so similar. Instead of inheritance, there’s a bunch of interfaces that describe the behavior of an object, and you just slap those puppies onto any object to give it that behavior.
now i want a creeper that eats grass
I assume you mean inversion of control / dependency injection. Dependency injection is one way to do inversion of control.
ECS is not dependency injection.
ECS is not inversion of control.
Components are often concrete implementations as well.
I don’t know at the moment. We need a better website, but I need to talk around to see what the plan is.
ECS seems like developers trying to “fix” Minecraft. I think it would make a lot of sense for a project trying to reimplement the whole game, but Sponge is just a plugin system.