P-RE vs RE? Do we really need both?

[Peopleperson49]

It's just a thought but why not eliminate pre-renewal completely from rAthena? Devs do a lot of extra work to maintain support and updates on P-RE that could be more focused on bettering RE. It takes up space on in the SVN. I know that a lot of servers still use P-RE and they could continue using those files as they are. It seems a lot like the old debate between txt and sql. Whether it was really worth the time to keep updating both. I understand that eliminating P-RE is different than that of txt vs sql, but I figured I woud it would be interesting to hear what other think. Besides I was bored!

Peopleperson49

PROS:

Reduce time and effort for DEVs.

Allow more focus to fixing issues with RE, since theres a good chance P-RE will be phased out eventually anyway.

Reduce SVN space.

Easier setup for new server owners.

Less confusing when adding new scripts and updates.

CONS:

Many servers still perfer P-RE.

Renewals still has some issues with skills and classes.

Would force some servers to have to update from P-RE to get new features.

Any future bugs with P-RE would no longer get the same support (but with no new changes to create new bugs that would eventually go away).

[Mystery]

Not necessarily. Having that ability to switch between PRE-RE and RE gives rAthena a huge advantage compared to 3CeAM and eA; eA just pre-re with minimal features and 3CeAM thats just RE with minimal features as well. rAthena has both 3CeAM and eA functions, but more advance. I don't think it's a good idea to remove PRE-RE at all. As all new server owners, they have to learn rAthena's emulator/SVN before they SHOULD EVER create a server; especially reading guides before ever opening up a server.

So no, not really. It really isn't "Easier" in a sense because there's already a lot of topics and guides throughout rAthena regarding how to switch between PRE-RE and RE and it's up to the own person's autonomy if they wish to move forward using rAthena's emulator.

If someone doesn't like rAthena's emulator, they're more than welcomed to use eAthena or 3CeAM for their needs. Keeping in mind, both aren't as updated frequently compared to rAthena.

[malufett]

hmmm..sounds good for me..since eAthena is still there for pRE..

anyway it doesn't bother me..

[phebs]

well i like classic and others too... so i guess this is imposible

[Peopleperson49]

Everytime you make a change you have to update your RE and P-RE servers and test it on both. That seems like it would take away from fixing the list of bug reports for the RE files that you aleady have. I know that rAthena is much more advanced and we can also keep that edge by aggresively fixing new bugs and adding new features. If the goal is to keep the advantage over them why are there so many released src mods out there for very useful commands or features? Take the guildmonster command that I like to push so much, it is super useful! I have actually changed it out on my server (well before I upgraded from 16265) for use with spawning castle emperiums. When used with the KoE it was a perfect fit.

I think I look at it like a company. Take General Motors in the US. They were a super powerful company that has dozens of different types of car companies within it. Chevy, GM, Buick, etc... The problem was that they has some much to stay on top of that there total efforts were always divided. Jack of all trades, master of none! I'm also not saying that they didn't produce quality products (I love my Chevy Silverado). But after they split and sold off those parts of the company the now smaller independant companies are turning more profit than when they were actually part of GM as a whole.

Peopleperson49

[Ziu]

@official servers only use renewal system... all servers the last server fRO.

rAThena is a renewal emulator.

Pre-renewal is old and need not erased... but i think they should stop supporting...

if you prefer old system when used SVN only download to last rev. before implementing renewal......it's easy..

[Euphy]

Since our pre-Renewal files are already very stable, I don't see the point in dropping them...

It doesn't complicate updates since, well, we're not updating those files, only Renewal ones.

[Valiente]

It'll be much better if rAthena has options for Classic 2nd jobs, Transcended and 3rd jobs. All in one. Since Private Server owners' preferences differ a lot.

Edited November 15, 2012 by Valiente

[Peopleperson49]

I use a renewal server, but I have the NPC quests for the 3rd jobs disables at this time until they fix all the issues with them.

Peopleperson49

[Lighta]

It does complicate a bit cause you need to be sure change won't break pre-re compability, so when it's a case or you're thing is only meant for RE you need to add an #ifdef etc, preventing flexibility.

Llike let say I would want SC_FOO->val2 for a new feature I would have to search all reference of sc->data[] usage and check if it ain't use in pre-re, (checking reference may be tricky as some may be hide with jsut sc->data[FOO2+5] with FOO2 declare 5 row before SC_FOO...

Then right now buildbot don't even build without #RENEWAL wich mean we could broke something for a plateform and won't even notice since he doesn't do it. Not likely but could happen very easily.

Finally there is no more or very few PRE-RE specific improvement, most of change concern both like new group system (doesn't care if you RE or not) or skill update (since 3rd ain't finish yet) etc. So imo if we keep it there right now it's just to not replicate those change on the PRE-RE version or vis versa.

It do bring avantage but now that thre more and more #ifdef I think would be better 2 version that we syncronise frequently for common change.

[Peopleperson49]

One thing that I really like about rAthena is how they that they made P-RE and RE basically share a common src to reduce work and space. But I don't completely agree with those who say that P-RE was very stable. Since they share files P-RE is really just as stable as RE. I don't think you can really just stop updating it (without completely removing it), because when you make changes to the src files for RE you then have to test out on both anyway. Even if it worked fine on RE, it could cause something negative on P-RE that would make rAthena seem broken. People tend to assume that looking through a small window shows the whole picture.

