Aleos

As Nova and Tales stated, you'll still need to update the data files that go along with it. Updated the first post with client download and other information.

If it's closing immediately then it's another issue, not pertaining to Packet Obfuscation. Please search or create a new topic in the Client Support section.

You don't have to make custom keys, unless you want to. The default keys will work just fine. If you prefer to use custom keys, then please use the tool nanakiwurtz made to create the keys. You can also test them on KeyWorld's webpage here.

I was able to use 2014-10-22 with Packet Obfuscation enabled just fine. Just don't apply the "Disable Packet Encryption" to your client. If you use "Packet First/Second/Third Key Encryption" make sure the keys you use match what you define in the packet_db.txt as well. As for Roulette, you are able to continue playing with the same coin until you lose or choose to accept the item. This means you can reach the top of the pyramid with a Bronze Coin. Each coin type defines where you start on the pyramid.

Implemented in 3d9c6e7.

2014 Client Support As of 3d9c6e7, rAthena is now able to support 2014 clients! Roulette Feature: To enable the Roulette Game, see conf/battle/feature.conf" class="bbc_url" title="Git" rel="external">conf/battle/feature.conf and set feature.roulette to "on". All of the Roulette rewards are stored in SQL. Please see the db_roulette table for more information. Roulette Coins give players the ability to participate in the Roulette Game. The coins set the variables RouletteBronze, RouletteSilver, and RouletteGold. Per-Character Gender Feature: This feature allows individual characters to change sex. The character table now stores a sex flag which can be "M" for male, "F" for female, or "U" for undefined (default). When the value is undefined the account sex takes priority. Character sex can be changed from '@changecharsex <sex>' or the script command 'changecharsex <sex>'. You can download the 2014-10-22 Client here. The client is currently patched with: Disable Ahnlab Disable ragexe filename check Read msgstringtable Read datafolder first Thanks to Yommy for the preparation of this client! These features require 20141022 or newer. Please report all bugs to the Issue Tracker! NOTE: This 'support' post means rAthena added 2014-10-22 client (source and packets), not "post your issue about installation, how to get, how to make it work of 2014-10-22 client"

Sorry, thought you were talking about the custom hunting missions quests. For the actual quest system then you'll have to change a bit of source. mob.c if( sd->status.party_id ) map_foreachinrange(quest_update_objective_sub,&md->bl,AREA_SIZE,BL_PC,sd->status.party_id,md->mob_id); You'll need to make it something like: if( sd->status.party_id ) map_foreachinmap(quest_update_objective_sub, md->bl.m, BL_PC, sd->status.party_id, md->mob_id);

.Party = 3; // Party options: 0 (exclude party kills), 1 (include party kills), 2 (same map only), 3 (screen area only) Just change that to 2.

No, not item storage. I meant the overall size/storage that variables take up in memory. Technically, right now, from what I've tested before is that rAthena supports a little over 1000 for player storage sizes (pertaining to your actual question). I know that there is a ShowWarning if query_sql is to return more than 128 results, I don't see you removing it on your pull. I'll test it soon, thanks a lot for the pull That check is limited by this: #define SCRIPT_MAX_ARRAYSIZE (UINT_MAX - 1)

The script command 'query_sql' isn't going to be affected/changed. The array variable that it saves to though is what is affected from this patch. Here you all go: Pull: 457. Give it a test and tell me if you find any issues.

I've been done with this for a few months and slowly fixing bugs, but it seems to be pretty much stable now. It's just been sitting on the back burner since I wanted some help to test it but everyone's been busy lately :\. I might create a PR/branch or just push to master very soon.

I have been working on this and am pretty much done. I've been somewhat hesitant of the release until I can do a bit more testing.

All SQL upgrades are in the sql-files/upgrades directory and are sorted by date.

That's wrong. It's supposed to be: packet_db_ver: <version of client> packet_keys_use: <version of client> or default if you want it to use packet_db_ver packet_keys: <your 3 keys>

Hm. Well you can always add a check before the query to get the class of the player, and if they aren't of Alchemist class, then ignore it.

That just means the default keys in the client are no good. You can create your own keys and test them on that site.

Are you talking about people using @makehomun? How would a class other than Alchemist get a homunculus?

I'm assuming you didn't disable Packet Obfuscation via source or your client isn't setup properly for packet obfuscation.

@AndrewDemonX: Like kyrato said, you have to change each file by hand and recompile the source. I suggest you start at the wiki and go step by step so you can figure out how to setup everything using Git.

You can either manually apply the fix to your server or just update your Git. @kyrato: https://rathena.org/wiki/Transition_from_SVN_to_GIT. We have been using Git for well over 2 years now.

Nice, I'm liking the new bound UI. Is all the data for binding stored in a LUB file now? This can certainly help clarify some of the item_trade items!

It was a bug reported in #308 and was fixed in 2fdcd92.

prontera,154,182,4 script SQLTest 90,{ query_sql "SELECT `prev_class` FROM `homunculus` WHERE `char_id` = "+getcharid(0), @prev_class; if (getarraysize(@prev_class)) { // If the person has a homunculus or not. if (@prev_class == gethominfo(1)) { mes "Your homunculus hasn't evolved yet!"; close; } else { mes "Previous class: "+@prev_class; mes "Current class: "+gethominfo(1); close; } } else { mes "You don't even have a homunculus!"; close; }

query_sql "SELECT `prev_class` FROM `homunculus` WHERE `char_id` = "+ getcharid(0) +" LIMIT 1", .@prev_class; if (.@prev_class == 6001) { mes "I was a small Lif!"; close; } Something like that should do fine.

You can already do this. Just do a query on the 'homunculus' table and grab the `prev_class` to get the ID of the homunculus' previous class.