Euphy

Transitioning from SVN to GIT While switching your server to GIT may sound like a daunting task, it's relatively simple and straightforward, even for servers with heavy modifications. We strongly encourage you to do so, since our primary efforts will now be directed towards our repository on GitHub. Simply follow the steps listed below, depending on your OS: Windows Instructions Linux Instructions Conflicts It's possible that you'll run into conflicts along the way, with messages such as: When you see these messages, a conflict in merging your code occurred. Much like resolving code conflicts in SVN, these conflicts create points within the files which show your code compared to the code pulled from the remote repo. To fix them, open your files and find the conflict locations denoted by: Then you can choose which piece of code you wish to keep. After all shown conflicts are corrected, you can continue your normal update process. References Setting your email in git How do I resolve git saying "Commit your changes or stash them before you can merge"? CONFLICT (content): Merge conflict in Credits to @Akinari for writing a good part of this guide.

63, not 16.

There's no command to make a SPR appear; not sure if the client would even support this, but you'd have to look further.

It is stored as #langtype, as you can see here: pc_setaccountreg(sd, "#langtype", lang); //For login/charIt's an account variable, so you can directly call it (no need to use an SQL query).

Read: RENEWAL item_db 'Class' Update (commit 5f12351)

Make sure your "VIP" player group has the 'can_trade' and 'can_party' permissions. Read: doc/permissions.txt

It seems the general consensus is that this is unnecessary, and I agree. Moving to "rejected".

We've covered our policy towards this in our rAthena Goals statement. Moving to "rejected".

'63' contains '15' in it (1+2+4+8), so that's why it also works. The beauty of flags~

Could be a battle config, if anyone else cares (?).

Marking as "rejected" due to the reason given by Rytech.

It's been over a year with no up-votes. Marking as "rejected".

Enabling the main setting, RENEWAL, makes your core mechanics based on Renewal (even if you disable the rest of the features). If that's okay with you, this is the easiest way. If you want to only run the Renewal databases, you'll have to make some source changes because the new items and mobs have features that didn't exist in Pre-Renewal (start by taking a look at the ifdefs in the related files). @vhan48: The other emulators don't have the new item/mob entries and won't support the format of our database.

Updated FRN and RUS with the two latest files posted in f6f1bca.

Bringing this back - there are still (very small) differences between us and your screenshots, even after implementing official HP/SP tables and Renewal Attack (along with countless other fixes). Can anyone explain them?

Cydh implemented this in cd9a776/r17485. Note that it's disabled by default (because it adds a lot of extra processing), so be sure to enable it in src/config/core.h if you're going to use the database or mapflags.

Sorry about that, fixed in 454781a. Please use the Bug Tracker to report bugs in the future. Thanks!

Instead of doing this with custom clients (which, as we've seen, tend not to work out), I think it would be a very good idea to post an official client/data combination "by rAthena" for each of the three clients we support. I would also prefer to create multiple versions of the client with different hexes, to give server owners some choices (even if they're too lazy to hex their own client XD!).

We've made the "Recent Revisions" sidebar link to our GitHub repository. We want to start slowly transitioning users to GIT, and announcements will begin popping up soon with instructions on how to do so. You can still access Trac to view SVN revision numbers, and we have no plans at the moment to drop them.

Yes, you could.

I'm assuming you mean in an automated fashion (otherwise it's very simple XD). To do so, you have to use an SQL item_db2 (or have it imported, at the very least). You can then have a script pull all the items from it. Here's an example script - simply send a whisper to "syncshop" on an admin account to refresh your shop with any changes in item_db2. prontera,150,150,0 shop Example Shop 83,512:-1 - script syncshop -1,{ OnWhisperGlobal: if (getgmlevel() < 99) end; dispbottom "Syncing your shop, please wait."; detachrid; OnInit: npcshopitem "Example Shop",512,15; npcshopdelitem "Example Shop",512; set .@count, query_sql("SELECT `id`,`price_buy` FROM `item_db2`",.@id,.@price); for(set .@i,0; .@i<.@count; set .@i,.@i+1) npcshopadditem "Example Shop",.@id[.@i],.@price[.@i]; end; }

Any client-side things won't be affected (so yeah, you can access 3rd job sprites). However, third jobs themselves won't be accessible unless you use @job to switch to them - the quests will be disabled if you use Pre-Renewal mode.

Capuche, you could alternatively use: atcommand "@go "+implode(.@atcmd_parameters$," ");

OnInit will always run in an enabled script. The issue is that you're setting NPC variables, which can only be directly referenced in that one NPC. Since your functions are external, you have to use the Getvariableofnpc command to access them.

There aren't many options. It's easiest to just use character variables to store the count of an item, with name formatting like: quest_total_<item id>It would be fairly straightforward to use setd/getd in a dynamic script. A separate SQL table will be slower, but if you're planning to have a lot of quests it'll be more efficient in the long run. (You don't want to end up with tons of character variables floating around.)