Kisuka

Nice nice glad to hear it got you into the scene :3

If I come across anything I'll be sure to toss it out there.

Stopping by to see what has been going on since I stopped doing RO stuff. Heard about the DMCAs on a bunch of projects and went down the rabbit hole again. So how are things going? What things are needed still in terms of matching official? Not sure if anyone will even reply to this

I'm having flashbacks to those eA days reading this. Good luck.

Thank You. I'm glad someone understands it

I never said you claimed to make yourself the script author. The problem is, is that you modified the script but are claiming it to be a 1.0 release. On top of that, you are claiming the 1.0 release as being author'd by you in the changelog. The 1.0 release of this script does not have your changes. The initial release did not come from you. The argument regarding "we have no 1.0 release in this project" is invalid, since most this project's scripts don't have an initial release here either, those releases came from eAthena. In short, you don't just change a version history log because your project doesn't have those releases. Welcome to open source development. Leave my commit history alone, add your own line. When I pull your clean ups and fixes into Hercules I intend to add a 1.0.1 line to the file with YOUR NAME. Please do me the common courtesy of leaving the initial release comment, author'd by it's original author, me, here in rAthena.

Ummm no... the changelog in a script is for that script. Yes of course there may be some difference between projects if one does not include certain changes in there own copy of a script. However, the 1.0 initial release comment has NO REASON of being changed just because you cleaned up some things and changed all item constants to IDs. I author'd the script. I did the initial release into the public domain. You have no right to modified my initial release comment in my changelog. You pulled the file into rAthena, and modified the script by cleaning up some things and replacing all item constants with IDs. This constitutes as a modification of the original release. As such, you should be adding onto the changelog, not modifying it. The changelog of a script does not automatically 'reset' because you've pulled it into a different project. That is not how this works. That's not even how open source development works. A script has it's own lifespan, it's own changes, spanning through different projects. You have no right to modify that changelog in a negative manner (deleting change history, changing authors, resetting). TL;DR You did not create the initial release into public domain. I did. Add your own line.

I posted a topic to double as a kind of a public service announcement, as I've been seeing this happen more and more lately. Changelogs in scripts are being either removed, modified, or overwritten. This should not be happening.

Euphy, why did you change my name to yours on the 1.0 entry in the changelog...? https://raw.githubusercontent.com/rathena/rathena/dd9719de62bf0a09d7527bc9d988367ca2c675ca/npc/re/instances/WolfchevLaboratory.txt Add your own line to the changelog, do not overwrite others work. If you made fixes, add a new line, as it has been done since the days of eAthena. Just because we are contributing to different projects does not mean the changelog is a different changelog (only unless changes from 1 isn't applied), especially when it's the init release comment.

Saw this coming years ago.. lol... Gravity really needs to srsly stop trying to revive the RO title by trying to create new versions of it

Tried this, but I'm getting failed retrieve when updating the KRO and RE, it seems to be the patch site is not working? Make sure you have an already somewhat updated kRO client. They changed FTP servers, the new one doesn't contain anything before 2011-07-20.

A plugin for RagnarokOnline Patcher Lite (RSU). Allows for patching multiple GRF files (kRO, RE, Custom) using just one patch client. https://github.com/kisuka/RSU-Multi-Plugin Basically this is similar to what the ragray plugin did, now you can use it for your own servers and what not Enjoy. Feel free to contribute to the repo if you want, my C / C++ sucks ^^;

Now that more and more people are voicing their opinions about branching RE, can we hear from the current core dev team members please? I'd like to hear their opinion on this matter which is currently halting the development process of RE. Please explain in more than one sentence and don't link past topics. Currently we have only heard from Lighta. At the moment, the topic is about branching RE and pre-RE into their own branches. A sub-suggestion attached to this one is moving to Git or even Github to make this process even easier for the development and participation from others. My side suggestion for the pre-RE branch: cut out any content that was added after RE. It should only contain pre-RE content (client features / packets, scripts, items, maps, etc). At that point it would only be a branch where things are bug fixed or optimized.

False, even bRO started a Pre-Re server. At this point you can't classify the international servers as 'official'. Yes they own a license to be an "official" server but they all change their scripts, and formulas, making them custom servers. The only true official server is kRO, which is what we should always be copying.

Done

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.

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.

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.

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.

Why would you even want that? Mixing the two types together causes the game to become unbalanced all to hell. Not to mention, it's much easier to add in small stuff like that with a custom diff for your own server than making a diff to remove all pre-renewal stuff.

It was a crude anti-bot method that was implemented some time ago on kRO. Around when RE was first released.

I'm not asking for complete removal. I'm asking for it to branched out of the main repo which should be developed for the current version of RO, which is renewal. Athena, historically has never followed iRO. The only aspect that is taken from iRO is the english translation of script files. All formulas, packets, heck even the client private servers use is all kRO based. Having an option for pre-renewal is fine as long as it's managed / implemented correctly :/ Having it under the same branch as renewal becomes a hassle. At a certain point the source is going to be FILLED with if else statements to see if the person has RE enabled or disabled. This makes the source nearly unbearable to read to a developer. Not to mention, give it a few more months, after Gravity has finished adding even more RE related scripts to the game, the database and scripts directory is going to be HORRIBLY messy. Basically what we're trying to do is support two different games in one emulator. This just doesn't work, it's horrible in terms of development. (I say different games because nearly all mechanics have been changed between Pre and RE, it's basically a different game than RO was). It would be much more efficient to branch pre-renewal off into it's own place and let RE be the main development project. Pre would still get bug fixes, but it should have a set cap on what client it should accept (non RE client) and only contain non-renewal aspects. Renewal should have all pre-RE stuff removed, the script directory needs to be organized (which I'm in the process of doing), and only RE clients should be accepted to connect. We're at a point in my opinion where we need to stop supporting such old content and start moving toward organizing the source and making sure it's supporting the most recent version of RO. The whole point of MMORPGs is they move forward with updates, not backwards. If RO was able to survive without RE, gavity wouldn't have implemented it to revitalize the game. There is no point in trying to support both game-types in one emulator. It's completely disorganized and is much harder to maintain a clean source. Too risky to use AEGIS

Is the captcha code thing still in the client or was it completely removed? Talking about this: // captcha code request (not implemented) // R 07e5 <?>.w <aid>.l case 0x7e5: WFIFOHEAD(fd,5); WFIFOW(fd,0) = 0x7e9; WFIFOW(fd,2) = 5; WFIFOB(fd,4) = 1; WFIFOSET(fd,5); RFIFOSKIP(fd,8); break; I can implement this if it hasn't been removed from the client. If it has we should remove the left over code.

I can grab the packets. Edit: Nevermind Looks like you've found them.

At this point Warp Portal is not keeping to the original "RO". They've pretty much become an official custom server. They grab aegis scripts from all the other official ro servers and use them to build their own up. Not to mention providing a non-renewal option is extremely against the image that Gravity is trying to push for. Athena is an RO emulator. We emulate the original RO, which is kRO. This mean iRO is not an example to lead by.