Status update - 16 September, 2014


#17

I already love this project.
a) it embraces the "community"
b) it communicates
c) it responds
d) it moves forward

Good job guys, I will keep my fingers crossed.


#18

Glad to see that even though an eye of caution is open wide it is not slowing down progress. I personally do not thing that Microsoft's purchase will cause this community to fail as the success of Minecraft is always created to the greater community that has opened up so many possibilities beyond the original scope. Yes Microsoft has made a few blunders in the past but when you put it into perspective look at the some of the wonderful things that they have accomplished: anyone remember when they first announced the XBOX and everyone told them they were fools getting into something they could never succeed at? Big companies are easy to hate, massive companies with huge market shares and a vast product offering are even easier to hate. This deal is (by Mojang's own admission) been in the works for a good while now, with this level of continued interest there is little way they could not be aware of what the community of developers, modders, server owners/managers, etc have done to make Minecraft the global phenomenon that it is today. Of course none of us can say what they have for plans with this purchase, but they are not going to want to lose such an important piece of the success.

Thank you to all that have made a contribution in the past and to everyone doing their own part to continue this adventure. This is what makes a community so strong and powerful. I have to admit that I look forward each day I arrive home to reviewing the discussions that have taken place and following the work/progress that has been made. Keep up the amazing work and community commitment!


#19

Should've used Scala, it supports mixins using Traits
Anyway, good work dev team!

Oh and why is the sprint called "Inspired Wallaroo"?


#20

While I agree and think it would have solved some of the API design problems related to running on Java 6, Java is what people are used to (probably including sk89q and co).


#21

I can't wait to sign up for API development, this project is looking good.


#22

According to Owexz, the new versioning system for Sponge builds is an adjective and an Australian Marsupial.

On that note, allow me to blow my own trumpet: http://forums.spongepowered.org/t/bardic-extrapolation-rime-of-the-ancient-sponge/555/7?u=inscrutable


#23

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


#24

That sounds great.


#25

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


#26

Thanks for the update, the project looks promising. Get the API released ASAP so us plugin devs can have a happy programming session smiley


#27

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


Getting event call cascade?
#28

Maybe a PlayerLeftEvent with a reason code of "Kicked", "Logged Off", "Disconnected", etc.


#29

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


#30

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.


#31

that is a good option too wink


#32

Keep up the great work, glad to see you guys chose to continue even with the whole Microsoft nonsense


#33

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.


#34

That's apparently the plan stuck_out_tongue


#35

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.


#36

So far... It is looking to be awesome.