exec

Sorry, I don't see the problem, the arguments look just like the ones for NA. What exactly isn't working, are you getting an error message?

One last request for the time being, I need a log of an item that's been sanctified with Holy Flame. Update: Got it.

Update 1.0.3 I fixed a few bugs, caused by left over MabiPale code. I recommend everybody to update, as those bugs could be potentially problematic. Fixed packets shorter than 12 byte being filtered. Fixed filter using op codes instead of names. You can download the latest version from the Download link in the first post.

Awesome news: The enchant scrolls take upgrade effects, just like the actual equipment. This means we can give effects to scrolls, and make those the effect of the scroll, we can create custom enchants, without client modifications

I don't know for sure, but I wouldn't expect it. Yea, I think that's how it's supposed to work. I guess it's all just added up, no matter where it comes from, and then, if it's greater than 10, it takes effect.

This is currently my favorite tool to extract and view the contents of ToS's IPF files. It works well and previews most file types contained in the IPFs. http://www.tosbase.com/downloads/IPF_Suite.zip.html Update: I'm now using my own tool to browse and extract IPFs, IPF Browser.

Thanks, but what I need is the ItemNew packet. To get it, you have to remove the item from your inventory and then get it back, by dropping and picking it back up for example, or by getting it back from a pet inv or the bank. I guess it does... but I expected something different =/ Petch's logs have the same though, so I guess that is how it works. I don't get it, they have X different calls, for different kinds of bonuses, but in the struct it's almost all the same. I guess effect-wise I should have everything I need now... thanks everyone =)

Actually, they don't. Thanks, Blade. Apparently I named one of the stats "LooksABitStrong", when I switched off my brain and spawned what felt like a thousand daggers, with various settings, to figure out the stat names. Should've been obvious to me what that was =P" I still don't know where set bonuses go though... I can see the skill enhancements in the meta data, but I don't see the stat set bonuses. Edit: Just realized that was a Broad Brimmed Feather Hat, of course I can't find the set effect, it's on the item itself =< I still need an enchant~

OH! Right, I totally forgot about those, now the name of the "function" (SetSetItemEffectOnEquip) makes sense. I was already wondering earlier, if there are enchant sets that I don't know anything about or something^^ I still need a log of such an enchant, but now I at least know what it is, thanks.

I'm in the process of creating the enchant db, but I need some more data =/ If you have an enchant on an item that does one of the following things, please post a log of them. Alchemy (AddBonusOnAlchemy) An enchant that affects a specific kind of alchemy damage. For example, rD enchant Spark: +5 Fire Alchemy Damage if Flame Burst Rank C+ Effect instead of Stat? (SetSetItemEffectOnEquip) I'm not sure what exactly this does, but it seems like it usually doesn't affect an actual stat, but has a general effect on what you do. For example: - rE Poison Archer: +1 Poison Resistance if Ranged Attack Rank E+ - rB Fixed: +1 MP Cost Reduction - r5 Marquis: +2~4 Fast Attack Piercing (SetItemOption) Any enchant that has Piercing. For example, r9 Piercing: +2 Piercing if Lance Counter is Rank 3+ Elements (SetStatusOnEquip) Item enchanted with an element, Poison, Lightning, Fire, or Ice.

G2? Hm... I don't know. I would've put it somewhere in C2.

Figured out the stat bonuses for skills. The value after the skill id (bytes 3+4 on the second line) is not a fixed value like the stats, e.g. 1 = damage, 2 = crit, etc, but defines a specific variable for any specific skill. For example, in my screen above I have Mind of Connous, with a bonus for Max MP. The value is "1", but a lot of values for a lot of skills are 1, and they're all different, depending on the skill. Instead, they correspond to the skill's variables. // Mind of Connous // Var1: [Transforming] Max MP // Var2: [Transforming] INT { id: 43012, name: "Mind of Connous", masterTitle: 0, type: 10, ranks: [ 1 equals Var1, 2 equals Var2, etc. And as you can see, the localization information I use for the comments in our db, come from the same place the client gets the bonus name for the description from. Now that that's out of the way, I'm almost ready to go I think o.o There are still unknown bytes, but this should be enough for the majority of the enchants. If you have more enchants though, feel free to post them, more data certainly can't hurt. And I still need information about CP enchants.

I've found 2 upgrade types, that assumingly have never been used officially, or at least I've never seen them. The description seems obvious, even though the effects seem unusual. The first one apparently sets the stat to a fix value, while the second one changes the stat to a percentage of its current value. Rather interesting, and it offers us an opportunity to add custom content not available officially, that is supported by the client I'm done mapping the upgrade stats, and I figured out a good portion of the upgrade struct. I think I have everything I need for normal stat upgrades, but I need more examples of skill effects. If you have items with enchants that affect any skills or transformations, please post them. (I don't need checks like "If Fireball > r5 STR + 10" anymore.) An example of a CP enchant would be nice as well =< Those seem to work different from the normal stats.

