A few weeks ago I asked most people related to L2J:
What would you do if they were in my place (Project Leader)?
Iโve got very interesting answers, the most challenging were not from people that was close to the team, but from those that from some (known or unknown) reason distanced from the public development.
The most interesting things that were mentioned to me are:
Change the task system.
Divide tasks between developers.
Use a task system, other than forum thread.
Public.
Get/hire more developers.
Focus on fixing existing bugs.
Prevent introducing new bugs.
Fix exploits as fast as possible.
Focus on stability .
Memory leaks.
Deadlocks.
Performance.
Keep up with newer game versions.
Reduce the time it takes to fix small problems.
Reduce the time consumed on obscure things, such as code refactoring, code comments, renaming, porting, etc.
Reduce the time that takes to integrate important features to the server.
Improve game customization, make it easy to manage and maintain.
Avoid unanswered threads, at least one person from the team should answer it.
Reduce long time synchronization between stable and beta branch.
Less :
Ranks.
Talk.
Inactive developers.
More:
Team work.
Collaboration.
Code.
Outdated wiki and documentation.
To be more flexible.
Allow unfinished or imperfect work to be committed.
Allow small commits instead of huge reworks.
Give the source structure (follow a pattern design).
Develop 3rd party features.
Web admin panel.
Deployment kit.
Include paid services to motivate developers.
Server deployment.
Configurations.
Custom features.
Implement an official L2J Server for testing purposes.
Make L2J run on pure Java.
Keep L2J as close as retail as possible.
This is based in over 30 messages Iโve got, and after thinking this through a few times I have come up with some changes to the project.
There will be a forum integrated, public, mandatory task list manager.
A priority list will be set for the work flow:
Exploits
Stability issues
Bugs
Small problems.
Medium problems.
Large problems, that require a large rework.
Reworks
Missing features
Custom features
A code standard will be set, public and mandatory.
An alpha branch will be set up to develop client compatibility with newer game versions.viewforum.php?f=105
A synchronization date will be set for stable and beta branches.
Team rules will be set.
Inactive members will be removed/retired.
Problematic members will be removed.
Wiki and documentation will be updated after the source has changed.
A promotion system will be implemented to increase the feedback.
A collaboration system between forks and future integration.
Powered by Eclipse 4.34 | Eclipse Temurin 21 | MariaDB 11.3.2 | L2J Server 2.6.3.0 - High Five
Skills!
I want to run a server for over a year now but with all the reworks (most notably the skills one that takes a lot of time) and the huge gaps between synching beta with stable i am hesitant.
P.S: Also id like to mention that maybe the reason theres not as much activity on the forums as it used be is because you kinda forgot about the simple user that wants to make a casual server and has little coding knowlege. Those are the guys that report bugs and stuff like that the most.
L2J Currently is great !
I'm only care about Skill , current High Five features , bug and exploit , AI ! It would be great if all features are working and skill fomulas corrected retail-like and Fake NPC
Just my opinion !
Good news!
Nice that u are starting to care about project. thanks that wiki will be updated after some changes.
i hope this news wont be only announced but we will se in action.
i like new system about developer share their task and activity. As most of them were inactive and in near future it wont happen .
For me, I think, that stable is unusable, because it is released in large update packs containing many incompatible thingsa with older versions (according to the customs) so I think that, stable featureset should reach stable whenever it could be considered stable. So a model containing unstable (development branch(es), where features are merged, might be buggy), testing (where bugs are fixed) and stable (production, hotfixes go there) branches should do the thing. So when using Git when a new feature is made, it starts in its own topic branch, optionally goes to the development branch to ensure compatibility and some polishing, after that, when it could be considered as feature-finished, it goes to the testing branch, where the bugs are fixed. From time to time it is called that there is feature freeze for testing (new features after that are developed in development branch), bugs are fixed and then it's merged into release.
Battlecruiser wrote:For me, I think, that stable is unusable, because it is released in large update packs containing many incompatible thingsa with older versions (according to the customs) so I think that, stable featureset should reach stable whenever it could be considered stable. So a model containing unstable (development branch(es), where features are merged, might be buggy), testing (where bugs are fixed) and stable (production, hotfixes go there) branches should do the thing. So when using Git when a new feature is made, it starts in its own topic branch, optionally goes to the development branch to ensure compatibility and some polishing, after that, when it could be considered as feature-finished, it goes to the testing branch, where the bugs are fixed. From time to time it is called that there is feature freeze for testing (new features after that are developed in development branch), bugs are fixed and then it's merged into release.
GIT is under consideration, because of it's pros regarding FOSS developing guidelines but, it carry some problems that we haven't solved yet.
Let's not make this a SVN vs GIT thread.
Powered by Eclipse 4.34 | Eclipse Temurin 21 | MariaDB 11.3.2 | L2J Server 2.6.3.0 - High Five