Creează-ți un cont sau autentifică-te pentru a participa la discuție

[SystemPolaris]

PROJECT POLARIS — TECHNICAL OVERVIEW

A modernized Metin2 source focused on removing old dependencies, cleaning the architecture and improving the parts that actually matter for long-term development.

SERVER SOURCE

• FreeBSD 14+ AMD64
• MariaDB 10+
• Native 64-bit server environment
• Cleaned and modernized server architecture
• Improved overall performance
• Improved Core, DB and network communication

The server is built around a native AMD64 environment, without relying on the old 32-bit setup commonly found in older Metin2 sources.

BINARY SOURCE

• Modernized C++ client source
• Legacy licensed Granny dependency removed
• Granny replaced with OpenGR
• Custom animation system implemented
• Licensed SpeedTree dependency removed
• Old and unnecessary runtime dependencies removed
• General cleanup across rendering, resources and client-side systems

The goal has always been to get rid of outdated dependencies and make the entire project easier to extend without being limited by closed-source libraries or old middleware.

PYTHON

• Upgraded entirely to CPython 3.14
• Modern PyConfig-based initialization
• Fixed multiple random crashes that could occur after extended gameplay
• Native C++ and Python integration maintained
• Old Python initialization code replaced where required
• Python execution and traceback handling updated for the newer runtime

The client structure looks like this:



NETWORK & PACKETS

The networking side has been improved as well.

• Packet structures reviewed and cleaned
• Packet flow simplified where unnecessary processing existed
• Safer packet handling and validation
• Improved client/server packet processing
• Redundant operations removed from frequently executed network code
• Send and receive paths cleaned and optimized
• Better handling of queued and fragmented data
• More consistent packet size and structure management

A lot of old Metin2 networking code was written around assumptions that no longer make much sense today, so this part has been treated as something that needs proper maintenance instead of being left untouched simply because it still works.

BUFFERS & MEMORY HANDLING

Buffer handling has also received attention, especially in networking and other frequently used systems.

• Buffer management cleaned and improved
• Unnecessary memory copies reduced
• Better control over buffer growth
• Safer handling of incoming data
• Improved data lifetime management
• Old fixed-size handling replaced where it made sense
• Reduced unnecessary allocations in frequently used code paths

PERFORMANCE

Performance work has been done throughout the project instead of being limited to a single system.

• Previous issues identified and cleaned
• Reduced redundant processing
• Reduced unnecessary allocations and copying
• Improved frequently executed code paths
• Network and packet handling optimized
• Resource handling cleaned
• Old dependencies removed where they added unnecessary overhead or maintenance problems

POPULAR QUESTIONS

What if I'm facing an issue?

I'm available to help whenever possible, and bug fixes and improvements related to the source are provided free of charge.

How long does it take to receive the files after payment?

Since I only need to prepare and upload the files, delivery normally takes around 1 hour.

Why should I buy these files instead of buying from someone else at a lower price?

There is an old saying: "You get what you pay for."

Don't expect premium quality at a cheap price. When it comes to Metin2, properly maintained and modernized sources are not cheap. Even a well-built project can still encounter issues because of the nature and complexity of Metin2, but the difference is having someone who actually understands the source and can fix them.

POLARIS - PRICES

Complete POLARIS Source Files: 300€

The price includes the current Client, Binary, Python and Server Source, my custom C++ packer/unpacker, my custom C++ item_proto/mob_proto compiler & decompiler and all of the things mentioned above and below.

• Client
• Binary Source
• Python Source
• Server Source
• Custom item_proto/mob_proto compiler & decompiler written in C++
• Custom unpacker & packer written in C++
• Current fixes and improvements
• Future bug fixes & improvements
• Direct support when needed
• Free first-time installation and complete setup through AnyDesk

Payment Methods

• Revolut
• PayPal
• Bank Transfer
• Paysafecard

Contact

Discord: systempolaris

The serverfiles is clean so there is no system added, the reason why no images were needed in the first place.

For questions, technical details or payment information, contact me directly on Discord.

[SystemPolaris]

PROJECT POLARIS
UPCOMING VULKAN UPDATE

Native Vulkan Renderer • Currently in Beta Testing

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

