CONTROL Showcase

[CONTROL 939]

Hello everyone,

I’m @ CONTROL, an active Metin2 developer mainly focused on systems, UI/UX improvements, optimization and gameplay improvements.

Some of you may know me from my previous releases and topics,

 

I decided to open this thread as my personal showcase topic where I’ll keep posting the systems and reworks I’ve been developing, instead of making separate topics for every project.

 

What to Expect Here ?

 

This thread will include showcases of things I work on,

Some projects are complete systems, others are experiments or work in progress.

 

This is mainly a showcase / development thread, not a release thread.

 

I’ll keep updating it whenever I have something interesting worth sharing.

Feedback is always welcome.

 

 

 

 

BUILDING SYSTEM REWORKED

This is not a brand new standalone system, but a deep overhaul of the vanilla implementation, 
improving both functionality and user experience while preserving the original concept.

 

Comparison

Vanilla:
- Build only
- Basic preview
- Outdated UI
- Hardcoded materials
- No move/delete workflow

Reworked:
- Full management system
- Modernized UI
- Dynamic materials
- Move/Delete support
- Smart validation
- Integrated help/wiki
- Better UX everywhere

 

Preview

 

 

 

 

 

SWING EFFECT SYSTEM

 

A procedural, motion-driven melee swing visualization system built from scratch.

 

This System Provides:

 

Real-time swing arc generated from attack data
Dynamic crescent slash mesh
Synced with attack timing
Smooth fade in / fade out
Cached geometry for clean post-attack fade

 

THIS APPLIES TO ALL MONSTERS IN THE GAME

 

Preview

 

 

Edited April 29 by CONTROL

[CONTROL 939]

GPU SKINNING SYSTEM

This is a fully custom GPU skinning implementation built from scratch, replacing the original CPU-based deformation with a modern shader-driven approach.

Each mesh is processed individually on the GPU, allowing precise control over rendering and lighting behavior.

 

Features

Mesh-by-mesh skinning evaluation
The system evaluates each mesh independently to determine whether it can be processed on the GPU based on bone count limits.

Fixed alpha rendering issues
In the official server, mixed GPU/CPU skinning causes incorrect alpha results (e.g. visible head with missing body).
This has been fully resolved, ensuring consistent rendering across all meshes.

Integrated specular lighting support

Correct per-mesh alpha blending

Fully working fog calculations inside the shader

Stable rendering across all character parts (body, face, hair, etc.)

Safe fallback to CPU when limits are exceeded

 

Improvements

Significant CPU load reduction

Smoother animation under heavy load

Better visual fidelity compared to CPU skinning

Eliminates legacy rendering inconsistencies

 

 

Notes

GPU skinning is automatically disabled for meshes exceeding the bone limit

Fallback is handled safely with no visual corruption

Fully compatible with existing models and assets

 

 

Example Logs

 

SYSERR: CGrannyModel::LoadMeshs: GPU skinning disabled for mesh 'sura_face' in model 'Bip01' because it needs 100 bones (limit=75)
SYSERR: CGrannyModel::LoadMeshs: GPU skinning disabled for mesh 'hair_1_1' in model 'Bip01' because it needs 100 bones (limit=75)

SYSERR: CGrannyModel::LoadMeshs: GPU skinning enabled for mesh 'wolf04' in model 'Bip01' because it needs 36 bones (limit=75)
SYSERR: CGrannyModel::LoadMeshs: GPU skinning enabled for mesh 'wolf04' in model 'Bip01' because it needs 36 bones (limit=75)

 

 

preview

 

 

 

 

Why is there a bone limit?

The bone limit comes from GPU shader constant restrictions.

Each bone requires a transformation matrix (typically 3x4), and all active bones must be uploaded to the shader at once. Older shader models (such as Shader Model 2.0/3.0) have a strict limit on the number of available constant registers.

In practice, this results in a safe limit of around 70–75 bones per draw call, depending on how many registers are reserved for other data (lighting, fog, etc.).

Meshes exceeding this limit cannot be processed on the GPU and will automatically fallback to CPU skinning.

 

 

 

Edited May 3 by CONTROL

[CONTROL 939]

Render Pipeline Optimization (GR2 State Cache)

