Variant

Oh, this is a really interesting idea. Think a clean way to do it would be to have a script command that creates a 'temporary' shop unique to the player, and then builds that shop, and then deletes it after the user quits. static const char* npc_parse_shop(char* w1, char* w2, char* w3, char* w4, const char* start, const char* buffer, const char* filepath) in npc.c is the function you'll want to look at for creating shops int npc_unload(struct npc_data* nd, bool single) for free'ing memory. ------ Unfortunately, because clif_buylist has this line: struct item_data* id = itemdb_exists(nd->u.shop.shop_item.nameid); It really screws things up if you're editing the same shop for multiple people, so you pretty much need to have a separate shop for every person.

I haven't been keeping up too much with everything that's changed, so I don't know if PCRE is enabled by default but... did you try configure --with-pcre before compiling? This should happen by default if you compiled using something like visual studio iirc. A good way to test if PCRE is enabled would be to setup a wildcard that'll pick up any text, and just see if the NPC responds to it.

from http://svn.rathena.org/svn/rathena/trunk/doc/script_commands.txt You are literally asking them to input the 0th element of that variable, and then asking to see if it equals itself. Change the input variable name to .@free$ or something, and then implement Patskie's change.

Er, it's integer division, so it wouldn't be made into a double precision floating point number. It will still be 64 bits because damage itself is declared as an int64 though, so it's kinda moot. Why is that cast even there?

http://git.or.cz/course/svn.html should help if you're familiar with SVN but unfamiliar with GIT.

SVN is pretty much: Central repository -> other people The central repo is what gets updated, and you HAVE to be connected to it somehow to make commits. Git is pretty much: Everyone has their own repo. Once you pull, you now have a local repository that you can make commits to. This conforms to 'version control'. It's pretty much just a powerful 'undo' system. So you'd: 1. Pull the repo 2. Git checkout into a new branch (this is a new local branch you'll use to make changes) 3. Make your customized changes, making several commits to your local repo 4. Test your stuff out ->Hey, I found a bug with this feature, what should I do!? 4a. No worries friend, just revert the commit, that's why it's called version control. 5. Once everything is tested out, switch back to master (original branch) and pull to update it 6. Then switch back to your custom branch, and merge changes in. Voila, you now have a clean up-to-date branch, and a custom branch that's up to date with your changes. To do this in SVN? You'd need to SVN checkout, copy that repo somewhere you can always access it (probably on your own machine), and then merge two repos together (gross). Usually with SVN people would just keep one repo and merge in changes, but having the clean branch comes in handy. But you couldn't do local commits. ->leading up to answering your question, the reason it's not linear is because now there's 2 branches that have had stuff happen to them either before or after (could be either, they could even happen simultaneously), so you can't really keep track of them in a linear fashion (incremental numbers). Edit: also, your local commits might not match up with the central repos, or other people, so if you were to all 'push' changes back to the origin, how would you keep track of the numbers? The answer is there's really no good way, because each one was effectively changing a different repo altogether.

^ You can use the SHA to look at the change history. Even if there's mods made, git keeps track of ancestry, so you'll know the origin branch "revision". You could probably just say the date/time of the last pull/merge though, for a rough estimate equivalent of revision. Edit: though the idea is usually to always be up to date. So posting revision shouldn't matter, you should always pull/merge latest changes before making a report. Usually how we use git at work anyway.

If you've already gotten that far, it's actually pretty straight forward. The code you're looking at on the left part of your picture is just a repeated algorithm to extract 6 digits (it's the same lines of code repeated 6 times), which you can easily replace with a loop (just think of how you'd do it in C, then translate that into x86 assembly). If you found CMP ECX,0F423F, then it's just a matter of editing the code a little to add the remaining 3 digits (9,999,999 then 99,999,999 and then finally 999,999,999). The really difficult part of it all is space management when you're writing the new instructions. It took me a week to do it without screwing up, in the end I just ended up using a JMP to jump to some free space at the bottom where I added the instructions, then JMP'd back to the main code. It's really tedious, I know, but it's not 'difficult' in the sense that you have to try to come up with some crazy new method to do it. I can't exactly give you a step by step guide, but if you're at that part, then you can always use my server's client as a reference point, it should help you quite a bit. I haven't looked at the new clients, but the worst I can imagine that changed was that that ridiculous digit extraction algorithm was replaced with an actual loop, so you'd have less space if you tried removing it (which is the entire point of replacing it with a loop). Should still be able to find it the same way.

I'm glad I was able to help. But I still think it's weird that monsters can't see past 14 tiles. According to the source, the max value should effectively be INT_MAX, so I don't see why increasing that past 14 shouldn't work (looking up battle_config.area_size in the source, and AREA_SIZE the macro doesn't seem to come up with any particular limitations). Does anyone know why that doesn't work?

