**Elvion Project – Current Status / Improvements & Fixes**
After extensive work on the original Elvion files, the project has reached a considerably more
stable, clean, and usable state.
The files are now **fully functional, extensively tested, corrected, and ready for further development**.
Both the **server and client are running with clean syserr logs**, and the
fixes were implemented directly into the existing Elvion codebase. No
systems or fixes were simply copied from other server files.
The main objective was to preserve the original project while fixing its underlying problems instead of masking them or replacing entire systems.
---
### Core Systems & Gameplay
Several
quests and systems were rewritten or heavily corrected to eliminate broken logic and improve reliability.
Some of the work includes:
* Guild
System repaired and fully functional.
*
Dungeon systems reviewed and corrected.
* Dungeon logic, states, information, and related interfaces fixed.
*
Quest flags and quest-related logic corrected.
* Mob-kill handling corrected.
* RespManager logic reviewed and fixed.
* TeamList handling corrected.
* Gameplay state inconsistencies resolved.
* Client/server state problems after teleporting, reconnecting, changing maps, or relogging investigated and corrected.
The goal was not only to make these systems "work", but to make their behavior consistent during normal gameplay.
---
###
Pet &
Mount Systems
The **Pet and Mount systems** received several improvements and corrections.
Pets and
mounts can now display their **actual names** instead of generic labels such as `"Pet"` or `"Mount"`.
Names can also be changed directly through the corresponding interface/panel.
Several related problems involving displayed information, states, names, levels, and UI behavior were also corrected.
---
### Client Performance & Optimization
A considerable amount of work was done on client performance.
CPU usage was significantly reduced, particularly in demanding areas such as **Farm Maps and
Boss Maps**.
During our tests, CPU consumption remained at approximately **20% or below** in these scenarios, although this obviously varies depending on hardware and the situation.
RAM consumption was also reduced.
Several unnecessarily frequent client-side operations were reviewed and optimized, including:
* Character and entity processing.
* Player and target detection.
* Buff and state verification.
* Repeated per-frame operations.
* Character list management.
* Cleanup of obsolete or invalid references.
* Removal of unnecessary background processing.
* Prevention of destroyed UI objects from continuing to receive updates.
The result is a noticeably lighter and more stable client compared to the original files.
---
### Client Stability & Crash Fixes
Several crashes were investigated using **crash dumps, syserr logs, runtime testing, and source-level debugging**.
This included problems involving invalid UI/window pointers and situations where destroyed objects could continue receiving updates.
Other crashes and stability problems involving:
* Skill Color.
* Internal matrices.
* UI objects.
* Character instances.
* Invalid/stale references.
* Window lifecycle handling.
were also investigated and corrected while preserving the existing functionality of the project.
The intention was never simply to suppress an error from the logs.
Where possible, the actual cause of the problem was identified and corrected.
---
### Server & Database Improvements
The server environment was extensively reviewed.
The project was standardized around **MariaDB**, including the compatibility work required by the existing database structure.
Several build, runtime, and environment problems were addressed, including:
* Makefile issues.
* Linker problems.
*
FreeBSD compatibility.
* Crypto++ related problems.
* Handshake-related issues.
* Unsafe empty-vector access.
* Incorrect format specifiers.
* SIGBUS-related problems.
* Database compatibility.
* Administrative database access.
* Dependency installation.
* Automatic server configuration.
* Automatic IP configuration.
The server compilation environment was also cleaned and corrected.
After the relevant corrections, the **GAME server successfully compiled with 0 errors and 0 warnings**.
---
### Runtime & Proto Safety
Additional validation was implemented around runtime data and proto handling.
Reload operations were strengthened with validation involving:
* Version.
* Type.
* Entry count.
* Structure size.
* Payload integrity.
* Hash validation.
* Atomic replacement of loaded data.
This reduces the possibility of malformed, corrupted, incompatible, or partially loaded data affecting a running server.
Persistence-related logic was also reviewed to reduce the risk of incorrect or potentially destructive database behavior.
---
### Security Audit
The project also underwent a **security-oriented source and runtime audit**.
Considering the history surrounding some public/private Metin2 files, one of the priorities was checking for suspicious behavior rather than simply assuming that the files were safe.
The project was inspected for potential:
* Backdoors.
* Hidden remote access.
* Suspicious authentication logic.
* Hardcoded credentials or access mechanisms.
* Key-related mechanisms.
* Suspicious network behavior.
* Unnecessary external dependencies.
The obsolete **HackShield implementation was disabled**, together with old or unreliable "protection" mechanisms that no longer provided meaningful security and could instead introduce compatibility or stability problems.
Sensitive client/server states and validation paths were also reviewed.
The philosophy here is simple: **security-sensitive decisions should be validated by the server rather than trusting the client.**
---
### General Cleanup
A large amount of smaller work was also performed throughout the project.
This includes fixes and improvements involving UI behavior, localization, gameplay states, quests, database interaction, server configuration, client/server synchronization, memory/state management, and general code cleanup.
Many of these changes are individually small, but together they make a substantial difference in the overall quality and maintainability of the files.
---
### Current Status
At this point, Elvion is in a very solid state for anyone who wants to **continue developing the project or use it as a foundation for opening a server**.
All major tests performed on the current build so far have completed successfully.
The server and client are stable, the major systems tested are working correctly, client performance has been substantially improved, obsolete protection mechanisms have been removed, security-sensitive areas have been audited, and numerous long-standing problems have been corrected.
Of course, no Metin2 project should ever be considered "finished". There is always additional balancing, content, optimization, testing, and polishing that can be done.
However, there is an important difference between the original state of these files and their current state.
**This is no longer simply a collection of files that compiles and starts.**
It is now a **cleaned, repaired, optimized, audited, and actively tested development base** that can realistically be used for continued development or as the foundation of a production server.
Most importantly, the work was done **directly on Elvion itself**, preserving its existing systems and structure rather than building a Frankenstein project from systems copied from multiple unrelated files.