In the original pipeline, multiple states were being set repeatedly per mesh and per material, including:

Vertex declarations

World transforms

Shader bindings

Fog states

This resulted in unnecessary overhead on the CPU → GPU command submission path.

 

What changed?

With state caching enabled:

GPU states are only updated when they actually change

Redundant calls to SetTransform, SetVertexDeclaration, etc. are avoided

Material batches are grouped more efficiently

Fog and shader states are applied once per batch instead of per draw call

 

 

Example

Instead of doing this per triangle group:

Set transform

Set vertex declaration

Apply fog

Draw

The system now:

Caches current state

Updates only when needed

Batches multiple draw calls under the same state

 

Result

Reduced CPU overhead

Fewer Direct3D state changes

Smoother frame pacing

Measured performance gain:

~10 FPS increase in heavy scenes (depending on model complexity and draw calls)

 

 

Notes

No visual changes — optimization only

Works seamlessly with both CPU and GPU skinning paths

 

 

Preview

 

 

Edited April 30 by CONTROL

[CONTROL 939]

 

ALPHA RENDERING FIX

A well-known rendering issue affecting colored monsters has been fully resolved.

Under certain conditions, applying color modulation would break proper masking, causing hidden parts of the model to become visible when they shouldn’t.

This resulted in incorrect visual output and inconsistent appearance across meshes.

 

 

Note

I’m not sure whether this issue has been fixed on the official server, but it is still present in many live private servers.

 

Preview

 

[CONTROL 939]

IMAGE PULSE SYSTEM

A lightweight, fully dynamic UI effect that brings images to life.

 

Features

Smooth pulse animation (scale + fade)

Multi-layer glow for depth

Soft bloom simulation (multi-pass)

Animated gloss sweep

Clean easing (no linear stiffness)

 

Notes

Works on any UI image

No shaders required (classic client friendly)

Safe render state handling

Easy to trigger (hover, click, etc.)

 

 

Preview

 

 

 

TEXT EFFECTS SYSTEM

A fully dynamic system that transforms any text into a modern, animated visual element.

 

 

 Features

Gloss Effect → smooth light sweep with customizable color

Particle Effect → dynamic particles around text with multi-color support

Color Effect → seamless multi-color transitions

Star Effect → animated decorative highlights

 

 

Notes

Built directly into CGraphicTextInstance

Works on any text in the game (TextTails, UI, etc.)

Fully dynamic & real-time (no static presets, no AniImage)

Independent effects (can be combined or used separately)

 

Preview

 

Edited May 3 by CONTROL

[CONTROL 939]

Effect Rendering Rework

After working with multiple game engines, I always wondered why their visual effects looked significantly better than what we usually see in Metin2, even when the textures themselves weren’t much different.

After digging deeper, I realized the difference wasn’t in the assets…

It was in the rendering pipeline.

Modern engines use a collection of subtle rendering tricks that make effects feel brighter, softer, richer, and more alive.

So I brought those same techniques into Metin2—

without touching a single asset, and without using shaders.

Everything was achieved through a complete pipeline rework.

 

Features

• Real-time bloom rendering for particles and effect meshes
• Multi-pass blur composition for soft light diffusion
• Additive glow layering for stronger visual intensity
• Selective effect-only rendering (world geometry remains untouched)
• Preserved original colors with enhanced luminance response
• Dynamic halo expansion for fire, magic, slash, and impact effects
• Zero asset modifications required
• Shaderless implementation using the existing DirectX 8/9 pipeline
• Fully integrated with the original effect system
• Minimal performance overhead

 

Notes

• Applies to all effects in the game automatically
• No client-side asset replacement required
• Compatible with existing particle and effect resources
• Does not affect terrain, water, sky, characters, or UI rendering
• Designed to preserve the original game style while modernizing visuals

 

Preview

 

 

[CONTROL 939]

Player Customizable Swing Effect

This system introduces customizable swing effects with improved blending, smoother rendering, dynamic texture support, and enhanced visual clarity — all integrated directly into the original DirectX pipeline without shaders.

 

Features

• Fully customizable swing textures
The system works with all weapon types and allows custom trail textures for every weapon individually.

