New Supporting Server Subversion Requirement (Beta)

[IStandAloneToo]

Well,
I started work at Nike this past week and I have gained a few ideas from how their software development teams work. I'm thinking that the supporting servers will be required to run their core base from a branch. This is essentially what the DoL core staff was wanting to require of the supporting servers. Their cores should be shared OPEN to anyone. This does not mean that you have to share your scripts! Scripts may be kept private in a private solution/subversion directory (like storm's). I have no problem with writing a quick tutorial on how to set up a private subversion directory to store your scripts and how you can make a solution to build all of DoL including your scripts!

If we have the supporting server's cores on sourceforge, we have the ability to using subversion's merging functionality to put fixes into DoL.

I have not decided if I'm going to make this a requirement or not, I am more wondering people's thoughts. However, I am very excited for the possibilities that this solution would provide to DoL and will be pushing this feature very hard!

[Dinberg]

As you know Ryan, my server is entirely unscripted - because the game I was designing had no practical use to keep up-to-date with new formulae or bugfixes - in many ways i was purposefully breaking DAoC. The sheer complexity of the calculations and balancing required as little to change without my knowing as was possible - lest a new formula wreck havoc on the new game dynamics - so i elected to not even SVN update.

Scripting was not possible at all, or I would end up basically overiding every function and class in the game. Even our packets had to be changed to allow things like the learnt skill system to function with the use of the exp bar, and its unpractical to suggest these as commits to DoL when no one else would use them.

I'm unable to argue after I leave for Tunisia tomorrow, but I'll be back for a bit in a week. As I can't argue back, take my point seriously; you know what I'm talking about, and scripting was completely unfeasible. I'd be gutted to think after any help I've given to DoL my server would be refused to be on the co-op list because I can't open up my svn; if I open up my svn, bearing in mind the server is entirely custom, it would be the equivalent of me opening my scripts up.

[Batlas]

meh, Dinberg. You will find out soon how much thats going to suck when you have a reason to update (Packet changes and core changes to that system) I've told you before and I'll tell you again. You will want to have everything as scripted as possible in order to take advantage of certain fixes that will come. As for your idea ISAT, personally, I like it. However I think it would require man power we don't necessarily have. This means someone who will have the free time to sit down and look at what changes were implemented in our supporting servers SVN. If anything I would suggest giving devs of sharing servers access to a private head svn in which we can test their changes on storm and as they become stable release them in stable format.

[Graveen]

Batlas said all. The idea is excellent in a system with many contributors. Actually, this would certainly result in SVN living side by side and never be browsed/merged. Worse, the DOL main branch should receive less contributions than actually, due to the fact they have an open svn.

And branch merge is to handle with care.

[Darwin]

