Search the Community

This topic about Nemo fork https://gitlab.com/4144/Nemo Most changes present in ChangeLog Patches reports service: http://nemo.herc.ws For test Ragnarok zero clients need: this nemo fork and enable at least patches from https://gitlab.com/4144/Nemo/blob/master/profiles/zero_minimal.log this or similar clientinfo.xml https://gitlab.com/4144/Nemo/blob/master/configs/zero/clientinfo.xml From 2018-11-14 in all clients must be enabled patch Remove hard coded address/port For clients newer than 2018-03-09: Need manually copy cdclient.dll from Nemo/input or enable patch "Copy patched Cheat Defender Game Guard" Clients exe downloads: http://nemo.herc.ws/downloads/ Full client downloads: http://nemo.herc.ws/downloads/#downloadable-full-clients Discord: https://discord.com/invite/ByEQHDf

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.

I've tried a couple different versions of NEMO and everytime I try to load a custom lua file instead of iteminfo.lub it fails in step 1 "reference not found" I assume it means iteminfo.lub has a different location in this ragexe.exe not sure how to find it though.

Hi to all, i'm having issue with Nemo, i'm using latest one by @4144 Hexed : 2014-03-05b everything is ok but the Hide Map Button / Hide Quest Button, i need at least to hide the map button, i already disable the world map.... can someone help with this? Edit: Solved i copy the new HideButton.qs from github thanks! https://github.com/MStr3am/NEMO/blob/df6da1542f2ef14be671b07a472ef2933ade2fc9/Patches/HideButton.qs

Need Help i search and change many thing on the config of the emulador and keep getting error when login! can't pass to character selection! when i login i even see the login_log on login-server but that it! nothing else. above all configs! please need help! my client is the one here: 2018-06-20d_RagexeRE.exe My clientinfo.xml: <?xml version="1.0" encoding="euc-kr" ?> <clientinfo> <desc>Ragnarok Online Client Information</desc> <servicetype>korea</servicetype> <servertype>sakray</servertype> <connection> <display>Local</display> <address>ipragnarok.myrag.com.br</address> <port>8040</port> <version>46</version> <langtype>0</langtype> <registrationweb></registrationweb> <loading> <image>loading00.jpg</image> </loading> <yellow> <admin>2000000</admin> </yellow> </connection> </clientinfo> char-server_log.txt login-server_log.txt map-server_log.txt map-server.conf packet.conf subnet.conf char-server.conf client.conf inter-server.conf login-server.conf

How Increase Hairstyles on newer clients without NEMO Diff (Enable 64k Hairstyle), Since it not work anymore on newer clients? I'm using: 2017-01-25a Hexed. Please, somebody could help me?

Can someone please fix this NEMO patch (using 2014-02-05 client) or any kind of code which will allow to display fake guild emblem on top of Player in BG maps. Enable Emblem for BG This patch has alignment problem like this image other than that it working fine, i would be great if this patch turned for regular Nemo version. Thanks.

hi guys! just wondering how to change font using nemo? what should i change inside clientinfo.xml? if you could please share step by step guide it would be awesome! thanks in advance!

I am following http://herc.ws/board/topic/8894-guide-setting-up-2013-client-for-hercules/ to setup my client side. I have tried patching several clients (2013-08-07, 2014-02-05, 2014-04-16a), tried disabling recover login and adding a launcher (loki), checked that the patch for disabling ragexe name was applied, etc. However whenever i start the client it just does not start, the process can be seen in the task manager, but it does not start and there is no error message to help me. The DATA.INI file is not created, i also have no idea about where i need to create the xml for the client settings, and the resources around are very scarce.

Hello! I diffed my client via NEMO Patcher, and it works great, but it seems to have some limitations ??? The minimum zoom out diffed is 50%, which is way tooo far for me. Is there a way to enable only up to 25% Can somebody lead me to hex of it? And I restored the old level 99 auras, it works great. But the problem is Monsters with lvl 99+ has also Auras. Nemo doesn't have option for that. How can I only allow auras to level 99? Btw, at server-side, I tried: But that did not help. LOL. Thanks!

