cdelorme

I didn't use nemo.herc.ws because they don't have the RE version listed in their downloads page, meaning they don't have a copy. I found two locations with a download for 2018-06-21a: https://drive.google.com/file/d/16VhFbvirHAmiQbiUde7oLE1XPcu1DSsi/view https://mega.nz/#!Zcdk2C4L!z9SkS36VGhJWAaxD9cRf1sVhgC9I6gMm0k6Cld-lYOQ I also found a link for 2018-06-20e from this discussion: After recompiling the 2018-06-21a client is working. I am checking to see how the wrong version got used, but I believe my issue is resolved. Thank you for your help. Edit: Confirmed, my mistake was in the docker-compose syntax; it provides environment variables that get passed, but only to the running container, not to a build. As a result it was using the old default in the Dockerfile that I had not updated. To correct it I had to add ARG properties and shift the parameter in the docker-compose file. Mostly adding this for self reflection.

I did search the community, and triple checked at least 3 pages worth of suggestions before posting. I think it's safe to rule out connection problems that may be the result of IP's, subnets, firewalls, etc... I did consider the subnet since I created a virtual network `172.16.24.0/28` I tried overriding `conf/subnet_rathena.conf` with these lines: subnet: 255.255.255.240:172.16.24.1:172.16.24.1 subnet: 255.0.0.0:127.0.0.1:127.0.0.1 This changed nothing. I have thoroughly tested the networking of the project. I even have an extended version that loads up two character servers and multiple map servers. I can ping the docker containers by IP from my host machine. The client was able to create an account. This means it established a persistent TCP connection, sent a packet, and the login server processed it. Every subsequent attempt also shows a log message saying the connection was successfully authenticated. I fail to see how that would occur if the IP or subnet configuration was invalid. I compiled with the 20180621 packetver, since it gets used via numerical comparison I am assuming adding the letter suffix won't help. I read that the `<version>55</version>` inside the `sclientinfo.xml` is no longer used, so that would be unrelated correct? Regarding compatible versions, where is the latest supported documented? In a September discussion someone suggested using 2018-06-21a. This discussion says 20180621 and older back in January. Another discussion in January saying it is better to use 2018-06-21. In March a discussion specifically claiming 2018-06-21a is the recommended compatible client. This discussion mentions support for the 20180621aRE client in April. Another discussion mentions 20180621a is supported in April. The documentation for zackdreaver's translation lists 20180621a as compatible. I didn't just pick 2018-06-21a for no reason, there was plenty of evidence to suggest it was compatible. However, I am happy to switch to the 2018-06-20 version if that is truly the latest compatible version.

So I decided to update an old project. The server is running fine, the map and char servers connect, the chat and login servers connect. It took a while, but I finally have a client I can launch. When I try to connect to the server the login server shows the logs: login | [Status]: Request for connection of record (ip: 172.16.24.1) login | [Notice]: Authentication accepted (account: record, id: 2000000, ip: 172.16.24.1) login | [Status]: Connection of the account 'record' accepted. login | [Info]: Closed connection from '172.16.24.1'. The client takes a moment then says "Failed to connect to server". Very clearly it connected, since it was even able to create an account when I used the `_M/_F` name format. I have no further insight as to what is going wrong. I am using the 20180621A client, configured and hexed as documented. Anyone have any clue what step(s) I am missing to get a working client/server pair?

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

There is an NPC in the towns that let's you warp between the a, b, c, etc... as well. So it can be navigated by players and not only by server settings (since the entry zones to the maps can create the same separation problem later).

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?

Cleaned up the implementation. It is now a single dockerfile, and the deployment script handles configuration. Changes to ports will require modifying the configuration files as well as deploy.sh. I could enhance but after a few days worth of constant docker blockers I've lost interest in moving this forward for the distributed model. Turns out docker is very strict about it's single-process per container model. Somehow CMD in Dockerfile works fine, but when I try using `docker exec` it zombies the processes. Three days worth of reading says nobody has managed to solve this problem sanely. So, this project is "done", at least as far as my efforts to make it work with docker. I may post again when I figure out a better way to test distributed rathena builds.

