Asheraf

Either add a
aFree(item_name); or better use a stack allocation instead of malloc
char item_name[ITEM_NAME_LENGTH];  

Macro Detection Interface
 
Four new client interfaces are getting implemented in Hercules:
- Macro Register UI
- Macro Detector UI
- Macro Reporter UI
- Captcha Preview UI
 
Usable though the chat commands: /macro_register, /macro_detector, macro_preview for all clients starting 2016-06-30.
Available for testing now at: https://github.com/HerculesWS/Hercules/pull/3051
 
Some sample images

Macro Detection Interface
 
Four new client interfaces are getting implemented in Hercules:
- Macro Register UI
- Macro Detector UI
- Macro Reporter UI
- Captcha Preview UI
 
Usable though the chat commands: /macro_register, /macro_detector, macro_preview for all clients starting 2016-06-30.
Available for testing now at: https://github.com/HerculesWS/Hercules/pull/3051
 
Some sample images

Macro Detection Interface
 
Four new client interfaces are getting implemented in Hercules:
- Macro Register UI
- Macro Detector UI
- Macro Reporter UI
- Captcha Preview UI
 
Usable though the chat commands: /macro_register, /macro_detector, macro_preview for all clients starting 2016-06-30.
Available for testing now at: https://github.com/HerculesWS/Hercules/pull/3051
 
Some sample images

Macro Detection Interface
 
Four new client interfaces are getting implemented in Hercules:
- Macro Register UI
- Macro Detector UI
- Macro Reporter UI
- Captcha Preview UI
 
Usable though the chat commands: /macro_register, /macro_detector, macro_preview for all clients starting 2016-06-30.
Available for testing now at: https://github.com/HerculesWS/Hercules/pull/3051
 
Some sample images

Macro Detection Interface
 
Four new client interfaces are getting implemented in Hercules:
- Macro Register UI
- Macro Detector UI
- Macro Reporter UI
- Captcha Preview UI
 
Usable though the chat commands: /macro_register, /macro_detector, macro_preview for all clients starting 2016-06-30.
Available for testing now at: https://github.com/HerculesWS/Hercules/pull/3051
 
Some sample images

Macro Detection Interface
 
Four new client interfaces are getting implemented in Hercules:
- Macro Register UI
- Macro Detector UI
- Macro Reporter UI
- Captcha Preview UI
 
Usable though the chat commands: /macro_register, /macro_detector, macro_preview for all clients starting 2016-06-30.
Available for testing now at: https://github.com/HerculesWS/Hercules/pull/3051
 
Some sample images

Macro Detection Interface
 
Four new client interfaces are getting implemented in Hercules:
- Macro Register UI
- Macro Detector UI
- Macro Reporter UI
- Captcha Preview UI
 
Usable though the chat commands: /macro_register, /macro_detector, macro_preview for all clients starting 2016-06-30.
Available for testing now at: https://github.com/HerculesWS/Hercules/pull/3051
 
Some sample images

Macro Detection Interface
 
Four new client interfaces are getting implemented in Hercules:
- Macro Register UI
- Macro Detector UI
- Macro Reporter UI
- Captcha Preview UI
 
Usable though the chat commands: /macro_register, /macro_detector, macro_preview for all clients starting 2016-06-30.
Available for testing now at: https://github.com/HerculesWS/Hercules/pull/3051
 
Some sample images

FYI, I have also added Custom Shields & Custom Jobs patches in WARP and yes it supports all clients from 2010 - 2021.

New features
Custom Shields:
Maximum Shield count can be customized now (limited to 127 for now). You can also validate a shield id based on the job id by modifying the ValidateShieldID function in ShieldTable_F.lub. Custom Jobs:
All the Lua files are now in a different folder called 'JobInfo' to avoid mixing in with others.
  You can specify different strings based on servicetype. For e.g. "korea" and "america" can have different strings. 
To achieve this, you need to specify an override table with the name LT_<servicetype number>.
For e.g. LT_0 specifies overrides for korea servicetype. Check PCNames.lub to get a clearer idea. 
At present, it is only used for name changes & palette path changes.
  Scaling for Baby Jobs can be changed. You can change this in Shrink_Map inside PCIDs.lub.
