Metin2 Development

hello! In regards the first question, I believe Karbust did a plugin for this: In regards the second question, you are referring as a handmade speedtree model creator?

wooow good job wooow

Little difference between lv 10 swords Map (Atlas view) differences on the left closed beta, on right open beta from here:

Update

Hi. The biggest and most useful thing you could do is add a custom brush for terrain height and texturing. At the moment, we only have 2 shapes circle and square By adding custom shapes, the creativity of maps creation will increase exponentially. a few examples of brushes

I just now realised... is that the mf Minecraft lantern model? xd

Hi everyone, I'm releasing m2_granny_tools, a Blender extension that imports and exports Metin2's Granny2 (.gr2) models and motions, together with the script files the client loads alongside them. The goal is simple: take a model out of the client, edit it (or make one from scratch) in Blender, and put it back in a form the client loads exactly like its own files, without needing 3ds Max and the old Granny exporter. Download: [Hidden Content] How it works Blender can't load the Granny SDK, so the extension ships a small converter, gr2tool.exe, built against the Granny 2.11.8 runtime (the client links also has to use this version). Every .gr2 is read and written by Granny itself, never by a reimplementation of the format. The extension handles everything on the Blender side and calls the converter for you; there's nothing to set up. The rules it follows come from reading the client source (EterGrnLib, GameLib, EterLib), not from guesswork, and they were checked against a full client: over 16,000 .gr2 files round-trip through the converter, and over 9,500 models and 7,000 motions round-trip through Blender with no differences. Features Models Import and export of characters, armors, monsters, NPCs, weapons and zone buildings. Always writes a file the client accepts: 32-bit, the model named after its root bone, and only the two vertex layouts the client handles (skinned PWNT3432 and rigid PNT332). Lossless round trip: importing and exporting a shipped file without changes gives back the same data, odd entries included. Only what you edited changes. Weapons and buildings: an unrigged mesh exports as a single-bone rigid model, as the Max exporter wrote them. Optional vertex colours, matching Max's output. Keeps the bind pose of scaled bones (the cloth and attachment helpers on player rigs) that Blender's rest pose can't represent, so skinned vertices don't drift. Motions Import and export of .gr2 motions. Motions you didn't touch keep their original curves exactly; edited ones are resampled and fitted to B-splines with the same tolerance and degree options as the Granny Max exporter. Motions + Motion List writes the whole set the client needs: one .gr2 and one .msa per action, plus motlist.txt. .msa extras from action properties: loops, accumulation (movement), motion events (effects, sounds, fly, screen waving, show/hide, warp, ...), attack data (AttackingData: hit type, stiffen/invisible time, swept hit segments) and combo input windows. Each is checked against what the client's loader requires, so a bad entry is reported instead of breaking the whole motion. Textures and materials Per-material texture paths, editable in the export dialog, with the path it will write shown before you export. Files under a ymir work folder automatically become d:\ymir work\... pack paths. Follows the client's material rules: diffuse alpha is the specular mask (not transparency), two-sided materials, and alpha cut-outs (helmet crests, leaves) through an opacity map. Warns you when moving a texture would silently break a .msm skin swap (monster colour variants). Client scripts beside the model .msm race scripts: reads them and writes them back with your new paths. Everything else (attach points, effects, comments) is kept byte for byte. Collision spheres and attached effects are editable as empties on the bones. .mdatr collision and height: imports collision shapes and walkable height meshes for zone objects, and writes them back. It can also write an empty file, so a building is walk-through on purpose instead of getting the client's automatic bounding box. All 2,912 .mdatr files of a client round-trip byte-identical. Working with 3ds Max Export a model's skeleton as FBX for 3ds Max (File > Export > Granny2 Skeleton for 3ds Max every bone at its bind pose, in centimetres with Max's axes, ready to skin against. Max brings the bones in as Dummy helpers, which skin and animate like bones. A model rigged and skinned in Max can come into Blender as FBX and go out as a client .gr2. Bind Pose from FBX recovers the bone scales Blender drops on import. Quality of life Export presets (safe JSON, never run as code), with a 3ds Max weapon preset included that matches a Max exporter setup. Clear reports after every export: what path each material got and why, what was left out, and what to fix. Tested in game A new armor on an existing skeleton, with new materials. A model skinned in 3ds Max against an exported skeleton. A monster's .msm collision and an attached effect, then restored to the original. Textures in a custom folder under d:\ymir work\. Requirements Windows x64. Blender 4.2 or newer (developed on Blender 5.2). Your client's .dds textures on disk if you want to see them in Blender. The .gr2 stores only texture paths, and the extension never copies or converts images. Installation Download io_scene_gr2-0.1.0.zip from the release page. Don't unzip it. In Blender: Edit > Preferences > Get Extensions, then the dropdown in the top right, Install from Disk..., and pick the zip. Everything is under File > Import and File > Export as Granny2 .... Known limitations Blender pose keys can't hold shear, so resampling a sheared bone is approximate. Motions you don't edit are unaffected. Of the two curve modes, the quantized one fits a few motions slightly less precisely (under half a centimetre). It targets clients on the Granny 2.11 runtime (32-bit .gr2). Feedback wanted This is the first public release, and it's only been tested on my own client, so your input matters. Please reply in this thread, or message me on Discord (karbust), if you: Found a bug: a file that won't import, an export the client refuses or crashes on, or a model that looks or moves differently in game than in Blender. Have a file that behaves oddly: clients differ, and odd files are exactly what I need to test against. Miss a feature or have an idea for your workflow. Just used it: what worked, what was confusing, what took too many steps. For bugs, it helps a lot to include: The Blender version and the extension version (0.1.0). What you did, step by step (import, what you edited, which export options). The export report or error message (copy the text from Blender's Info area or the system console). The file itself or the client path of the model (e.g. ymir work/monster2/raptor), plus a screenshot if it's visual. Don't want to share your model publicly? No problem. Send it to me privately on Discord (karbust) instead. I'll only use it to reproduce and fix the issue, and won't share it with anyone. Thanks, and have fun modelling!

Balancing the game is not only drop percentages. It all depends on the systems you have and will be using on progression. It depends on a lot of things and i believe there is no right answer for your question. You just need to do your balancing and test. Re-balance and test. Re-balance and test. And that's it. There is no server that launches with perfect balance. People always complain about something and changes are made. You just need to find your formula.

Thanks @StormyFF, looking forward to see your unique project running.

THANCKS