• Dynamic blend mode switching
Supports different rendering blend styles to achieve softer, brighter, or sharper swing visuals.

• Smooth alpha-based rendering
Improved transparency handling for cleaner and smoother trail fading during attacks.

• Texture-based glow-style trails
Allows glow-like weapon traces using textured rendering without requiring shaders.

• Improved trail visibility and motion clarity
Makes attack movements easier to see while keeping the original combat feeling.

• Shaderless DirectX 8/9 implementation
Built entirely using the original rendering pipeline for maximum compatibility.

• Lightweight and performance friendly
Designed to have minimal impact on performance even during intense combat situations.

 

Notes

• I’m fully aware this isn’t something entirely new — some private servers had similar concepts before.

• However, this implementation was built completely by me from scratch.

 

Preview

 

 

 

[CONTROL 939]

Dynamic Guild Land Expansion System

I made a new system that allows guild leaders to expand their guild land instead of being limited to a static predefined area.

 

The system was designed to give guilds more freedom for building and land management while still allowing full control from the server side.

 

Overview

Guild leaders can progressively expand their guild territory through a dynamic expansion system.

Each expansion increases the usable land size and unlocks additional building space for the guild.

The maximum number of expansions is fully configurable by the server owner, with support for up to:

10 total expansions per guild land.

 

Example

 No new table were created this is from the already existing "land" table

 

StartX: 20200   StartY: 10000
Width: 3000     Height: 3000

ExpansionAmount: 0

ExpandLeft: -500
ExpandRight: 500
ExpandTop: -500
ExpandBottom: 500

In this example, the guild land starts with its default size.

Since ExpansionAmount is currently 0, no expansion is applied yet.

Every time the guild upgrades its territory:

ExpansionAmount += 1

The expansion values are then applied in RealTime to the land boundaries.

 

Example behavior:

ExpandLeft = -500
→ expands the territory 500 units to the left

ExpandBottom = 500
→ expands the territory 500 units downward

The final land size and boundaries are recalculated dynamically based on the current expansion level.

 

Preview

 

 

 

 

Final Note  

This has honestly been one of the most painful systems I’ve ever worked on.

Even in its current state, the system is still not fully complete, and there are already many additional features planned for future updates.

 

Future Expansion Requirements

For example, future guild territory expansions may eventually require:

Yang

Specific items

Guild materials

Guild level requirements

Long-Term Territory Progression

 

I also plan to make guild territories far more interactive and rewarding.

For example, guild lands could eventually generate passive resources for the guild whenever someone:

Farm inside the territory

Mine ores

Fish

Participate in other territory-based activities

This would transform guild lands into actual progression-based territories rather than simply decorative building areas.

The main goal is to turn guild territory progression into a true long-term gameplay system instead of just a simple land size increase.

 

Territory Guards

One of the next planned features is the introduction of guild guards designed to protect guild territories.

Possible features include:

Spawnable guild guards

Territory defense systems

Guard upgrades (Level / Attack / Defense)

Multiple guard types

PvP and siege interaction possibilities

Custom guard positioning inside expanded territories

This would make guild lands feel more alive, strategic, and meaningful rather than serving purely as decorative spaces.

 

 

i mean look at them they look way more ready than iam 

 

Edited May 11 by CONTROL

[CONTROL 939]

Attacker Pet System

Turn any Monster OR Boss into a fully combat pet.

Just set:

item_proto.txt - Value0 = MonsterVnum

Done.

The pet instantly gets:

Original monster AI
Original monster skills (even the Turtle warp)
Original animations exactly like the monster
Smart target switching
Target queue system
Auto follow & auto respawn like any other pet

 

Extra
Level & rank scaling

 

Overview

The AI is designed to behave like a real combat companion.

The pet knows exactly when to stay on its current target and when to switch to a higher priority one.

Any monster that attacks or get attacked by the owner is automatically added to the pet’s target queue.

The pet processes queued enemies one by one without interrupting active combat.

All item drops, rewards, and ownership remain assigned to the player.

The pet can be killed during combat like a real companion.

If you target any mob the damage that your pet does appear to you

If the pet dies, it automatically respawns after 10 seconds and returns to battle.