There is one caveat though, due to client limitation, the factor needs to be specified as IEEE hex string.
(no floating-point support in Lua function calls 😒) Common to both:
You get the option to copy the files to your patched client area. The files are copied only if you apply the patch. For Custom Shields, the max shield value also gets updated in the copied file automatically.
  I was planning on more amount of changes in Custom Jobs, but it's on hold for now.
 

Happy Thanksgiving everyone. Since I couldn't get the turkey, I thought I would bring this instead. 
Without further ado, Let me introduce...

WARP (Windows Application Revamp Package)
Why this name?
Because I like using acronyms and this name sounded apt. Plus it's the function & features that matter more.
And no, I am not gonna change the name.
  Why not just fix up NEMO?
The codebase for NEMO is pretty much ancient at this point. So rather than fixing it up, I decided to go the route of creating it fresh from scratch. The end result is a far superior product. 
  OK, but what if you end up AFRO (Away From RO)again?
Well, I can't promise that I will be around forever. However, this time around, I am releasing the source code for the tool as well.
  So, exactly what has changed?
Well, quite a few things. Let's start off with how the GUI looks now.

  As you can see, the GUI is much more modern and aesthetically pleasing thanks to @Haziel & @Hadrias.
  The package comes with 3 tools - Console version (for simple patching), Main GUI, and Tester GUI (for batch testing).
  A big salute to @4144  for keeping NEMO alive while I was AFRO 😄.
Ok, jokes aside, I discussed with him about the changes he made and I have incorporated almost all of them but with some differences. 
  Language & Styles are now on the bottom as you can see. All the remaining menus have now been shifted to drawers (moving side panels). To reveal them you can either swipe from the respective edge or click the button at the top. 
  The right side drawer houses all the Extensions (Used to be called 'Addons' in NEMO).
They are now loaded independently of the client. This avoids unnecessary redefinitions and now you can also use Extensions for activities that don't need a loaded client.
  All the common functions have been added to the 'Quick Actions' group and all the remaining ones are in the left drawer, which is not many. If you have suggestions for more features let me know.

Moving on to the Back end (This is of no use to the regular user. So you can skip this part if you want)
  It was high time for us to have a proper input file format. Enter YAML. Love it or hate it but it's here to stay.
Frankly, I like it more than libconfig and INI. You would be seeing YAML being used for almost every file in WARP.
This includes input files for Patches & Extensions, Files defining those two, Session files, etc.
  Writing patches is far more flexible now. Say goodbye to PTYPE_HEX and \xAB. Now we can do wild card searches with the actual wild cards inside hex codes. Of course, we still need to have some well-defined characters for that.
Currently, we have 2 forms of wildcards - Nibble wise - For e.g. => A?, ??, ?3 Bit wise - For e.g. => [1.0...01] 
  If you have any suggestions about it let me know.
  Speaking of writing hex code, I have provided functions looking almost identical to Assembly instructions for generating their equivalent hex code. This helps in making the hex code more human-readable and adds a little more flexibility.
  User inputs have a few more types and little more flexibility in specifying constraints now. 
  Scripts have proper segregation now. Please follow them when adding your own.
Only the scripts inside the 'Init' folder gets reloaded each time the client is loaded. This avoids unnecessary reloads.
  exe has now become 'Exe'.  But in addition to this, you get 2 more objects - System (for filesystem activities) & Warp (whatever is outside the scope of the other two)
  Many of the functions used for retrieving some constant information in the 'Exe' have become properties now. For e.g. PEoffset, ImageBase, BuildDate, etc.

  During patching, the Diff section is only added if you have inserted any code using one of the 'Add' functions. Also, the Diff section now grows dynamically as per requirement (in increments of Section Alignment of course).
  In addition to the Patched Exe, The tool also generates an (Extra Patch Info) file with the suffix '.epi'. It holds just enough info for the tool to recognize existing patches in an exe from a previous patch session. 
