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?
About Handlers Unhardcordings in 2884
Forum rules
READ NOW: L2j Forums Rules of Conduct
READ NOW: L2j Forums Rules of Conduct
- DrHouse
- L2j Inner Circle
- Posts: 912
- Joined: Mon Jan 22, 2007 12:14 am
- Location: Spain
Re: About Handlers Unhardcordings in 2884
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...
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...
Leadership and management are not talk and talk, but talk and do
Proud of being a part of this project
-
- L2j Inner Circle
- Posts: 350
- Joined: Wed Jun 07, 2006 2:26 pm
Re: About Handlers Unhardcordings in 2884
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.
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.
<ZaKaX> Ohh nBd, you're so professianal with your analconda.
-
- L2j Veteran
- Posts: 3437
- Joined: Wed Apr 30, 2008 8:53 am
- Location: Russia
Re: About Handlers Unhardcordings in 2884
Actually, actually... much more problems (for me) was produced by refactoring instances.
Commiter of the shit
public static final int PI = 3.1415926535897932384626433832795;
public static final int PI = 3.1415926535897932384626433832795;
-
- L2j Veteran
- Posts: 418
- Joined: Fri Jan 25, 2008 6:09 am
Re: About Handlers Unhardcordings in 2884
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...
Any reason this would not work if committed?
*edit* wow... how many times did I write the word default in this post...
-
- Posts: 750
- Joined: Sun Dec 07, 2008 7:01 pm
- Location: Poland
Re: About Handlers Unhardcordings in 2884
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.
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.
-
- Posts: 12
- Joined: Sun Sep 09, 2007 3:49 pm
Re: About Handlers Unhardcordings in 2884
This is really great idea.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...
Would be really nice if this could be done...
-
- Posts: 45
- Joined: Sun Feb 18, 2007 3:49 am
- Location: Germany
Re: About Handlers Unhardcordings in 2884
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?
- poltomb
- L2j Veteran
- Posts: 225
- Joined: Wed Jul 13, 2005 7:13 am
- Location: USA
Re: About Handlers Unhardcordings in 2884
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.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?
- DrHouse
- L2j Inner Circle
- Posts: 912
- Joined: Mon Jan 22, 2007 12:14 am
- Location: Spain
Re: About Handlers Unhardcordings in 2884
Let's say semiframework
Leadership and management are not talk and talk, but talk and do
Proud of being a part of this project