[Future of rA] rAthena C++ Migration

[Jezu]

We discussed this with @Stolao about C++ and yes, its happening!  

[Darknessfmy]

 

I completely support this project. I'll probably send in donations to Secret every now and then.

 

If you are going to donate, donate to rA instead. I'd like some money for some coffee, but this project is solely for the community.

Better Get to implement what is missing, we are in 2016 (starting 2017) and has content emulator 2012 and part of 2013 ... The time you will spend in c ++ perfectly Might dedicate to improve what exists. You know perfectly well I'm right.

 

Why fill the void with these things?

 

This project needs much attention in the void to fill missing and you think about changing everything from scratch again? You need to focus and find a direction.

 

I write with great respect for you and the work of all.

 

I would love to have the knowledge and studies all have to improve this project, unfortunately I specialize in managing and directing no programming.

Thank you for your feedback. You might be afraid that 100% of time available by our team will be dedicated to this project, but, no, we still improve our current emulator (rA) with current information we have. As for the void you mentioned, I'd like to fill those where I can, too. However, it was mostly caused by no official server files being leaked since a year or two years ago. New features were datamined from official servers, and it takes longer time than converting stuffs directly from official server files.

 

@Secrets thank you for you answer now understand more.

[Fratini]

It's a very nice improvement. I'll try to do whattever I can by helping track glitches, bugs, etc.

 

About the Current Emulator: Is there anything that needs to be tested?

How about a list to what it's necessary to test? I just downloaded the Current emulator and it's ready to be tested in a offline mode. I just need a direction =)

 

Thank you guys for the awesome work!!!!

I'll someday be helpful to this beautiful community!!

 

41 20 73 74 65 70 20 66 6f 77 61 72 64 20 74 6f 20 70 72 6f 67 72 65 73 73

Edited November 8, 2016 by Fratini

[Everade]

At first glance it might look great.
And i understand that you as the devs have rather good points on why you would switch to C++.

C++ is very powerful afterall.

But you're missing something out. Or well, you're not missing it out, you're just "naive" or blind enough to think that it's going to work out well.
The community.

Don't take this lightly, i have seen more than enough projects falling apart because of such specific events.

I would never dare to get my feet together and rewrite all the mods (2 projects) in C++
Or let's rephrase this:
I can't, lol. But i understand, that's not your problem.
I'm just trying to point out that i'm for sure not the only one.