So how is it useful? Let's say you have a patched client and its EPI file. But you don't have the original anymore.
Now you can remove 1 or 2 patches and keep the rest OR even restore the original from the patched exe.
  Last, but not least, I am providing documentation about everything including the API. But bear with me for a bit, as I am still working on the documentation part.
  I probably forgot more points to add here, but I think this pretty much covers the important stuff. Anyway, the documentation would be pretty comprehensive.
  Is it ready to be used now? The tool is definitely ready. I have added most of the patches but not all just yet.
  But I was not able to test all the patches in-game. So please don't attack me if something failed.
I would appreciate a Bug Request in Github instead.
  Also note, that some patches are still failing for new clients, and some failing for old ones. However, I saw the same behavior in NEMO, so that would be part of the next stage of operations - Updating Patch scripts.
  So, where do I get it from?
https://github.com/Neo-Mind/WARP
  How to use it?
There is a User Guide in the git repo (best viewed from Github itself). Everyone is used to NEMO by now, so it shouldn't be difficult to use this even without the guide. Plus the Github wiki is pretty detailed. 
  Any last words before we close this?
Just like in the case of NEMO, my intention with WARP is to create a common tool for patching without being restricted to RO or which OS you use it in. For this reason, you will be seeing multiple branches in the Git repo.

If you are planning to use WARP for patching some other application, Create a branch using the 'win32' branch as a starting point.


That's about it from me for now.

 

Oops, my mistake i mixed up the checks... it does indeed check for 1 element (a 4 bytes float).
This is the struct for cell attributes in aegis, and the check against water level uses h1
struct AttrCell { float h1; float h2; float h3; float h4; int flag; }; *Edit*: corrected the code in previous post