Oh, well the warning is (presumably) because: struct script_code { int script_size; unsigned char* script_buf; struct linkdb_node* script_vars; }; was changed to struct script_code { int script_size; unsigned char* script_buf; struct DBMap* script_vars; }; A change made in r15997 by Epoque to "make use of the DBMap* structure for storing variables (for Ind <3)" (see here). So my thoughts are that simply switching out linkdb functions with idb functions should (hopefully) solve your warnings, and change the diff to support the current revision. Unfortunately I don't have too much time to look into and test it myself, but I don't think I'm missing anything. Also, the area_size isn't capped to 14 is it?

Regarding this script, couldn't you have just changed the mob mode to make it unable to move before sleeping? If that doesn't do the trick, then maybe there's something wrong with how unitwalk interacts with mobs? This might sound silly, but there's always the ridiculous route of making unwalkable cells surrounding the monster, or creating a status that freezes them after a duration or that triggers after walking so many tiles (actually, that'd be pretty cool for other purposes). Does anyone know where the limitation on only being able to walk within a certain range comes from? I'd think monsters would have full map sight range... @Annie: What's line 3640-3645?

Wouldn't it be much simpler to just do: playertalk(1,"Hello there!"); ? It's much faster than typing out this: unittalk getcharid(3),"Message"; I believe it would be more efficient. You could always just do: set o,getcharid(3); unittalk(o,"Hello there!"); sleep2 1000; unittalk(o,"How are you?"); ... Setting it to o was arbitrary, but the point still stands. The playertalk you're suggesting is just a subset of unittalk, or am I missing something here? Doesn't clif_disp_overhead send the message to the surrounding area? Whereas the message script command uses clif_displaymessage.

What is it doing that it shouldn't? That'll help narrow it down. Edit: Oh. You have a 'close' in your NPC after the first two lines, so literally every single thing after that will not trigger unless you use a DoNPCEvent. (Look at line 50 on your pastebin link) You also have a close inside your switch statement on line 55, along with a close on either case, it's redundant. You may want to consider commenting your code to follow your own logic, because there are actually a lot of functional errors with your quest. Try looking at another quest script as an example/something to compare to (an official one, maybe, that comes with rAthena), it'll help out a lot.

I was always under the assumption that calling several different event queues in different scripts lead to the queue being full. For example, if you have several scripts that trigger when a player dies, then each event, even though they're all PCDieEvents, get added to the queue separately. Did rAthena change that recently? killerrid = Person who killed the player, killedrid = Person who the player just killed, last I made a script that used them. Relatively recently. Yeah, it would be more efficient to trigger only a single event and attachrid to swap between the two. You could also avoid the issue of killing multiple people at once and only being credited for a single kill while using sleep2 if you used OnPCDieEvent.

Well, GMOcean is right, you should remove the sleep regardless. If the killer kills multiple people within that .5 s limit, then that already messes things up. If players log out immediately after dying too, before the sleep finishes, it'd mess up also. In other words, it'll cause you more grief to debug with those in there. Try having a debugmes(killerrid); and debugmes(killedrid); in PCDieEvent and PCKillEvent respectively, right as the event starts (where sleep2 is). You'll get some string/integer conversion warnings, you can just ignore them. Your console would show something like: [Debug] 12345678 [Debug] 12323123 Whenever someone died. And you should be able to monitor what's going on with the RID that way. It might also help to comment your script so you can easily understand your logic if you come back to read it later, might also help you find the issue.

Oh, I was just interested in if he had found a compression algorithm to do it with only 2040 bits. I'm sure the SQL method proves to be much faster overall (the compression algorithm may significantly increase the number of executed instructions), but it'd be cool to see if it was possible, if not viable, to do it via compression. I'm sure it would have some implications for certain scripts too, but I can't think of any off the top of my head. Edit: Though I finally understood Mytzer's post, took me a few tries. That actually helps a lot.

So wait, just to clarify. This is basically saying that you can just use the individual bits in a 255 character string (2040 total bits) to store multiple variables, right? So as to drastically reduce variable usage in scripts (as a result, in large population servers, use significantly less rows in global_reg_value). Well, potentially at least. I had actually taken advantage of something similar to this, but I had used 5 integer variables (that is, 32 bits). It was a script that kept note if a player had collected ~150 different items, and so I just used bitmasking 5 times. Totally forgot that strings held 255 characters... Never need boolean arrays ever! @KeyWorld: Did you ever figure out a good compression method to store a character's skill build? Edit: On another note, does anyone think it'd be viable to support 64-bit integers on rAthena (given a 64-bit system)? I can think of a few uses for 64-bit integers off the top of my head, and I'm sure there are people out there with some crazy projects that they'd like to do given numbers.

Ah, no it's not quite that. You've got the right idea by looking for case 11A of a switch, but it should look similar to: PUSH 8 ;packet size = 8 bytes I'm going from memory so I can't remember 100%, but I'm fairly sure that's what it looks like. Talking about the click delay that appeared in around 2011 clients and higher? I fixed that by checking the mouse lock box. When disabled the client seem to do a check to see if the mouse is in the window or not....maybe???? Its around 500ms between each one. So to get a free mouse I just leave the lock on and use the mouse freedom plugin ive used for years. No click delays at all. Tho thats based on the server program I use. Not sure about rAthena. Is that so? I'll look into it. What exact client version did you test with? And is that server emulator significantly different from rAthena in terms of how it deals with packets?

It's the skill spam delay basically. It's more noticeable on higher rate servers where the serverside delay can be non-existent. Like Beret said as an example, Jupitel Thunder spam, or even something like spamming FO with a champion.

Wait, why packet 0x0284? To use it as a special effect-type thing? That seems overly complicated. If I recall, you can just use Olly to search for switches and find the case for 0x11A and adjust the size of the packet. All you really need to do is set the size of heal up to 4 bytes instead of the 2 (?) it's at. Something similar to: PUSH 0x11A PUSH X ;X = packet size is what I remember it being. Also packet 0x13D, which I think has to deal with regen? Increase the size of this packet by two also and you're good. Laniency setting on conf/battle/skill.conf ? Has nothing to do as said only occurs in 2011 + client, 2010 client works perfectly. You're talking about the click delay after using a skill, right? I've had the same issue. I was talking to Ai4rei about it before, and I managed to pinpoint a lot of the functions used for skill effects. Ultimately I managed to figure out how to remove the skill effects from happening altogether, but even then the delay still existed. Which then led me to believe that there's an internal timer or something that's forcing a delay. I'm still searching for it, does anyone have any ideas on what's causing the delay if not an internal timer?

http://www.asciitable.com/index/asciifull.gif

Minor? Just minor? Dude my jaw dropped when I saw the pic in hopes it was real. Watching your video made my jaw drop again. To see skill damage go past the 999k limit is like a major break through in client customizing and a beautiful sight to see. To low and mid rate server's its pointless, but when looking at high rates, it starts to become necessary depending on the setup. And when looking at super high rate server's it would be a major need. I started wondering if its possible to also increase the damage shown by regular attacks. It might be tricky or impossible since its likely coded in a signed 16-bit, making it show up to 32,767 and then just not appear at all when higher damage is done. Skill damage display is a 32-bit unsigned if im correct, right? Im trying to remember. Im pointing this out since their's been issues on some servers where players could deal more then 32,767 and then not be able to see damage anymore. It was like "Am I hitting my enemy?". Healing does show its display when healing more then 32,767, but doesn't display any higher then that. Do you think its possible to fix those issues? I didn't have problems modifying up to 8 digits for damage. The 9th digit wouldn't show up, so I had to use Olly to find some empty spot on the stack to use for the 9th digit. It was a workaround, but when you're dealing with a closed-source client, I guess you can't really be picky. Healing? ^Like that? Healing follows a different packet so you need to adjust the packet size not only in clif.c/.h (and other server side locations I'm forgetting), but also in the client itself. I wish I could remember everything I had to edit, but I was too excited at actually getting everything working to note it all down. You're welcome to mess around with my server's client if it'll help you guys figure things out though. I'm not very good at explaining things. Edit: This was possible on a client from June of last year, so though I'm like 90% sure it's still possible on newer clients, there's the possibility that something fundamental changed (but I doubt it).

Set it to 0 to show just the name. Coincidentally, to clarify what EvilPuncker said it's basically just that all the choices are powers of 2, you'll see it all over the configurations (item restrictions for example) in areas where you can pick multiple options. So the possibilities would be 2, 4, 8, 16, 32, 64, etc... and so you'd add the options you want. For example in this case if you wanted to show the Mob's HP bar and level but not the % you would make it: 1 for the HP bar + 4 for the level = 5 if you wanted the HP bar and the %, you would make it 1 for the HP bar + 2 for the % = 3

My folder is a bit of a mess, but I'm fairly sure it's 04/18.

Able to instance just fine and look at the instance information window with no problems. Battlegrounds window?