Arcenciel Posted January 13, 2013 Group: Members Topic Count: 69 Topics Per Day: 0.02 Content Count: 1315 Reputation: 372 Joined: 12/10/11 Last Seen: August 31, 2013 Share Posted January 13, 2013 Not to be a spoil sport but wasn't this already in the suggestions section and wasn't this idea already rejected? That's what I thought. This was discussed a long time ago and well obviously that didn't happen since well as we still have both up to now. 1 Link to comment Share on other sites More sharing options...
saithis Posted January 13, 2013 Group: Members Topic Count: 2 Topics Per Day: 0.00 Content Count: 40 Reputation: 20 Joined: 12/31/11 Last Seen: May 10, 2013 Share Posted January 13, 2013 Not to be a spoil sport but wasn't this already in the suggestions section and wasn't this idea already rejected? That's what I thought. This was discussed a long time ago and well obviously that didn't happen since well as we still have both up to now. Here is the old topic about removing pre-re: http://rathena.org/board/topic/74215-p-re-vs-re-do-we-really-need-both/ And yes, it was rejected. 2 Link to comment Share on other sites More sharing options...
Kisuka Posted January 13, 2013 Group: Members Topic Count: 9 Topics Per Day: 0.00 Content Count: 56 Reputation: 30 Joined: 02/22/12 Last Seen: August 8, 2020 Author Share Posted January 13, 2013 The explanation given on that topic does not make any sense. How are we ditching people's work? We'd be branching there work off into another branch. I have tons of work in eA that got ditched in rA because scripts evolve. This is a development project, work gets removed, added, and changed all the time. That's how development works. And yes, TONS of things from RE need to still be implemented. This is more of a reason to branch pre off into another branch, so we can focus more on the RE stuff and less on supporting the pre stuff. Everyone should be working toward getting RE matching kRO, we shouldn't be worrying about old content. It's gone guys, sorry, but it's the facts. RE is the current version of RO which we should be putting our major focus at. Supporting pre in the conf, databases, scripts, source (everywhere) is just a major distraction in my honest opinion. Not to mention that when implementing things down the road you'll always have to remember to have that Pre-RE check. You need to think about how the project will evolve 5 ~ 10 months from now. How much of a pain in the ass is it going to be to remove all those pre-RE checks once the RE side is matching kRO perfectly? There will be tons more work to do then, than there would be if we just get it done now. I don't understand why this is such a hard thing to do. Need to stop worrying about feature requests (pre/re support) and worry more about the foundation and cleanliness of the project as a whole. Heck look at it already... so messy... it's just going to get worse the more that we add to it. The whole point of being an emulator is making yourself work nearly identically to the official. As it appears right now, rA is not that at all; To me rA seems more like "Here's your custom server suite package, use it to mix and match pre/re and make a completely unique RO server". On another note: the argument that it becomes more work if we have two branches is completely dismissed if we also move to git. If a dev is implementing a change in the RE branch that also needs to be in the pre branch. They can push it to the RE branch and then have the Pre branch pull / merge it. Git handles all of it, no need to worry about copy-pasting code over to the other branch. It's no additional work at all. If you try to say "well what if they're working on tons of things at once and commit them all at the same time?". They shouldn't be doing this, it's bad practice. If we switch to git, they should locally be making branches for each project they work on (this takes no time at all, it's literally a one-line command in git). Once they are done with a project they merge it back into the master branch and commit / push it. Master should always be clean, no dev work should take place in it. Always branch out your work into different areas so you keep things clean for yourself as a developer. This way you also have a much more understandable commit history log. If each commit is branched out it's much easier to revert things if they break if they've been properly branched out like this. Link to comment Share on other sites More sharing options...
Arcenciel Posted January 14, 2013 Group: Members Topic Count: 69 Topics Per Day: 0.02 Content Count: 1315 Reputation: 372 Joined: 12/10/11 Last Seen: August 31, 2013 Share Posted January 14, 2013 The whole point of being an emulator is making yourself work nearly identically to the official. As it appears right now, rA is not that at all; To me rA seems more like "Here's your custom server suite package, use it to mix and match pre/re and make a completely unique RO server". Isn't that one of there reasons people play in private servers for? To have a completely unique RO experience, if people wanted the original they'd just play in the officials. iRO is free to play. No matter how much argument is made about this or how much logical sense there is to it..It's not probable that a majority of the community is going to support it. People like having options. 9 Link to comment Share on other sites More sharing options...
Relzz Posted January 14, 2013 Group: Members Topic Count: 33 Topics Per Day: 0.01 Content Count: 355 Reputation: 34 Joined: 02/09/12 Last Seen: April 14 Share Posted January 14, 2013 Leave rAthena as it is now. Link to comment Share on other sites More sharing options...
Maki Posted January 14, 2013 Group: Members Topic Count: 146 Topics Per Day: 0.03 Content Count: 1195 Reputation: 467 Joined: 11/15/11 Last Seen: April 11, 2023 Share Posted January 14, 2013 The whole point of being an emulator is making yourself work nearly identically to the official. As it appears right now, rA is not that at all; To me rA seems more like "Here's your custom server suite package, use it to mix and match pre/re and make a completely unique RO server". Isn't that one of there reasons people play in private servers for? To have a completely unique RO experience, if people wanted the original they'd just play in the officials. iRO is free to play. No matter how much argument is made about this or how much logical sense there is to it..It's not probable that a majority of the community is going to support it. People like having options. It was rejected a few(?) times previously; the one I moved was not the first of these suggestions. I personally love that people can mix and match however they choose and setup whatever style server they like; it definitely adds more options to a 10+ year old game now. Personally, I'd be against the removal of pre-renewal or even a branch split, not to mention we have more pressing issues to worry about (like Renewal ATK =p). On another note: the argument that it becomes more work if we have two branches is completely dismissed if we also move to git. If a dev is implementing a change in the RE branch that also needs to be in the pre branch. They can push it to the RE branch and then have the Pre branch pull / merge it. Git handles all of it, no need to worry about copy-pasting code over to the other branch. It's no additional work at all. This would/could be a good idea but considering the history of *athena it will never work! Branches are almost always brushed off to the side to the point that no one cares for them anymore. People would just develop Renewal and Pre-RE would rot away until it breaks compatibility and then everyone would be too lazy to fix it because it would be too much work (even if it is a simple push/pull request). 2 Link to comment Share on other sites More sharing options...
Lighta Posted January 15, 2013 Group: Members Topic Count: 16 Topics Per Day: 0.00 Content Count: 737 Reputation: 216 Joined: 11/29/11 Last Seen: December 20, 2020 Share Posted January 15, 2013 That why I said you'd need someone to handle that. (like pushing change from RE to PRE) etc... Also I pointed the last topic in my 1st post bouhou no one read me =). Making it clean is imo important for maintenance. Like you don't want to read hundread of preprocess #if. Wich will increase more and more time go on. Will make it harder for people to take it over and participate in project. (harder to search where was the correct handler..). Well you can if you will... But actually there's other project who will have better impact on project imo : - Documentations / Schema. (even if partially done it's still minimal and this may be good to review code and not have duplicate handler..) - Tests. (one thing that slow down major change is that we don't have regression test, we just try on our own commit and wait => this why we have quite significant reverts amount, 1 change break another etc... need like a QC. - Open it more. (git good for that for exemple). Many could contribuate occasonially but enter on "staff" may mean to much responsability time etc. (like right now I have no time and feel bad....). So yeah improve casual help. (danger might be we have too much mods and "pollute" repo too much... => In short probably require better guideline/milestone.). In comparaison branching would impact less I think, but all this is admin and we need more code done !! 2 Link to comment Share on other sites More sharing options...
Relzz Posted January 15, 2013 Group: Members Topic Count: 33 Topics Per Day: 0.01 Content Count: 355 Reputation: 34 Joined: 02/09/12 Last Seen: April 14 Share Posted January 15, 2013 (edited) split re and pre into different files xD like ifdef re incluide re things and that's lke r-pre-re folders.. im sleepy xD i can't think.. i don't want to see rathena switchng ability taken off Edited January 15, 2013 by Ryu Link to comment Share on other sites More sharing options...
phebs Posted January 15, 2013 Group: Members Topic Count: 11 Topics Per Day: 0.00 Content Count: 57 Reputation: 0 Joined: 09/13/12 Last Seen: November 18, 2013 Share Posted January 15, 2013 split re and pre into different files xD like ifdef re incluide re things and that's lke r-pre-re folders.. im sleepy xD i can't think.. i don't want to see rathena switchng ability taken off agreed. and then adjust the forum for renewal topics and pre renewal topics, but its good to see a final branch for pre-renewal Link to comment Share on other sites More sharing options...
Saisho Posted January 15, 2013 Group: Members Topic Count: 52 Topics Per Day: 0.01 Content Count: 185 Reputation: 20 Joined: 01/06/13 Last Seen: November 11, 2018 Share Posted January 15, 2013 LevelUP games the company who host the official Ragnarok in brazil also started a pre-renewal server and i think theres more official servers doing the same, specially because theres many players who hate renewal *raise hand* i like the updates on it but not the game mechanics. Link to comment Share on other sites More sharing options...
Relzz Posted January 16, 2013 Group: Members Topic Count: 33 Topics Per Day: 0.01 Content Count: 355 Reputation: 34 Joined: 02/09/12 Last Seen: April 14 Share Posted January 16, 2013 there are many Official "Classic" Servers =) Link to comment Share on other sites More sharing options...
Mystery Posted January 16, 2013 Group: Members Topic Count: 94 Topics Per Day: 0.02 Content Count: 2192 Reputation: 252 Joined: 11/11/11 Last Seen: June 24, 2020 Share Posted January 16, 2013 Once again, I say no. It'll be MORE of a hassle to branch off Pre-renewal than to just leave it where it is. It's not harming anyone where it is.. if you don't like pre-renewal, turn it off. If you hate renewal, turn that off. Very simple thanks to the implementation of the mechanics to do so. I'm not going to give a whole spue as to why it should stay, but instead I just went straight to the point. Link to comment Share on other sites More sharing options...
Kisuka Posted January 16, 2013 Group: Members Topic Count: 9 Topics Per Day: 0.00 Content Count: 56 Reputation: 30 Joined: 02/22/12 Last Seen: August 8, 2020 Author Share Posted January 16, 2013 Once again, I say no. It'll be MORE of a hassle to branch off Pre-renewal than to just leave it where it is. It's not harming anyone where it is.. if you don't like pre-renewal, turn it off. If you hate renewal, turn that off. Very simple thanks to the implementation of the mechanics to do so. I'm not going to give a whole spue as to why it should stay, but instead I just went straight to the point. From an end-user yes that's fine if you're never looking at the source. As someone who wants to help contribute to the source though and actively works on it for my own needs; I find it to be a complete headache. To a person who doesn't modify the source sure it's easy as pie, but to a developer this is a snowball which will become a much larger problem down the road. Link to comment Share on other sites More sharing options...
phebs Posted January 17, 2013 Group: Members Topic Count: 11 Topics Per Day: 0.00 Content Count: 57 Reputation: 0 Joined: 09/13/12 Last Seen: November 18, 2013 Share Posted January 17, 2013 so any new when you will started to remove the pre-renewal? Link to comment Share on other sites More sharing options...
saithis Posted January 17, 2013 Group: Members Topic Count: 2 Topics Per Day: 0.00 Content Count: 40 Reputation: 20 Joined: 12/31/11 Last Seen: May 10, 2013 Share Posted January 17, 2013 so any new when you will started to remove the pre-renewal? It isn't even decided if it will be removed... Link to comment Share on other sites More sharing options...
Relzz Posted January 17, 2013 Group: Members Topic Count: 33 Topics Per Day: 0.01 Content Count: 355 Reputation: 34 Joined: 02/09/12 Last Seen: April 14 Share Posted January 17, 2013 Once again, I say no. It'll be MORE of a hassle to branch off Pre-renewal than to just leave it where it is. It's not harming anyone where it is.. if you don't like pre-renewal, turn it off. If you hate renewal, turn that off. Very simple thanks to the implementation of the mechanics to do so. I'm not going to give a whole spue as to why it should stay, but instead I just went straight to the point. From an end-user yes that's fine if you're never looking at the source. As someone who wants to help contribute to the source though and actively works on it for my own needs; I find it to be a complete headache. To a person who doesn't modify the source sure it's easy as pie, but to a developer this is a snowball which will become a much larger problem down the road. use syntax highlighting programs like notepad++? you use normal notepad? ._. come on.. it's easy to understand.. Link to comment Share on other sites More sharing options...
ScriptingPhailure Posted January 18, 2013 Group: Members Topic Count: 30 Topics Per Day: 0.01 Content Count: 87 Reputation: 21 Joined: 01/13/12 Last Seen: March 15, 2014 Share Posted January 18, 2013 How about we end things with a cliche quote? "If it ain't broke, don't fix it." 2 Link to comment Share on other sites More sharing options...
Lighta Posted January 18, 2013 Group: Members Topic Count: 16 Topics Per Day: 0.00 Content Count: 737 Reputation: 216 Joined: 11/29/11 Last Seen: December 20, 2020 Share Posted January 18, 2013 Ryu is nothing about understanding or not. I have no doubt people understand it well, but that not mean it's longer to do so then a clean branch without those extra. Some of those #if have implicite relation like (struct item_data) orders declaration. Or thing like a status.val initialise on both but only used in 1 case. (yeah we could add proper #if check to make it proper but it's not the case). And if you get what I said image we doing so in a very well done handling, then you can magine as long dev continue; ifdef will increase giving a lessand less readable code. That really what he meant, nothing to do like can't understand or not... Now why readable matter ? on OpenProject like that many people contribute and if they can't read it fast they most likekly put code on a wrong place creating 2 handler for the same mean -> code complexion_> spaghetti... or just a general that long paragraph of mine make u lose more time to understand than a quite sentence. (time that you coul use to dig another bug etc..) But even if it's interesting for dev (even if that mean frequent extra merge work between both..) what really annoying imo is that people support/diff contribution etc will be impacted. Will at least require more info from support (wich branch/version if we could set it as prerequisit) and seing some say version=latest on bugreport doesn't feel to good about. (yeah you may found what was latest with date of report, but that not always their real rev...). For modules/diff well since index won't match obviously in both branch, you'll need most likely to do a version for each branch. (not that long but..) etc... 2 Link to comment Share on other sites More sharing options...
Kisuka Posted January 19, 2013 Group: Members Topic Count: 9 Topics Per Day: 0.00 Content Count: 56 Reputation: 30 Joined: 02/22/12 Last Seen: August 8, 2020 Author Share Posted January 19, 2013 Well said Lighta. For the last part though, I honestly don't think it will be that much more work if we also switch to git as well :/ merging in git is so simple. Also if we're on github they have their own bug tracking system which is much more understandable to a developer. I know I'm kinda pushing for two things here but honestly this is one of the best ways we could help expand the project even more :/ Github has been proven to take open source projects to another level and cause their development participation to shoot through the roof. For an example of a emulator on Github and with proper branching instead of if statements to enable / disable newer features cluttering up the code. Check out MaNGOS: https://github.com/mangos/server The goal of an emulator is to always be emulating the most recent version of the official. Honestly we aren't even using SVN correctly. There should have been a tag created for before development on renewal even began. That would have been the "pre-renewal" branch. Historically athena has never used version control correctly :/ though not many do anyways. 1 Link to comment Share on other sites More sharing options...
Flaid Posted January 19, 2013 Group: Members Topic Count: 20 Topics Per Day: 0.00 Content Count: 398 Reputation: 140 Joined: 01/04/12 Last Seen: February 19, 2022 Share Posted January 19, 2013 I really don't see why we should drop pre-renewal... It's runing stable and doesn't need much work anymore anyways. I don't see why you people have a problem with it, you can change it on or off to your needs. 2 Link to comment Share on other sites More sharing options...
Kisuka Posted January 19, 2013 Group: Members Topic Count: 9 Topics Per Day: 0.00 Content Count: 56 Reputation: 30 Joined: 02/22/12 Last Seen: August 8, 2020 Author Share Posted January 19, 2013 I really don't see why we should drop pre-renewal... It's runing stable and doesn't need much work anymore anyways. I don't see why you people have a problem with it, you can change it on or off to your needs. It's not a matter of if we like or not. Nor is it a matter of if we want on our servers or not. We're talking about this as purely a development aspect. It's a fact that a few months down the road the source is going to become even more ugly with the further addition of RE stuff but wanting to keep pre available as an option. This discussion is more about branching pre out of the working branch (development) of rAthena. The rAthena source needs to be clean and understandable to everyone as it's an open source project. All the pre/re checks makes it cluttersome. 1 Link to comment Share on other sites More sharing options...
AnnieRuru Posted January 19, 2013 Group: Members Topic Count: 18 Topics Per Day: 0.00 Content Count: 2044 Reputation: 682 Joined: 10/09/12 Last Seen: December 20, 2020 Share Posted January 19, 2013 as the discussion turns out I have to agree with Lighta and Kisuka now rather than placing #ifdef RENEWAL all over the place its better to create a fork using github @Kisuka change the topic title into -> branch pre-renewal using github something like that or people keep misunderstanding =/ Link to comment Share on other sites More sharing options...
icabit Posted January 20, 2013 Group: Members Topic Count: 28 Topics Per Day: 0.01 Content Count: 353 Reputation: 70 Joined: 07/14/12 Last Seen: February 12, 2023 Share Posted January 20, 2013 Once again, I say no. It'll be MORE of a hassle to branch off Pre-renewal than to just leave it where it is. It's not harming anyone where it is.. if you don't like pre-renewal, turn it off. If you hate renewal, turn that off. Very simple thanks to the implementation of the mechanics to do so. I'm not going to give a whole spue as to why it should stay, but instead I just went straight to the point. i still agree with this 3 Link to comment Share on other sites More sharing options...
Kisuka Posted January 20, 2013 Group: Members Topic Count: 9 Topics Per Day: 0.00 Content Count: 56 Reputation: 30 Joined: 02/22/12 Last Seen: August 8, 2020 Author Share Posted January 20, 2013 as the discussion turns out I have to agree with Lighta and Kisuka now rather than placing #ifdef RENEWAL all over the place its better to create a fork using github @Kisuka change the topic title into -> branch pre-renewal using github something like that or people keep misunderstanding =/ Done 1 Link to comment Share on other sites More sharing options...
Stolao Posted January 20, 2013 Group: Developer Topic Count: 48 Topics Per Day: 0.01 Content Count: 1443 Reputation: 337 Joined: 10/17/12 Last Seen: April 17 Share Posted January 20, 2013 So im still for removing/branching pre. Link to comment Share on other sites More sharing options...
Recommended Posts