At this point i would either move to hercules or wait for the next xAthena to show up and continue what has been done the past >10 years.
(Because that's what usualy happens... It splits the community even further)


And i repeat: I understand your situation... absolutely.
In the end, the devs are doing all the work, so it's just fine that you're molding your future with process optimisations.

It's just going to mess up a lot of rAthena servers. Because it increases the workload by tremendous bounds, for the community and the devs.
You won't be able to keep up with updates (rAthena is already years behind) even though you might tell us now that future updates are going to be faster. The problem is just that there's a huge ass gap inbetween now and the time you manage to start on updates. On top of that, it won't speed up the process by months, so it's not like it's the holy grail.

Because there might be a 4 year gap before we reach rAthena's current standpoint (almost stable environment and < 1000 bugs)
Not even talking about re-reporting bugs you will re-create and absolutely new bugs falling at us like shooting stars.

So my bet would be that >60% will move to hercules before you even manage to finish it.
We're not getting younger guys.

 

But it's funny to see Sirius_Black back in a list.
I remember about 8 years back from now, rumors were going around that he managed to recode entire eAthena to a much powerful version.
It was praised as the holy grail. Yet we've never seen any proof. Unless that we knew that Black is an old german genius.
Now we finally get to see something out of it ?!

Edited December 19, 2016 by Everade

[Aleos]

C++ is a very powerful language as you stated. It also is very similar to the C language with many more features and optimizations on the original language. With this mind it would be very simple to convert your mods. I don't see why switching to a different emulator would benefit from this. You'd have to make all your changes anyways in the new emulator, let alone the fact this branch would support true C++ Plugins. I also don't think any of the devs are blind or ill-willed towards the community at all. If we were, would we be in these positions? We donate hundreds/thousands of our hours for free to better the community.

The point of this branch is so we can get out of this hole *Athena has dug itself into over the greater side of a decade and finally make things right for the emulator. Sure it will take time to fully migrate the entire emulator to C++ but that's already been stated by Secret that this will be a gradual process of refactoring the source. Keep in mind C++ is a great language (as stated before) to use for a MMO engine and provides many advancements in memory optimization and features that we can't achieve in C as easily. I've been writing the Achievement System and I can't tell you how many times I've wanted to bang my head against the desk because of how dirty the implementation has to be with our current setup. If we were using C++ I could have easily created a simple class and threw everything together very quickly.

As for RO updates. That's a separate matter. Of course updates won't "speed up" because we are using C++ for some features. This is because of the lack of kRO leaks in the recent years. Sure there have been leaks from other official servers but they can't always be taken as 100% credible sources since we aren't sure what was modified for that server. This means that all of the recent updates we've been implementing has been the hard work of devs getting on official servers and playing again to gather the resources needed to complete the feature.

[Secrets]

30 minutes ago, Jman said:

Coincidentally eAthena almost fell apart because they decided back then to try and re-write in C++. Lost a bunch of good developers and years of work.

 

I could see your concern, but this time things are different. Converting codes to C++ isn't the highest priority work. In fact, we still do most of updates on our current C codebase.

Login, char, inter and perhaps in the future, map server will be rewritten from ground up instead of reusing 200x tech that *Athena used.

[Banana-Boy]

Awesome! The past is the past don't let it hold us back.
Move forward and don't look back. GO GO new emu

[mirabell]

i think C++ is a nice idea if rathena was more of a sharing community. The way it is right now i think the Devs are overwhelmed and going C++ would tear community a bit more. I think the community need to be a little bit more open to sharing and helping the devs before this can even begin to work.

Edited April 9, 2017 by mirabell

[meko9586]

When code is tightly coupled, changing a line in some place is easily break the code in many places. Sometimes, it even doesn't cause compile errors and it will be very difficult to trace.

The point of making the current code base to object oriented code is to resolve tight coupling into loose coupling. Hence, the code will be easier to be maintained and extended.

Unit testing and integration testing are must for achieving continuous deployment in the future.

In order to write code that is loosely coupled and maintain re-usability, it is better to follow the SOLID principle and use dependency injection container to assist.

Edited May 6, 2017 by meko9586

[Ninja]

Do you guys have a plan for the milestones which contains which stuff should be prioritized to be converted to c++? (e.g. Milestone 1: Development Ready, Milestone 2: Modification ready) I had a long hiatus to learn stuff in dev-ing (though mostly on testing) and now I'm back, I want to find a way to be able to contribute.

 

@meko9586 This is actually one point of interest that I'm looking forward to.

Edited May 10, 2017 by Ninja

[Secrets]

12 hours ago, Ninja said:

Do you guys have a plan for the milestones which contains which stuff should be prioritized to be converted to c++? (e.g. Milestone 1: Development Ready, Milestone 2: Modification ready) I had a long hiatus to learn stuff in dev-ing (though mostly on testing) and now I'm back, I want to find a way to be able to contribute.

Currently the common project supports adding C++ source files.

Though a C facade is required for it to be used in other C source files.

[Kisuka]

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

Good luck.

[Lighta]

I like the idea

I heard someone ask what major issue was remaining. Well I would say we need a test framework.

As even if I have confidence in the dev. The most time consuming thing was :
1) Understand / reproduce the issues. (but github look way better now =) )
2) Implement that feature with limited tool of C / current spagetthi.
3) Test and hope for no side effect. <= Here is the main bug creator. side effect.
So if any one would help I would say try the branch and maybe let work on some kind of test framework.

NB : About Rust and GO, if we ever go there I think the simpliest way would be to create some dll about our current implementation. Use it into a Go/Rust wrapper. then transform bit by bit the dll to the new langage. But honestly Go is much slower but yeah Rust look miamy  but right now switching to c++ is the "simpliest" way to go.

[Lemongrass]

