KirieZ

These are all related to your client Lua files. (Note: ".lua" may be ".lub" and you may have some other suffix depending on main/RE or if you have some nemo patch renaming them) The small yellow/white text is part of Quest UI, it is in System/OngoingQuestInfoList_True.lua The item issue is likely related to some issue in System/ItemInfo_True.lua The icons are in data/luafiles514/lua files/signboardlist.lub

The reason I mentioned enabling/disabling plugins, and also trying a clean hercules is to help you find where the issue is. There is no way to fix without knowing where the issue is. If you can find the hercules version (follow 4144 advice above), try creating a separate folder and cloning hercules in this version and build and run it with no further customization (just change client date and set pre-re). Make a totally new server, should take you only a few minutes. This will tell whether it is an hercules bug or a bug in your changes (most likely, at least I don't remember hercules having this issue in the last few years). If it is an hercules issue, you may search the fix in herc repo and apply manually, or update your emulator, or fix it yourself. I don't think there is another way around it. Hercules changelog may help find what to look for in this case. If it is an issue with your custom changes, disabling your plugins and scripts can help you pin point where to dig further. - If you disable all plugins and scripts and the issue persists: The issue is changes in source itself (so you are limited to src/ folder) - If it works, try to enable 1 plugin, test, 1 more plugin, test, and so on, until you find the culprit (or find that it is not a plugin issue) - If all plugins are loaded and drops are still working, enable a few scripts per time, test, enable more, until you find the culprit (so you have only a few scripts, which you can them do the reverse process: disable 1 per time until it works again: you found the actual culprit) If the issue is in source, you can use a debugger (Btw, what you pasted above is NOT a debugger, it is just the build log). A debugger allows you to step through each line of code and check values there, this will help you find some line that is no behaving as expected. You seem to be using Windows and Visual Studio, so you can see a bit about debugging here: - https://github.com/HerculesWS/Hercules/wiki/MSVC-Crash-Debugging (This will give the steps to run the debugger -- you won't get into the "crash step" though) - https://learn.microsoft.com/en-us/visualstudio/debugger/getting-started-with-the-debugger-cpp?view=vs-2022

I will add some ideas and questions here - Are you on latest herc? - Renewal or Pre-renewal? - Have you tried a clean herc? (This will help solve the question whether it is an Hercules issue or a customization issue) If you change rates back to the original, does something drops? - If it does, maybe there is a bug there... - If it doesn't, ok -- rates shouldn't be the problem Does using mobinfo shows the drops? If it doesn´t, there might be something wrong with your drop loading If a clean herc also shows this problem, we would have to look the entire drop logic (or in case last test is "yes", something specific for bonus calculation), I don't think there are other ways. If a clean herc works fine, you have to debug your customizations. Things to consider: 1. Do you have any installed plugins that affects drops? 2. Do you have scripts that affects drops? 3. If you disable every plugin, does it solve? 4. If you disable your custom NPCs, does it solve? 5. Do you have source changes? If yes, any of them touches drops? this may be the culprit. 6. If none of the above helps, I guess the only way will be to really go into the drop logic and try to find where something is going wrong (debugger may help here) Hope this helps

I would say that possible or impossible really depends on how far you want to go and how much you know about programming / hercules source It is not supported by default. So if you are looking for a config to enable it, the answer is: no, not possible. But we have complete access to Hercules source and database so it is possible to just make a new implementation of a new storage (or modify the existing one) that works based on character, just like we have storage for guilds and for accounts. I don't know if it matters for the client which kind of storage you are using, if it does, just send it as an account storage and should work fine. The server side is what really matters. If you are going forward with the idea of making a new storage, looking into the current storage implementation may serve as an useful reference (I think starting at src/map/storage.c and src/char/int_storage.c would be great starting points)

It won´t be able to read the variable itself, but if the variable value is included in soemthing that is sent to the player (e.g. in a mes), it will be written in plain text there. if .@encrypted$ is part of the url you are writing with mes command, it will be in the text. .@encrypted$ = "lalala"; // Until now, .@encrypted$ is only visible to the server .@urlForClient$ = "<URL>Code Page<INFO>http://www.myserver.com/antibot?code=" + .@encrypted$ + "</INFO></URL>"; // .@urlForClient$ is still only visible to the server, but it contains the value of .@encrypted$ inside it (Because we are concatenating) mes("Go to " + .@urlForClient$ +" to get your code"); // The text will be sent to the client, including the url, that includes the text in ".@encrypted$" // The client doesn't know that there is a concat here, but it will receive a text like that: // "Go to <URL>Code Page<INFO>http://www.myserver.com/antibot?code=lalala</INFO></URL> to get your code" // // Note the value originally in ".@encrypted$" is part of this text (because I concatenated it in the steps above). // I only get the final text in client, but I could just search for "code=" and pick the value in front of it. Or search for "INFO>" and get the entire URL. input(.@input$); if (strcmp(.@theRealCode$, .@input$) == 0) mes("Ok, you are not a bot"); //... But you are right that, this value being encrypted, the bot developer/user have to open the website and scrap the decrypted value that was shown in there.

I think I should step back first and explain a few things: Most things the bot can do requires someone that knows what they are doing. Making it talk to custom NPCs generally requires someone to do some advanced config telling it what do to. It is not simply "use this super cool npc" and it is ready. At the very least people would have to code the conversation sequence, etc. And as more custom stuff is required, it will require more knowledge for the one coding it. And I may be totally wrong, but usually the amount of users with advanced knowledge is far smaller than the ones with very simple knowledge of setting a "kill monster and use storage" config. If the target is to stop even the ones with advanced knowledge, most things you can do using Hercules only will be bypassable. If you are targeting the majority that has less knowledge, simply having a NPC may make it somewhat hard for a considerable amount of botters. I think the main thing to keep in mind is that, the bot is simply another software, and it is coded in a programming language (openkore specifically is coded in Perl), anyone with knowledge to change it can code it to do anything the language allows them to, even outside RO scope (if there is a way to open a web page in perl, openkore could be coded to do it too). General purpose antibot measures are hardly things made in the game itself, and it is hard to make it completely safe (and sometimes it becomes something too intrusive to the real players). Measures against packet-based bots tends to be changes in the client/server communication, like custom packet encryption, or requiring other protection software running together with the game, which performs checks in the user client/computer, etc. But these only targets some classes of bots, and even them may be bypassed if there is someone with the knowledge and desire to do so (Let's say, 0.1% of botters would be able to do it? or even less..). When people limit the scope of what their cheat can do, they can even get more creative: I saw cases where people used image recognition to drive where their mouse will click, so you are not even touching the game in unnatural ways, but you get a limited scope as you have to make the image recognition pick exactly what you want (e.g. talking to a NPC gets much harder). keyboard/mouse macros are another case too (ok, this one wouldn't work to talk to NPCs, but works for hunting aggressive monsters, for example). And this is more of a suggestion: be careful to not make something so intrusive that real players starts hating the antibot haha ---- Going back to your message, If I understood it right, your NPC will be something like that: .@theRealCode$ = ...; .@encrypted$ = getMyEncryptedCode(.@theRealCode); // Imagine getMyEncryptedCode does the encryption work you mentioned mesf("Go to <URL>Code Page<INFO>http://www.myserver.com/antibot?code=%s</INFO></URL> to get your code", .@encrypted$); input(.@input$); if (strcmp(.@theRealCode$, .@input$) == 0) mes("Ok, you are not a bot"); //... If that's the case, as long as the bot user knows how to code the bot, they could read the message, make a request to this URL (which would have the encrypted code), get the value, and input it. Maybe if the URL shows the text inside an image will make it harder? probably, extracting text from image would be harder (not impossible, there are many OCR technologies today). If the programmer has knowledge to do it, and it is feasible to programmatically do something, it can do, and may be even faster than a human at that. Note that this requires someone with programming knowledge, so as long as there isn't someone with knowledge who does it and give to everybody, you would be blocking people who are simply bot users with the basic knowledge of how to config it (which I think is the majority). But not someone that knows what they are doing.

Not the script itself, it will be able to read what is being sent to the client. This is NOT the script, but messages (packets) to do the actions that the client has to see. for example, when you a script like that: prontera,150,123,4 script Nice Npc 1_M_01,{ mes("Hello"); mes("How are you?"); next(); switch (select("Fine", "Bad")) { case 1: .@var = rand(100); mesf("Cool! %d", .@var); close(); case 2: mes("That's bad"); close(); } } Let's go back to the NPC identification first, once the player character (regardless of being a real client or a bot) gets near the NPC, hercules will send something like: - Hey, there is a unit of type NPC (GID: 1234, Sprite: 47) at coordinates 150,123 looking in direction 4. This NPC is named "Nice Npc". The player clicks the NPC, and client sends: - Hey server, I want to talk to unit 1234 Hercules will then process this request, see that the player is in distance and start executing the script, and thus will start sending messages telling the client what it needs to do: - Hey, Show Message "Hello" (first mes) - Hey, Show Message: "How are you?" (second mes) - Hey, Show Next Button At some point, the client will send a next clikcked input, and then Hercules: - Hey, Show Menu: "Fine, "Bad" Client will then send whether it clicked in 1 or 2, let's say the client says it clicked 1. Hercules wil lthen send: - Hey, Show Message "Cool! 50" --- Or any random number here ; note that the variable and "rand" didn't send info to the client - Hey, Show Close Button It won't send the script itself, but the stuff it needed for the client to show. It won't give script internals, like variables or function calls, but if there is something that does something in the client (e.g. render a message, show a next/close/menu, show a effect), these will be sent to the client in a message format that is suited for the communication. Note that some things in this example were NOT sent to the client: - Variables, - The random itself -- only the result of the execution is - The message for case 2 (we just clicked case 1, only case 1 will be sent) You can check what is being sent to the client using packetlogger plugin (https://github.com/HerculesWS/StaffPlugins/tree/master/4144/packetlogger), it will dump every packet sent on the network to a file (in binary form, so some knowledge on how RO networking works would be required to actually understand everything). The example I gave before that openkore could generate a script is that, if you pick all those "Hey, SHow MessagE" and write to a file as being a "mes("message")" , you kinda create the NPC back. it is not perfect, but except for the internal logic, you got all the messages, menus, effects, etc

the packet itself may be sent regardless of Herc allowing it or not. A packet is simply a message. The client may send it whenever it wants and with whatever content it wants. Herc will have to parse this message and process the action in it (if it thinks it should) The distance check is performed by Herc by default. You can see here: - NPC Clicked packet parsing: https://github.com/HerculesWS/Hercules/blob/stable/src/map/clif.c#L12795 (clif_parse_NpcClicked is where the packet for NPC Click gets parsed and an action is taken) - Distance check in npc_click: https://github.com/HerculesWS/Hercules/blob/stable/src/map/npc.c#L1374 --- Not sure what you meant about monsters and changing NPCs, but note that the GID is not something hidden, simply getting near the NPC is enough to get their GID, because Hercules will give it. And GIDs are assigned during unit creation (e.g. monster spawn, NPC load, etc). And bots simply need the GID once they are close, so if they had to get close anyway, the GID is already there This is just how the client tells it is clicking something (instead of a name or something else, it uses this id). Depending on what you are trying to achieve, extra NPCs and monster may help for very specific cases (help, not solve), but if there is a way to tell them apart via code, someone that knows how to touch a bot code can do it. As a general solution for botting, I am not so sure this would work BOTs may also be coded to do whatever their user wants with the data they receive. For example, a long time ago I made a code to use OpenKore to generate NPC files for Herc as I played. If I clicked a npc, every dialog, menu, input, etc that I saw was written to a file

Very late reply, but: The previous messages ended up not being an issue in the option system, but in the script being used. (more on that after the next quote) Very late reply, but: Are you sure the issue is in the random option system and not in what you are trying to do? The previous messages ended up not being an issue in the option system, but in the script being used. It is important to note that a combination of delitem + getitem does NOT carry options by itself, and this is working as intended. If you want to carry options when deleting an item and creating a new one, you have to do it yourself. If I understand your message, the issue you are experiencing is that: 1. you have Knife [3] with options 2. you want to "slot it" so you get Knife [4] with options but when you try to do that, you get Knife[4] with 0 options (so options were lost). Without information on how the script was coded, I can only assume it is like the official slotting NPC where it does something like: // Deletes Knife[3] -- the item you originally had delitem(Knife, 1); // Adds Knife[4] -- the sloted item getitem(Knife_, 1); In this case, the options does NOT get carried to Knife_, and this is working as intended, because you are deleting the previous item and creating a brand new one -- the script engine doesn't know you were simply "upgrading" the item, they will even get completely different Item UIDs. The issue fiction mentioned before was exactly this case, a script was deleting the unidentified (and optioned) item and creating a new one (identified, but without options). In order to carry the options to the new item, you will need to use script commands to get the options of the old item before delete and them set the options in the new one. See "getequipoption" and "setequipoption" script commands for some leads.

I am not an expert in OpenKore, but: OpenKore (and any other bot that works by emulating client behavior/packets) works by receiving packets from server and sending other packets just like a normal RO client. But, not being the original RO client, it may send packets as it wishes. Moving into your questions: - ~ Can both communicate to an NPC even if it's not visible on the screen? (They are both in the same MAP it is just that the NPC is not visible on screen because it's moving or changing coordinates.) Every unit (NPC, Player, Monster, Homun, Mercenary, ....) has a unique ID (what is called GID). Those IDs are sent to the client by Herc when you get near a unit, along with other info such as appearance and what kind of unit it is. When you click an NPC through the original client, the client sends a packet with something like "Hey Server, I clicked NPC ID X". As official clients will make the npc disappear once it is a few cells aways, you won't be able to click an NPC that is far away or in another map. BUT this is just because your screen doesn't allow it. OpenKore can still send this packet through the network, provided it knows the GID of the NPC, it has nothing preventing it to saying he wants to talk to that NPC in the other side of the map. BUT, on the other hand, Hercules does have measures to prevent those kinds of exploits, it won't simply accept the client request. Before executing the NPC, hercules will ensure the player is close enough to that NPC. So the answer is: It could try to, but it will be forced to be in acceptable distance in order to really work (due to Hercules checks) ~ Can BOT identify the NPC on the screen (some kind of ID? How?) and click it or go to the location to communicate? I don't know the details inside OpenKore, but it will receive info on every unit that enters, moves or leaves the near area, because hercules has to send that to a normal client, and openkore does need that info if it wants to interact with something (because of the GID I mentioned before) It is also able to communicate with NPCs, move to coordinates, and etc just like a normal client does. That's how it works in order to interact with RO world. It will send the same packets a normal client needs to send in order to perform the same operations. It can even tell about NPCs that has invisible sprites if Hercules is sending them to the client Given that it knows the position of everything, telling if something is in the screen would be possible if you know your position and the other unit position, it is a simple distance in 2d space. also several clients (if not all) relies on Hercules sending enter/leave packets, which controls what is in the near area. There might be features that are not fully coded in OpenKore, like some specific UI or things like that. But this would be more of a "not implemented yet" (just like Hercules misses some features the client has), rather than a "it can't do that" Edit: I think it is valuable to add that: OpenKore (and any other tool that imitates an official client) can do anything an official client can, with the addition that it is not limited to any constraint posed by client side logic (e.g. it is not limited by buttons in the UI, by information rendered in the screen, client-forced delays, etc). It is able to send any kind of data to server, whenever it wants. What prevents it from causing a complete chaos is that the server validates (or at least it should) everything to match what an official client should or should not do. And usually, those tools are coded in a way that at least it won´t be doing stuff server doesn´t accept, or it wouldn't work to begin with. Hope this helps

