Mabinogi Technical Info (Updated 4/27/2015)

• Rydian wrote on 2013-11-17 05:02
  Mabinogi Technical Info

  
  
  This thread is for me to post any interesting technical info I find about Mabinogi. The findings will be loosely-organized and include my theories on why things work the way they do. This data was gathered from the client (mostly while it was running), I'm not hacking the game servers or FBI wiretapping Nexon's toilet stalls. Do note that I'm not an expert hacker or anything so I'm missing insight into some things and a lot of data I have is incomplete, so if you have any questions or additions feel free to post.
  
  
  
  Graphics / RAWs
  
  /data/color/metal.raw
  256x256 @24BPP
  

  [Image: http://s23.postimg.org/rnh4c63u3/metal.png]

  
  Somebody at devcat was both happy and perturbed at making gradients and swatches.
  
  /data/gfx/gui/minimap_dungeon.raw
  128x128 @ 24BPP
  

  [Image: http://s12.postimg.org/szcb6bgah/minimap_dungeon.png]

  
  I guess save rooms and chest rooms might have been an idea they were playing with originally?
  
  The fossil images for fossil restoration are stored in the raw format too (200x200, 24 bpp).
  

  [Image: http://s12.postimg.org/cw2yn2nhp/fossil_pelvis.png]

  [Image: http://s12.postimg.org/bkv7elrvx/fossil_shooting_star.png]

  [Image: http://s12.postimg.org/8cqq1k5m5/fossil_skull.png]

  
  The raw images look quite nice outside of that dirty fossil display!
  
  I assume they're using raw images opposed to compressed textures because DXT compresses based on 4x4 blocks, whereas they need pixel-perfect translucency for the minigame, otherwise it'd be uglier (even blockier) and they'd need to use square brushes or less visually-appealing fossils.
  
  
  
  Coordinates / Movement
  
  So I found the character's coordinates in RAM and was watching them for a bit as I did stuff.
  
  This can be used to tell how exactly a skill does or does not move you. Like how Smash's "movement" is just animation, you don't actually move. This is why, even if you appear to move over an item while smashing, you can't pick it up then, because your character is not actually on top of it, just the model is moved from it's origin point.
  
  On the other hand Shooting Rush immediately teleports you to the end the moment you start the skill (and your body and the camera following it are just playing out the animation). So if your opponent is using Natural Shield and you'd pass through them but not land inside the shield, the effect of the shield takes place since you're technically outside of it the whole time. On the other hand if you would land inside the shield, then since you're teleported there the moment the skill starts, it acts as if you did the entire skill from inside their shield.
  
  Also when you log in or dismount a pet, your coordinates are floored (rounded down to the units, the decimal chopped off). I don't think this could be used to squeeze through walls or anything though, unless you're very very patient and the game allows you to squeeze a tad more in each log-in.
  
  Anyways for some examples... standing inside the north Dunbarton gate, the Z corodinate is ~45028. At the south gate, it's ~31791. The east wall's X coordinate is ~46634 and at the west gate it's ~32537. So I can estimate that Dunbarton is ~13237 units from north to south and 14097 units from east to west. The housing boards appear to be ~234 units wide (the fat way).
  
  The origin of maps (at least the Dunbarton map) appears to be the SouthWest corner, not the NorthWest.
• Rydian wrote on 2013-11-17 05:02
  Stats
  
  I've managed to write some scripts that can let me view all the detailed stats of whatever character I'm logged into.
  
  

  [Image: http://i.imgur.com/nc4BXt3.png]

  
  
  [spoiler="Show ALL the stats! =D"]

  [Image: http://i.imgur.com/Z2252er.png]

  [/spoiler]
  
  Things of note...
  
  

  • Most stats are stored in the form of a base and then whatever additions do it are done to reach the final value. This means that some stats can reside in multiple places as pieces of themselves (so a stat that shows as 500 might be one piece that's 350 and one that's 100 and one that's the last 50) so it's sort of hard to find some of them because the stats screen only shows the final result for a lot of it.
    
    
    
  • Yes, your base stats can have fractions. And yes, these fractions are not displayed. The value is either floored or simply truncated for display, like a base 152.75 Will would show up as "152" in-game.
    
    
    
  • The "additional" stats are what's added onto the base to make the total. For all of your "core stats" (STR and such) it's simply one plus the other, though I've never seen the "additional" stat have a fraction except in the special case of heavy armor's DEX cut.
    
    
    
  • Potion poisoning is stored in the form of a negative float. So if you're missing 100 STR, your "Toxic STR" value is -100. This is simply added onto your current stats and it was never intended for this value to be non-negative so it doesn't have an upper bound check. This means that if you somehow manage to get negative potion poisoning, it'll add stats and the added stats can bypass the stat cap.
    
    [Image: http://i.imgur.com/ITpiFHK.jpg]
    
    
    
    
  • Your current HP, upon login, actually keeps regenerating past your max HP, but any sort of attempted change like getting healed (even if it does no visible change as you're at max) or getting hit will fix it back to normal. So it seems if there is a function that makes sure your current HP doesn't exceed your base then it's not foolproof (done after a change) or tick-based (routinely checked), but rather it's done per-function, probably copied in a couple of functions that would affect your HP.
    
    
    
  • It's kind of funny that your MP pool actually has only three addresses associated with it, versus four for HP and stamina... whereas magic is generally one of the more complex things stat-wise.
    
    
    
  • Your current MP can go negative.
    
    
    
  • As you can see with the stamina-hunger-conversion thing, most stats are floating-point and can raise and lower a small fraction at a time (and are rounded and slightly-inaccurate the further from the left you go). However outside of your "pools", stats are generally in quarters at the finest.
    
    
    
  • DEX comes before INT in RAM for the older stat values, despite it being the other way around on the character screen. And yes, it was like this before en/zero too.
    
    
    
  • AP is stored as a two-byte integer, so the max you can save up and display properly is 65535. This might cause issues with All Skill Reset Capsules down the line...
    
    
    
  • "The various damage addition slots are for things like Paladin bonuses, Bare Hands stats, weapon mastery bonuses, etc. In some cases they same bonus slot is added to multiple times, for example when duel-wielding you get the Sword Mastery damage bonus twice, the same slot is doubled.
    
    
    
  • Your minimum injury rate is capped at your max injury rate, even if you try to set it much higher.
    
    • Injury rate is displayed as a percentage, but it's not float in the client. It's an integer, (1 = 0.1% and 25 = 2.5%) and so on, it's just fancied-up for display.
    
    
    
  • No, I cannot read the stats of other players, other than their CP (I guess that's needed technically) and their HP (client needs that info to render their health bar).
    
    
    
  • The elemental stats seem to match the idea that the first level is ignored, as I put on a weapon with a level 2 elemental reforge and it went from 9/0/0/0 to 8/2/0/0, though it'll take more testing to see what's up.
    

  
  
  Stats listed with "???" don't match anything I know or have not been accurately found yet.
• Rydian wrote on 2013-11-17 05:02
  RP Dungeons/Quests
  
  If I get a lock on my stats and then enter an RP dungeon, my stats/data stay loaded and in the same addresses. So it looks at first glance like my character isn't unloaded while I'm in an RP dungeon. What's more interesting, though, is that my hunger/stamina conversion on the main character continues to happen over time while I'm in the RP dungeon on the RP character. The hunger/stamina gets reset to what it was before entering once I'm out though.
  
  In addition the main char gets set to interesting coordinates while I'm controlling the RP character too. 12207.27832, 0.0546875, 10385.33398 is just one example, they vary a bit from what I've seen (like maybe a hundred units or so). Since my character still gets hungry and has changed coordinates, it leads me to believe that the server just warps my main character to some hidden map for safekeeping while I'm in the RP dungeon. That Y coordinate being almost exactly 0 suggests it's not anywhere fancy, maybe just a flat plane.
  
  This makes sense, though. I have to keep adjusting the whole "character the stats are reading" data to point to myself (instead of other players or monsters or NPCs), which leads me to theorize that the client does not concern itself with such a concept as "the main character", it loads the player characters, NPCs, and monsters up in whatever order, all in the same fashion (and the client allocates memory for the stats of other things even if it doesn't know them), and then it just happens to control whichever of these pawns the server says to.
  
  

  Quote from Aubog007;1169479:

  Your ego also gets hungry and you lose durability as well.

  
  
  
  
  ~
• Rydian wrote on 2013-11-17 05:03
  Feature Toggle
  
  It seems that the Mabinogi client has the ability to run with certain features enabled or disabled. This could be used for testing, for devs to use the same installation for multiple regions, or whatever. One notable example is that the ability to view a reforge's actual stat edits is disabled by default for NA. Turning that feature back on and sticking an appropriate language file to pull from, and we can see the extra data that overseas has access to by default.
  
  

  [Image: http://s24.postimg.org/kw896k3tx/mabinogi_2014_03_06_021.jpg]

  
  (Seeing how the game tries to format the data versus the stats into a sentence, one possible reason NA doesn't have this is likely because the grammar would be as awkward as ever if they tried to make it into a sentence like other things.)
  
  What's most interesting is the sheer number of features that can be toggled on and off, and also what exactly is considered a "feature" that can be toggled or rolled back just by editing some of the package's data files (and no, not plaintext/xml ones). Do note that one major reason some things were implemented as a toggleable feature may be that the original devs know that not all regions would react to the same content the same way, and so put in a lot of stuff as toggle so that regions with cultures that don't like certain things could disable what they feel their players might not react well to. Anyways, here's a list of some of the more interesting examples that other people have found, along with my thoughts/notes.
  
  [php]gfFreeRebirth "I do remember hearing that the earliest versions of Mabi had no freebirth."
  
  gfVisualChat "Enable this in NA? DICKS EVERYWHERE."
  
  gfRelationSystem "That ErinnOn thing?"
  
  gfAliceCharaterCard "Was this character card (and title) possibly considered OP?"
  
  gfHumanPet "Going to refer to my maid as my HumanPet from now on."
  
  gfManaBurnRemove "The fact that mana burn reduction is in four different toggles is interesting."
  
  gfManaBurnDecreaseRemove "Perhaps they made the first change, then the upgrade changes later?"
  
  gfManaBurnUpgradeToManaUse "Or maybe it was such a big mechanic change at the time..."
  
  gfManaBurnUpgradeToDamage "That they wanted to unit test it?"
  
  gfRecommendSystem "Something NA will probably never get due to the lack of xSSN-based accounts."
  
  gfPetIceDragon "Was this considered possibly OP at the time? Well we have worse now!"
  
  gfCharacterMakeAbusing "Does anybody know what this is referring to?"
  
  gfWarpPet "I understand why this is a toggle, since the skill would be a game+server feature."
  
  gf3DaysRebirth "Hnnnnnng."
  
  gfRefineSuccessRankUp "... potentially a change of refine training to not require fails?"
  
  gfHomosexualmarriage "This is an examples of one of those 'culture' things, thus a toggle."[/php]
  
  
  Development Paths
  
  Debugging symbols are collections of data that developers can use to help figure out what happened in a crash. These symbol files are either packaged in with the executable itself, or stored locally and referenced when needed. Because of this, it's possible to get a record of where the debug symbols exist(ed) on Devcat's computers.
  
  

  • [Image: http://s28.postimg.org/hyzo7e2x9/client.png]
    
    
    
    
  • [Image: http://s21.postimg.org/7xwoeyu1z/esl.png]
    
    
    
    
  • [Image: http://s21.postimg.org/ub4f1ruzr/exl.png]
    
    
    
    
  • [Image: http://s21.postimg.org/4gumbzuzr/mint.png]
    
    
    
    
  • [Image: http://s21.postimg.org/p29e3wckn/nmcogame.png]
    
    
    
    
  • [Image: http://s21.postimg.org/xlss1nkx3/nmconew.png]
    
    
    
    
  • [Image: http://s21.postimg.org/ofahedfon/oasis.png]
    
    
    
    
  • [Image: http://s21.postimg.org/sptqnpa5j/pathengine.png]
    
    
    
    
  • [Image: http://s21.postimg.org/7jzxt3zc7/renderer2.png]
    
    
    
    
  • [Image: http://s21.postimg.org/vdj6y236v/skill.png]
    
    
    
    
  • [Image: http://s21.postimg.org/4efc2wgpz/standard.png]
    
    
    
    
  • [Image: http://s21.postimg.org/gp8amz2qv/pleione_2.png]

  
  
  The folder names being used for most of mabi's files are interesting. It's also interesting to see which components were build by which teams (matching structures). The Z drive is, in general small-scale networking practice, the letter assigned to the first/main network storage drive.
• Rydian wrote on 2013-11-17 05:03
  Dye Colors
  
  Here's the color coding for non-flashy dyes and colors.
  ######## (Example: 00BB9955)
  It's MRGB coding, where M is metadata (not ARGB as it could be mistaken for outside of flashies).
  

  • The first two characters are the color type. 00 or FF for no flashy.
    
  • The second set of characters is the red portion of the color.
    
  • The third set of characters is the green portion of the color.
    
  • The fourth set of characters is the blue portion of the color.

  This gives ~16.7 million possible colors in total for dyes. Why do we keep seeing certain colors repeatedly though? There's two answers to this.
  
  

  • First: Not all dyes are truly random. There's a certain (but unknown?) number of hand-selected dyes that devcat put into the game. FF0000 (pure red) C00000 (dark red) 000000 (pure black) and FFFFFF (pure white) are the most notable, but there's other set colors that come from mabi's palettes (for examples BB9955 is a common fixed gold because it's the most common color on the metal hilt palette). When a dye is generated, it seems that the game determines whether to use a pre-set color or generate a random one, and there's a limited pool of pre-set colors so they're bound to repeat for many players.
    
    
    
  • Second: Two different colors can look the same. This is a hot pink. This is also a hot pink. Those two links are actually two different colors, each one linking to a page examining the colors. However Mabi users would look at them both and say "hot pink". And that's fine. They might as well be the same color as far as dyeing clothes go.

  
  
  However, flashy dyes don't work like that. Flashy dyes seem to have been shoehorned into the old system (which is common for mabi), but the issue is how do you fit multiple colors into the color space of a previous one? The answer is that, unlike non-flashy colors (both fixed dyes and colors from normal dyes applied to clothes), you can't specify the RGB components exactly. Instead you pick from a pool of preset selections.
  
  Not all of this has been mapped out, but...
  ## ## ## ##
  
  

  • The first character is the type of flashing (how the colors fade into each other).
    Then the second character is the speed this happens at.
    
  • The next two characters are the ID of the intermediary color(?), if it's needed. [Note 1]
    
  • The next two characters are the ID of the final color.
    
  • The last two characters are the ID of the first color.

  
  [SPOILER="[Note 1]"]From what I've seen, flashies either have two colors, or three. A lot of two-color flashies may appear to have three because when rotating the hue, it'll run through another color before getting to the destination even if one isn't set, but this is more natural than having three colors.
  
  Here's an example of what I mean.
  

  [Image: http://s24.postimg.org/cden1cxed/gradient_examples.png]

  
  
  The first sequence only has two colors, a start and an end.
  The second sequence has three set colors, with a middle.
  
  The first setup is more natural, and used for most of the older fixed dyes because it makes for smooth transitions. However some of the new dyes coming from the flashy dye wells seem to have data for the intermediary color, which is part of the reason why some are so mismatched.[/SPOILER]
  
  The color IDs are in hex, just like the static colors, and they go from 00 to FF, in decimal that means 256 possibilities.
  
  00 = 000000 (Black)
  01 = 002084 (Dark Blue)
  02 = 008221 (Dark Green)
  03 = 0082A5 (Dark Cyan)
  04 = 840C18 (Dark Red)
  And so on so forth.
  
  Now, this means that flashies cannot start or end on just any exact arbitrary color. While there may be ~16.7 million possible colors for non-flashy things, there's only 256 possible colors for the start/end/middle of a flashy dye. So normally you'd think that any two flashies that look the same are made of the same code, right? That's what I thought too for a bit.
  
  However even though there's a limited number of possibilities, they were all hand-selected by humans, so a lot of these colors are still pretty close to each other visually (like I showed above, two different pinks that look like the same color), and a couple of the color IDs are exactly the same even though they have different IDs. For example 0C and FA both equal FFFF00 (pure/bright yellow).
  
  However, just like with non-flashing dyes, there seems to be hand-picked ones that look good and randomly-generated ones that may or may not look good, which is why so many of the newer flashies are just plain ugly.
• Rydian wrote on 2013-11-17 05:03
  Archery Aiming Lag
  
  People have mentioned that in archery "the server's aim lags behind yours", and I know it's been mentioned on these forums before so I figured now's a good time to do a little research to show the idea.
  
  So here's some packet logs taken during controlled combat (wilderness, non-aggressive monster) on my elf (R1 Ranged Attack) as a player located on the east coast of the US. Red are outgoing (things the game tells the server), blue are incoming (things the server tells the game).
  
  
  

  1. Here's what happens when I start out in a non-combat pose and click on an enemy with my bow+arrows.
     
     
     [Image: http://i.imgur.com/vDXyBDZ.png]
     
     
     Change combat stance, choose the target, prepare a skill, do some stat updates (for loading enemy targeting info and my changed stats from loading a skill), skill preparation is confirmed by the server, I tell the server I'm going to start using the skill and request the knockdown meter, then the server confirms both the aiming and sends me the target's knockdown info.
     
     0.878 seconds, and that's a good bit of back-and-forth communication and delay.
     
     Of course it's less if you're already in combat mode and targeting that enemy...
     [spoiler="Shorter Process"]
     [Image: http://i.imgur.com/yGW9bzb.png]
     [/spoiler]0.406 seconds needed to start aiming in this case.
     (And this is the value I will be using for the rest of this post, of course.)
     
     
     
     
     
  2. And now... what happens when you tell the server to actually fire that shot? How much back-and-forth communication is there, how much delay?
     
     
     [Image: http://i.imgur.com/aRThPY5.png]
     
     
     0.178 seconds to fire. One single command sent out, no client delay waiting on back-and-forth responses. You tell the server one single command, "fire the shot" (doesn't even have arguments). Then the server does the calculations and sends the resulting combat actions all back to you.
     [spoiler="What the server sends back"]
     [Image: http://i.imgur.com/82Gp5nz.png]
     [/spoiler]
     
     
     
     
  3. So in that measurement it's about ~0.225 seconds of difference between aiming and firing. That is, that's about how much extra time the player wants to aim for that the server doesn't know about. And how much aim percentage does that translate to? For an elf with R1 Ranged Attack, I recorded aiming using a stock Elven Long Bow at both long range and half range and recorded the aim speed at both a low percent at a high percent to get some expected ranges.
     
     [spoiler="Aim Speed Increase In 0.225 Seconds"]
     Long Range, High Speed
     
     [Image: http://i.imgur.com/amYRJ0I.gif]
     
     20.017 = "16%"
     20.233 = "34%"
     16% difference.
     
     Long Range, Low Speed
     
     [Image: http://i.imgur.com/xDKxOje.gif]
     
     21.900 = "90%"
     22.133 = "95%"
     5% difference.
     
     Half Range, High Speed
     
     [Image: http://i.imgur.com/AQXeTMy.gif]
     
     25.950 = "18%"
     26.167 = "40%"
     22% difference.
     
     Half Range, Low Speed
     
     [Image: http://i.imgur.com/TjXCH7n.gif]
     
     27.250 = "90%"
     27.483 = "95%"
     5% difference.
     
     Shaky parts of the recording are due to excluding non-keyframes.[/spoiler]
     So on average under my testing conditions, when I'm aiming below 95%... I can expect the actual server's aim percent to be 5-22 less than the number displayed on my screen.
     
     Of course these measurements are personal ones and results will vary a bit depending on internet quality, your physical location, your in-game equipment, and things like that. The results are mainly to show the discrepancies between starting the aim process and then actually firing the shot to help explain why the number you see on-screen is almost never the actual shot aim chance.