Quote from Kenero;1170735:
When the memory Mabinogi uses spikes either due to memory or CPU usage or rendering, it will cause the client to close automatically or lose out.
Yeah, this was an issue back when they did that one big update that made loading maps so slow that people would often crash before being able to access Tara.
Quote from Kenero;1170735:
Which is why a lot of mods that reduce lag is actually beneficial.
I made this one just to get into Tara at the time.
Quote from Kenero;1170735:
The reason I use CC++ as an example is because whenever Mabinogi crashes, the debug I get from my Microsoft Visual Basic usually acts up asking me to debug the Mabinogi Client interestingly enough.
People without the tools installed won't get that prompt, and that option won't do anything since we don't have the client source anyways. It's something that'll be offered to almost any program that crashes in a certain way by default.
Quote from Kenero;1170735:
Just by looking how it was coded, it seemed like originally they only planned Mabinogi to be short termed. The system itself seemed like it was made with the intention of lasting a few years... and for it to last nearly a decade was probably overshooting it.
That is to say, the people who originally made Pleione probably didn't intend too look far in the future, which is why there's a lot of bad optimization and problems in Pleione.
Well, a lot of it isn't actually Devcat's fault
originally, it's the old libraries and technologies they were using at the time.
Here's a good technical article about some of the flaws of older graphics APIs for one example. Minecraft also ran into this issue in numerous ways, sticking to OpenGL 1.2 limits the things they can do and 1.2 also doesn't have some basic performance improvement functions, which is why
they plan to drop support for the old version of the API and move to a newer one being required.
The problem with dropping old tech to move to new tech is that it's not always just a little upgrade. For example
DirectX 10 is not an update to Directx 9. It's a re-write, and is incompatible with 9. Because of this, most systems that have Directx 10 also have Directx 9 installed, since 10 doesn't overwrite 9 (and this is why people sometimes get messages about updating Directx 9 even though they have 10 installed, confusing the crap out of them). This also, however, meant that games that wanted to support Directx 10 would not automatically support machines that only had 9, and if they wanted to support both they would have to write two different renderers.
Some games (like Assassin's Creed 1 at least) did this (I can see AssassinsCreed_Dx9.exe and AssassinsCreed_Dx10.exe in steam's installed folder), others stuck to 9 to avoid all the users that weren't on 10 yet being unable to play/buy the game (if they didn't want to spend a bunch of time writing two rendering engines).
Now, one notable case is Crysis, which was originally hailed as having DX10 support...
but it doesn't use a DX10 rendering engine. It uses DX9, and if DX10 is enabled on the system, it unlocks some extra shader options that mostly need DX10. Running DX10 shaders on top of DX9 is notably slower than going DX10 natively (which is part of why Crysis was and still is so hard on the GPU), but Crytek made a bit of a bonehead decision and decided to lock off some DX9-capable options as well to try to make the difference more pronounced, since they didn't really HAVE all that much DX10 stuff to lock off in the first place (what with the new API not having been explored much at that point in time). Cue people editing the config files to enable all the options, seeing some of the more obvious changes (god rays) and assuming that all of DX10 was a lie. Geeze, that was a hell of a mess caused by dev laziness,
but time is money when your game is your source of income.
Anyways Mabi's engine needs an update, but if so it'd likely need a full rewrite, and that means a lot of time spent (months to a year easy). They'd have to analyze the current game and make note of all the things that work the way they do and the workarounds in use so they have a plan for the new engine. Then they'd need to analyze the tech level of the majority of their user base so they know the minimum they'd be able to work with to avoid cutting off a large portion of their users (other companies
collect hardware information automatically to make this process easier, even Minecraft and Runescape do it because you don't want to add a new feature that stops 50% of your customers from being able to play suddenly).
After that they'd need to do the actual rewrite, which with a system Mabi's size could take months to a year of hard work (hard work
they're not getting any additional income from as users are not paying NX for it), then with an MMO like Mabi, they'd have to spend a few more months testing all the in-game systems in depth to eliminate bugs and exploits that are going to pop up.
The entire process is going to take a long time (other games that did total rewrites often lay out the workflow as having taken ~18 months or so), and that's a lot of time that key devs will be working hard for no additional income to the company.
But they're going to need to do it eventually if Mabi continues running for the next few years, because some tech they're using is likely so old it's reaching deprecation level by now. XD
Quote from Aubog007;1170752:
As far as i know about mabi, it was built during the era of single cored computers, and that's the way they thought it was going to be, not multicored.
Really shot themselves in the foot with that one.
Well to be fair, many games even now are still not multi-core, and that's because multiple cores doesn't immediately equal better performance, it's only if you actually have CPU-hungry jobs to run on multiple cores
and if these jobs can run parallel (that is the outcome of one does not depend on the outcome of another).
I'm sure by this point in time though, some of Mabi's jobs could be offloaded. Main logic (game) on one core and extra logic (networking, sound) on another is the usual. AI not mentioned because that's server-controlled in this case. Not sure how much of a gain this would be, a lot of Mabi's strain comes from it's redundancy.
Speaking of core usage though, Mabi's unrestricted sucking of all the cycles it can get reminds me a lot of Phantasy Star Online: Blue Burst's client. That game is a port of a Dreamcast game, and it'll suck up 100% of a core at any given time since the original version had no need to spare resources or account for other programs running, and they didn't bother to rewrite the engine to that degree for the PC port.
Quote from Splatulated;1170780:
this is neat :3
what else can be dug up i like the one with the pallette swathes
Well, changes to what the default colors show up as can be done, but as they'd only affect the computer the mod is done on, I don't think anybody's cared enough to do it.
Quote from Xcelled194;1170829:
Where to begin...
Somebody's sure seen a lot of crap in their time. :P
Do you have additional info on things such as...
- "GM Hide" actually being the bird skill?
- Homestead return being a teleport coupon in your hidden inventory and being able to destroy it to stop the homestead from saving your last location for login purposes?
- Parties being attached to a player, so you could join parties even when not on the same map, only knowing the name of the player?
- And then there's all those plugins that do things like auto-harvest and auto-drop certain items and junk, but that's more about forced plugins than Mabinogi itself.