L2J Server

Ok, Just a question. I thought Datapack was the place we use to keep *DATA*, all those things you may want to change without compiling. And Core is where we all write *CODE*, operations, processes...
Am i wrong in something?
Well can you Just tell me one good reason to move ALL the handlers to Datapack? I can't see what is the scope, will we ever need to change an Handler on-the-fly? Are the handlers something we need to deal daily just like Skills and Sql? NO. We just write down an handler for some new item type and we leave it there doing his work for YEARS w/o changing anything.
And what else? Oh dear, all chat handlers too! why? I just can't see the point.

I just see a HUGE work for me (and i guess for the biggest part of server devs out there) to move all my customs to DP without ONE appreciable good reason.

Can you show me this single good reason, if any?

Just in case you haven't seen it, this discussion started (and maybe ended too) here http://l2jserver.com/old-forum/thread.p ... 660&page=1

I can't imagine such big work. Whether or not you have custom stuff in your handlers, you have to highlight all of them and move to a folder in DP...

Moving them to DP ist just Cut and Paste them there and change "package" declration to correct folder. Should be easy for "devs" like you. It took me 10 mins to move ALL handlers to DP. So you should be done fast.

If you are a dev and working on a production Server, you will notice that coding handlers DP side has more positive effects then negative.

Actually, actually... much more problems (for me) was produced by refactoring instances.

Can we get the DP devs to commit an update to the DP .project in order to configure the DP project as java project by default and have the default core location added as a project source so that syntax will be checked correctly in eclipse by default if using the default project locations?

Any reason this would not work if committed?


*edit* wow... how many times did I write the word default in this post...

Kudos, it's been argued to death pretty much. Trust me, I was there for it all.

But what I learned is that when something like this gets committed, no amount of arguing is going to change that. The core team has a plan (I think... I hope) and this is part of it. So as annoying as it is (and it can be at times depending on what you're working on), we just have to roll with it.

GodKratos wrote:Can we get the DP devs to commit an update to the DP .project in order to configure the DP project as java project by default and have the default core location added as a project source so that syntax will be checked correctly in eclipse by default if using the default project locations?

Any reason this would not work if committed?


*edit* wow... how many times did I write the word default in this post...

This is really great idea.
Would be really nice if this could be done...

Well, if the core should really be changed to a framework, this gets really really difficult... The folder content of model/actor/instance, the full AI, all server- and clientpackets must be moved to DP. And then isn't it a question of performance, at least with packets and AI? Are you sure you want this?

crion wrote:Well, if the core should really be changed to a framework, this gets really really difficult... The folder content of model/actor/instance, the full AI, all server- and clientpackets must be moved to DP. And then isn't it a question of performance, at least with packets and AI? Are you sure you want this?

Yes, if we moved EVERYTHING to the DP it would cause a little bit of performance issues, but just because we want it to be a framework doesn't mean we cannot modify this framework. IMO we should eventually have another folder in the trunk called framework that contains all the unadulterated framework files, and the core should contain the modified files.

Let's say semiframework