@Lighta
I think best way for the test framework would be to write a test by using the plugin system once we have it.
That way you could hook onto each function and check the returned/modified values and if they match what we expect or expected in the past.

[cdelorme]

On 10/9/2017 at 7:13 AM, Lighta said:

I like the idea

I heard someone ask what major issue was remaining. Well I would say we need a test framework.

As even if I have confidence in the dev. The most time consuming thing was :
1) Understand / reproduce the issues. (but github look way better now =) )
2) Implement that feature with limited tool of C / current spagetthi.
3) Test and hope for no side effect. <= Here is the main bug creator. side effect.
So if any one would help I would say try the branch and maybe let work on some kind of test framework.

NB : About Rust and GO, if we ever go there I think the simpliest way would be to create some dll about our current implementation. Use it into a Go/Rust wrapper. then transform bit by bit the dll to the new langage. But honestly Go is much slower but yeah Rust look miamy  but right now switching to c++ is the "simpliest" way to go.

I actually wrote a POC login server in golang that worked quite a bit faster than the C login server, although I suppose it's apples and oranges depending on what you are benchmarking.

I'd be happy to help test the new code, but I'm a linux user so until it reaches a linux-ready state I don't know if I want to stick my hands in (and loose fingers).

During this rewrite will support for really old (eg. circa 2004) clients or complex irregular/unused features be dropped, or is the aim for 100% feature parity?

[Lighta]