Now Before we delve into the details, lets consider a few things - this is meant for newbies. If you have made patches before skip ahead. Introduction to patching When we say we patch a client what it means is we change few bytes with a different set of bytes. (essentially we change a few opcodes or assembly instructions for e.g. a JNE to JMP so that the client behaves differently) Now these codes will be different for each client date and/or their location will change. So how do we make it generic? For this you need a sort of flow-chart to follow to get to the locations where modification needs to be made and for getting the replace logic. If you know how the original bytes were found , try to make note of the procedure you followed and you can usually make a patch following same logic. For e.g. like find a string -> find where its pushed -> 8 bytes later there is a JNE -> change to JMP Another step that helps out is finding a common pattern in a set of clients around where your modification is to be done. For e.g. Lets say i find '75 C0 E8 09 22 04 00 68 44 65 97 00' in 20130612 and '75 C0 E8 10 23 04 00 68 54 44 98 00' in 20130626 common pattern => '75 C0 E8 ?? ?? ?? 00 68 ?? ?? ?? 00' where ?? can be anything so you can use this common pattern instead of the individual ones. Not sure whether I made it clearer or confused you with that Intro. To summarize - making a patch is a combination of finding byte patterns, finding referenced addresses, changing instructions, finding vacant spaces and adding new codes, updating calls etc. If you know assembly language then it should be easy for you. If you don't know already try to read up on it at-least a little before going forward Now then back to topic Patches in NEMO The patches for NEMO are written in QtScript which follows ECMAScript format guidelines same as ... Javascript Therefore almost all of the functions & behaviors offered by Javascript you will find is also there in QtScript (well except for the actual web development part ) So I am not going to concentrate on the language itself. But rather I would be focussing on What all aspects are there specific to NEMO. NEMO Patch Instructions For NEMO to recognize a patch it needs to be registered. This is done in _patchlist.qs file in the patches folder. FORMAT for registering patch : registerPatch(patch id, functionName, patch Name, category, group id, author, description, recommended [true/false] ); patch id - a unique number used for referring to the patch internally in NEMO. functionName - the name of the function which will be called when a patch is enabled in NEMO. This function will contain your logic for making modifications into the client. patch Name - Name of the patch (displayed in the table) category - Category of the patch (like UI , Data, etc. displayed in the table) group id - id of the registered group to which this patch will belong. (details below) author - Patch Maker's Name (displayed in the table) description - Description of what the patch does (displayed in the table) recommended - boolean value showing whether this belongs to the recommended list of patches. Each Patch will belong to a Patch Group (if its not supposed to be part of any specific group use group id 0). All Patch Groups must be registered before they are used (except for 0 which is the Generic Patch Group registered by default) FORMAT for registering group : registerGroup(group id, group Name, mutualexclude [true/false]); group id - a unique number used internally in NEMO as well as when registering a patch. group Name - Name of the group (displayed in the table for all member Patches) mutualexclude - boolean value determining whether member patches are mutually exclusive i.e. Only 1 can be selected at a time or not. Once a patch is registered you need to make the function (name specified while registering). You can make it in any .qs file and save it in patches folder. It will be read automatically. Now to facilitate writing patches there are some ready-made variables & functions available to you. Now to facilitate writing patches there are some ready-made variables & functions available to you. 1) Reserved Keywords (well in a sense) i) Section Types - The following four can be used for referring to a section instead of using the section name itself as an alternative. CODE = 0, DATA = 1, IMPORT = 2, DIFF = 3 ii) User Input Types - These are the available input types in NEMO that you need to specify while getting an input value from user with the getUserInput() Function. Based on the types a different prompt appears for the user to select the value. You will understand more once you see function later on. XTYPE_NONE = 0, XTYPE_BYTE = 1, XTYPE_WORD = 2, XTYPE_DWORD = 3, XTYPE_STRING = 4, XTYPE_COLOR = 5, XTYPE_HEXSTRING = 6, XTYPE_FONT = 7, XTYPE_FILE = 8 iii) Pattern Types - You can specify a string in two forms : PTYPE_STRING => 0) Regular C Style string with Null termination - i.e. anything after '0' or "x00" will be ignored. E.g. "Ragnarok" PTYPE_HEX => 1) Hex String with spacing - You specify each byte with a space prefixed before it. E.g. " 68 90 00 95 00" As you might have guessed already if you have a null byte in your hex string always use PTYPE_HEX. iv) Address Types - Currently it is only used in findString() function to specify the type of value you want returned RAW = 0, RVA = 1 i.e. RAW/real address or Relative Virtual Address 2) Global Variables APP_PATH = path where NEMO is run from. CLIENT_FILE = path of the currently loaded client exe. Whenever your client exe gets loaded the object gets updated to refer to the loaded client. To access the bytes inside the exe we make use of the various methods of this object (Client Access functions detailed below). 3) Client Access Functions 3.1) - Fetching data i) exe.fetchByte(offset) - Extract 1 Byte and return it as a signed number. ii) exe.fetchWord(offset) - Extract 2 Bytes and return it as a signed number (little endian) iii)exe.fetchDWord(offset) - Extract 4 Bytes and return it as a signed number (little endian) iv) exe.fetchQWord(offset) - Extract 8 Bytes and return it as a signed number (little endian) v) exe.fetch(offset, num) - Extract <num> Bytes and return it as a string ( PTYPE_STRING ). vi) exe.fetchHex(offset, num) - Extract <num> Bytes and return it as a hex string ( PTYPE_HEX ). Do note that the returned hex string will already have space prefixed. 3.2) - Searching for data i) exe.find(pattern, type, useWildCard = false, wildCard = "xAB", start = -1, finish = -1) This is the core searching function available in NEMO. All the others are just extended versions of this function. This function searches for the <pattern> you provide in the client between the <start> and <finish> offsets. You need to specify the pattern <type> (PTYPE_STRING or PTYPE_HEX) for the client to use it accordingly. if start is -1 then it will automatically shift to beginning of the file i.e. 0, similarly if finish is kept at -1 it automatically shifts to the end of the file. Sometimes you wish to search for a pattern like " 68 ?? ?? ?? 00 74 ?? 83" where ?? actually means you dont care what is there in those areas. So how to search in those scenarios? First replace the ?? with a byte you dont have in your original pattern. For e.g. " 68 AA AA AA 00 74 AA 83" and call exe.find() with useWildCard as true and wildCard as "xAA" like shown below. var offset = exe.find(" 68 AA AA AA 00 74 AA 83", PTYPE_HEX, true, "xAA") - i didnt set the start and finish since i want the full client searched. If a match is not found then this function returns -1. ii) exe.findAll(pattern, type, useWildCard = false, wildCard = "xAB", start = -1, finish = -1) Same functionality as exe.find except that exe.find() stops at the first matched location but this one returns array of all matched locations. If no matches are found returned array is empty. iii)exe.findCode( pattern, type = PTYPE_HEX, useWildCard = false, wildCard = "xAB") - Extended version of exe.find() function with searching limited to CODE section iv) exe.findCodes(pattern, type = PTYPE_HEX, useWildCard = false, wildCard = "xAB") Extended version of exe.findAll() function with searching limited to CODE section v) exe.findString(pattern, rtype = RVA, prefixZero = true) - Extended version of find function with searching limited to DATA section. pattern can only be a PTYPE_STRING. rtype argument here refers to what type of address should be returned when found (RAW or RVA). If you want to search for isolated strings (i.e. NULL on both sides) set prefixZero to true vi) exe.findFunction(pattern, type = PTYPE_STRING, isString = true) - Extended version of find function for getting the address of an imported function. You can either specify the function's original name or the address of the function name in IMPORT section. vii)exe.findZeros(zsize) - Extended version of find function used for locating empty space in DIFF section for inserting new code. The function always looks for zsize+2 null bytes to make sure each inserted code is seperated by atleast 1 null byte. 3.3) - Modifying data i) exe.replace(offset, code, type = PTYPE_STRING) The core function used for replacing bytes in the client file. code is the pattern which will replace the original - don't forget to mention the pattern type. There is no return value for replace functions. You can also provide the variable name you used in exe.getUserInput() function earlier as the code (NEMO will pick up the value inside). ii) exe.replaceWord(offset, code) - Extended version of exe.replace(). Here code is expected to be a 16 bit signed number. iii)exe.replaceDWord(offset, code) - Extended version of exe.replace(). Here code is expected to be a 32 bit signed number. iv) exe.insert(offset, allocSize, code, type = PTYPE_STRING) - Extended version of exe.replace() used for Inserting code into Null areas. offset should be the value you got from exe.findZeros(allocSize). 3.4) - User Interaction i) exe.getUserInput(varname, valtype, title, prompt, value, min=0, max=2147483647) - Prompts the user for a value. Based on the valtype you get different windows for value entry and the value selected by the user is also returned by the function. varname used should be unique across patches and can be used in replace & insert functions to refer to the user entered value. title is the text displayed on the input window title bar prompt is the text displayed as prompt next to the input box. in case there is no input box. for e.g. like in XTYPE_COLOR , the prompt is suffixed to the title bar itself. value is the initial value to use for the input. If the variable was set previously or reloaded from a profile/from a previous applied patch, this value is ignored. 3.5) Section information All the four functions mentioned below gets 1 information of a section specified by key. key can be either the section name or section type (mentioned at top) i) exe.getROffset(key) - Real Offset ii) exe.getRSize(key) - Real Size iii)exe.getVOffset(key) - Virtual Offset iv) exe.getVSize(key) - Virtual Size 3.6) Miscellaneous i) exe.getClientDate() - Need i say more? ii) exe.isThemida() - return true if its a 2013 unpacked client. iii)exe.Raw2Rva(rawaddr) - Converts a RAW/real address to Relative Virtual Address. iv) exe.Rva2Raw(rvaaddr) - inverse of above. In case you are still wondering: RAW address is the physical offset of a code (bytes) from beginning of the client which you see in a Hex Editor such as HxD. Relative Virtual Address or RVA is the address you see for the same code when you open the client in a debugger such as Ollydbg. RVA is relative to a value called imagebase hence the name Relative Virtual Address. RVA - imagebase = VA. 4) Utility Functions There are a few utility functions written in QtScript (you will find them in the core folder) to facilitate some commonly done routines. i) "string".replaceAt(i, newstring) - by default strings have a replace command but no command to replace at a specific offset this one does that. For e.g. "abracadabra".replaceAt(4,"k") will return "abrakadabra" ii) "string".repeat(i) - returns new string with the "string" repeated i times e.g. "na".repeat(4) will return "nananana" .... ... batman? iii)"hexstring".hexlength() - returns the number of bytes in the hex string (PTYPE_HEX). For e.g. " 90 49 54".hexlength() returns 3 iv) "string".toHex() - converts string to hex string (from PTYPE_STRING to PTYPE_HEX) e.g. "AM".toHex() returns " v) "string".toHexUC() - converts string to hex string (similar to above but extra null byte padding is provided - like ASCII in Unicode) vi) "hexstring".toAscii() - reverse of iv) vii) (Number).packToHex(size) - packs a number to its little endian hex string with the size number of bytes used up size can be maximum 4. the number or expression needs to be in a bracket or a variable. e.g. (123456).packToHex(4) => " 40 E2 01 00" viii) getInputFile(f, varname, title, prompt, fpath) - repeatedly loops until a valid file is specified as input or the form is cancelled => patch should be disabled. 5) TextFile class Since I found no suitable types in QtScript for accessing files. I have added a new class called TextFile for accessing textfiles.To use the class first we need to make an object of the class (yes i mean in the patch file itself) var fp = new TextFile(); Methods i) fp.open(<absolute file path>, <mode>) - once fp is assigned we need to use the open method to use it to access a file. mode can be "r" or "w" ii) fp.readline() - currently only reading full line is available, since i needed full lines at a time. iii)fp.write(data) - writes the specified data onto file. iv) fp.writeline(data) - same as above but also adds a carriage return + form feed (goes to new line) v) fp.eof() - true when end of the file has been reached. vi) fp.close() - closes the file opened by fp.open() You can check the TranslateClient.qs file in patches folder for an example of its use. --------------------------------------------------------------------------------------------------------------------------------------------------------- Hmm what else .... so now that you have gone through this guide, hopefully you can better understand what is written in the patches already there. and maybe bring in your own ideas? Let me know if any part of this guide didn't make sense, needs elaborations, clarifications etc. FYI: I know it doesn't look pretty right now. But this was done in a hurry since I will be gone for a week . I will clean things up later on.