Re: L2J Changes, Server Discussion.
Posted: Wed Apr 30, 2014 1:31 am
Hello everyone,
While I highly doubt there is anyone still around that remembers me from the old forum, I am somewhat glad to see that at the very least my profile is still here, somewhat. Since it appears it lost the post count I had, I am left unable to present the comment I would like to this topic in server discussion section. Now, instead of replying to a bunch of irrelevant threads, with matching irrelevant replies just to reach the minimum post count, I will rather present my comment about the referred ongoing topic here. I decided to post here on the Off-Topic section, because it will also include a few observations not really related to server specific discussion, but relevant to my comment. Be warned, it may get long since I have been quiet here for years... and there may be a lot piled up since. For that I apologize in advance, but bear with me please.
For starters, I am actually glad to see that there has been a drastic change in the mindset of the project leader ring. It was so sorely needed. At the very least, now it seems that among other things people are now open to suggestions. The opening post on the topic in question, bore a rather curious meaning in the way I see it. For the looks of it, it appears that it has been noticed by the leader ring that L2J has been loosing development resources and as time passes it seems less and less people are willing to commit anything at all to the project. Now this has a multitude of reasons that I will not go into detail, since I am sure the smart person Zoey appears to be is already aware of. But in my case, one of the reasons that made me become a silent bystander of the L2JServer project career, and stop contributing to it (I can still recognize bits and pieces of patches submitted by me on the current builds...), was that nobody seems to have any grasp at all where they want to lead this project to. I am not speaking about the leader ring, as this is an open source project anyone in the community shares part of the responsibility of it. Even me.
In that sense, the way I read it, there are a few ideas various members seem to have, but basically they are variations of these two:
- Keep chasing NCZ0ft, regardless of the ability of the project to commit enough development effort to deliver proper releases on time.
- Fix it all up before moving on, regardless of the limited development effort available, not caring for how much this causes the project to stall.
The community appears conflicted by these two stances. As expected, because these two stances are two matched opposites. IMO, this is what seems to be making people loose interest, and it is part of the base problem that needs to be taken care of. Which is, the leader ring needs to find a balance between these two first and foremost before making plans about "hiring more developers" vs "implementing task systems" and whatnot. Any system, rule, protocol, status, methodology, etc ... is irrelevant if placed on an "empty room". I salute the initiative of starting a vote cast in order to obtain community feedback, about where the project should go. But in the end, I believe this will only serve to provide evidence that not even the community itself has any idea, as a collective entity, of where/how the project should proceed. At least, not with the vote options that we are given. And since I do not agree with either of them, I will not cast a vote. As an example of what I am trying to say, the option "bugs and exploit fixes" is terribly biased. Of course that on such a project, the vast majority of voters will pick that option. It has no reason to be there, because regardless of whatever comes out of it, the project will need to have it's "bugs and exploits" fixed. And the leader ring surely knows it (my guess is that's why it asks for two options rather than one...), it doesn't need the community to tell it, or does it?
I have been following L2JServer since a first checkout of Interlude, back in the day. During that initial stage, I have to thank the project for providing for a lovely entertaining educational platform. As time passed, and chronicles progressed, it became evidently clear that the project itself could not keep up with NCZ0ft releases. But this didn't stop the progressive accumulation of bad programming practices, and poorly conceived implementations to pile up over time, thus choking the potential of the project. Without underestimating the commitment effort put by everyone involved with it, I believe that if one would simply strip the bad bits out of it one would be left with little more than what L2Chef had when he made his last visible commit using that name. It was around when Kamael/Hellbound was released, that I decided to part with L2JServer due to severe divergences in development implementations. The working copy that I was contributing to, stopped looking even remotely like L2JServer sources. There was no longer a way for me to contribute to this project, and there was also no other way for me to get anything from it anymore, except much valued data from the datapack side. This working copy then progressively became the standard basis for a server, that grew a modest community around it (which I will not mention, due to personal reasons...) with a taste for very specific modifications that found their way into it. Hence, why I could no longer contribute back to the datapack side either. Basically, the game not only forked from L2JServer but also form NCZ0ft itself, since almost none of the gameplay changes that take the old-school retro-Lineage II feel from it exist on the private repository sources I contribute to.
Knowing this, I'm sure the ones that are not yet asleep should be wondering what does this have anything to do Zoey's poll. Well, it has _everything_ to do with it. Because the same lead ring difficulties that Zoey seems to be evidencing, are the exact same difficulties my "secret" development team has faced, and solved internally. That is, once we settled on what we wanted for our own little ongoing experiment everything just sort of clicked into place. Then the beauty began to grow. Blazing fast database pool (not c3p0...), vector math, polygonal spawn zones with accurate surface placement, updated libraries, logback back-end for logging, random number sampling using Mersenne Twister, and the list just goes on... with ongoing development. And it pains me to know that none of this can be used by L2Jserver without some severe, serious porting job, which would still require extensive modification of the core to even be remotely pluggable. The story for the data side is different. Our data is useless to L2J because the parts we develop/change/update do not mimic NCZ0ft. Sometimes I look at everything from afar, and wonder what would have become of L2JServer if I ignored the conflicts that began to brew between me and most of the narrowed view commiters back then, and insisted on voicing alternative implementations.
So you see, this can be considered an example, of talent and development commitment that L2JServer project sorely needs and cannot be used by it. And like me, I'm sure there is a whole truckload of talented developers that have made a checkout in the past, but could no longer contribute to L2JServer at some point because the successive leader rings over the years made "no-so-correct" decisions about the project. These dropped/forgotten talents, if put together, would surely amount to a development driving force that would surely be able to tackle the 3 most wanted goals of that poll: "bugs and exploit fixes", "new missing features" and "compatibility with new game versions". Thus, possibly rekindling the interest of many more "silent community spectators" into an active role. I believe with enough development power, the two conflicting stances I mentioned before will rather merge into one clear course for the project. But for that, the current inertia needs to be broken, and the voices of these talents must be heard and heeded. Talent shapes the project, the other way around chokes talent and it will simply run away.
Final word, commenting on Zoey's list of "todo's" (if one can call them that...), I believe the leader ring should rather consider first how to recover lost development force (regardless of it's form), rather than fancy tools without having people to use them. The lead ring should try to track down people that lost interest, and possibly attempt to bring them back into the loop, and scout new talents without pretentiousness or arrogance in the likes of "I R L2J Core dev., thou art noob. Be my code slave.". Most of the recruiting attempts people have done in the past, came across like that most of the time, because there seems to be next to no-flexibility in accepting new perspectives for old problems that still linger today (check how "lovely" character movements are synchronized between server/client...). The most used excuse a while ago was the "coding standards" bull. Yes, there should be standards. But not when these standards are used to shackle talents into submission. I know this, because some of the people with me came from here and they told me about their experiences with L2JServer project leads. If Zoey and the current lead ring are actively working to change this, then I'm sure we will see again brighter days for L2JServer.
Thanks everybody, for your attention. And sorry for the long read. Good evening.
While I highly doubt there is anyone still around that remembers me from the old forum, I am somewhat glad to see that at the very least my profile is still here, somewhat. Since it appears it lost the post count I had, I am left unable to present the comment I would like to this topic in server discussion section. Now, instead of replying to a bunch of irrelevant threads, with matching irrelevant replies just to reach the minimum post count, I will rather present my comment about the referred ongoing topic here. I decided to post here on the Off-Topic section, because it will also include a few observations not really related to server specific discussion, but relevant to my comment. Be warned, it may get long since I have been quiet here for years... and there may be a lot piled up since. For that I apologize in advance, but bear with me please.
For starters, I am actually glad to see that there has been a drastic change in the mindset of the project leader ring. It was so sorely needed. At the very least, now it seems that among other things people are now open to suggestions. The opening post on the topic in question, bore a rather curious meaning in the way I see it. For the looks of it, it appears that it has been noticed by the leader ring that L2J has been loosing development resources and as time passes it seems less and less people are willing to commit anything at all to the project. Now this has a multitude of reasons that I will not go into detail, since I am sure the smart person Zoey appears to be is already aware of. But in my case, one of the reasons that made me become a silent bystander of the L2JServer project career, and stop contributing to it (I can still recognize bits and pieces of patches submitted by me on the current builds...), was that nobody seems to have any grasp at all where they want to lead this project to. I am not speaking about the leader ring, as this is an open source project anyone in the community shares part of the responsibility of it. Even me.
In that sense, the way I read it, there are a few ideas various members seem to have, but basically they are variations of these two:
- Keep chasing NCZ0ft, regardless of the ability of the project to commit enough development effort to deliver proper releases on time.
- Fix it all up before moving on, regardless of the limited development effort available, not caring for how much this causes the project to stall.
The community appears conflicted by these two stances. As expected, because these two stances are two matched opposites. IMO, this is what seems to be making people loose interest, and it is part of the base problem that needs to be taken care of. Which is, the leader ring needs to find a balance between these two first and foremost before making plans about "hiring more developers" vs "implementing task systems" and whatnot. Any system, rule, protocol, status, methodology, etc ... is irrelevant if placed on an "empty room". I salute the initiative of starting a vote cast in order to obtain community feedback, about where the project should go. But in the end, I believe this will only serve to provide evidence that not even the community itself has any idea, as a collective entity, of where/how the project should proceed. At least, not with the vote options that we are given. And since I do not agree with either of them, I will not cast a vote. As an example of what I am trying to say, the option "bugs and exploit fixes" is terribly biased. Of course that on such a project, the vast majority of voters will pick that option. It has no reason to be there, because regardless of whatever comes out of it, the project will need to have it's "bugs and exploits" fixed. And the leader ring surely knows it (my guess is that's why it asks for two options rather than one...), it doesn't need the community to tell it, or does it?
I have been following L2JServer since a first checkout of Interlude, back in the day. During that initial stage, I have to thank the project for providing for a lovely entertaining educational platform. As time passed, and chronicles progressed, it became evidently clear that the project itself could not keep up with NCZ0ft releases. But this didn't stop the progressive accumulation of bad programming practices, and poorly conceived implementations to pile up over time, thus choking the potential of the project. Without underestimating the commitment effort put by everyone involved with it, I believe that if one would simply strip the bad bits out of it one would be left with little more than what L2Chef had when he made his last visible commit using that name. It was around when Kamael/Hellbound was released, that I decided to part with L2JServer due to severe divergences in development implementations. The working copy that I was contributing to, stopped looking even remotely like L2JServer sources. There was no longer a way for me to contribute to this project, and there was also no other way for me to get anything from it anymore, except much valued data from the datapack side. This working copy then progressively became the standard basis for a server, that grew a modest community around it (which I will not mention, due to personal reasons...) with a taste for very specific modifications that found their way into it. Hence, why I could no longer contribute back to the datapack side either. Basically, the game not only forked from L2JServer but also form NCZ0ft itself, since almost none of the gameplay changes that take the old-school retro-Lineage II feel from it exist on the private repository sources I contribute to.
Knowing this, I'm sure the ones that are not yet asleep should be wondering what does this have anything to do Zoey's poll. Well, it has _everything_ to do with it. Because the same lead ring difficulties that Zoey seems to be evidencing, are the exact same difficulties my "secret" development team has faced, and solved internally. That is, once we settled on what we wanted for our own little ongoing experiment everything just sort of clicked into place. Then the beauty began to grow. Blazing fast database pool (not c3p0...), vector math, polygonal spawn zones with accurate surface placement, updated libraries, logback back-end for logging, random number sampling using Mersenne Twister, and the list just goes on... with ongoing development. And it pains me to know that none of this can be used by L2Jserver without some severe, serious porting job, which would still require extensive modification of the core to even be remotely pluggable. The story for the data side is different. Our data is useless to L2J because the parts we develop/change/update do not mimic NCZ0ft. Sometimes I look at everything from afar, and wonder what would have become of L2JServer if I ignored the conflicts that began to brew between me and most of the narrowed view commiters back then, and insisted on voicing alternative implementations.
So you see, this can be considered an example, of talent and development commitment that L2JServer project sorely needs and cannot be used by it. And like me, I'm sure there is a whole truckload of talented developers that have made a checkout in the past, but could no longer contribute to L2JServer at some point because the successive leader rings over the years made "no-so-correct" decisions about the project. These dropped/forgotten talents, if put together, would surely amount to a development driving force that would surely be able to tackle the 3 most wanted goals of that poll: "bugs and exploit fixes", "new missing features" and "compatibility with new game versions". Thus, possibly rekindling the interest of many more "silent community spectators" into an active role. I believe with enough development power, the two conflicting stances I mentioned before will rather merge into one clear course for the project. But for that, the current inertia needs to be broken, and the voices of these talents must be heard and heeded. Talent shapes the project, the other way around chokes talent and it will simply run away.
Final word, commenting on Zoey's list of "todo's" (if one can call them that...), I believe the leader ring should rather consider first how to recover lost development force (regardless of it's form), rather than fancy tools without having people to use them. The lead ring should try to track down people that lost interest, and possibly attempt to bring them back into the loop, and scout new talents without pretentiousness or arrogance in the likes of "I R L2J Core dev., thou art noob. Be my code slave.". Most of the recruiting attempts people have done in the past, came across like that most of the time, because there seems to be next to no-flexibility in accepting new perspectives for old problems that still linger today (check how "lovely" character movements are synchronized between server/client...). The most used excuse a while ago was the "coding standards" bull. Yes, there should be standards. But not when these standards are used to shackle talents into submission. I know this, because some of the people with me came from here and they told me about their experiences with L2JServer project leads. If Zoey and the current lead ring are actively working to change this, then I'm sure we will see again brighter days for L2JServer.
Thanks everybody, for your attention. And sorry for the long read. Good evening.