Error 403 on this link/page.
Hello, I didn‘t see problems on my side actually, you can send me your external Ip Adress for further analysis via an private message.
Thanks and kind regards Krotti
EN/EU Customer Support -
US Customer SupportError 403 on this link/page.
Hello, I didn‘t see problems on my side actually, you can send me your external Ip Adress for further analysis via an private message.
Thanks and kind regards Krotti
Display Moreyou can call yourself adolf hitler if you want , ill allow it . you can use a picture of isis for all we care but there had better not be a skew number in it .
there is nothing wrong with 32 bit . it built the intranet . it ran just fine and still does .
your machine may need to be downgraded ... lol .
the subject is game crashing , mine does not . disconnects and crashes are not the same thing .
access violation the memory instructions cannot be read ? = disco .
a crash writes a log . post em if ya got em .
the latest update is still new content no matter what files they used to create it .
Display MoreAs for RoM crashes: They occur due to memory issues that occur due to the extremely outdated 32bit architecture. They will never be fixed as that would require a complete rewrite of the entire client.
Hello,
Thank you for your reply! I keep hearing about updating the game build to 64bit architecture, instead of 32bit architecture, is a meaning of completely rewriting the client and is a very complex procedure.
As of my research and knowledge, this is not a generally valid statement. The action of switching a software project from a 32bit to a 64bit (and vice-versa) architecture is a matter of few minutes/hours. You just have to specify the compiler/interpreter in which architecture you want to build the project. BUT, even if the compilter/interpreter managed to create a build, that doesn't mean the game will work fine.
This architecture switch can cause alot of problems. You have to check what 3rd party libraries you used, what variables you used (certain variables allocate more memory at 64bit). In short, you have to test alot, after such modification, as switching to a 64bit, but I think you don't have to rewrite the client
Also, regarding my previous post, I wanted to mention that, personally, I'm not even sure if the fact that the client is built on a 32bit architecture is the real reason behind the game crashing.
Diogenes said in a previous post: "Runes of Magic is still running of a 32bit client and having issues with memory leak.". And regarding this quote, I'm still waiting for further explanation, because 32bit software should still run properly on Windows 10/11. I don't understand why would you blame the 32bit architecture of a software, for having game crashes
* you can find an explanaition here: Serverwartung 21.11 it's german but i guess google translate will do the job
"Runes of Magic is still running of a 32bit client and having issues with memory leak.". And regarding this quote, I'm still waiting for further explanation, because 32bit software should still run properly on Windows 10/11. I don't understand why would you blame the 32bit architecture of a software, for having game crashes
This is not difficult to answer.
If you have a 32-bit application, you can address only 2 Gigabytes of memory by default. In theory, you could opt into getting access to 4 GB, see the documentation: Memory Limits for Windows and Windows Server Releases - Win32 apps | Microsoft Learn
However, since I have never seen RoM use more than 3 GB of RAM, I doubt it takes advantage of this option.
Anyways, if you continuously generate garbage memory usage and don't clean it up, there will be a point when you cannot acquire more virtual memory from the operating system, let alone deal with memory addresses that don't fit into 32 bit pointers. Most programs just crash if they reach this point, because it is viewed as a non recoverable error.
Now, if you compile for a 64 bit architecture, you can address 128 TB of memory in Windows and the situation of a crash is delayed to a much much later point in time, because you can leak way more memory until the all the available amount of memory is used (practically it will be the size of your RAM + swap file size minus lost gaps due to memory fragmentation, which is usually smaller than 128 TB)*.
Now the crash happens after a week of running RoM or perhaps not until a full year has passed (who will do that in practice?).
Thus, being restricted to the 32 bit memory addresses may not be the root cause, but upgrading to 64 bit makes the painful symptom of crashes due to memory leaks go away in practice.
*Assumption: parts of the program don't explicitly or implicitly depend on the memory limit and, because of this, don't have to be adapted a bit first
* you can find an explanaition here: Serverwartung 21.11 it's german but i guess google translate will do the job
I translated the post, and I loved to see that it confirms (and more than that, it completes) my previous post about 32bit/64bit compilation.
Display More"Runes of Magic is still running of a 32bit client and having issues with memory leak.". And regarding this quote, I'm still waiting for further explanation, because 32bit software should still run properly on Windows 10/11. I don't understand why would you blame the 32bit architecture of a software, for having game crashes
This is not difficult to answer.
If you have a 32-bit application, you can address only 2 Gigabytes of memory by default. In theory, you could opt into getting access to 4 GB, see the documentation: Memory Limits for Windows and Windows Server Releases - Win32 apps | Microsoft Learn
However, since I have never seen RoM use more than 3 GB of RAM, I doubt it takes advantage of this option.
Anyways, if you continuously generate garbage memory usage and don't clean it up, there will be a point when you cannot acquire more virtual memory from the operating system, let alone deal with memory addresses that don't fit into 32 bit pointers. Most programs just crash if they reach this point, because it is viewed as a non recoverable error.
Now, if you compile for a 64 bit architecture, you can address 128 TB of memory in Windows and the situation of a crash is delayed to a much much later point in time, because you can leak way more memory until the all the available amount of memory is used (practically it will be the size of your RAM + swap file size minus lost gaps due to memory fragmentation, which is usually smaller than 128 TB)*.
Now the crash happens after a week of running RoM or perhaps not until a full year has passed (who will do that in practice?).
Thus, being restricted to the 32 bit memory addresses may not be the root cause, but upgrading to 64 bit makes the painful symptom of crashes due to memory leaks go away in practice.
*Assumption: parts of the program don't explicitly or implicitly depend on the memory limit and, because of this, don't have to be adapted a bit first
This is a great explanation! From your shared article, I understand that a Windows 64bit OS can increase the max limit of allocated memory of a process to 4GB (by setting the IMAGE_FILE_LARGE_ADDRESS_AWARE flag). And, as I understand, you supposed that RoM does not take advantage of all these 4GB, since it crashes before reaching 3GB of the allocated memory
Also, it makes sense what you said about the connection between 32bit client and the game crashing: the limitation of 2GB/3GB/4GB given by the 2^32 possible memory adressing makes the client reach the max allocated memory (due to memory leaks) faster, than if it was built on 64bit.
I'd have a brief conclusion to this: there are only 2 options, in regard of fixing this problem:
1. Developers can try building the client on 64bit, but the biggest headache, in my oppinion, are the 3rd party libraries which can lack 64bit support, considering there's a 16 yrs old game.
2. Developers can try analyzing the source code and observe where the memory leaks come from. A common and very visible case where memory leak occur is at transporting to another zone (personally, I get most of the crashes because of it)
Thank you for your answers!
as pyr in my linked post says: out of memory errrors aren't the problem here (at least not the main problem)
a 64 bit client with updated libraries will crash almost as often as our current version.
out of memory errrors aren't the problem here (at least not the main problem)
this isn't a conclusion, I can make from the linked post:
Pyrr lists several issues which can lead to crashes, however it isn't clear how often they occur compared to out of memory errors.
Neither did Pyrr state a distribution of crash causes nor can I as a player observe the reason for a crash.
As a consequence, with the given information, it's hardly possible to state that it is (not) the main problem
Also- people who run the game in Linux say they don't crash.
I'd say they're lying.
When I ran a full-blown PC, I used Linux with Windows inside a VirtualBox for those specific apps that had no real Linux alternative back then.
I used WINE/PlayOnLinux/Bottles to run RoM and it would eventually build to a crash, just as Windows did.
As of my research and knowledge, this is not a generally valid statement. The action of switching a software project from a 32bit to a 64bit (and vice-versa) architecture is a matter of few minutes/hours. You just have to specify the compiler/interpreter in which architecture you want to build the project. BUT, even if the compilter/interpreter managed to create a build, that doesn't mean the game will work fine.
I have no in-depth knowledge of the source code and compiler myself, however I can say this with absolute certainty:
I've first played RoM during the last week of its open beta in 2009 before it was released. March 11 to be precise, it was my first MMORPG and I've grown incredibly attached to it. So much so that I stayed with it until the summer of 2012 when ArenaNet released a new game at the time. I've seen the infamous crits myself, I was there when Chapter 3 was first released with Dalanis. I've been through the Hall of Survivors that too caused a great many crashes.
I've also dipped into the private server community ever since I first picked it up because I found the way MMORPGs work very interesting. I've seen servers for th is game, for Aion and others and also used them. Although in the case of Aion, only as an emulator because the official server files were never made public.
However, a 64bit version of RoM does exist. That wasn't the first time there was access to RoM's server files. I've seen and used them before 6.5.2 and after. I've spent a great many years trying to find this stuff because I could see the game's overall downfall way back in 2014 and witnessed too many MMOs shutting down for good to risk losing yet another one. Tera was the most recent game. The 64bit version I got to try led me to experience an entire 14 days with 8 hours of constant playing without a single client crash at all. Obviously this might be different on a server with thousands of players on it.
Gameforge is aware of the existence too and that is exactly why certain terms are on the censored words list here. I've openly talked about this matter with a few moderators as well and never denied what I gained experience with. The nature of this is also why I'm not divulging any more details. It is a very sensitive matter and many people at GF don't like it for good reason. But its existence can't be denied.
Instead of combatting it, IMO it would be better if GF officially acknowledged it and made attempts to purchase the RoM IP entirely and acquired the files for themselves so that the game could exist officially in a polished, modern version and with some more edits regain a bit of its former fame.
the problem with those version is simple: those who made them had no legal right to do so and if GF would buy something like that, RW will most likely sue both since they have the legal rights on the runes of magic source code.
i agree that i would like it if maybe even rw would buy the new client from those pserver ppl but this won't happen in the same way as rw would sell the IP to gf.
hose who made them had no legal right to do so
That may be true but the work and result are wroth admiring nonetheless. It takes serious dedication to this game to undertake such an endeavor and come out with a successful result in the end.
Whatever the cause of these critical client crashes may be in the end, that work fixed it. Some claimed it was due to RoM being incapable of properly handling modern amounts of RAM, others claimed it was the architecture alone, some claimed both, some said it was simply Runewaker's mess of bandaid bugfixing that led to a messy as hell code and more crashes as time went on.
I remember that when Chapter 3 was released, I could barely walk around Dalanis for five minutes with the camera fixed on the ground without the client crashing or the framerate dipping. When I had my hands on that other work, it felt as stable as I always hoped the game would be one day.
We might also consider VRAM as a patch. I keep hearing that you crash less if you minimize the view distance. It's true, I've tried it. My last PC build boosted me from 4g VRAM to 8g and I can run in medium view range longer than I ever did with even minimum graphics before. I'm not saying it's a fix, but I suspect the more VRAM, the more stable. Any thoughts on that?
My 4070 can safely disprove your statement and so could my 1070 which had only 8GB back then. But this so-called "refurbished" version I've been using for a few years? Fat chance getting that to take a dump. I could probably pull it off if I really pushed it by spamming an area with NPCs or something but for my purposes of playing by myself, it's working perfectly fine. To me it doesn't matter if I play on a GF server or not, the population in the lower level zones I spend the most time in is zero in either case. I find the occasional sparkly shiny P2W whale camping the auction house but that's about it. Groups leveling in the howling mountains? Abbey runs? Gallery? Origin runs? Goblin village raids? All of that is a thing of the past.