rAthena - the fork

[Rhon]

Well well well...

More power...

Cheerzs...

[Olrox]

Thx Jguy, Brian and all the people involved, for once again, support this project again. I know that all will be better from now.

But.

Did I read right? renewal branch only? I wonder if we will have 2 branches, or only ... one?.

I'm not a server owner anymore, but, I know that a lot of servers still use pre-renewal mechanism

Edited November 28, 2011 by Olrox

[Jman]

there is plans to have two branches. It's not specifically the renewal branch, but the name was chosen for the fact that we will be supporting the renewal branch 100%.

[Z3R0]

Not to mention it's the "Renewal" of the eAthena community -> RAthena

[Nameless2you]

I thought the main reason why eA didn't move to 3.2 was because there was to much db to be converted into the newer version so that the db can support it..

anyways it's good to see that you're basing on renewal but don't forget pre-renewal, there will always be people that will play pre-renewal, considering how many servers and seeking server posts i've seen for retro & pre-renewal, that highly outweigh renewal seeking players, as for myself i don't mind either but purely doing everything on renewal would be bad.

[Jman]

That is the main reason. If you notice, none of the posts came with to this installation. That's because:

1) we didn't have the posts

2) we can't convert them, there's just too many.

[Aurora]

To be honest, it's about time.

More power to y'all for trying to work things out peacefully, but all I've ever seen out of Paradox is uselessness. Of course, that's just one person's opinion, and I'm certainly not going to bad-mouth him as I do not know him. He certainly was doing eAthena no good, hoiwever, and I'm so happy that y'all took it in to your own hands to make sure the engine was well taken care of, not to mention being sure Renewal is continued.

