Realusion

There is no other way - Gepard has already mentioned the only possible solution. Either use an existing anti-cheat-engine or get into programming and develop your own library.

It's actually back up again. [Edit]: Damn, Judas beat me to it!

A.) What did you edit? Please post the code snippets. B.) Does your server run in Renewal Mode (#define REMODE 1 or #define REMODE 0)?

I'm afraid it's not that easy. Since item_data->script is a struct called script_code (if I remember correctly from top of my head) you can't just cast it to type char. The code of the script is, at that point, not even stored as plain-text - it has already been parsed. You would have to look around in script.c (or itemdb.c) somewhere and search for the snippet where the item script is parsed and then store it somewhere else as plain-text. That way you can display it via sprintf. I don't know how good you are at C and handling the source code, but this may require some experience to be accomplished

None said that he would have legit characters on the other slots. I was just saying there would be an increase in flexibility, which is essentially true.

Yep, I've also seen servers where only one character was given GM powers. A re-design of the system would provide a lot more flexibility in cases like that and perhaps grant various other possibilities as well.

I think one thread PLUS one bug report is enough. http://rathena.org/board/topic/56401-spam-fishing-system/ http://rathena.org/board/tracker/issue-5199-avoiding-the-delay-of-sleep-and-progressbar/ As I stated in the first link, the sleep command is also affected. After some testing, it seems that this is quite a fundamental flaw. Probably caused by the fact that continuously sending the "close" packet to an NPC resets the idle time, because it's script_state based.

No, I'm afraid it's a bit more complex. I have already played around a bit with the matter and sleep/sleep2 are also affected. I have also submitted a bug-report: http://rathena.org/board/tracker/issue-5199-avoiding-the-delay-of-sleep-and-progressbar/

I was able to reproduce your situation. What I did was to record 2 packets from the "conversation" with the NPC. Afterwards I continuously sent them to the server. The effect was, that it kind of "canceled" the progress bar and thus, enabling me to do the whole process A LOT faster. I'll provide a fix later, as I currently don't have enough time to think about the smartest way to fix this. Just letting everyone know in case someone is up to the task.

tl;dr: In my opinion a custom file extension is not needed at this point. In general, a custom file extension would make sure that a certain file type gets opened with the appropriate program. In this case, if we had an eAthena script editor that supports .txt files, said script editor would be in conflict with the standard windows notepad, because both of them want to open the .txt file. A custom file extension could be associated with the eAthena script editor. However, quite frankly, this is completely unnecessary. Another aspect why custom file extensions are created is that only the appropriate program can read the file (GRF, for example), which is simply not needed in this case. An effect which could actually be of use would be a complete revamp of the entire scripting engine to make parsing faster/better and to implement some features that I, personally, and maybe some other people have been missing. However, at this point there are far more important things to focus on.

Seems as if you're limited to Trac (http://sourceforge.net/apps/trac/rathena/log/) to be kept up-to-date for now. As far as I can see the changes are mostly clean-ups anyway so far. I suppose a major feature implementation would be posted in the SVN News section. Nevertheless, a collection of all major updates would be desirable.

src/map/atcommand.c In the function ACMD_FUNC(main) search for: } else { if(!sd->state.mainchat) { sd->state.mainchat = 1; clif_displaymessage(fd, msg_txt(380)); // Main chat has been activated. } if (sd->sc.data[sC_NOCHAT] && sd->sc.data[sC_NOCHAT]->val1&MANNER_NOCHAT) { clif_displaymessage(fd, msg_txt(387)); return -1; } sprintf(atcmd_output, msg_txt(386), sd->status.name, message); // I use 0xFE000000 color for signalizing that this message is // main chat message. 0xFE000000 is invalid color, same using // 0xFF000000 for simple (not colored) GM messages. [LuzZza] intif_broadcast2(atcmd_output, strlen(atcmd_output) + 1, 0xFE000000, 0, 0, 0, 0); // Chat logging type 'M' / Main Chat log_chat(LOG_CHAT_MAINCHAT, 0, sd->status.char_id, sd->status.account_id, mapindex_id2name(sd->mapindex), sd->bl.x, sd->bl.y, NULL, message); } and replace it with the following: } else { if(!strstr(message, ":")) { if(!sd->state.mainchat) { sd->state.mainchat = 1; clif_displaymessage(fd, msg_txt(380)); // Main chat has been activated. } if (sd->sc.data[sC_NOCHAT] && sd->sc.data[sC_NOCHAT]->val1&MANNER_NOCHAT) { clif_displaymessage(fd, msg_txt(387)); return -1; } sprintf(atcmd_output, msg_txt(386), sd->status.name, message); // I use 0xFE000000 color for signalizing that this message is // main chat message. 0xFE000000 is invalid color, same using // 0xFF000000 for simple (not colored) GM messages. [LuzZza] intif_broadcast2(atcmd_output, strlen(atcmd_output) + 1, 0xFE000000, 0, 0, 0, 0); // Chat logging type 'M' / Main Chat log_chat(LOG_CHAT_MAINCHAT, 0, sd->status.char_id, sd->status.account_id, mapindex_id2name(sd->mapindex), sd->bl.x, sd->bl.y, NULL, message); } else { clif_displaymessage(fd, "Invalid characters"); } } This will result in ignoring all messages containing ":" and displaying "Invalid characters" as a dispbottom instead.