I remember that after some update, monsters were suddenly able to go into deadly. I'm very sure that prior to that, there was no chance for that to happen, if a monster reached 0 Life, that was it, but after the update they would start to unexpectedly jump back up. While I am very sure about this... can someone confirm it? And do you remember when exactly this was changed? It happened while I was still actively playing EU, so it must have been pre-G14. It's hard to tell though, as EU got G4~G10 in one go =<

Yaha! I finally got to use Lua, since there was nobody advocating for C#! I wanted to use Lua for ages. Sneak peek?

Melia is a server emulator for the MMORPG Tree of Savior (commonly referred to as the spiritual successor to Ragnarok Online). Development began in August 2015 as a side-project, and while we have made some decent progress, the emulator is still very young. Some of the basic features currently working are: Character creation, moving and warping, inventory and equipment, and NPCs. We also have working test code for basic combat. Melia uses C# for its core, MySQL for the database, and Lua for its scripts. Our current plan is to not release Melia before the actual game is available to the general public (this means international release, or at least open beta). While this plan might change in the future, it probably won't, as it wouldn't feel right to us, to release an emulator before the game. Afterwards it will be available as open-source, just like our Mabinogi server emulator, Aura. For the time being, you may subscribe to me on YouTube, where I upload videos about new features that get implemented from time to time. Should you have questions about the future of Melia, feel free to ask them in this sub-forum. FAQ Where can I download the client? For legal reasons we're unable to share the client here. If you weren't in the international closed beta, I'm afraid you will have to wait until the game is released, or find a different source. Preview

PaleTree is a packet logger that utilizes data coming from packet providers, like Zemyna. Just like its cousin MabiPale, PaleTree allows you to log packets, and save, load, and modify the logs. However, unlike MabiPale, you won't see clear, separated variables here, as ToS's protocol doesn't communicate this information. Instead, PaleTree features a hex editor on the right side, and it has a plugin to show which values might hide behind a bunch of random bytes, starting at the selected index. For deeper analysis, a tool like 010 Binary Editor is recommended. Another difference to MabiPale, is that due to the availability of op codes, there are no unknown ops, and in case of changes, the ops are saved inside the logs, so you never have to worry about incorrect op names. But you should update PaleTree regularly, since any change in an op could result in confusing data. Download Remember to regularly update PaleTree and Zemyna whenever one is available, as they need to be up-to-date to work with the latest client. Features Logging packets Saving logs Log management (deleting, filtering) Plugin system Official plugins: Variable Preview: Displays what values could be read from a packet, starting at the selected byte. How to use Put Zemyna.exe into your ToS folder Create a link to Zemyna.exe, using parameters for the appropriate server. For example to connect to the international server Laima, you would use Laima's login server IP and port: Zemyna.exe host:54.88.25.242 port:2000 And to connect to a local server, without Steam auto-login, but with a login form, you would use this: Zemyna.exe host:127.0.0.1 port:2000 nosteam Start the client with that link whenever you want to log packets. Click connect in Pale to subscribe to Zemyna's packet broadcast and to start logging packets. Packet data The packet data in the hex editor is always the raw data received/sent by the client, incl. packet header. This means the actual values don't start at the first byte. Packets from the client to the server have a 10 byte header: short op; int sequence; int checksum; Packets from the server to the client are the same, just without the checksum, so it's 6 bytes in total. Additionally, packets that don't have a fixed size have another short (2 byte) before the actual data, the length of the entire packet. Packets that have a fixed length will say something like "Size: 50 (Table: 50, Garbage: 0)" in the packet information on the right side, after the op, while dynamic packets don't say this (dynamic packets are ones that include lists or variable sized strings, where you can't define a fixed size). The last thing of note is the potential "garbage" at the end of packets from the client to the server. Because of how the packet encryption works, the length of packets from the client to the server is always a multiple of 8. Packets that have a fixed size will be able to determine that X byte are "garbage", because they don't belong to the actual data, but are a left-overs from the encryption process. The garbage bytes can generally be ignored, the only reason we don't truncate them is that we could potentially lose data if the ops are outdated.