i would say Yes, supporting servers should share for other supporting servers (only, because we can't provide any support for features/fastfix we code just for us) and it would be a nice boost for Dol improvement

[Hxxride52]

I agree with Darwin. I'm open to it. Sorry about my lack of commits in the past 2 days btw, I'm having to deal with a packet bombing issue, and my host charging us for remote hands fees. "cries" (Shattered)

[Blues]

I am not realy sure.
Basicly this is an open source project, so it should all be open.
Question is should scripts made by single persons for a special server be open too?
I dont know. I was able to work a bit with the i50 Team a while ago, seeing what they have done i dont think it would be ok to lay that all open. That is imensive work, far beyond what the dol code is about, especially their tools for server management.
Though they realy have all their custom stuff seperated from the dol code in a scripts section. So it would be possible to lay the basics open for them and keeping their own stuff.
But other servers merged custom stuff and basic dol more, making their dol stuff public would mean making everything they have done public.
Also a lot of servers do not have up to date cores. I dont think you can blame em for that. If you create tons of scripts working with a certain revision and than someone comes along changing basic things that would require a whole rework of essential parts of your server while you dont see a sense in the changes made its easier to stop doing svn updates and keep on going your way.
There can be other reasons too, like your scripts start to cause bugs after a svn update. Well when you have to keep a server going you might not be able to spend hours looking for what caused the bugs, you just go back to the latest version and stop doing updates.

Well whatever, i dont know what would be the best. It doesnt feel that good to me to make this a requirement. Maybe asking to make stuff public would be enough for now.
What would be cool would be something like a DOL Community Manager, someone that keeps up the contact between the servers and dol. Not only asking servers to share, also trying to bring them all together. I think one of the worst things in the daoc freeshard community is that all servers strugle with each other. So ofc everyone tries to hide the best things from every other shard. Also no Admin cares about the rest when his server has to be shut down.
If all the great code of those servers that dont exist anymore would have been shared after they went down there would be a lot of stuff to add to the dol project and even more great scripts for certain, special things.

[Graveen]

yeah Blues, an important point you got is the compatibility. We internally got this discussion (and have it again) mainly on DB changes. I think this point is discouraging others to update to latest core and thus do not maintain everyone at the same level.

But we are also oblilged to make dol evoluate (gamepet, db changes ie) to ensure it is ever better and faster.

[Batlas]

I just want to add in Blues that DOL has been "suggesting" that other servers share their code since they started. Most people want to remain competitive so they get stuff to work so that they have their "niche" and grab players. For example before catacombs classes were made everyone flocked to servers that had those classes.

[Dinberg]

meh, Dinberg. You will find out soon how much thats going to suck when you have a reason to update (Packet changes and core changes to that system)

I dont update from the svn for the principal reason that the SVN is building a different game to me. When I did used to have it scripted, I'd update from the svn and suddenly all of the class balancing had gone - because a simple change to a calculator had ruint a few weeks of balancing effort. While packet changes and core changes are great, they aren't essentially an SVN-only thing - alot of core changes go in a different project to GameServer (I only don't update GameServer), and the packet changes can easily be copy and pasted in for new packet libs.

And for the other packets that get fixed? Well, most of my time is spent breaking packets to make them do other things, such as the gadgeteer's laser gun, or to allow learnt skills to use the xp bar through that /memory observe <skillname> command. If I update the old packets, it too causes too much of a nuisance.

Besides, if you think you can click a button and synch together all of the svns I guarantee you will get a few sneaky bits popping in there - plvl code, db access, etc.

[IStandAloneToo]

I think this point is discouraging others to update to latest core and thus do not maintain everyone at the same level.

However, people don't update to the latest core anyways. I know of 3 servers that do: Shattered, Storm, and Eden.

[Graveen]

right, but this was because changes/structure were breaked too often.i hope all new servers choose svn core update

[Blues]

Impossible.
Not all Servers are doing a "Standard" Concept.
We are currently building up a new Server (and want to become supporting Server). We will have home invasion where rvr means raiding villages. All NPCs in a Village will be part of a "keep", damages will be calculated different. A Mob will be yellow for a lv 1 and also for a lv 50. Crafting will work completly different, chances will be like 100% and the main difficulty will be to gather the components for crafting, what means to chop wood, mine ores and such.
Those are just some points, but maybe you get an idea about how huge our changes to the code will be.

[Graveen]

i understand.

On another way, i wonder if a project hosted in scripting isn't interesting enough to help your project:
- getting your project up to date with svn, thus allowing exchange
- putting a complete project in script (a full project, containing all changes, as we did on Storm, then we include it on svn solution to work on entire server), even if you have to change some functions to virtual. The goal is to maintains a solid base (svn one) that you should use too, and allowing a lighter project management, focusing only on differences.

Of course, this is another organisation, you should not fit into, but a lot of shard could easily - i insist ! - do this. Imho the main problem is data organisation (new tables, old tables, shared informations etc..). For performance, the main problem is db <--> software, i think it should not be the point.

[Graveen]

(double post 4 the health of my postcount )