Gurgarath

I am super stoked by this discovery. Good job guys. You all deserve the utmost respect for finding this gem! I have spent countless night with many others fighting link rot, archiving screenshots & articles about it and never found anything remotely interesting. Now, may we lay hands on the original private beta Korean materials that predates this client, if it is not definitely lost.

Hello, Yes it is, and it can make sense in specific scenarios. It is not a silver bullet, it will not make your client magically faster (it may even be a bit harder to run on lower-end computers), but it is a nice update to have. Back in the days it would have been way harder (and it was), as we had nothing to move forward and just ourselves, internet and die-and-retry. Now with the amount of libs that has been shared or replaced, you can "easily" have them in x64 and update, it is way easier. You can check Distraught's shared sources which already has a 64 bit client, which is a base you can build upon.

Hello! Excellent project, good luck on that! My two cents on this, I think, can be summed by what Exynox said: It is excellent either if you want to keep your own server, start a new field, an university / hobby project or the likes of QuantumCore for the OG's in the back. But for the end user, it might be an absolute pain, and I mean this also if we end up with newer sources in our hands. I personally work on sources I have been meticulously stripping and updating since 2014. To the point that in 2022 I was already unable to provide systems working on other sources. Currently, my server is in Rust and my client is not having a single piece of their old EterX DX8 code. Which makes it really good for me and my own usage, but really bad for anyone else or even just me trying to sell or share systems that would work "as-is". All the resources exists for the 2014 sources, which makes it already extremely hard to maintain all the existing branches, some people already do not give support for Ava or N2 sources, some systems have a Marty version, some other have an Owsap version. The end user basically will not bother trying something that changes everything from the ground up because at the very first bump in the road, it will be them and only them and their knowledge. We even, to this day, have people asking for help on 2010 tutorials that are now outdated with the .txt protos and the knowledge base of pre-2013 wasn't even fully ported to the 2014 sources for the beginners. This is for the same reasons that most "advanced" users out there still recommend Marty's or TMP4 sources (or Owsap with support), because the potential of having something go south without any resources is lower than with other (leaked or sold by less advanced users) sources. However, this is an interesting project to take upon!

Hello, Thank you for your release. Please note that you can directly sanitize inputs inside your C++ function by using the EscapeString function, so that all queries are sanitized as best as it can regardless.

Actually a good QoL, great job!

Your device is getting reset by the resize and you do not properly recreate your render targets, shaders and all of that. You must. Everything created outside of a MANAGED pool must be recreated in the restore device function

Great work! This is what this forum and this game aspires to, to be modernized and make use of modern build systems and libraries to ditch most of the homemade and error-prone utils, parsers or methods that are also especially hard to maintain for newcomers (most of the help requests about porting to x64 server I received was about ProtoReader, go figure). Way to go. Well done!

I like the idea, I have made my own world editor back then for similar reasons, mostly because I needed granularity on specific things that was specific to my project and that I could not achieve without sources. Even though it set me back from Marty's in many aspects at first. As for the release, I think that the community is mostly looking for sources rather than alternatives. If it is really much better than Marty's, a standalone can be good, but other than that, I think it will just somewhat fragment usages and people will end up with either (or only one).

Yes, I was at the M2Dev Conference along with @ VegaS™. I have no idea where Marty and Owsap can be, I do not recall talking with them or ever seeing them. So is VegaS. All the allegations are unfounded. I would however still DM @ Amun just to be sure. #MartyIsFree #OwsapIsFree

Facts, VMWare also have such capacities and I use them (I actually most of the time compile my client on a VM and the rest on my native OS) as well and it comes in clutch to easily move files or even sync them without having to go lengths and set-up a RSync. I would also rejoin with Takuma on what he said, which is locking yourself into a specific environment, unless you ONLY work on Windows for the testing and dev and then push into your active FreeBSD compile machine and or server and keep that discipline (or use a script, some sync, git and some CI/CD or anything msnas said). It can be boring, but most of the workflow on Metin2 is pure ass and you usually just end up into what works for you and it might be way different than what the other guy would use. Please note that the Windows server has actually a few small issues with signal handlers (I shared something for that so it should be fine, or just set-up boost::signal) and with random algorithms, so take that into account when developing. If you fix that (which is not that hard to be fair, just add proper C++11 random into libthecore) you can have a fairly solid Windows Server and actually run remotely your server on a Windows server itself and avoid having to deal with FreeBSD at once, but I would also not recommend that considering how powerful FreeBSD is, but it's a boost in convenience if that is your thing. You can find documentation on Windows on the forum, it's not that hard, compile the .sln (or best, set up a CMake) and just host a local database using Xamp, Wamp or anything and you are good to go. If you want to move on Linux, the network stack should be changed, but now it is released, so you will be fine with that as well.

Hello, People just got used to it, with modern IDE, you can easily set-up CMake and compile from within your VM, or use Rsync for that matter. I assume this is what most people do. I personally have my server on Linux, which makes it way easier for WSL2 on Windows and simply for my native desktop to work, on the server only, as the client is by default really hard to cross compile. You can also very much run a Windows server (Metin2 server has Windows support so you can run it easily on your desktop rather than in a VM) and it will make your daily use easier. Having to boot your VM just to push the changes you made locally on your Windows server. I would advise you to first look into CMake (or Meson if that's your thing) and set-up a modern IDE. This will already limit the fragmentation and wasted CPU / Ram that the VM overhead is costing you.

Hello, my shaders' processing loop is in RenderGame() right after "m_pyBackground.RenderAfterLensFlare();" and they do not apply on the UI.

Hello, you can run a Metin2 server on Linux but you will be more on your own than on FreeBSD if things go south, so I would say it is based on your skills and confidence. As for the sources, either go with renowned sellers or go with TMP4 (free and good). The aforementioned topic is based out of them. Most sources and files include a working client with them. Minimum requirement depends on your needs, but any 15$ dedicated server would do enough for most people and modest servers. As for tutorials, it is pretty much scattered here and there on the platform, but it is usually streamlined.

Great work, I would say I am unsure about that one, on the one hand it is probably the most powerful way to handle this and fairly fail-safe, but on the other hand it is some boilerplate code and it feels like reinventing the wheel. I would prefer the original way for really "basic" items but as soon as we need to go the extra mile and really provide specific items and modify it on the fly, this take the edge fairly quickly. I also like the fact that it can be easily extended (like allow random rare attr on the json would simply mean a token and a few lines of c++) AND that this can be reused for other parts. I really feel like it can be a powerful way to give "uniform" items in the case of events for example, or even battle-pass and whatnot. Great release and great use of lovely forgotten code!

Regardless, pass the include holding the signals, like signal.h for instance from libthecore or whatever you use. This is clearly looking for an include, pass it to the file.