Neo-Mind

Introduction
     For our Example we will create the Custom Class "Shinobi" and its Child version i.e. "Baby Shinobi" along with their Cash Mounts/Halter Mounts. Each Job has 3 ID values :
 
1) Job ID - we will use 4230 & 4231 respectively for the jobs (4232 & 4233 will be reserved for the mounts client side).   2) Map ID - Also called EA Mask. If we are extending a class we OR the existing class with a modifier. Since Shinobi is going to be a seperate branch, we will use 0x11 for Shinobi and 0x11 | 0x2000 for Baby Shinobi (0x2000 is the JOBL_BABY mask).   3) Msg ID - Defined in messages.conf file. We will use 700 and 701.   Before we begin, A few points to note:
1) For the client side i will be using my own patch from NEMO not Xray clients - So dont ask me about Xray.
 
2) This guide is meant to be an overview towards adding jobs - meaning that your job will be enabled once you have done the changes     specified here . You can add further details on your own which depends on your Class.
 
3) If i am missing out on anything please let me know. Nobody is perfect including me
 
4) We will use Sprite and some data from Ninja class for the time being but you can add your own entries just as easily.
 
 
Server Source 1) src/common/mmo.h: look for JOB_REBELLION assignment and insert our Job IDs after it.      
 
2) src/map/map.h: look for MAPID_BABY_CHASER and insert our Map IDs after it.         3) src/map/pc.c:     i) find case JOB_BABY_CHASER: and insert our cases after it       ii) find case MAPID_BABY_CHASER: and insert our cases after it         iii) find case JOB_REBELLION: followed by return msg_txt(655); and insert our cases after it. (returns the Msg ID)       iv) find { "Rebellion", JOB_REBELLION }, and insert our Job Names after it       4) src/map/itemdb.c: Here we check the job masks that is specified in item_db.conf. There is one limitation, however.     Currently there is only 1 more slot left in the job mask since it is 32 bit. In case you need to add more you will need to     change the variable to 64 bit.         Find jobmask & 1<<30 and insert our class check after it.         5) src/char/inter.c: Find case JOB_REBELLION: and insert our case after it.(returns the Msg ID)         Server Config 1) db/const.txt:       i) Find Job_Rebellion and insert our Job IDs after it       ii) Find EAJ_BABY_CHASER and insert our Map IDs after it         2) db/<pre-re|re>/exp.txt: Insert your IDs in one of the entries (or if you want to specify your own exp per level you can add that).    Since our jobs are meant to be amongst First Class, we will simply add it into existing ones.       i) Base:     ii) Job:   3) db/<pre-re|re>/job_db.conf: Add entry for your Job. We will copy the entry from Ninja with slight changes for now.         4) db/job_db2.txt: Add entry for your Job. Again we will reuse the data from Ninja.         5) conf/help.txt: Insert your class entries to the @go message         6) conf/messages.conf: Add the Msg IDs after Shadow Chaser T         7) db/<pre-re|re>/skill_tree.conf: Add entry for your Job similar to the others.      -pic to be added-     Client Lua Files Now to make the client support Custom Jobs it should be patched with "Enable Custom Jobs" patch in NEMO.  Also you should copy the lua files inside Support folder to different area so we can Add entries of our jobs.  (LuaFiles514/Lua Files/Admin folder inside is what we need essentially)   1) PCIDs.lub :     i) First we add all our Job IDs (look for JT_2004_JOB_LAST entry).       ii) Next we connect the Cash Mount Job IDs to Main Job IDs (Look for JT_REBELLION mapping).         iii) Lastly we need to add our Baby Class & its mount to the Baby_List (Look for JT_LION_CRUSADER_B).       2) PCNames.lub: To illustrate that different names can be assigned based on gender, I am calling them as Shinobi M & Shinobi F for Male & Female respectively.     i) First we add the Job Name for Male Characters (Look for Rebellion)     ii) Next we make the Cash Mounts inherit Names from their respective Main Jobs - since Mounting don't change the name (Look for JT_PECO_REBELLION).         iii) Last but not least we add the Job Name for Female characters - Only necessary if it differs from Male name (Look for JT_SORCERER_B).       3) PCPaths.lub: Here we specify the job specific prefix used by the client to get the job sprite.   i) First we add the Path prefix for Jobs that is not shared with any existing ones.       ii) Next we make the Jobs that has shared path inherit from existing (for e.g. Baby Jobs inherit from Adult versions).   4)PCHands.lub: Here we specify the job specific prefix used by the client to get the weapon and shield sprite locations     i) Like before, First we add the Hand prefix for Jobs that is not shared with any existing ones.     ii) Next we make the Jobs with shared prefix inherit from existing (e.g. Baby Jobs, Mounts, Baby Mounts etc. all can inherit from Adult versions).   5)PCPals.lub: Here we specify the job specific prefix used by the client to get the Palette file location.     i) Like before, First we add the Pal prefix for Jobs that is not shared with any existing ones.     ii) Next we make the Jobs with shared prefix inherit from existing (e.g. Baby Jobs, Mounts, Baby Mounts etc. all can inherit from Adult versions).     Note: You can also optionally add entries in PCImfs.lub file in case you have an Imf file, but I haven't seen any issues even without it.  Hence I am not pursuing it.   Once the edits are done pack it into your grf or put it in your data folder and use it. With this much your job will be visible and able to do everything provided you have the sprite files in the right location.   spriteÀΰ£Á·¸öÅë³²<pathprefix>_³².spr and act for Male Job  spriteÀΰ£Á·¸öÅë¿©<pathprefix>_¿©.spr and act for Female Job   Snapshot: (to be added)    

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.

 

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.

 

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.
 

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.
 