The athena way is what aegis uses, it reads the 4th dword in the cell info struct and compares it with the map water level read from the RSW, the code roughly looks like this (quick draft so i apologize if it's not so clear).
{ std::ifstream gat_fs(filename, std::ios::binary); VALIDATE_MAGIC(gat_fs, "GRAT", 4); gat_fs.read(reinterpret_cast<char *>(&m_verMajor), sizeof(char)); gat_fs.read(reinterpret_cast<char *>(&m_verMinor), sizeof(char)); gat_fs.read(reinterpret_cast<char *>(&m_width), sizeof(int)); gat_fs.read(reinterpret_cast<char *>(&m_height), sizeof(int)); m_cells.resize(m_width * m_height); gat_fs.read(reinterpret_cast<char *>(m_cells.data()), m_cells.size()); std::for_each(m_cells.begin(), m_cells.end(), [idx = 0](struct CAttrCell &cell) mutable { if (cell.flag == 1 || cell.flag == 5) m_TileInfo[idx] |= SVR_CELL_BLOCK; if (cell.flag != 1) m_TileInfo[idx] |= SVR_CELL_ARROW; if (cell.h1 > m_waterLevel) // m_waterLevel from RSW m_TileInfo[idx] |= SVR_CELL_WATER; ++idx; }); return 0; }  

Oops, my mistake i mixed up the checks... it does indeed check for 1 element (a 4 bytes float).
This is the struct for cell attributes in aegis, and the check against water level uses h1
struct AttrCell { float h1; float h2; float h3; float h4; int flag; }; *Edit*: corrected the code in previous post

The athena way is what aegis uses, it reads the 4th dword in the cell info struct and compares it with the map water level read from the RSW, the code roughly looks like this (quick draft so i apologize if it's not so clear).
{ std::ifstream gat_fs(filename, std::ios::binary); VALIDATE_MAGIC(gat_fs, "GRAT", 4); gat_fs.read(reinterpret_cast<char *>(&m_verMajor), sizeof(char)); gat_fs.read(reinterpret_cast<char *>(&m_verMinor), sizeof(char)); gat_fs.read(reinterpret_cast<char *>(&m_width), sizeof(int)); gat_fs.read(reinterpret_cast<char *>(&m_height), sizeof(int)); m_cells.resize(m_width * m_height); gat_fs.read(reinterpret_cast<char *>(m_cells.data()), m_cells.size()); std::for_each(m_cells.begin(), m_cells.end(), [idx = 0](struct CAttrCell &cell) mutable { if (cell.flag == 1 || cell.flag == 5) m_TileInfo[idx] |= SVR_CELL_BLOCK; if (cell.flag != 1) m_TileInfo[idx] |= SVR_CELL_ARROW; if (cell.h1 > m_waterLevel) // m_waterLevel from RSW m_TileInfo[idx] |= SVR_CELL_WATER; ++idx; }); return 0; }  

As of Release v2019.05.05 you can now create groups of random options that may be assigned to items dropped by monsters.
In order to use it you must first create an Option drop group in db/option_drop_groups.conf, one group will set how each option slot is filled, the chance of it getting filled, etc. Each group has the following structure:
<Group Name Constant>: ( { // Option Slot 1 Rate: (int) chance of filling option slot 1 (100 = 1%) // Possible options for slot 1 // min/max value : int, defaults to 0 // chance : int, 100 = 1% if not set, will be 100%/number of possibiltiies OptionName: value // or OptionName: [min value, max value] // or OptionName: [min value, max value, chance] // ... (as many as you want) }, // ... (up to MAX_ITEM_OPTION) ), Details about this file may be found on Hercules' docs (doc/option_drop_group.md). This is an example group called MYGROUP:
MYGROUP: ( { /* Option Slot 1 */ Rate: 10000 /* It has 100% of chance of being filled */ /* This slot may have one of the following options: */ WEAPON_ATTR_WIND: 5 /* WEAPON_ATTR_WIND Lv5 (33.33%) */ WEAPON_ATTR_GROUND: [2, 4] /* WEAPON_ATTR_GROUND Lv 2~4 (33.33%) */ WEAPON_ATTR_POISON: [1, 4, 8000] /* WEAPON_ATTR_POISON Lv 1~4 (80%) */ }, { /* Option Slot 2 */ Rate: 5000 /* It has 50% of chance of being filled */ /* If filled, may have one of the following options: */ WEAPON_ATTR_WATER: 4 /* WEAPON_ATTR_WATER Lv4 (100%) */ } ) Once a group is defined, you can them assign it to monster drops in mob database by using a new syntax that works for both Drops and MvpDrops:
AegisName: (chance, "GROUP_NAME") This will set that the item AegisName has chance chance of drop (like we already know from the format already in use), and, when dropped it will get random options as specified by the group GROUP_NAME.
For example:
Knife: (5000, "MYGROUP") Will make "Knife" be dropped with a chance of 50%, and when dropped it will get options as defined by MYGROUP option group, in other words, the first slot will be filled with Wind, Ground or Poison option, and the second slot may or may not be filled with Water option.
This feature should work on any client that supports item random options.

Display group (titlte) and icon for mobs, homunculus, npc, mercenaries
For set icon in some way need get bl_id of npc, mob etc and call function:
 
Set icon
setunitdata(GID, UDT_GROUP, ID) Icon files stored in directory data/texture/유저인터페이스/group/group_ID.bmp
Where GID is bl id of being, ID is icon id.
Example for npc:
setunitdata(getnpcid(), UDT_GROUP, 3); It will use this image:
data/texture/유저인터페이스/group/group_3.bmp  
Set group
setunittitle(GID, group_name);
Where group_name is any name what you want assign to group
Example for npc:
setunittitle(getnpcid(), "Hercules");  
Sample images



 
Works from versions:
ragexe from 20180207,
ragexeRE from 20171129,
ragexe_zero from 20171130

View File Custom Flag GR2
Hello once again... ;]
Here to bring you guys this GR2 edit of the old guild flag that i've made years ago.

This release features a more high resolution mesh with a 2 sided flag, showing the emblem in both sides. It means that you can overlap 2 flags with 2 oposite directions to generate a  cool effect. You can do what you want.

The instalation:
- at jobname.lua/lub:
-- [jobtbl.JT_GUILD_FLAG] = "rapa_flag.gr2",

note that you cannot have the _1 at the end of de .gr2 filename since it brings the 3dmob_bones into action and we dont want that.

some cons:
- since it is a high res model it takes longer to load ( affects map loading time )
- the positioning of a 3D gr2 mob is always very glichy, for example the final position after movement is diferent from deafault 8 directional.. so you can come up with some ideas to position it right. For example, doing a OnInit: walknpc... to make it walk to the direction you want it to face...

Video: ( Was recording other stuff but the model appear on screen, don't mind what i'm doing... )
 
Submitter raPalooza~ Submitted 05/02/19 Category Other Graphics  

The data available in the GRF files is just the resources, the actual animation is done by the client code (which isn't public), basically his project is to look into decompiled client code and try to emulate these animations in roBrowser.

Well I've done few changes to this, I used same method as @AnnieRuru but as a plugin, first hercules provides us with the amazing status->pc_calc_additional which is meant for plugins, it's placed right after Equipment parse so it would not overwrite the value the plugin set, and then the plugin set the matk rate to 0, and tada!
I've also changed map check to check the id of the map instead, this is simpler, faster and also allowed a run time check for if you accidentally put a wrong map name (check server_online function), and it's tested :3 works as charm!
/** * This file is part of Hercules. * http://herc.ws - http://github.com/HerculesWS/Hercules * * Copyright (C) 2013-2019 Hercules Dev Team * Copyright (C) Hemagx <[email protected]> * * Hercules is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program. If not, see <http://www.gnu.org/licenses/>. */ /// Zero Matk Hercules Plugin #include "common/hercules.h" /* Should always be the first Hercules file included! (if you don't make it first, you won't be able to use interfaces) */ #include "common/core.h" #include "common/mapindex.h" #include "map/map.h" #include "map/pc.h" #include "map/status.h" #include "plugins/HPMHooking.h" #include "common/HPMDataCheck.h" /* should always be the last Hercules file included! (if you don't make it last, it'll intentionally break compile time) */ HPExport struct hplugin_info pinfo = { "Zero MATK", // Plugin name SERVER_TYPE_MAP,// Which server types this plugin works with? "0.1", // Plugin version HPM_VERSION, // HPM Version (don't change, macro is automatically updated) }; const char *map_name = "prontera"; int16 map_id = -1; // init it with invalid value to make sure on failure it would always cause our check to fail. static void status_calc_pc_additional_post(struct map_session_data *sd, enum e_status_calc_opt opt) { if (sd == NULL) // I don'r prefer usage of nullpo in hooks, unless we're replacing a function multiaple nullpo reports can turn confusing. return; if (sd->bl.m != map_id) return; sd->matk_rate = 0; return; } /* run when server starts */ HPExport void plugin_init (void) { addHookPost(status, calc_pc_additional, status_calc_pc_additional_post); } HPExport void server_online (void) { unsigned short map_index; if ((map_index = mapindex->name2id(map_name)) == 0) { ShowError("%s:plugin_init: Failed to get map index for map %s the plugin would now fail to start\n", pinfo.name, map_name); core->runflag = CORE_ST_STOP; } if ((map_id = map->mapindex2mapid(map_index)) == -1) { ShowError("%s:plugin_init: Failed to get map id for map %s the plugin would now fail to start\n", pinfo.name, map_name); core->runflag = CORE_ST_STOP; } }  

im not sure how this is could be done but an easier solution would be to give the player the box again if it failed.

As of v2018.07.29 release Hercules supports  item id up to 65535 for client versions older than 2018-07-04 RE, main and zero client, and up to 2147483648 for RE clients with version bigger than that.

Hello, I'm sure i have answered this somewhere else but basically, Ragexe, RagexeRE, Ragexe_zero these are the client releases used on the official Korean servers in general there is few user interface differences and few features that may exist in one and not the others but eventually all of them get the features in later releases. as for Hercules I'd suggest the use of Ragexe or Ragexe_zero (zero only if you want something that exist in it..) because those are the main servers (RagexeRE are for a test server so some features can be broken in early versions) last thing your server build (pre-re or re) doesn't matter to the client you can run any version for any build you want.
for nemo fork secret's  one is discontinued you can use this instead: https://gitlab.com/4144/Nemo

use
atcommand(sprintf("#warp \"%s\" %s 22 50", .@playername$, .arena_map$));  

@astralprojection I have pushed an update to #2218 which added support for specifying an item amount range (0 should be allowed), feel free to test it and tell me if you found any issues.