The pet handles everything automatically.

 

 

 

Example

Set:

Value0 = 101

Monster 101  becomes a combat companion.

No new tables
No hardcoded pet lists
No extra configuration

Built for performance, scalability, and plug-and-play integration.

 

Preview

 

 

Edited May 15 by CONTROL

[CONTROL 939]

Dynamic Guild Land Defenders System

Today I completed the Guild Land Defenders system for guild territories.

This system allows guild defenders to actively protect guild lands and creates a much more alive and strategic guild territory experience instead of lands being just decorative spaces.

 

Features

• Guild Defenders display the guild name and guild icon
• Defenders automatically detect enemy players inside the guild territory
• They ignore guild members and only target enemy guild players
• Invisible / hidden players are ignored correctly
• Defenders cannot leave guild territory boundaries
• If the target leaves the guild land, defenders immediately stop chasing and return back
• Automatic return to original spawn position after combat
• Original spawn rotation is restored after returning
• Full support for Dynamic Guild Land Expansion System
• Defenders correctly work with expanded guild territories, not only default land size
• Defenders cannot attack allies and allies cannot attack them (Server + Client protected)
• Defenders will never attack new players or players without a guild

 

This means guild lands now have actual territorial defense logic with controlled patrol behavior and proper boundary protection.

The goal is to make guild territories feel like real strategic zones with progression, defense systems, and long-term guild value instead of simple empty building areas.

 

Notes

All mobs shown in the video are official mobs, which honestly makes me think they may have once planned something similar for guild territory defense systems.

 

4601    Guild Archer
4602    Guild Mage
4603    Guild Warrior
4690    Lord of Battle

 

I do not play official servers, so I cannot confirm if they ever implemented anything like this there, but the idea definitely feels like it was meant for something bigger.

 

 

Preview

 

 

 

 

 

[CONTROL 939]

Cinematic Dialogue Camera System

Bring NPC conversations to life with a fully cinematic dialogue experience.

 

 

Features

Dynamic camera focus on NPCs

Smooth cinematic camera transitions

Player movement lock during dialogue

Real-time smooth background blur

NPC remains sharp and highlighted

Automatic camera restoration after conversation

 

 

Overview

The system transforms standard NPC interactions into immersive cinematic scenes.

When a conversation begins, the camera smoothly focuses on the NPC while the surrounding environment is softly blurred, naturally directing the player's attention to the dialogue.

The camera dynamically analyzes the positions of both the player and the NPC to create a cinematic over-the-shoulder view, resulting in a more natural and engaging presentation.

Once the interaction ends, the camera smoothly returns to its normal gameplay state.

The showcase demonstrates the system during a quest dialogue, but it can be integrated into any event, interaction, or custom sequence where a cinematic camera is desired.

 

Preview

 

 

[CONTROL 939]

 

Text Effects v2

Added a new glow effect with a pulse effect.

Refined the gloss effect to make it cleaner, smoother, and more visually appealing.

 

 

[CONTROL 939]

 [experimental] Texture Neon System

Add emissive and neon effects to any GR2 model using an additional texture layer.

 

 

Features

Automatic detection of Neon textures

Per-model emissive effects

Color-driven Neon rendering

Alpha-controlled Neon intensity

Works with all GR2 models

No model editing required

Automatic fallback when no Neon texture exists

Lightweight and easy to integrate

 

 

Overview

Texture Neon System allows artists to add emissive details to existing models without modifying the model itself.

When a texture is loaded, the system automatically checks for a matching texture with the "_neon" suffix. If found, it is used as an additional emissive layer on top of the original texture.

The Neon texture defines both the visible emissive areas and their colors. This makes it possible to create glowing lines, magical symbols, energy effects, armor details, weapon highlights, wing effects, and similar visual elements directly from the texture artwork.

Neon intensity is controlled through the texture's alpha channel, allowing precise control over how strong each emissive area appears in-game.

Models without a corresponding Neon texture continue to render normally, making the feature fully optional and compatible with existing content.

 

Usage

The original texture defines the model appearance, while the Neon texture defines the emissive regions.

Artists can control:

• Neon colors

• Glow intensity

• Visible emissive areas

