Jump to content

Variant

Members
  • Posts

    52
  • Joined

  • Last visited

2 Followers

Profile Information

  • Gender
    Male

Recent Profile Visitors

4236 profile views

Variant's Achievements

Poring

Poring (1/15)

6

Reputation

1

Community Answers

  1. 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.
  2. 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.
  3. 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.
  4. 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?
  5. http://git.or.cz/course/svn.html should help if you're familiar with SVN but unfamiliar with GIT.
  6. 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.
  7. ^ 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.
  8. 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.
  9. 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?
  10. 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?
  11. 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?
  12. Variant

    Playertalk

    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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...