100% parity is the main goal. Altough few cleanup of really old / unused feature might be done. It is not our goal but if it take more time to convert / ensure an unused feature then to nicely drop it why would we not ? (at best we could #ifdef _cplusplus it).
For the linux part, is all done. There was only a small moment where the cmake/makefile/src wasn't fully compatible with linux (e.g like 1 commit using invalide include or thing thing of that kind). We always supported linux and always be.

I'd love to see your benchmark test. If you want you could try against : https://github.com/lighta/rathena/tree/refactor/rA-cpp-bleeding-edge
User, Please there is lot a talk about the migration on discord and that link is in no way a beta or anything. It's just a mere test.

[cdelorme]

On 10/26/2017 at 8:01 AM, Lighta said:

100% parity is the main goal. Altough few cleanup of really old / unused feature might be done. It is not our goal but if it take more time to convert / ensure an unused feature then to nicely drop it why would we not ? (at best we could #ifdef _cplusplus it).
For the linux part, is all done. There was only a small moment where the cmake/makefile/src wasn't fully compatible with linux (e.g like 1 commit using invalide include or thing thing of that kind). We always supported linux and always be.

I'd love to see your benchmark test. If you want you could try against : https://github.com/lighta/rathena/tree/refactor/rA-cpp-bleeding-edge
User, Please there is lot a talk about the migration on discord and that link is in no way a beta or anything. It's just a mere test.

I sent you an invite to the repo, it's not something I'm ready to show to the world.  The code I wrote is far from complete and I haven't really had a chance to continue working on it for many months.

The integration tests can be run against rathena still, I just gave that a shot against the latest stable (not the cpp branch) and no changes in performance.  I am compiling your bleeding edge branch now to give it a try.

I only wrote the bare minimum functionality into the login server to get it to work with a single client, so it does not have feature parity to the current.  However, I doubt the extra conditional statements in the C code are making the difference, but rather the lack of prepared statements and indexes on the database are where rathena is failing in performance when it comes to key operations (eg. account creation and login requests).

In that sense, the language used should make little if any difference in terms of important metrics or performance, hence why I prefer go over C for its faster compilation and significantly better tooling.  Also, if you want a more fair comparison of raw languages then [the benchmark game](https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=gpp) shows comparable performance for many complex operations.

 

Thank you for confirming linux support, I'll be sure to try the cpp branch soon and contribute where able.

 

**Edit**: I ran against your project lighta and it had the same scores as rathena, but your code compiled much faster which was really cool:

$ go test -v -run=X -bench=.
BenchmarkMain/Create-8         	    2000	    637379 ns/op
BenchmarkMain/Access-8         	    3000	    406756 ns/op
--- BENCH: BenchmarkMain
	benchmarks_test.go:12: Testing Account Name pxpvehko63d6w Against Login Server 127.0.0.1:6900
	benchmarks_test.go:15: 3 parallel creators failed 0 times
	benchmarks_test.go:20: 3 parallel accessors failed 0 times
PASS
ok  	github.com/cdelorme/gro/integration	2.604s

The code I wrote only outperformed rathena once I added prepared statements, but testing on the same box is blocked by the network cap I believe:

$ go test -v -run=X -bench=.
BenchmarkMain/Create-8             10000            206749 ns/op
BenchmarkMain/Access-8             10000            187941 ns/op
--- BENCH: BenchmarkMain
        benchmarks_test.go:12: Testing Account Name uhtjghgnrok1 Against Login Server 127.0.0.1:6900
        benchmarks_test.go:15: 3 parallel creators failed 0 times
        benchmarks_test.go:20: 3 parallel accessors failed 0 times
PASS
ok      github.com/cdelorme/gro/integration     3.996s

Unfortunately I can't get the `refactor/rA-cpp` branch to compile with `make server`:

$ make server
make[1]: Entering directory '/home/cdelorme/git/ragnarok/rathena-cpp/src/login'
ls: cannot access '*.c': No such file or directory
make[2]: Entering directory '/home/cdelorme/git/ragnarok/rathena-cpp/src/common'
make[2]: *** No rule to make target 'obj/core.o', needed by 'common'.  Stop.
make[2]: Leaving directory '/home/cdelorme/git/ragnarok/rathena-cpp/src/common'
Makefile:79: recipe for target '../common/obj/common.a' failed
make[1]: *** [../common/obj/common.a] Error 2
make[1]: Leaving directory '/home/cdelorme/git/ragnarok/rathena-cpp/src/login'
Makefile:34: recipe for target 'login' failed
make: *** [login] Error 2

 

Edited October 28, 2017 by cdelorme

[E_E]

Hello, I would like to share my code for a C++  Athena-like server I started to develop some time ago. It's a rewrite from scratch retaining Athena's interfaces (like internal network protocol, etc.) Basically all skeleton functionality is ready except the game mechanics itself: account, character and zone servers accept client up to login to the map, SQL database is abstracted, 99% of all network code is ready. I am not actively developing it now and I don't know if it is of any interest to anyone, but I suspect that at least it's code can be reused in other projects. I published it here: https://github.com/elelel/ares

[Lighta]

That a nice base thank you for sharing.
I love the asio part already.

[Vietlubu]

This project already drop?

[anacondaq]

12 hours ago, choidk said:

This project already drop?

No, it's not. They already switched from c to cpp at least with extensions, and very small primitive constructions. *Athena code is a big mess of many very bad, very complex, very hard to understand, trace, and read the code. So the process of switching to use CPP features will take years (like I said more than 1 year ago). rAthena needs more powerful developers and contributors (just my vision) for finishing a lot of things much faster. They physically do their best with the code, but this is to be clear is not enough... A lot of problems as I see comes from supporting legacy things and current user-base. If they will drop user-base support (community / administrators) on the same day will be created a new emulator where users will not be dropped and rAthena will die in months. So, as you see, this is very hard and responsible work, and current devs to be clear, working really hard. 

Edited February 22, 2018 by Anacondaqq

[Ninja]

On 05/11/2016 at 9:15 AM, Secrets said:

If you are going to donate, donate to rA instead. I'd like some money for some coffee, but this project is solely for the community.

Thank you for your feedback. You might be afraid that 100% of time available by our team will be dedicated to this project, but, no, we still improve our current emulator (rA) with current information we have. As for the void you mentioned, I'd like to fill those where I can, too. However, it was mostly caused by no official server files being leaked since a year or two years ago. New features were datamined from official servers, and it takes longer time than converting stuffs directly from official server files.

If I may suggest, maybe you can also "open" the task list, if it exists, even just the minor to medium ones to the public and let them contribute? I know issues are there to get worked on but how about features and all that? That way you can offload/streamline some of the minor stuff to other people who wants to contribute. This is my 2 cents.