• Different visual styles for each asset

No additional configuration, model changes, or special setup is required.

To create a Neon effect, simply add a second texture using the same filename and the "_neon" suffix.

 

Example

weapon_choegogeup01_02_neon.dds

for example - more alpha = more neon

 

 

 

Preview

   the idea was something like this

 

 

i didn't 100% get it but i'm very close

 

the neon dosen't only shine in white btw it takes the texture color

 

 

volcanic textures are alive !

 

Edited June 19 by CONTROL

[CONTROL 939]

Custom In-Game Wiki

I never wanted to make my own wiki. Like... ever.

Unfortunately, after reading pretty much every available wiki system, I couldn't find a single one that matched what I needed, so

 

Overview

The entire wiki is built around a custom content loader capable of loading and animating:

* Text
* Grids
* Items
* Images
* Custom widgets
* Basically anything I want

 

Features

### Refine Wiki

A complete refine wiki with data retrieved directly from the server.

Monsters / Stones / Bosses / Ores Wiki

A complete encyclopedia with server-driven data.

All relevant information, including spawn locations, is retrieved directly from the server.

For high-density content such as regular monsters, Metin Stones and Ores, location data is clustered server-side to reduce network traffic and improve efficiency while maintaining accurate results.

### Chests Wiki

A complete chest wiki with server-driven data.

### Cube Wiki

A complete cube wiki with server-driven recipes.

### Costume Viewer

Create any costume set combination with ease.

* Custom set names
* Custom item combinations
* Easy configuration

### Navigation System

A fully working Back / Forward navigation system, similar to a web browser.

### Advanced Search

Real-time search with related suggestions.

The search only displays content that actually exists inside the wiki.

 

Server-Driven Design

The wiki follows a single-source-of-truth philosophy.

Only the data that actually matters is transmitted from the server.

I honestly hate wiki systems that require duplicated data, hardcoded pages, and manual synchronization every time something changes.

If a refine recipe, cube recipe, drop table, chest content, or monster information changes, the wiki updates automatically without maintaining the same data in multiple places.

 

Cross Referencing

Every piece of data is indexed in both directions.

An item can instantly show:

* Where it drops
* Which chests contain it
* Which cube recipes use it
* Which refine recipes require it
* Which shops sell it

No expensive runtime scans are required.

 

Performance

I built it like a fkn chef.

The entire data structure was designed around O(1) lookups wherever possible.

* No unnecessary scans
* No duplicated data
* No weird hardcoded stuff

Everything is heavily indexed and optimized to keep searches and page loading extremely fast even with large datasets.

 

Models & UI Loading

To provide the smoothest experience possible:

 

Every monster model is fully preloaded ahead of time, eliminating runtime asset loading and ensuring instant transitions across the entire wiki. This results in zero loading spikes and no noticeable FPS drops, even when browsing pages with a high number of monsters or NPCs.

 

---

 

UI elements are loaded lazily and only when needed.
* Models are preloaded in advance.
* Content is generated dynamically.

This keeps navigation responsive and avoids loading hiccups while browsing.

 

---

 

Still a work in progress, but it has already replaced several standalone systems and made content maintenance significantly easier.

 

Preview

 

 

Edited June 20 by CONTROL
Core X - External 2 Internal

[CONTROL 939]

Random Party Matchmaking System

 

This is a system I originally designed for a private Metin2 server to make finding dungeon parties much easier and to encourage players to play together instead of waiting around for party members.

 

 

How it works ?

 

* A player talks to the NPC and selects a dungeon.
* The player becomes the party leader and starts a **Random Party Matchmaking** request.
* Every online player who meets the dungeon requirements (level, conditions, etc.) instantly receives a popup invitation on their screen.
* Multiple invitations can stack, allowing players to receive requests for different dungeons without missing any of them.

 

 

Live Matchmaking

 

As players accept the invitation:

* The UI updates in real time for everyone who received the invitation.
* Players can see the current participants joining the group, **but only their character portraits are displayed**—no names, levels, guilds, or any other information are revealed. This keeps the matchmaking anonymous and prevents players from judging or rejecting others based on their character.
* Everyone has **10 seconds** to decide whether they want to participate.