However, I do have to agree, there should probably be two SVNs. One pre-Renewal, and the other Renewal. While servers who continue down the path of non-Renewal may get left in the dust a bit, there are way too many people out there who would prefer to be able to start their own server on the basis of the old mechanics. Leaving it as the only option would probably discourage those people (such as RetRO, they've been around for over a year now?). Though, I do have to admit, forcing people to get used to the Renewal side of things may do a world of good, seeing as everyone's scared of it like a housewife to a mouse.

Anyways, good job. I hope to see this project grow and stick around.

Edited November 28, 2011 by Aurora

[Terces]

I'm glad...nothing more for me too say

[Kratos]

@xazax

I just didn't want to be rude with the previous developers about the improper documentation and weird shorthanded variables, but Xazax you're right we need better documentation from now on.

Not sure if someone likes this idea, but I think as this is a new fork and we will need new developers, there should some kind of workshop for new members. I mean there are lot of stuff like clif.c, chrif.c which people currently don't know what it does, so we should have something like a general glossary of what file controls or does.

Good luck, if I see I can help with something I'll do it, but for now I'll refine my skills

Actually, I think it is pretty obvious what those files are for, at least it should be for those, who wants to apply for a dev position. However that is true, there is a room for improvement in the documentation of the code. So what we need there, is not a glossary, but proper documentation.

@KeiKun, true if you have some knowledge of C, java or C# you might find what each function does, but some commentaries aren't even translated (check the code for Japanese comments, they're still there since forever)

and I don't think it's fun for new people to search for every file just to know what a variable means or a function does, besides remember this is C, not a an OOP language where you can know directly which class you're using and where to search.

Not sure if someone likes this idea, but I think as this is a new fork and we will need new developers, there should some kind of workshop for new members. I mean there are lot of stuff like clif.c, chrif.c which people currently don't know what it does, so we should have something like a general glossary of what file controls or does.

Good luck, if I see I can help with something I'll do it, but for now I'll refine my skills

if you have knowledge with C language

its already easy to determine what that file is for~

[Teny]

@xazax

I just didn't want to be rude with the previous developers about the improper documentation and weird shorthanded variables, but Xazax you're right we need better documentation from now on.

Not sure if someone likes this idea, but I think as this is a new fork and we will need new developers, there should some kind of workshop for new members. I mean there are lot of stuff like clif.c, chrif.c which people currently don't know what it does, so we should have something like a general glossary of what file controls or does.

Good luck, if I see I can help with something I'll do it, but for now I'll refine my skills

Actually, I think it is pretty obvious what those files are for, at least it should be for those, who wants to apply for a dev position. However that is true, there is a room for improvement in the documentation of the code. So what we need there, is not a glossary, but proper documentation.

@KeiKun, true if you have some knowledge of C, java or C# you might find what each function does, but some commentaries aren't even translated (check the code for Japanese comments, they're still there since forever)

and I don't think it's fun for new people to search for every file just to know what a variable means or a function does, besides remember this is C, not a an OOP language where you can know directly which class you're using and where to search.

Not sure if someone likes this idea, but I think as this is a new fork and we will need new developers, there should some kind of workshop for new members. I mean there are lot of stuff like clif.c, chrif.c which people currently don't know what it does, so we should have something like a general glossary of what file controls or does.

Good luck, if I see I can help with something I'll do it, but for now I'll refine my skills

if you have knowledge with C language

its already easy to determine what that file is for~

I agree with you 100% Kratos.

I have about 2 years of OOP(Java) experience but I find I constantly have to refer to 2 or sometimes 3 other files to see what's going on in the source code.

Plus I think it would allow beginners/people whom aren't that familiar with source coding to get their feet wet as opposed to looking at the source, getting overwhelmed and giving up.

[mirabell]

i agree, that this project go Renewal. Chopping up code just to make renewal option work in a non renewal server is just ridicules. This new fork should pick up the principles that EA originally had about keeping up with kro. If member really dont want renewal, i dont see the reason they cant stay in there current svn and just commit the npc and database items only. Not to mention the fact that people need to stop living in the past and move on to renewal. i swear people make it seem like renewal is end of the world. In fact without renewal, 3-1 and mobs and new mob skill are way to overpowered and unbalanced.

Good job on moving to renewal

[KoKe]

Did I read right? renewal branch only? I wonder if we will have 2 branches, or only ... one?.

I'm not a server owner anymore, but, I know that a lot of servers still use pre-renewal mechanism

I was wondering that too

To be honest, it's about time.

However, I do have to agree, there should probably be two SVNs. One pre-Renewal, and the other Renewal. While servers who continue down the path of non-Renewal may get left in the dust a bit, there are way too many people out there who would prefer to be able to start their own server on the basis of the old mechanics. Leaving it as the only option would probably discourage those people (such as RetRO, they've been around for over a year now?). Though, I do have to admit, forcing people to get used to the Renewal side of things may do a world of good, seeing as everyone's scared of it like a housewife to a mouse.

At least one option to keep the pre-renewal option off/on

i agree, that this project go Renewal. Chopping up code just to make renewal option work in a non renewal server is just ridicules. This new fork should pick up the principles that EA originally had about keeping up with kro. If member really dont want renewal, i dont see the reason they cant stay in there current svn and just commit the npc and database items only. Not to mention the fact that people need to stop living in the past and move on to renewal. i swear people make it seem like renewal is end of the world. In fact without renewal, 3-1 and mobs and new mob skill are way to overpowered and unbalanced.

everything you said is true, but for example you like to play in renewal and others like to play pre-renewal

Also keep working RAthena Team!!

[Yommy]

i think it would be best, if we put PreRE into its own branch.

and then Renewal into the trunk as active development.

it might help to remove all backwards compatible support for older clients in this renewal trunk.

there is way too many #ifdef packetver

this should make the code alot cleaner and easier to debug.

[Diconfrost VaNz]

+1 to Yommy :3

[KeiKun]

may i ask

@ Renewal...

Implementation of what? 3rd jobs including Mechanics or what

another thing

about new branches

2 Trunks?

- PreRE

- RE

~

[WishBone]

I applaud the overall success of this fork. Congratulations! Will be lurking some more.

[Erid]

Great, it's good to see progress. I think that everything related to the development of the emulator will be discussed in another topic, we'll see what happens there =).

I hope RAthena the best!.

[Denken]

rathena sounds great

[Protimus]

In brAthena we are doing as Yommy talked for one year. The idea is good... I advise this, so far we had no problems.

This is a structure that can be fine in SVN:

Branches -> Pre-Renewal | Renewal

Developement -> For develop additions and tests

Episodes -> For develop new episodes...

Pre-renewal may be treated as stable and renewal as trunk.

[Mystery]

In brAthena we are doing as Yommy talked for one year. The idea is good... I advise this, so far we had no problems.

This is a structure that can be fine in SVN:

Branches -> Pre-Renewal | Renewal

Developement -> For develop additions and tests

Episodes -> For develop new episodes...

Pre-renewal may be treated as stable and renewal as trunk.

Pre-renewal as stable for brAthena?.. or for rAthena?

I would love Pre-renewal for stable and Renewal for Trunk, though, I don't really like the renewal mechanics.. rather stick to old Pre-renewal.

Also, wouldn't 2 SVNs give rAthena more work to do?

[KeiKun]

In brAthena we are doing as Yommy talked for one year. The idea is good... I advise this, so far we had no problems.

This is a structure that can be fine in SVN:

Branches -> Pre-Renewal | Renewal

Developement -> For develop additions and tests

Episodes -> For develop new episodes...

Pre-renewal may be treated as stable and renewal as trunk.

Pre-renewal as stable for brAthena?.. or for rAthena?

I would love Pre-renewal for stable and Renewal for Trunk, though, I don't really like the renewal mechanics.. rather stick to old Pre-renewal.

Also, wouldn't 2 SVNs give rAthena more work to do?

SVN:

Trunk

- Renewal

Branches

- Pre-Renewal

from name itself RAthena ( a Rat xD )

LOL

[Daniel]

You've already read my thoughts about this issue.

I sincerely wish the best for the rathena, and hope the momentum isn't lost any time soon!

Edited November 30, 2011 by Daniel

[Protimus]

In brAthena we are doing as Yommy talked for one year. The idea is good... I advise this, so far we had no problems.

This is a structure that can be fine in SVN:

Branches -> Pre-Renewal | Renewal

Developement -> For develop additions and tests

Episodes -> For develop new episodes...

Pre-renewal may be treated as stable and renewal as trunk.

Pre-renewal as stable for brAthena?.. or for rAthena?

I would love Pre-renewal for stable and Renewal for Trunk, though, I don't really like the renewal mechanics.. rather stick to old Pre-renewal.

Also, wouldn't 2 SVNs give rAthena more work to do?

Yes, give a lot more work... But it is very well organized.

About mechanics is possible just add battle flags for settings, adding something like: conf/battle/renewal.conf, containing all options to active or deactive the mechanics.

It would be possible to use these flags without the hassle of creating more than one branch, but there are changes to database and NPCs, so it makes a bad stability and size of the emulator for those who will use the pre-renewal.

So i still think better to create two branches.

Edited November 30, 2011 by Protimus

[Mystery]

That'd be cool to add a conf file to enable or disable mechanics.

[iFoxkun]

Ahh hope this goes well, although I barely became a member in sprite repository ;___; Most staffs are nice from there