Peopleperson49

[xazax]

Even though maintaining pre-re support involves additional work, I do not feel like throwing it away. I don't think it would have significant impact on dev's productivity.

[EvilPuncker]

I do not agree.

[Dastgir]

Its better if rAthena have both because most of the users prefers pre-re because they don't like the renewal mechanics,

While some of the people likes new updates and are in renewal.

Edited November 16, 2012 by Dastgir Pojee

[michaelsoftman]

I say leave both, otherwise you're forcing pre-re users to go back to eAthena, which is pretty dead compared to rA.

[Dastgir]

I say leave both, otherwise you're forcing pre-re users to go back to eAthena, which is pretty dead compared to rA.

rA is not dead, its updating oftenly as I see,

rA is lot behind from kRO but rA is doing good and updating the emulator.

[Peopleperson49]

Dastgir Pojee he wasn't saying that rA was dead, he was saying that eA was dead. Which is true eA is pretty much dead. Michael when you say leave both do you mean two seperate versions, or keep it with shared files as it is now? Seperate versions are even work than the shared version. That would truely require twice the work to update each. Atleast the way it is now they pretty much share src files so there not doubling all the work. The way we have it now is working, my question was whether it was worth it to keep both in the future?

Peopleperson49

[michaelsoftman]

I mean to keep both in the same SVN, with the option in Renewal.h to turn on and off the features, just like it is right now.

I think it's nice and simple to keep it that way, and if people want further edits done, they will have to learn to edit the source themselves.

[Peopleperson49]

So basically rAthena not not a true RE emulator. Were a P-RE/RE emulator. It is working great the way it is with everything meshing. I just wonder if we focus on only RE maybe we can reduce the gap between rA and KRO. Besides can we truely maintian the 1:1 goal if we still have P-RE.?

Peopleperson49

[Beret]

I got a suggestion on a topic related to this topic, but kinda different, make the separation of maps and job 's, letting the user choose.

http://rathena.org/board/topic/73726-suggestion-to-separate-renewal-of-pre-renewal/

[Lemongrass]

I would suggest to create a certain branch for PRE-RE and to tell the users to use that one for PRE-RE features and to only update it once or twice a month or if some huge and important updates are done. That would clean up the sources and database files a lot and it would make it also easier for the PRE-RE server owners, because they would not have to do a lot of settings for the renewal features like it is now.

[Peopleperson49]

What we currently have works for both. Why create a seperate item to be maintained? Those huge and important updates will probably be very time consuming and annoying to Devs, even if it is only a couple time a month. Nobody wants a chore they have to do, expecially when they don't get paid to do it! Currently all they have to do is update one set of src files and then test them on both P-RE and RE. What your saying is to update them seperately and then they still have to test them. Plus somebody has to decide what is important to update on P-RE. Its just even more work then they have now! I don't think that it should be easier for the server owners at the expense of the people taking the time to update it for us all!!! Server owners should have a general clue about what needs to be done or they shouldn't even attempt to create/maintain a server. The method here is easy if you read the guide, change the renewal.h file, and recompile. That is all there is to it. All this goes back to me saying that we should either have it or not.

Peopleperson49

[Lemongrass]

And although it is so simple we have dozens of threads that hold questions about these easy steps. For me it is an easy task too, I do get your point, but it is not so easy to understand for everyone.

And what I wrote in my last post in nothing else than the standard stable branch for projects(trunk/stable+additional branches), that is nothing special or something I came up with. It is a standard way of handling such projects.

And because you said they have to test it for PRE-RE and RE, from what I can see at the changelog not everyone of the developers test their sources and/or read compiler warnings and such things. I came across a lot of "woops missed something" commits since the beginning of rAthena. I know that such things can happen, but they are becoming more frequently lately.

Anyhow it was only a suggestion and if the community and/or the development team does not like the idea, they do not have to implement it.

Best regards,

Lemongrass

[Lighta]

Warnings depends on compiler and on wich architecture. like gcc won't complain if you declare a new variable in middle of a scope {} while MSVC will complaint he want it at begining. (or more recent the ret unintialise you can check the buildbot result for that)

The forget part is not good but doesn't mean neither that the src wasn't test, well not the final release one but it was probably tested on localbranch then forget while merging for commit.

The only thing certain is that commit aren't perfectly tested before commit. Well after all it's a trunk and there no QC team so...

I do agree that split version is generally how project are handle and i'm in favor about it but your last comment just look like small flame sorry.

[Peopleperson49]

The Devs do an excellent job continually updating all the files and fixing bugs as they appear! They have other work and lives outside of rA and that is more why I started this topic. Its much easier to update, fix, and test one platform instead of two. Since I have been here I have been very impressed with the level of professionalism from everybody involved! If you have ever scripted anything Lemongrass then you know how easy it is for the smallest thing to slip by the cracks when you have a lot of other stuff to manage at the same time. Or even if you don't crap happens! I don't know how many times I have fixed a script to find something else wrong! I generally keep very detailed logs of what I fix and I have some of my more complex scripts in the version 10.?+. Devs are challenged by the fact thats hundreds of servers rely on them all the time! Cutting down on what they have to do goes a long way!

Peopleperson49