During this countdown:

* Any invited player can cancel their participation.
* The party leader can also cancel the matchmaking before it finishes.

 

 

Party Creation

 

Once the countdown reaches zero:

* All confirmed players are automatically teleported to the leader using P2P.
* A party is automatically created with all confirmed members.
* After a short synchronization period (around 10 seconds), the entire party is warped together into the selected dungeon.

 

 

Goal

 

The purpose of this system is to break the ice between players and remove the hassle of manually searching for dungeon groups through chat.

Instead of standing in town spamming messages like:

> "Need 1 Sura"
> "Looking for Healer"
> "Need DPS"

Players can simply queue for the dungeon and instantly be matched with other interested players, making dungeon content much more active and accessible.

The anonymous preview is also intentional. Since players only see character portraits before the party is formed, they can't cherry-pick teammates based on level, equipment, or class, resulting in a more fair and spontaneous matchmaking experience.

This concept was something I designed some time ago for a server owner, and I thought it would be nice to showcase it here since it may inspire other developers or help improve the multiplayer experience on their own servers.

 

Preview

 

 

[CONTROL 939]

[experimental] UI Shaders

 

kinda difficult but very satisfying,

can work with any ui (Text/Images/etc) with many options like MaskChildren(True) etc

with a call back (OnEndShader)

and a decent python API

bg.AddShader("Pearl", 4.0, True)
bg.MaskChildren(False)
bg.SetShaderPalette([
	(1.00, 0.75, 0.85),
	(0.65, 0.50, 0.95),
	(0.55, 0.80, 1.00),
	(1.00, 0.95, 0.70),
])
bg.SetShaderColor("g_Color", 1.0, 1.0, 1.0, 0.7)
bg.SetShaderFloat("g_Cycles", 2)
bg.SetShaderFloat("g_MaskLow", 0.5) 
bg.SetShaderFloat("g_MaskHigh", 0.8)

 

 

 

 

 

 

 

Edited July 17 by CONTROL

[CONTROL 939]

Mining System Rework

 

I've always hated Metin2's mining system.

From the first time I saw it, I knew it'd be my forever enemy.

The timers, the fixed looping animation... everything about it felt absurd when it came to actually enjoying the game.

Mining always felt like a chore rather than something you could genuinely enjoy while grinding.

So I decided to completely rework the entire system, taking inspiration from a Roblox game called The Forge.

 

 

What's changed?

 

Real per-swing mining. Every pickaxe swing is processed through ,

CHARACTER::Attack()

just like a normal melee attack.

There are no timers, no scripted hit counts, and no random event deciding when the vein breaks.

Every swing deals actual damage to the ore vein through the normal 

CHARACTER::Damage()

pipeline, meaning HP, death, effects, and everything else are handled by the exact same combat system the game already uses.

 

Mining now has complete freedom. You can swing your pickaxe anytime, even if there isn't an ore vein in front of you—exactly like using any normal weapon. No more being locked into a mining animation or waiting for the game to decide when you can swing.

 

On every successful impact, the familiar mining effect is played alongside a subtle screen shake to make each hit feel satisfying.

 

And for the first time ever, I can finally say... I'm actually enjoying mining !!

 

 

preview

 

 

[CONTROL 939]

This maybe irrelevant but

 

I've built many apps over the past few years, and around 90% of them have been written in Python. Not because Python is necessarily my favorite language or the one I'm most comfortable with, but simply because I never took the time to learn ImGui — which would have made building this kind of application in C++ much more practical for me

This is one of the hardest projects I've worked on so far

I've spent months building it, and I still plan to spend more time polishing and improving it

 

 

The idea behind the app is simple

 

If you have a Discord webhook or bot, this app allows you to easily create and send Discord embeds without having to manually write JSON or build everything from scratch.

What started as a simple Python script eventually grew into a fully structured and functional application with support for embeds, polls, batch sending, templates, plugins, and more.

I know this might sound like a relatively simple or even useless idea to some people, but it's something I personally enjoy using and building.

It became a new challenge for me — taking a small script and turning it into a complete application.

I've put a lot of time and effort into this project, and I wanted to share it here, just in case it never gets the chance to see the light of day.