NATIVE VULKAN RENDERER

I also want to give a small preview of something i've been working on lately

The client is almost done moving from DirectX 8 to a native Vulkan renderer

This is not a wrapper or a D3D8 translation layer, the old DirectX rendering parts are being replaced directly inside the client

WHAT IS BEING REPLACED

A lot of the old rendering code was built around things like

• IDirect3DDevice8
• IDirect3DTexture8
• IDirect3DVertexBuffer8
• IDirect3DIndexBuffer8
• SetRenderState
• SetTextureStageState
• SetTexture
• SetTransform
• DrawPrimitive
• DrawIndexedPrimitive

Those parts are being replaced with Vulkan equivalents like

• VkDevice
• VkBuffer
• VkImage
• VkImageView
• VkPipeline
• VkDescriptorSet
• VkCommandBuffer
• Vulkan swapchain and synchronization

The renderer is no longer depending on the old DirectX state based rendering system

Instead of constantly doing things like

Code:

SetRenderState(...)
SetTexture(...)
SetTransform(...)
DrawIndexedPrimitive(...)

the Vulkan side now handles the pipelines, resources and rendering commands directly

WHY VULKAN

The point is not just to replace DirectX 8 with something newer

I want a renderer that i can actually continue building on without being limited by such an old graphics API

This gives me a much better base for things like

• Modern shaders
• Better lighting
• Better shadows
• PBR materials
• GPU based rendering features
• Better control over rendering and memory
• Future platform support

CURRENT STATUS

The Vulkan version has already been in beta testing for over a week

A large part of it is already working but i'm still testing maps, effects, characters, UI rendering and older rendering paths that still need to be cleaned or replaced

Because of that it's not ready for release yet

I don't want to release something this big just because it launches and renders the game

WHAT COMES NEXT

Once the base Vulkan renderer is finished the work doesn't stop there

The next step is to start using the new renderer as a base for improving the graphics of the game itself

That means things like better shaders, lighting, shadows, materials and other rendering improvements can finally be built on top of something modern instead of continuing to work around DirectX 8

PRICE AFTER RELEASE

The current price will stay the same while Vulkan is still in testing

Once the native Vulkan renderer is finished and included in the main files the price of PROJECT POLARIS will increase

This is not just another system added to the game

It's a replacement of one of the most important parts of the client and has required a lot more work, testing and changes to the engine itself

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

CURRENTLY IN BETA — NOT YET PART OF THE RELEASE

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PROJECT POLARIS — TECHNICAL UPDATE

CLIENT STRUCTURE CLEANUP




What changed:

• Unused runtime files removed
• The amount of legacy DLLs reduced
• Runtime configuration and game resources kept in a cleaner structure

Why:

The original Metin2 client accumulated a large number of runtime files and dependencies over the years, many of which are not even necessary anymore

Keeping the client minimal makes dependency management easier, reduces deployment problems and makes it much clearer which components are actually required by the binary

VCRUNTIME140.DLL REMOVED

The client no longer needs to ship a separate VCRUNTIME140.dll next to the executable

What changed:

• VCRUNTIME140.dll removed from the client distribution
• Runtime configuration changed so the client no longer relies on that locally distributed DLL

Why:

This removes another unnecessary external runtime file and keeps the client structure cleaner

Instead of keeping legacy runtime DLLs in the client folder simply because they were previously required, i'm going for a cleaner and more modern runtime setup

PYTHON MODULES FROZEN INTO THE BINARY

A large part of the Python runtime modules are now frozen directly into the client binary instead of being loaded as separate Python files

How it works:

Code:

Before:

metin2client.exe
    ↓
filesystem
    ↓
Python modules
    ↓
import / execute


Now:

metin2client.exe
    ↓
frozen modules
    ↓
Python import

Advantages:

This keeps the Python side of the client much cleaner

There are fewer loose files to deal with, less dependency on the exact folder structure and the whole client becomes easier to recompile and move around

A good part of the internal Python modules are now already included inside the executable so they can be loaded directly from there instead of depending on separate files in the client

The client still uses CPython 3.14, this just changes the way a large part of the internal modules are handled and loaded