exec

I think the situation here is a little different though. The game is basically ready for release, it had multiple closed betas in multiple regions already, there's simply no reason for them to do another payed, closed beta, except for wanting to rake in money. Founder's packs are always a way to make money of course, but usually you buy them to get access to the closed alpha/beta. In TOS's case the closed beta is done, but they announced another one for no reason, after announcing an open beta first. At least that's how I see it. Another point might be the value of what you get. In many founder's packs you find exclusive things that you can't really get any other viable way. You want in now, and you want the special features/items/titles/pets/whatever, so you pay up. Maybe $50, maybe $100, maybe even more, but in TOS you get nothing special. It's 2 headgears (dunno if those are even exclusive?) and the value of your buy-in in their cash currency. Like they said themselves, it's a headstart, nothing else. You're paying in advance what you might spend on the game later on. Even that is done better by other companies though, as they usually don't only have 1 pack, but multiple ones. Like Albion, which does not only have the $100 one, but also one for $30. It definitely is, for better or worse. I don't mind buying into a closed beta, but not into an "open" one, if you know what I mean =| Keep in mind though, while Melia is a little more advanced than R1, it's not complete yet either. You will be able to set up a server, login, and do things upon release of the code, but not much more than what I have demonstrated in my videos so far. It will be on all of us to change that =)

As long as it's clear what you're saying there's no problem^^ I can see how the recent announcement might've piqued your interest. It will be interesting to see where they're going now, though I'm starting to lose confidence in them.

Yes, the plans are still the same. Though I might speed them up a little bit. Originally I wanted to wait until the game is available to everybody, but I don't like the idea of waiting another 3 months.

For those who get plugin errors upon starting Pale on Windows 8/10, please refer to this issue: https://github.com/exectails/MabiPale2/issues/7

Which Friday did you mean, specifically? xD

I actually haven't worked on it these past few weeks, because I was pretty busy with Aura, our main project here. The release plans haven't changed, I'll make it open-source shortly after iTOS opens.

Welcome~ I'm not aware of any public private servers atm, and for legal reasons we can't have people post information about pservers on this forum, but if you want to try Aura for yourself or learn more about it and its users you certainly came to the right place^^

Welcome~

Depends, there's still newbie stuff that has to be logged^^

Welcome~ So did you just search for a random server emulator or have you played Mabinogi? =P

So far I've tried to set various values for the byte, for the other premium related bytes, and adding the Nao clothes related keywords, nothing =|

Now that Soul Stones are working, I was wondering if anyone has a Nao with non-standard dress, to log how that works. We have a comment mentioning Nao's outfits in our creature helper, but that byte doesn't seem to do anything, and the person who wrote that comment is hard to come by today. If you have a non-standard outfit, could you log a) how you login, and b) how you get resurrected by Nao? Optionally it would be great to get a log of how you give her another dress.

Writing everything down would work, but you have to make sure to get the line breaks and paragraphs right in that case. Alternatively you could use Morrighan+MabiPale to log the packets, and get the exact text sent to the client.

I know, collecting dialog is boring, but if you feel like doing some PTJs, think about logging the dialog, which is the most time consuming part of adding the PTJs. If it wasn't for that, some of them could be added in a matter of minutes. Specifically, we need these dialogues: Dialog for when you're already doing a different PTJ. Dialog for coming back early without being done. Dialog for coming back early after being done. Report later dialog. Report now dialog. Dialog for reporting without having done anything. Dialog for reporting with having only done a little. (You get different dialogues and rewards, based on the amount you've done.) Dialog for reporting with having done almost everything. Dialog for reporting with having done everything. Dialog for PTJ keyword while no PTJs are given out. Dialog for declining the PTJ offer. If deliver PTJs go to various NPCs, the dialog for each of them. As you can see, every single PTJ takes several in-game days to get everything, but there's no way around it, to implement them, we need the dialog =| I'm working on logging Dilys right now, and Endelyon is already done.

While adding the fomor scroll hunting quests, I've noticed a few unused fomor scrolls, which give us options for custom content, either by implementing the quests they were intended for, and their monsters, or by replacing them for custom ones. Namely, the unused ones are: 71014: Gray Dire Wolf Fomor Scroll 71020: Giant Spider Fomor Scroll 71024: White Fox Fomor Scroll 71027: Black Bear Fomor Scroll 71033: Giant Rat Fomor Scroll 71036: Golem Fomor Scroll 71046: Black City Rat Fomor Scroll 71048: Boar Fomor Scroll 71053: Giant Worm Fomor Scroll 71054: Gargoyle Fomor Scroll 71071: Dungeon Rat Fomor Scroll Some are monsters I didn't know yet, and 2 are bosses, which I find really intriguing. I also wonder why they didn't add Giant Worm and Gargoyles. Especially Gargoyles are monsters you encounter very frequently in early generations after all.

It's been some time since I tried to work out this DungeonInfo packet, but the general idea is that every single tile for every floor marked as "custom" in the dungeon db is sent to the client, for a total of 225 for a 15x15 floor, instead of only sending where the rooms are supposed to be, which leaves the layout generation to the client. This is because the Nekojima Dungeon actually uses a grid layout iirc, something that the dungeon generator can't generate, so they added a way to send the dungeon floor layouts from the server. As such, the packet structure differs slightly from our current DungeonInfo packet. Instead of this: packet.PutInt(dungeon.Generator.Floors.Count); foreach (var floor in dungeon.Generator.Floors) { var rooms = floor.GetRooms(); packet.PutInt(rooms.Count); foreach (var room in rooms) { packet.PutByte((byte)room.X); packet.PutByte((byte)room.Y); } } You get this: packet.PutInt(dungeon.Generator.Floors.Count); foreach (var floor in dungeon.Generator.Floors) { var rooms = floor.GetRooms(); packet.PutInt(/* floorWidth (e.g. 15) */); packet.PutInt(/* floorHeight (e.g. 15) */); foreach (var room in rooms) { // Short : 0 // Int : 388910688 // Short : 0 // Short : 0 // Byte : 0 // Short : 0 // Byte : 0 // Short : 0 // Byte : 0 // Short : 0 // Byte : 0 // Short : 0 } } I did some research on what these values mean back then, and I did figure a few things out, but unfortunately it seems I don't have that data anymore =/ It was limited anyway though, because of how tedious it was. The client crashes very easily, if you make even the slightest mistake. It might make sense to take another look though, now that we know a whole lot more about dungeons.

This was originally posted by Arufonsu on the old forum, between December 2012 and March 2013. While we don't need normal dungeon logs anymore, he made some logs of Nekojima, a special dungeon, that works differently from all others, as the floor layout is generated by the server and sent to the client, tile by tile.

It has that argument. If you want to log a local server, just start Zemyna like normal, without "kr", but with "nosteam".

Your theory about them going into aggro faster if you're in hearing range seems weird to me. What I was actually thinking about was whether they might aggro faster if they see you. Aside from the logical standpoint, there are AIs that have much better hearing than eyesight, like bats. For those the visuals would be completely pointless if both were equivalent, or if hearing would have a higher "priority". But some difference between them would certainly make sense, and it might explain some weird aggro behaviors, where sometimes they don't aggro immediately, but seem to wait around for a while. Maybe they aggro faster if they can both see and hear you?