Zemyna acts as a kind of proxy, it makes the client connect to a special local server that forwards all packets from the client to the actual server. This way it's able to read every single packet that gets sent or received. These packets can then be passed to other applications, so they can work with them, e.g. loggers like PaleTree. If you're familiar with Morrighan, you will feel right at home here. Download Remember to regularly update PaleTree and Zemyna whenever one is available, as they need to be up-to-date to work with the latest client. How to use For Zemyna to be able to read packets, it needs control over the starting process, as it temporarily adjusts your client, to tunnel its connection. It does so by making a backup of your client.xml, that contains information about where to connect to, and creates a new one. This change is reverted once Zemyna closes, this way you don't have to fiddle with any files yourself. To tell Zemyna where to connect the client to, you use command line parameters. For example, let's say you wanted to log packets on the international server Laima, you would simply start it like this from the command line, after moving Zemyna to your game folder: Zemyna.exe host:54.88.25.242 port:2000 The IP and port are of the login server for Laima. For easier reusability, you should create a link or bat file. Zemyna will then take the necessary steps to be able to read packets from the network, and start the client. A small window in the upper left corner will show you that Zemyna is running, it closes automatically when the client gets closed. You can also double click it to quickly close Zemyna and the client. Since you can only have one server in the server list this way, the one you specify in the parameters, you could create multiple links/bats, one for each server. If you want to use Zemyna on a server that doesn't use the Steam auto-login, but a login interface, you have to tell it, with another parameter. For example, connecting to a local server: Zemyna.exe host:127.0.0.1 port:2000 nosteam How to connect to Zemyna Zemyna uses the same API as the tool it was inspired by, "Alissa". It uses WM_COPY messages to communicate between Zemyna's and the subscriber's window. To subscribe to Zemyna, to receive packets, you send the "op" (dwData) 100 to Zemyna's window (window name: "mod_Tossa"), to unsubscribe, you send 101. While you're subscribed, you receive all incoming (op 0x10101012) and outgoing (op 0x10101011) packets via the same method. For an actual example on how this works, I suggest looking at the corresponding functions in Pale. Alternatively you can also create a plug-in for Pale, which will be easier. Restrictions Zemyna currently only supports the Login and Channel servers. Due to ToS's protocol, Zemyna needs to be updated regularly, or there's a high chance for it not to function correctly. Check for updates after each game patch and report potential issues. Korean TOS If you click on Download, you will find multiple versions, one of them being for kTOS (notice the "k" prefix). Choose that one if you want to log packets on the Korean server. Due to kTOS using a web login, we had to do things a little differently for the Korean version of Zemyna. You need an additional argument, "kr", which activates certain KR only options. Example: Zemyna.exe host:54.88.25.242 port:2000 kr After you started Zemyna like that, the client won't start automatically, but it will still modify the client files, so when you finally start the client via the web login, the connection will still go through Zemyna, allowing you to log packets using PaleTree.

Nice, thanks. Looks like Artisan uses the same system, that's good to know. Good news, the client reads the upgrade effects from the item data coming from the server, we have total control over the upgrades^^

Enchants are apparently saved as structs inside the item data, similar to ItemInfo and ItemOptionInfo, and by the looks of it, every enchant effect might actually be its own struct. You can clearly see the values as a short, at the end of the first line, and the short before that is probably the stat. I wondered where the increased repair fee is for a moment, but then I remembered that the fee is based on the item's price, so the enchant most likely simply increased the price. Reforges seem to work the same way, with one struct inside this list for every effect. From what I can tell they start with 07, instead of 01, so the first int (?) is probably the type. Unfortunately I don't have a clue what the other values mean, which is why we need more data. Much more. We need logs of many different enchants, with different stats, different values, and different effects. For example, I have no clue where it would store the "Level >= X" checks. If you want to help out, get your enchanted items, drop one, pick it back up, log the packet with the op ItemNew, and post it here, or send it to me via PM, with a note, of which enchants the item has, so I can compare the information. Posting here would be better though. Don't worry about the data, if you exclude or mask the packet id and the first long in ItemNew, there shouldn't be anything that could lead back to you.

No, just the usual Nexon problems^^

The attached file contains all field spawns up to G3, as ready to use function calls. They are based on the group data from the region/area files. However, last time someone worked on these, we discovered that some area definitions don't seem to be 100% correct, and that some spawns shouldn't exist (anymore?). I don't know if there are missing ones as well, but this file should still help whoever decides to add those spawners. Every spawn has to be checked though. If someone decides to tackle this to make a pull request, please put the spawners in appropriate region scripts, and comment them, so you can see where they are. Just take the existing ones as an example. Like in regions/tir.cs: // Graveyard CreateSpawner(race: 30014, amount: 22, region: 1, coordinates: A(18595,40025, 15904,44605, 21371,47817, 24062,43237)); // White Spider CreateSpawner(race: 30003, amount: 1, region: 1, coordinates: A(18595,40025, 15904,44605, 21371,47817, 24062,43237)); // Red Spider We should probably also use a dummy AI for the monsters added in this way, if they don't have one already. (You can find the available AIs in scripts/ai/.) Otherwise they'd just be standing around. The "wander" AI for example would at least make them walk around. spawns.txt

Got it to work, even though it required a little hack. Note that there are 9 more stickers that apparently haven't been translated yet.