Update 2021-02-26:
While this still has no tangible name, currently running under the working name SKAL (which was previously ELUR and permutations thereof, including LURE, even though it won't lure anyone), the patching launcher itself is taking form. The plug-in system will be post-poned to a later version, because currently it is very fragile and the built-in functionality ought to be enough for anybody.
 
The skin support, as opposed to ROCred, will use PNG rather than BMP. While magenta will still serve as transparent color and alpha-blending support is absent, at least the skin files will be smaller. Like pre-2.4.5 RSU plug-ins PANTEXT and PANHTML, the patch news will be built-in and use the IE WebView for HTML patch news (how that works out on Win10 will be left for community feedback). The major difference is, that you can summon multiple patch news (as much as Windows allows), for example for providing seem-less interactive controls to the interface, like server status. As in ROCred the amount of buttons is also limited by available memory only.
 
The patch part builds on top of the RSU4 framework and the RSULIB3 library so you get the same performance, but with multi-GRF support. RGZ support is planned in the initial version. Later versions may introduce support for ZIP, RAR, 7Z/LZMA, either built-in, or as plug-ins.
 
The launcher part remains essentially unchanged to ROCred.
 
How configuration will be provided is not yet decided, options are three. Embedded into the plauncher (AV vendors hate this), a separate file or files, or all resources stored in a remote location.

Hello.
I know that much time has passed, but for now i'm getting back on the client.
Soon aesir.perfontain.ru will be shut down, so, please, stay tuned on aesir.perfontain.cc
Thanks for your support !
 
@banhelba2019For sure, any type of effect you can implement.

Of course, people will read it 😀. Atleast I am waiting to see how this turns out.

Merging is still in progress, the rsu codebase is messy, so it will take some time.
Update 2017-08-04:
Someone give me a full week hikikomori mode without disturbance and I can release it...
Update 2017-08-05:
People who will want to extend the functionality of the patncher, can start learning COM. The plug-in will have to establish communication with a call like this:
hr = CoGetClassObject(CLSID_PluginServiceProvider, CLSCTX_INPROC_SERVER, NULL, IID_IClassFactory, &lpServiceProvider); Update 2020-08-18:
Obviously no one will read this, and no one will dare to make a necro-post in response to this. Since I have nothing to do for a week, I'm finishing that thing. Things are coming along quite well so far. The updater part is written from scratch, since the RSU code-base is too outdated. Not sure about the ROCred part, there is currently no UI. Oh yeah, there is no name either...

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

maybe it got "auction"ed off !! 

Probably not xD.
Anyways, I am working on development of a new patcher as a successor to the original aka NEMO. 

Initially, I was planning to just release the source for NEMO but is quite outdated.
So I decided to just start off fresh utilizing concepts from the original along with new ideas (Already have some implemented, which I will explain later)

Also this time, I will be keeping it open source. I will publish to Github once there is a solid foundation.
 
I am building it using the latest version of Qt (5.15) and utilizing QML for creating the GUI. I want to give it a more modern appearance, however, I am a "novice" on this front. So I am inviting suggestions for the UI from the talented individuals here.

 

Probably not xD.
Anyways, I am working on development of a new patcher as a successor to the original aka NEMO. 

Initially, I was planning to just release the source for NEMO but is quite outdated.
So I decided to just start off fresh utilizing concepts from the original along with new ideas (Already have some implemented, which I will explain later)

Also this time, I will be keeping it open source. I will publish to Github once there is a solid foundation.
 
I am building it using the latest version of Qt (5.15) and utilizing QML for creating the GUI. I want to give it a more modern appearance, however, I am a "novice" on this front. So I am inviting suggestions for the UI from the talented individuals here.

 

Probably not xD.
Anyways, I am working on development of a new patcher as a successor to the original aka NEMO. 

Initially, I was planning to just release the source for NEMO but is quite outdated.
So I decided to just start off fresh utilizing concepts from the original along with new ideas (Already have some implemented, which I will explain later)

Also this time, I will be keeping it open source. I will publish to Github once there is a solid foundation.
 
I am building it using the latest version of Qt (5.15) and utilizing QML for creating the GUI. I want to give it a more modern appearance, however, I am a "novice" on this front. So I am inviting suggestions for the UI from the talented individuals here.

 

Probably not xD.
Anyways, I am working on development of a new patcher as a successor to the original aka NEMO. 

Initially, I was planning to just release the source for NEMO but is quite outdated.
So I decided to just start off fresh utilizing concepts from the original along with new ideas (Already have some implemented, which I will explain later)

Also this time, I will be keeping it open source. I will publish to Github once there is a solid foundation.
 
I am building it using the latest version of Qt (5.15) and utilizing QML for creating the GUI. I want to give it a more modern appearance, however, I am a "novice" on this front. So I am inviting suggestions for the UI from the talented individuals here.

 

Probably not xD.
Anyways, I am working on development of a new patcher as a successor to the original aka NEMO. 

Initially, I was planning to just release the source for NEMO but is quite outdated.
So I decided to just start off fresh utilizing concepts from the original along with new ideas (Already have some implemented, which I will explain later)

Also this time, I will be keeping it open source. I will publish to Github once there is a solid foundation.
 
I am building it using the latest version of Qt (5.15) and utilizing QML for creating the GUI. I want to give it a more modern appearance, however, I am a "novice" on this front. So I am inviting suggestions for the UI from the talented individuals here.

 

Probably not xD.
Anyways, I am working on development of a new patcher as a successor to the original aka NEMO. 

Initially, I was planning to just release the source for NEMO but is quite outdated.
So I decided to just start off fresh utilizing concepts from the original along with new ideas (Already have some implemented, which I will explain later)

Also this time, I will be keeping it open source. I will publish to Github once there is a solid foundation.
 
I am building it using the latest version of Qt (5.15) and utilizing QML for creating the GUI. I want to give it a more modern appearance, however, I am a "novice" on this front. So I am inviting suggestions for the UI from the talented individuals here.