Status update - 16 September, 2014

Why not combine ECS with inheritence. Keep everyone happy. Make certain attributes a component and keep others in their own classes.

1 Like

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 :smiley:

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.

3 Likes

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

1 Like

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 :wink:

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.

1 Like

That’s apparently the plan :stuck_out_tongue:

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.

7 Likes

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 :smile:

1 Like

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.