Ind

Thank youuuuu extremely appreciated, I'll be having them in the repo within some minutes.

guide-wise I think if you ctrl+f all places the '@' thing is check, just adding another check for your new symbol should work

I don't know when this feature was first introduced, in the case that it was present in 2010 clients, support can be added if the keys are identified (check Yommy's post on the first page of the topic for instructions on doing that) -- If you find the keys, please do share so we can put them in the repository.

Yes, anything that may be used to send packets outside of the client will not function (if you send as much as 1 packet outside of the client the formula in the client and in the server will go off, and the server will disconnect you in the next packet).

Hercules WPE Free - June 14th Patch Made Possible Thanks to Yommy We're only able to provide you with this feature thanks to Yommy, Thank you very much! WPE Free - Official Packet Obfuscation Support Packet spamming is no longer possible by normal means, with this feature each packet sent has its own id, so spamming (by sending the same packet more than once) is impossible. For this feature to function you MUST NOT use the 'disable packet obfuscation' client diff. conf/battle/client.conf // Whether to enable the official packet obfuscation support (good vs WPE)// 0: disabled// 1: optional (not recommended) -- identifies whether it is required// 2: enabled (recommended)packet_obfuscation: <value> Currently functional for over 44 clients (Thanks to Shakto!): 2011-08-17 - 2015-05-13 Special Thanks to Yommy ..Yommy ...The all-awesome Yommy~! Thank you again! Shakto for the 44 PacketKeys! Also - SQL DB Updates & DB2SQL For logical and performance reasons we've modified the structure of the renewal item db tables, atk and matk no longer share the same column, equip_level was replaced by equip_level_min so that we could add equip_level_max which is required by new renewal items. Note however that because of the previous atk:matk format, it was not possible to provide a upgrade file that would save the matk data Item script errors from sql dbs used to point to a inexistent line number, it was modified to display the item id instead. This update has shrunk the sizes of the item db .sql files, making it possible for tools such as phpmyadmin to parse them, once again. With this patch we're also introducing a new official plugin, db2sql, its purpose is to make it easier for our developers to keep the .sql db files up to date (but you may use that to convert your own if you so desire, too), to use this plugin (when it is enabled in plugins.conf) type server tools db2sql in the console. Link~u! Commit 1 Commit 2

HELLOOOO <3

I'm crying O_O soo happy, such amazing update malufett!

most likely the subnet.conf setup is incorrect

You inspired me to do this over IRC

paste the contents of the Makefile.in

Currently that can be done by copying the pointer to the original, and then throwing it back at it after your custom stuff goes (check my example at the skill error message plugin test), but we have a HPM Hook implementation in the plans that'd make doing what you propose much easier.

File Name: Skill Error Messages File Submitter: Ind File Submitted: 09 Jun 2013 File Category: Plugins Its more of a way to demonstrate how HPM overloading can be used (its going to be much more fun to play with once we get HPM Hooks released). SkillErrorMessages Replaces client-side error messages by custom server-side error messages, for skills. Not Enough Spirit Spheres Message %d requires a total mind bullets becomes %s requires a total %d spirit spheres (%s being the skill name, %d the amount of spirit spheres) Contribute / Customize Its available at our Staff Plugins Repo, pull requests are more than welcome. Click here to download this file

I tried to continue this and something came up, since there is no minimum, when does it start? only when maximum is reached?

First I once again would like to thank Susu for doing this pull request, its been of great help (as was his previous one). Second, if you don't work on the source you can skip this, it wont mind you later. Now, as you may know these interfaces (and the others existent prior to them) were/are-being made because of two things. [*]They give life to our Hercules Plugin Manager [*]It further increases flexibility in the source code up to this point we've always considered: [*]Making their names as short as possible, while trying to maintain its name as similar as possible to its previous stuff The current interfaces are the following [*]Common [*]console [*]DB [*]SQL [*]strlib [*]sv [*]StrBuf (StringBuf) [*]iTimer [*]Map Server [*]atcommand [*]battle [*]buyingstore [*]clif [*]guild [*]homunculus [*]ircbot [*]log [*]iMap [*]party [*]pc [*]script [*]searchstore [*]skill [*]vending [*]Char Server [*]pincode We've had no problem with their names up to now, on map.c's interface it wasn't possible to change it to 'map' because 'map' is already in use by the 'map[]' array of maps, Susu (in his pull request) created the map.c interface and named it iMap to avoid the conflict, another is timer.c's interface, its not possible to name it 'timer' because 'timer' is a existent function on some unix distros, and it'd conflict on them (and make it not compilable), Susu (in his pull request) created the timer.c interface and has gone around this by naming it 'iTimer'. While this topic is a notification on why the names differ, it is also a opportunity for you to point-out (and/or discuss) any comments or modifications on the interface names Worry not if we come to decide to change any of the interface names, it will hardly be a bother. a single 'Old->' => 'New->' case-sensitive find&replace will take care of it in a couple of seconds.

woonderful I didnt (failed to) see this before i did the recent commits, but dont worry i'll get a topic set up

o-o idioma errado nao, vc postou na area em portugues e eu respondi em portugues (eu falo portugues btw o-o)

28 de Janeiro, 2013.

as a official feature, we might end up implementing it soon

we already have coloured dragon support via *setdragon (script command, I coded it for RREmu about 2 years ago). /** * setdragon({optional Color}) returns 1 on success or 0 otherwise * - Toggles the dragon on a RK if he can mount; * @param Color - when not provided uses the green dragon; * - 1 : Green Dragon * - 2 : Brown Dragon * - 3 : Gray Dragon * - 4 : Blue Dragon * - 5 : Red Dragon **/but you have a point o-o would be interesting if @mount supported it as well

My opinion on this issue is pretty similar to what mkbu95 and Xgear put forward, in short I don't see / failed to understand the benefit of this

We already have been discussing how to implement such things for some time now, should be out once we wrap it up.

interesting sure could be handy

Very nice, thank you.

https://github.com/HerculesWS/Hercules/commit/86e9900db60e06738880a57820125ca169c37520there we go, thank you