This is an archive of the mabination.com forums which were active from 2010 to 2018. You can not register, post or otherwise interact with the site other than browsing the content for historical purposes. The content is provided as-is, from the moment of the last backup taken of the database in 2019. Image and video embeds are disabled on purpose and represented textually since most of those links are dead.

To view other archive projects go to https://archives.mabination.com
Home » The Data Mines » Blacksmithing Minigame & Production

Blacksmithing Minigame & Production





[SIZE="5"]- Initial Analysis[/SIZE]
The Byte might be whether you've made that hit or not (as all are made when the data is sent), I'll have to see if this is a structure I can find in RAM to determine that.

It looks like the two Shorts (2-byte values) are the coordinates that you hit, the X and Y in the minigame. The little mappable area you click in measures about 200x200 pixels so this seems to match.

At first glance the Int (4-byte value) could be your progress along the bar when you hit or how close you are to the right spot, but that seems incorrect after measuring. Multiple different "in the red" areas have wildly different values, even green ones have anomalies. So I'm not sure what's going on with this value.

I tried things like RAM dump comparisons to try to find relevent data to form a signature scan off of to watch the minigame data as it runs, but I've been unsuccessful so far. Perhaps a different approach (like trying to hit 0,0 5 times and finding the structure with that) may be needed.
  • X wrote on 2015-06-27 02:02
    What came in from the server in terms of initialization?

    Also have you considered that the int might be milliseconds since the bar started? Or is that wrapped up in your progress thing?
  • Rydian wrote on 2015-06-27 02:10
    Hm, checking out initialization stuff from the server might include coordinates or something to see if the visual spots match what the game expects or not.

    And milliseconds since it started wouldn't match up with what happened either.
  • X wrote on 2015-06-27 02:12
    Yeah, the init stuff would be good to get. Also, when you do you 0, 0 clicks, try doing one where you click right away, and another where you click at the last possible instant.
  • Rydian wrote on 2015-06-28 08:02
    So I messed around again, here's the (non-item data) the server sent upon initializing the game.

    [spoiler="Minigame Setup From Server"]Short : 4
    Short : 150
    Short : 48
    Float : 1.15565

    Short : 0
    Short : 100
    Short : 113
    Float : 1.11273

    Short : 3
    Short : 80
    Short : 159
    Float : 0.94098

    Short : 2
    Short : 153
    Short : 134
    Float : 0.8282

    Short : 4
    Short : 43
    Short : 137
    Float : 0.86173[/spoiler]
    And here's the board I was presented with when the game actually started.

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


    So I took the coordinates from the incoming packet and mapped them out on the board.
    ... they match perfectly.

    [Image: http://i.imgur.com/qFMiehY.gif]


    So chances are any misses are not based on the client purposely skewing the hit spots.
    It's gotta' all be the hammer/cursor/icon alignment thing (that I still need to check out).

    Upon finishing the game, these were my results.

    [spoiler="Results Sent To Server"]Byte : 1
    Short : 148
    Short : 50
    Int : 4844

    Byte : 1
    Short : 104
    Short : 113
    Int : 3885

    Byte : 1
    Short : 81
    Short : 163
    Int : 5184

    Byte : 1
    Short : 157
    Short : 133
    Int : 4281

    Byte : 1
    Short : 46
    Short : 138
    Int : 5133[/spoiler]
    So I still don't know what the Int is for, and the Byte is weird too when it's incoming.

    Incoming coordinates marked 0-4 with 4 duplicated and 1 missing?
    Why is it all 1 when outgoing?
    What's with the int versus the float mismatch?
    Is the int a measurement of missing from the float?
    If it is, in what unit is that supposed to be in?
    Is the float a target instead?
    That's a relative measurement, what is it relative to?

    [video=youtube;NsEIu6-lciA]https://www.youtube.com/watch?v=NsEIu6-lciA[/video]
  • X wrote on 2015-06-28 10:03
    I think the 1 byte outgoing signifies you made the hit. I bet it'll go to 0 if you abstain.

    Also I don't think the incoming shorts have anything to do with order. They're already ordered in the packet, duplicating that wouldn't make sense.

    Could the incoming floats be seconds? I don't have much experience with the smithing game to say, though.

    What else varies from hit to hit?
  • Osayidan wrote on 2015-06-28 12:59
    Could the int be some sort of calculation the client makes based on how close to the center you hit for that spot combined with the value of the bar? Though I would think something like this would be server-side to avoid exploits but... nexon?

    There's some things I seen you guys dig up that make me want to kidnap a devcat programmer, tie them up to a chair in a basement and start asking questions. But I don't speak korean so can't do it.
  • SozenCratosFocker wrote on 2015-06-28 14:02
    That was my first guess based on most of the data, but unless it's a typo, the last hit of the second attempt at the fifth test in the first post seems to rule that out.
  • Rydian wrote on 2015-06-28 16:54
    So here's an example of the game being played normally.
    [spoiler="Minigame Setup From Server"]Short : 4
    Short : 38
    Short : 88
    Float : 1.09017

    Short : 1
    Short : 122
    Short : 118
    Float : 0.87526

    Short : 4
    Short : 137
    Short : 129
    Float : 1.1293

    Short : 4
    Short : 59
    Short : 83
    Float : 0.9027

    Short : 4
    Short : 153
    Short : 158
    Float : 1.15458[/spoiler]
    This is me playing that setup...
    [Image: http://i.imgur.com/utyexnP.gif]


    And here's those results.
    [spoiler="Results Sent To Server"]Byte : 1
    Short : 38
    Short : 90
    Int : 4259

    Byte : 1
    Short : 124
    Short : 120
    Int : 4063

    Byte : 1
    Short : 134
    Short : 130
    Int : 4910

    Byte : 1
    Short : 61
    Short : 85
    Int : 5130

    Byte : 1
    Short : 153
    Short : 161
    Int : 3964[/spoiler]




    So I tested again, and this time I didn't click for the first, third, and fifth hits (I hit the second and fourth).
    This produced some different results that shed some light on the situation.

    [spoiler="Minigame Setup From Server"]Short : 4
    Short : 161
    Short : 49
    Float : 1.10552

    Short : 2
    Short : 137
    Short : 88
    Float : 1.10311

    Short : 4
    Short : 138
    Short : 83
    Float : 0.87701

    Short : 3
    Short : 123
    Short : 45
    Float : 1.16071

    Short : 2
    Short : 38
    Short : 71
    Float : 0.84861[/spoiler]
    [Image: http://i.imgur.com/80k7pHo.gif]


    [spoiler="Results Sent To Server"]Byte : 0
    Short : 0
    Short : 0
    Int : 0

    Byte : 1
    Short : 133
    Short : 90
    Int : 4113

    Byte : 0
    Short : 0
    Short : 2
    Int : 0

    Byte : 1
    Short : 125
    Short : 46
    Int : 4197

    Byte : 0
    Short : 3
    Short : 1
    Int : 0[/spoiler]
    So it seems yeah, the outgoing byte is whether that spot was clicked or not.

    Re-watching the gifs, the incoming floating-point value looks like a speed modifier for how fast the bar fills up (I didn't notice it varied before). Perhaps an attempted anti-botting measure by making it not always take the same amount of time before you need to click? Could just be an intended part of the game to make it slightly trickier though.

    So since the float is probably the relative speed of the bar, this means that the short doesn't have to be linked to it additively and is it's own measurement. Checking out the gameplay again with a timer, it seems that the outgoing short is the amount of milliseconds before the player clicked (which the server will use to determine if it was in the green or not I suppose).
  • Rydian wrote on 2015-06-28 17:49
    Alright so I grabbed the client-side GUI mod that changes the blacksmithing cursor, supposedly so you can figure out where you're aiming more precisely.

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


    Oh yeah that's much better. Alright so the first target is 72,116. Let me just click and-

    [Image: http://i.imgur.com/Ohy14I3.gif]


    Okay my click ended up on 71,119 according to the outgoing packet.

    I guess I'll just have to offset myself a little high and-

    [Image: http://i.imgur.com/J0hH1mI.gif]


    Oh. 81,158 -> 85,157. Um. Right okay.

    So it's not just a cursor/GUI thing. The minigame itself offsets your hit randomly.

    - This might be lessened at higher ranks but lolno at ranking this skill.
    - That incoming byte might be a "which offset measure to use" thing, but I need more materials to test further.
  • SozenCratosFocker wrote on 2015-06-28 17:58
    Have you checked to see if the offset is at the same angle as the movement of any of the dots in the first 10 seconds of the minigame?
  • Zure wrote on 2015-06-28 19:05
    Whenever you click during the minigame it seems that it randomly sets an offset. Sometimes it hits where you want, sometimes it moves you 1 or 2 pixels to any direction from where you clicked. This applies even at rank 1 :\
  • Rynn wrote on 2015-06-28 19:34
    Quote from Rydian;1280233:
    So it's not just a cursor/GUI thing. The minigame itself offsets your hit randomly.


    Yep, this is why heavy smithers used to mod so they could see offset pixel and cancel the minigame (when the finishing mats for said item are not expensive). If the finishing mats are expensive, best you can really do is stack all the quality bonuses you can and hope for the best.
  • SozenCratosFocker wrote on 2015-06-28 19:58
    Quote from Zure;1280236:
    Whenever you click during the minigame it seems that it randomly sets an offset. Sometimes it hits where you want, sometimes it moves you 1 or 2 pixels to any direction from where you clicked. This applies even at rank 1 :\


    "1 or 2"? Rydian's data has it being off by as much as 4 pixels per axis. Does it get reduced at higher ranks or something?
  • callback wrote on 2015-06-29 04:08
    Quote from SozenCratosFocker;1280240:
    "1 or 2"? Rydian's data has it being off by as much as 4 pixels per axis. Does it get reduced at higher ranks or something?


    Almost definitely. The pixel is always somewhere under the default cursor, which shrinks with rank. I'm guessing it represents the full estimate for where it could land.

    I also envy those GUI mods.