# METIN2 — COMPLETE AURA SYSTEM REWRITE
## ZERO-BASE, PRODUCTION-QUALITY IMPLEMENTATION
You are working on a heavily modernized Metin2 server/client codebase.
Your task is to implement a COMPLETE, PRODUCTION-QUALITY AURA SYSTEM from scratch.
This is NOT a small feature addition.
This is NOT a simple port of an existing implementation.
This is NOT a copy of the old Metin2 Aura code.
The objective is to create a clean, modular, server-authoritative, data-driven Aura System while reproducing the documented Metin2 Aura gameplay mechanics.
============================================================
0. CRITICAL EXECUTION RULE
==========================
DO NOT ASK THE USER FOR CONFIRMATION.
DO NOT STOP AFTER THE AUDIT.
DO NOT PRESENT A PLAN AND WAIT.
DO NOT ASK:
"Should I proceed?"
"Do you want me to implement this?"
"Can I modify these files?"
"Which architecture do you prefer?"
You are explicitly authorized to:
* inspect the repository
* inspect the existing ACCE system
* inspect the existing shoulder sash system
* inspect existing quests
* inspect item definitions
* inspect item attributes
* inspect packet structures
* inspect database structures
* inspect UI
* create new files
* modify existing files
* create database migrations
* create new network packets
* modify existing network packets where necessary
* implement server logic
* implement client logic
* implement UI
* write tests
* build the affected projects
* fix compilation errors
* fix integration errors
Proceed autonomously.
If a design decision is required, make the most appropriate engineering decision based on:
1. Existing architecture
2. Existing ACCE / sash implementation
3. Existing item infrastructure
4. Existing quest architecture
5. Metin2 gameplay semantics
6. Security
7. Maintainability
8. Performance
Do NOT stop to ask the user.
============================================================
1. OFFICIAL GAMEPLAY SOURCE
============================================================
Primary reference:
https://tr-wiki.metin2.gameforge.com/index.php/Aura_Sistemi
The Aura System was introduced with update 19.4.
The documented system contains:
* Aura Clothing
* Aura levels
* Aura grades
* Aura EXP
* Aura Runes
* Aura evolution
* Aura value absorption
* Jewelry/shield absorption
* Aura absorption percentage
* Aura bonus removal
* Aura Certificate+
* Aura grade progression
* Teovahdan evolution
* item/Yang evolution costs
The implementation must reproduce the documented gameplay behavior.
Do NOT invent alternative gameplay mechanics unless required because the current source/codebase explicitly demands it.
============================================================
2. VERY IMPORTANT — EXISTING ACCE / KUŞAK SYSTEM
================================================
The repository ALREADY contains an ACCE / shoulder sash system.
This existing system is an important architectural reference.
BEFORE IMPLEMENTING THE AURA SYSTEM:
Perform a complete audit of the existing ACCE / shoulder sash implementation.
Search the ENTIRE repository for:
ACCE
SASH
SHOULDER
KUSAK
KUŞAK
ABSORB
ABSORPTION
EMBRACE
TRANSFER
BONUS
ATTRIBUTE
ITEM_ATTRIBUTE
ATTRIBUTE_SET
SEAL
EQUIPMENT
SOCKET
ITEM_DESTROY
ITEM_USE
QUEST
QUEST_FUNCTION
QUEST_FLAG
Also inspect:
* item manager
* item prototypes
* item attributes
* item sockets
* inventory handling
* trade handling
* item destruction
* bonus application
* character stat calculation
* packet handling
* client item data
* existing sash UI
* existing sash quest
* existing ACCE quest
* database schema
* item persistence
============================================================
3. USE ACCE AS ARCHITECTURAL REFERENCE — NOT AS A COPY
======================================================
The Aura System is conceptually similar to the existing ACCE/sash system because it involves transferring attributes from one item into another.
However:
DO NOT simply duplicate the ACCE implementation.
Instead:
1. Understand how ACCE represents the absorbed item.
2. Understand how ACCE stores absorbed values.
3. Understand how ACCE applies the resulting bonuses.
4. Understand how ACCE destroys the source item.
5. Understand how ACCE validates source/target items.
6. Understand how ACCE handles UI.
7. Understand how ACCE communicates with the server.
8. Understand how ACCE handles quests.
9. Understand how ACCE handles persistence.
10. Identify which components are reusable infrastructure.
11. Identify which components are specifically tied to weapons/armor and must NOT be reused.
Then design Aura on top of reusable infrastructure where appropriate.
If the ACCE implementation contains legacy/hard-coded behavior, do not propagate that technical debt into Aura.
============================================================
4. EXISTING ITEMS ARE ALREADY PRESENT
=====================================
The required Aura-related items already exist in the item prototype/database.
DO NOT create duplicate items unnecessarily.
Inspect the existing item proto first.
Find the exact item IDs and definitions for:
Aura Clothing
Aura Runes
Aura Certificate+
Aura evolution materials
Akik
Basit Kaos Taşı
Güzel Kaos Taşı
Görkemli Kaos Taşı
Auranın Buz Runiği
Auranın Ateş Runiği (10)
Auranın Ateş Runiği (50)
Auranın Ateş Runiği (100)
Auranın Ateş Runiği (250)
Auranın Ateş Runiği (500)
Also inspect all existing:
* jewelry
* shields
* bracelets
* necklaces
* earrings
Do not hard-code guessed item IDs.
Use the existing proto definitions.
If an item exists but has an incomplete definition, repair the definition rather than creating a duplicate item.
============================================================
5. EXISTING QUEST ARCHITECTURE
==============================
The repository already contains ACCE-related quest logic.
Inspect the ACCE quest implementation carefully.
Determine:
* how NPC interaction is implemented
* how item insertion is handled
* how source/target items are validated
* how Yang is handled
* how item destruction is performed
* how success/failure is reported
* how client UI is opened
* how quest state is synchronized
* how item IDs are passed
* how item attributes are read
* how item attributes are written
Then use the same established quest architecture where appropriate.
However:
DO NOT blindly copy the ACCE quest.
Aura has different source item types:
Aura absorbs:
* Bracelets
* Necklaces
* Earrings
* Shields
Aura does NOT use the same weapon/armor absorption rules as the shoulder sash system.
============================================================
6. CORE CONCEPT
===============
The Aura Clothing is the target.
The jewelry/shield is the source.
Conceptually:
SOURCE ITEM
|
| absorb
v
AURA CLOTHING
|
+-- absorbed bonus values
+-- Aura absorption percentage
+-- Aura level
+-- Aura EXP
+-- Aura grade
+-- evolution state
+-- active state
The source item is destroyed after successful absorption.
The Aura Clothing remains.
============================================================
7. SOURCE ITEMS
===============
Aura may absorb:
1. Bracelets
2. Necklaces
3. Earrings
4. Shields
The absorbed item provides ALL of its bonuses.
This includes:
* base item bonuses where applicable
* item attributes
* bonus attributes
* relevant additional bonuses
The exact attribute set must be determined from the existing item/attribute infrastructure and the official Aura rules.
Do not assume only the first four/five attributes.
Do not accidentally ignore attributes that are legally part of the source item's bonus state.
============================================================
8. SOULBOUND / TRADE RESTRICTIONS
=================================
Aura Certificate+ cannot be used on soulbound items.
Implement this validation server-side.
Do not trust client UI restrictions.
The server must reject:
* soulbound source item
* invalid source item
* source item from another owner
* source item currently locked by trade
* source item currently used by another system
* source item already reserved for another operation
============================================================
9. SOURCE ITEM DESTRUCTION
==========================
Successful Aura absorption destroys the source item.
This operation MUST be atomic.
Example:
Validate Aura
+
Validate source item
+
Calculate absorbed bonuses
+
Calculate absorption
+
Persist Aura
+
Destroy source item
If any step fails:
ROLL BACK.
Never create:
Aura bonus applied
+
source item still present
unless the transaction intentionally failed and state is restored.
Never create:
source item destroyed
+
Aura not updated.
============================================================
10. AURA ENTITY / ITEM MODEL
============================
Determine whether the existing codebase represents Aura Clothing as:
* an item with extended sockets
* an item with attributes
* a special persistent object
* another representation
Use the existing infrastructure where safe.
However, Aura state must be modeled cleanly.
At minimum the system needs to persist:
Aura item identity
Aura level
Aura EXP
Aura grade
Aura evolution state
absorption percentage
absorbed source item identity/type if required
absorbed bonus values
active/inactive state
Do not store arbitrary state in unrelated item fields.
Do not overload unrelated sockets unless the existing item architecture explicitly defines them for this purpose.
============================================================
11. AURA GRADES
===============
Implement the official six Aura grades:
1. General Aura Clothing
2. Plain Aura Clothing
3. Noble Aura Clothing
4. Brilliant Aura Clothing
5. Fancy Aura Clothing
6. Shining Aura Clothing
Level ranges:
General:
1–49
Plain:
50–99
Noble:
100–149
Brilliant:
150–199
Fancy:
200–249
Shining:
250
Use an explicit enum.
Do NOT determine the grade through scattered magic numbers.
Create one authoritative:
AuraGradeCalculator
============================================================
12. MAXIMUM LEVEL
=================
Maximum Aura level:
250.
At level 250:
Aura is at final grade:
Shining Aura Clothing.
No EXP beyond the maximum should create overflow corruption.
Define deterministic behavior for excess EXP.
============================================================
13. AURA EXP
============
Aura can gain EXP through Aura Runes.
Documented Rune values:
Auranın Buz Runiği:
1 EXP
Auranın Ateş Runiği (10):
10 EXP
Auranın Ateş Runiği (50):
50 EXP
Auranın Ateş Runiği (100):
100 EXP
Auranın Ateş Runiği (250):
250 EXP
Auranın Ateş Runiği (500):
500 EXP
These must be read from the existing item definitions/configuration where possible.
Do not hard-code item IDs.
============================================================
14. EXP REQUIRED PER LEVEL
==========================
Documented EXP requirement depends on Aura grade:
General:
1,000 EXP per level
Plain:
2,000 EXP per level
Noble:
4,000 EXP per level
Brilliant:
8,000 EXP per level
Fancy:
16,000 EXP per level
Shining:
Final
Implement exact level progression.
Do not accidentally make the requirement cumulative if the official system uses per-level EXP.
Use an explicit AuraExperienceCalculator.
============================================================
15. LEVEL PROGRESSION
=====================
Aura levels:
1 → 250
Grade transitions:
49 → evolution → 50
99 → evolution → 100
149 → evolution → 150
199 → evolution → 200
249 → evolution → 250
Evolution is required at these thresholds.
Evolution always succeeds.
Do NOT implement a random success chance.
============================================================
16. AURA EVOLUTION
==================
Aura evolution occurs through Teovahdan.
Implement the documented materials.
GENERAL → PLAIN
Source:
General Aura Clothing
Required:
Akik ×10
Yang:
5,000,000
PLAIN → NOBLE
Source:
Plain Aura Clothing
Required:
Basit Kaos Taşı ×10
Yang:
5,000,000
NOBLE → BRILLIANT
Source:
Noble Aura Clothing
Required:
Güzel Kaos Taşı ×10
Yang:
5,000,000
BRILLIANT → FANCY
Source:
Brilliant Aura Clothing
Required:
Görkemli Kaos Taşı ×10
Yang:
8,000,000
FANCY → SHINING
Source:
Fancy Aura Clothing
Required:
Görkemli Kaos Taşı ×20
Yang:
10,000,000
Evolution must always succeed.
============================================================
17. EVOLUTION ATOMICITY
=======================
Evolution must be transactional.
Validate:
* correct Aura
* correct level
* correct grade
* correct materials
* correct Yang
* inventory space if needed
* no trade lock
* no concurrent operation
Then:
consume materials
consume Yang
change grade
change item visual/state
persist
notify client
If any step fails:
nothing is consumed.
============================================================
18. AURA ABSORPTION
===================
This is the central Aura mechanic.
Aura absorbs the values of:
* bracelet
* necklace
* earrings
* shield
The source item is destroyed.
Aura receives the source item's bonuses multiplied by the Aura absorption percentage.
Example:
Source bonus:
20% Critical Hit Chance
Aura absorption:
25%
Result:
20 × 0.25 = 5
Therefore Aura grants:
5% Critical Hit Chance
Implement the exact documented rounding behavior.
============================================================
19. ABSORPTION PERCENTAGE
=========================
Aura absorption percentage depends on Aura grade.
Higher Aura grade means higher absorption.
Maximum:
25%.
Create a centralized:
AuraAbsorptionCalculator.
Do NOT duplicate this formula in:
* UI
* server
* quest
* item manager
* packet handler
There must be one authoritative server-side calculation.
If the exact grade percentage is not explicitly present in the current source/reference, inspect the existing game data/code and document the discovered values before implementing them.
Do NOT invent percentages.
============================================================
20. ROUNDING RULE
=================
This is critical.
The official documentation states:
If the resulting value is smaller than 1, the result becomes 1.
Otherwise decimal places are rounded DOWN.
Examples:
1.32 → 1
0.92 → 1
1.92 → 1
Therefore:
result = floor(source_value × absorption_rate)
BUT:
if result < 1:
result = 1
Apply the rule consistently.
Do not use ordinary round().
Do not use bankers rounding.
Do not use floating-point comparisons if avoidable.
Use deterministic fixed-point/integer arithmetic.
============================================================
21. ALL BONUS TRANSFER
======================
Aura must receive all applicable bonuses from the source item.
Create a generic:
AuraAbsorbedBonusSet
rather than supporting only a fixed small number of bonuses if the item system allows more.
Each absorbed bonus should preserve:
* bonus type
* original value
* absorbed value
This allows:
debugging
recalculation
future changes
display
migration
Do not store only the final values if doing so makes auditing impossible.
============================================================
22. BASE ITEM BONUS VS RANDOM ATTRIBUTE
=======================================
Inspect how the current Metin2 item system represents:
* base bonuses
* item attributes
* special attributes
* sockets
* set bonuses
* item effects
Determine exactly which values Aura legally absorbs.
Do NOT accidentally absorb:
* sockets
* upgrade materials
* item level
* durability
* attack damage
* defense
* price
* stack count
unless the official Aura mechanic explicitly says so.
The source item's BONUS STATE must be distinguished from unrelated item metadata.
============================================================
23. AURA BONUS REMOVAL
======================
Implement Aura Certificate+.
Aura Certificate+ removes Aura bonuses.
Documented restriction:
It cannot be used on soulbound items.
The operation must:
1. Validate Aura.
2. Validate Aura Certificate+.
3. Validate soulbound state.
4. Remove absorbed bonus state.
5. Consume certificate.
6. Persist.
7. Notify client.
Do not destroy the Aura itself.
Do not reset:
* Aura level
* Aura EXP
* Aura grade
unless the official mechanic explicitly requires it.
The certificate removes the absorbed bonus state.
============================================================
24. RE-ABSORPTION
=================
Define safe behavior for absorbing into an Aura that already contains bonuses.
Do not overwrite silently.
Determine from the official system / existing game behavior whether:
* new absorption replaces old absorption
* old bonuses must first be removed
* the system allows reabsorption directly
Implement the actual rule.
Do not invent behavior.
If source/game data is ambiguous, inspect the existing implementation/data before proceeding.
============================================================
25. SOULBOUND VALIDATION
========================
The server must check soulbound status.
Client restrictions are not sufficient.
Aura Certificate+ must fail on:
* soulbound Aura
* invalid target
* missing certificate
Use existing soulbound flags/attribute infrastructure.
============================================================
26. ITEM LOCKING
================
Before Aura operations:
Lock:
* target Aura
* source item
* required materials
* required currency
Prevent simultaneous operations.
Examples:
Player sends two absorption packets simultaneously.
Only one operation may succeed.
Player sends absorption + trade simultaneously.
Trade must not steal the source item mid-operation.
Player sends evolution + item move simultaneously.
Inventory state must remain consistent.
============================================================
27. SERVER AUTHORITY
====================
The client MUST NOT be trusted for:
Aura level
Aura EXP
Aura grade
Aura absorption percentage
absorbed bonus values
source item bonuses
source item identity
Yang cost
material count
evolution result
Client only requests:
"Perform Aura operation X."
Server validates and calculates everything.
============================================================
28. NETWORK PROTOCOL
====================
Audit existing ACCE packet architecture.
Reuse generic packet infrastructure where appropriate.
Create explicit Aura operations.
Conceptually:
AURA_OPEN
AURA_CLOSE
AURA_INFO
AURA_ABSORB_REQUEST
AURA_ABSORB_RESULT
AURA_REMOVE_BONUS_REQUEST
AURA_REMOVE_BONUS_RESULT
AURA_EXP_REQUEST
AURA_EXP_RESULT
AURA_EVOLUTION_REQUEST
AURA_EVOLUTION_RESULT
AURA_ERROR
Use actual project naming conventions.
Every packet must:
* validate length
* validate enum
* validate item slots
* validate item IDs
* validate ownership
* validate state
* reject malformed data
============================================================
29. NO CLIENT-SIDE CALCULATION AUTHORITY
========================================
The client may display:
Source bonus:
20%
Absorption:
25%
Final:
5%
But the client must not decide:
5%.
Server sends authoritative final value.
The client should render the server result.
============================================================
30. DATABASE PERSISTENCE
========================
Inspect existing item persistence first.
If Aura is represented as an item, determine whether its absorbed state can be safely persisted using the existing item attribute/socket system.
If not:
create a dedicated Aura persistence structure.
Possible conceptual structure:
AuraState
{
ItemID
Level
EXP
Grade
AbsorptionRate
AbsorbedBonuses
Version
}
Do not create a parallel database if existing item persistence can represent the data safely.
Do not corrupt legacy item fields.
============================================================
31. VERSIONING
==============
Aura state must have a version.
Example:
AuraStateVersion = 1
This allows future changes to:
* bonus format
* absorption format
* new Aura grades
* new bonus types
* new source item types
without corrupting existing Auras.
============================================================
32. UI
======
Implement a complete Aura UI.
The UI must display:
* Aura Clothing
* Aura grade
* Aura level
* Aura EXP
* EXP progress
* absorption percentage
* absorbed bonuses
* source item preview
* resulting bonus preview
* evolution requirements
* evolution state
* required materials
* Yang cost
* Aura Certificate+ operation
* Rune insertion
* success/error states
UI should be similar in usability to the existing ACCE/sash UI where appropriate.
Do NOT copy weapon/armor-specific UI assumptions.
============================================================
33. ABSORPTION PREVIEW
======================
When a player places an eligible source item into the Aura UI:
Show:
SOURCE BONUS
×
AURA ABSORPTION
===============
FINAL AURA BONUS
Example:
Critical Hit:
20%
Aura absorption:
25%
Result:
5%
The preview is informational.
Server remains authoritative.
============================================================
34. SOURCE ITEM VALIDATION
==========================
Allowed source types:
BRACELET
NECKLACE
EARRING
SHIELD
Reject:
weapon
armor
costume
helmet
shoe
belt
sash
pet
mount
alchemy
other unrelated items
Unless the official game data explicitly indicates otherwise.
Do not infer item eligibility solely from inventory position.
Use item type/subtype/proto.
============================================================
35. AURA ITEM VALIDATION
========================
Target must be an actual Aura Clothing.
Validate:
* item type
* item subtype
* ownership
* not destroyed
* not traded
* not locked
* not soulbound if the operation forbids it
* valid Aura state
============================================================
36. RUNE LEVELING
=================
Implement Aura Rune consumption.
Supported rune EXP:
1
10
50
100
250
500
The player may add runes according to the existing UI mechanics.
Server validates every rune.
Rune consumption and EXP gain are atomic.
No duplicate EXP.
No negative EXP.
No level overflow.
============================================================
37. BULK RUNE OPERATIONS
========================
If the existing UI allows multiple runes:
Support bulk application efficiently.
Do not send 500 separate packets if one atomic operation can safely process them.
However:
Every consumed item must be validated.
If operation fails:
rollback all consumption.
============================================================
38. EXP REQUIREMENT TRANSITIONS
===============================
At each level:
Deduct the required EXP according to the game's actual model.
If a Rune causes multiple levels:
process all level-ups deterministically.
If the level reaches:
49
99
149
199
249
stop at the evolution boundary if evolution is mandatory before further leveling.
Do not silently jump:
49 → 52
without evolution.
============================================================
39. EVOLUTION GATE
==================
When Aura reaches:
49
99
149
199
249
it must enter:
EVOLUTION_REQUIRED
state.
The Aura cannot proceed beyond that grade until evolution is completed.
The UI must clearly display:
Evolution required.
============================================================
40. AURA STATE MACHINE
======================
Use explicit states where appropriate.
Example:
NORMAL
EVOLUTION_REQUIRED
MAX_LEVEL
OPERATION_LOCKED
Do not rely on dozens of booleans.
============================================================
41. CONCURRENCY
===============
Protect against:
double absorption
double Rune consumption
double evolution
double certificate use
duplicate bonus removal
trade during absorption
destroy during absorption
disconnect during operation
Use transaction locking/versioning.
============================================================
42. DISCONNECT SAFETY
=====================
If the player disconnects during:
Aura absorption
Aura evolution
Rune insertion
Aura Certificate operation
the server must leave the database in a valid state.
Never rely on client completion.
============================================================
43. SERVER RESTART SAFETY
=========================
After server restart:
Aura state must remain exactly correct.
Verify:
level
EXP
grade
absorbed bonuses
absorption percentage
evolution state
No state should depend solely on RAM.
============================================================
44. TRADE SAFETY
================
Auras and source items may be subject to existing trade rules.
Audit current trade behavior.
Prevent an item from being:
* traded
* absorbed
* destroyed
simultaneously.
Lock the item during Aura operation.
============================================================
45. ITEM DUPLICATION PROTECTION
===============================
Explicitly test:
Aura absorption + disconnect.
Aura absorption + packet replay.
Aura absorption + simultaneous trade.
Aura evolution + disconnect.
Rune EXP + packet replay.
Certificate + packet replay.
No operation may duplicate:
items
Yang
EXP
Aura bonuses.
============================================================
46. LOGGING
===========
Create structured Aura audit logs.
Events:
AURA_CREATED
AURA_EXP_GAINED
AURA_LEVEL_UP
AURA_ABSORBED
AURA_BONUS_REMOVED
AURA_EVOLVED
AURA_RUNE_USED
AURA_OPERATION_FAILED
Include:
timestamp
character ID
Aura item ID
source item ID
source item type
old level
new level
old grade
new grade
old bonus state
new bonus state
absorption percentage
Yang delta
materials consumed
result
Do not log sensitive account credentials.
============================================================
47. GM DEBUGGING
================
Implement:
/aura info <itemid>
Display:
Aura Item ID
Level
EXP
Grade
Absorption Rate
Evolution State
Absorbed Bonuses
Original Values
Final Values
Version
Soulbound State
Owner
Lock State
This is essential for debugging.
============================================================
48. DATA-DRIVEN CONFIGURATION
=============================
Do not scatter:
1000
2000
4000
8000
16000
5000000
8000000
10000000
25%
throughout the source code.
Create centralized configuration.
Example:
AuraConfig
{
MaxLevel
MaxAbsorption
GradeDefinitions
RuneDefinitions
EvolutionDefinitions
SourceItemRules
BonusRules
}
============================================================
49. SOURCE ITEM RULE CONFIGURATION
==================================
Configure:
BRACELET
NECKLACE
EARRING
SHIELD
as valid source types.
Future source item types should be addable without rewriting core Aura logic.
============================================================
50. BONUS SYSTEM INTEGRATION
============================
Aura bonuses must integrate with the existing character stat system.
Do NOT create a parallel combat-stat system.
If the character currently calculates bonuses through:
POINT_MAX_HP
POINT_DEF_GRADE
POINT_CRITICAL_PCT
POINT_RESIST_SWORD
etc.
Aura must use the existing mechanism.
Aura should contribute another source of those bonuses.
============================================================
51. BONUS LIFECYCLE
===================
When Aura becomes active:
Apply Aura bonuses.
When Aura is removed/unequipped:
Remove Aura bonuses.
When Aura bonuses change:
Remove old state
+
apply new state.
Never stack old + new.
Relog must reconstruct the correct state.
============================================================
52. CLIENT PRESENTATION VS SERVER STATE
=======================================
Client:
display.
Server:
calculate.
Database:
persist.
This separation must be maintained.
============================================================
53. TESTING
===========
Write unit tests for:
Aura grade calculation
Aura EXP calculation
Rune EXP
Level progression
Maximum level
Evolution thresholds
Evolution material validation
Evolution Yang validation
Evolution success
Absorption percentage
Absorption rounding
Minimum 1 rule
All source item types
Invalid source item
Soulbound restriction
Bonus transfer
Bonus removal
Certificate use
Concurrent absorption
Packet replay
Disconnect during absorption
Disconnect during evolution
Server restart
Trade race
Item duplication prevention
============================================================
54. PROPERTY TESTS
==================
Invariant:
Aura level <= 250.
Aura EXP >= 0.
Absorption <= 25%.
Final bonus never negative.
If source bonus > 0:
final absorbed bonus >= 1.
Evolution always succeeds after validation.
Aura cannot evolve without required materials.
Aura cannot level beyond an evolution boundary.
Source item cannot remain after successful absorption.
Source item cannot be destroyed after failed absorption.
============================================================
55. PERFORMANCE
===============
Do not query database on every UI refresh.
Do not recalculate Aura bonuses every frame.
Cache static configuration.
Calculate only when:
Aura changes
Aura equipped
Aura unequipped
character loads
Aura state changes
Avoid unnecessary packets.
============================================================
56. LEGACY CODE AUDIT
=====================
Before writing new Aura logic:
Create:
AURA_SYSTEM_AUDIT.md
Document:
* existing ACCE architecture
* reusable ACCE infrastructure
* legacy ACCE limitations
* item prototype definitions
* existing Aura-related item IDs
* existing quests
* existing packet structures
* existing UI
* database representation
* item attribute infrastructure
* item destruction mechanisms
* trade locking mechanisms
* stat application mechanisms
Then create:
AURA_SYSTEM_DESIGN.md
Then implement immediately.
Do NOT wait for user approval.
============================================================
57. FILES / QUESTS
==================
Inspect the existing ACCE files and quests.
If the current ACCE quest has reusable concepts:
reuse the architecture.
But create Aura-specific quest/service logic.
Do NOT put all Aura gameplay inside a quest script if the server architecture supports proper C++ service logic.
Prefer:
Quest/UI
↓
Network Request
↓
AuraService
↓
AuraValidator
↓
AuraCalculation
↓
Item/Character/DB transaction
↓
Network Result
============================================================
58. PROPOSED MODULES
====================
Use architecture similar to:
AuraSystem
Aura
AuraManager
AuraService
AuraRepository
AuraConfig
AuraValidator
AuraAbsorption
AuraExperience
AuraEvolution
AuraBonus
AuraNetwork
AuraUI
AuraAuditLogger
Names may be adapted to the repository.
The important requirement is responsibility separation.
============================================================
59. IMPORTANT DIFFERENCE FROM KUŞAK
===================================
Do NOT assume:
Aura = Kuşak.
They are related systems but not identical.
Kuşak:
existing ACCE implementation
different source equipment rules
different absorption semantics
Aura:
source items:
Bracelet
Necklace
Earring
Shield
Aura has:
Level
EXP
Grades
Evolution
Runes
Aura Certificate+
25% maximum absorption
Therefore:
reuse infrastructure where appropriate,
but implement Aura-specific business rules.
============================================================
60. OFFICIAL MECHANICS TO REPRODUCE
===================================
The implementation must reproduce the following documented mechanics:
Aura introduced with update 19.4.
Aura Clothing can level up.
Aura Clothing can evolve.
Aura receives transferred values from:
Bracelets
Necklaces
Earrings
Shields
Transferred source item is destroyed.
Aura receives all applicable bonuses from the source item.
Absorption percentage increases with Aura grade.
Maximum absorption:
25%.
If calculated value is below 1:
result becomes 1.
Otherwise:
decimal portion is rounded down.
Aura Certificate+ removes Aura bonuses.
Aura Certificate+ cannot be used on soulbound items.
Aura Runes provide:
1
10
50
100
250
500
EXP.
Grade progression:
General 1–49
Plain 50–99
Noble 100–149
Brilliant 150–199
Fancy 200–249
Shining 250
Evolution thresholds:
49
99
149
199
249
Evolution always succeeds.
Evolution is performed through Teovahdan.
Evolution costs:
General → Plain:
Akik ×10
5,000,000 Yang
Plain → Noble:
Basit Kaos Taşı ×10
5,000,000 Yang
Noble → Brilliant:
Güzel Kaos Taşı ×10
5,000,000 Yang
Brilliant → Fancy:
Görkemli Kaos Taşı ×10
8,000,000 Yang
Fancy → Shining:
Görkemli Kaos Taşı ×20
10,000,000 Yang
============================================================
61. DO NOT GUESS MISSING VALUES
===============================
If the official documentation does not expose an exact numeric value:
DO NOT INVENT IT.
Search:
existing source
existing item data
existing ACCE/Aura code
game data
database
official documentation
existing client data
If the value can be derived reliably, document the derivation.
If it cannot:
implement the system so the value is configuration-driven and record the unresolved value in:
AURA_SYSTEM_IMPLEMENTATION_REPORT.md
Do not silently guess.
============================================================
62. BUILD REQUIREMENT
=====================
After implementation:
Build all affected server projects.
Build all affected client projects.
Fix compilation errors.
Fix linkage errors.
Fix protocol mismatches.
Fix database errors.
Run tests.
Do not stop at:
"Code has been written."
The feature must compile.
============================================================
63. END-TO-END TEST
===================
Perform this complete scenario:
1. Create/find Aura Clothing.
2. Open Aura UI.
3. Find bracelet.
4. Put bracelet into Aura.
5. Preview bonuses.
6. Execute absorption.
7. Verify bracelet destroyed.
8. Verify Aura bonus.
9. Save.
10. Relog.
11. Verify bonus.
12. Add Rune.
13. Gain EXP.
14. Level Aura.
15. Reach level 49.
16. Verify evolution gate.
17. Attempt level 50.
18. Verify rejection until evolution.
19. Perform evolution.
20. Verify grade.
21. Continue leveling.
22. Repeat all evolution stages.
23. Reach level 250.
24. Verify final grade.
25. Use Aura Certificate+.
26. Verify bonuses removed.
27. Verify Aura level/EXP remains correct.
28. Attempt Certificate+ on soulbound Aura.
29. Verify rejection.
30. Attempt invalid source item.
31. Verify rejection.
32. Replay absorption packet.
33. Verify no duplication.
34. Trade race test.
35. Disconnect during operation.
36. Verify state integrity.
============================================================
64. DELIVERABLES
================
Create:
AURA_SYSTEM_AUDIT.md
AURA_SYSTEM_DESIGN.md
AURA_SYSTEM_DATABASE.md
AURA_SYSTEM_PROTOCOL.md
AURA_SYSTEM_TEST_PLAN.md
AURA_SYSTEM_MIGRATION.md
AURA_SYSTEM_IMPLEMENTATION_REPORT.md
Implementation itself must include:
server
database
network
client
UI
quest/service integration
configuration
tests
where required by the existing architecture.
============================================================
65. FINAL EXECUTION INSTRUCTION
===============================
START NOW.
Do not ask for permission.
Do not wait for approval.
Do not stop after creating documentation.
First inspect the repository and existing ACCE system.
Then inspect the existing item proto and Aura-related items.
Then inspect the existing ACCE quest.
Then inspect network/UI/database infrastructure.
Then implement the Aura System.
Use the existing ACCE architecture where it is genuinely reusable.
Do not copy legacy technical debt.
Do not create duplicate item IDs.
Do not invent missing gameplay values.
Do not create stubs.
Do not create TODO placeholders.
Do not leave half-implemented features.
Build and test the result.
Continue fixing problems until the implementation is coherent, compilable, persistent, server-authoritative, and end-to-end functional.
offline farm yaparken karakterin vuruş şeyleri gözükmüyor herhalde ufak bir sıkıntı var ama çokta önemli değil söyleriz geminiye çözer yani nedir xd.