Usually it is recommended to check which features you want/need, and which nemo patches you may want to use, after that, just pick a client that matches your needs. For example, anything newer than 2019-06 would have the new guild emblems which is not implemented, so you may want to go with a previous date to have guild emblems. But if you want rodex, you would need at least 2015-05 or something around that. Another thing to consider are which nemo patches you may want to apply, as some won't work for some client dates. Unfortunately there's no list of features/client date, but for patches you may check nemo.herc.ws

Recent clients (IIRC >= 2019-06) uses a new format for guild emblems which is not supported by Hercules yet, you have to use an older client

I don't think you actually need skills for those cases, you could make a SC for the cooldown and set it to not be removed upon death. When the character dies: - does it have the SC? yes: -> do nothing (still in cooldown) no: -> set SC -> ressurect (maybe check how siegried token does it?)

It looks like your db is missing some parts, are you using the sql files from your emulator? Try recreating your database

It is not safe to edit an account cash points while user is online in-game. What flux does is store the cash points in website only (I don't remember the table, but iirc it is one of the flux ones). You buy the items through its website and redeems the item in game through a npc. I hope this helps

What 4144 saying is that you can only change files read by Sakray (test server) client. For sakray client you have to edit the itemInfo_Sak file. For main client (kro live server) you can't edit and translate it because kRO has anti-cheat enabled and the anti-cheat will prevent you from editting it.

I don't think you'll find a ready server that mix both. But it is possible to create one if you do it by yourself. Most renewal features are available for pre-re out of the box, but disabled. For example, random option drops works for both renewal and pre-re, but we don't have items set to drop with them. If you want monsters and items to work like renewal, you may want to start by picking the renewal db (db/re) and moving parts of it to pre-re folder, or vice versa (depending on which mechanics you want to keep, re or pre-re). Also, most renewal features can be switched on/off in source. I don't know much about revo-classic so I can't tell how much work it takes to make a server like it I hope this helps

If you are sure that you have all the updates, I think you can run the queries that insert entries in the sql_updates table: https://github.com/HerculesWS/Hercules/blob/stable/sql-files/main.sql#L876

Hello, I think you may have run into the wrong board. This board (herc.ws) is about Hercules MMORPG server (https://github.com/HerculesWS/Hercules), your question seems to be about something else, maybe Hercules Mainframe emulator?

It should be possible if you change it on sql_connection file (https://github.com/HerculesWS/Hercules/blob/stable/conf/global/sql_connection.conf#L46) but I wouldn't recommend doing so as this will probably make queries take longer.

IIRC Item stat enchants basically add a "card item" into the 4th slot (which enchantable items doesn't have for cards), and that item looks like an sphere. It is an item, you can find it on item db (look for Int_3 or something like that). You can probably change the sprite if you want, just like you do for any other item. But in this case it looks more like yourdata. grf is out of date... does other enchants work fine? I may be wrong, but this is what I remember... ItemInfo.lua and .lub are "the same" (actually .lub would be the "compiled" version of .lua, but a lot of time we use it in plaintext)

I didn't understand your question :x

Hmm yes, I think you should duplicate original card act and rename to taogunka.act. You need to get it from official data.grf, it is probably at: data/sprite/¾ÆÀÌÅÛ/À̸§¾ø´ÂÄ«µå.act

It should be exactly like adding any item. You have to put the .spr file in the sprite directory as you did and also the item and collection bmp in texture folder. Iirc they are: texture/À¯ÀúÀÎÅÍÆäÀ̽º/item/<item name>.bmp --> the sprite that appears in yor inventory texture/À¯ÀúÀÎÅÍÆäÀ̽º/collection/<item name>.bmp --> the image that appears when you right click