@MrDracula, glad you like it and I hope to do more too. Just finished the `full` image with 1:1 port mapping and tested locally. I have included a bare-bones `deploy.sh` in the root that should build all three images then deploy the container with the direct mapping (minus exposing the mysql database mostly due to potential port conflicts). I hope to spend time tomorrow fixing things: - update Dockerfile `CMD` to execute parameterized template on `docker create` - reduce footprint by making the initial image smaller (no build or build tools, just clone) - remove expose from Dockerfile for mysql/full and set at create time - enhancing the deployment script to interactively ask for inputs and deal with confligs The way it works currently is that configuration files are modified prior to `docker build`, which means the image created cannot be re-used (which was the original goal). I have notes about the efficiency, and while originally it was for consistency across builds, that same consistency is preventing reusability. I think I can solve it by leveraging the first step during the final images. I am pretty sure a smaller final diff is better for creating multiple instances without taking up disk space so I'd almost rather have the build tools in an image prior to each deployable component. I may toy with some ways to make this more efficient or even reduce the number of planned Dockerfiles. Setting expose in the Dockerfile may not be a great idea, since we can't ensure the external mapping and may have to adjust at least the rathena service configuration during `docker create`. I am also on the fence about exposing mysql for the full container, but if anyone feels that they want phpmyadmin access I can probably add support for mapping. Finally, I want to make the `deploy.sh` ask for inputs, and deal with things like conflicting ports preemptively. I can't say it'll be a perfect solution, but it's a step forward.

I began writing a modular docker implementation of rAthena. Here is the source Currently it only supports the initial layers, I am working on creating a finished full-image and a deployment script to run the stack. Afterwards I hope to create individual images for each component, and add logic to the deployment script that allows a distributed local deployment for testing and demonstration.

Thanks secretdataz! The description was not clear on this, ("// Can you use _M/_F to make new accounts on the server?"). Does that mean if you provide a username with `_M` or `_F` for gender as a suffix, it automatically creates the user? Just gave it a try and it did exactly as described. That's awesome, thanks again!

This may be a combination of a question and a suggestion, but I don't see an option to specify a host for the mysql server. Is this something anyone is interested in? To separate the database from the server would allow separation of concerns for a more distributed installation of rAthena. If so, I'd propose switching to a mysql connection string format if possible, as it is more interchangeable and reduces the inputs for the different storage objects currently inside `conf/inter_athena`. Derp, for some reason I glanced over and missed the `_ip` per database in the file. Thanks for pointing that out secretdataz. If multiple databases are an option I'd still be interested in replacing the separated inputs with a connection-string, since that syntax is then also compatible with other database solutions. - postgresql - mongodb This is of course assuming anyone is open to alternative DBMS solutions.

_Sorry, I'm not trying to bombard the forum, just have a few entirely separate ideas and figured it'd be easier to discuss them that way instead of in one super-post._ I was curious what the barriers are to alternative DBMS options? Is it purely maintenance, or is there significant tight-coupling with mysql? Assuming it is more modular and nobody is against adding/maintaining more DBMS modules, I'd be curious what the performance would be using mongodb or postgresql for character saves specifically.

I am wondering if anyone else might share an interest in automatic account creation on first login? Thinking for development and LAN servers where physical access and/or a network connection are the gatekeepers this might be more convenient for some than running FluxCP or executing SQL. Not sure whether it'd make more sense to code a condition with `conf/login_athena` or add it to `./configure` pre-compiled conditions, but we'd have options.

Any chance you'd be willing to let interested developers contribute? I'd like to see something like this exist, and if I can be of assistance I'd love to lend a hand.

@Qura, Thanks for the reply. I followed this guide and just realized it was mentioned as a bug for the starting map. I managed to type `@go 0` and it transported me to another area where I can properly move around. I am guessing this would be a problem for all non-GM accounts that can't use `@` commands. I will try that grf and relaunch with the secondary account and report back in a moment. I pulled the latest master and ran imports as I wrote (all files in sql-files/ first-level directory, nothing in updates/ or tools/). According to this topic it sounds like support for Doram is newer than my client, so I'm not sure if maybe the rAthena sql files simply don't yet have the items to match. The grf seems to have done the trick, and I rebuilt and loaded the item database from the txt file. This seems to have done the trick, character starting location and Doram are working. Any chance you can share where you grabbed that OldIzlude.grf from?