Jump to content

miguelmig

Member
  • Posts

    44
  • Joined

  • Last visited

  • Feedback

    0%

Everything posted by miguelmig

  1. Well, I'd rather say not everything is possible. As people have said, monsters are not sent to the client if they're not in View Range. So M2Bob either tries to guess where those monsters are by using a default regen.txt or they use a tp-hack to teleport around the map and save the coordinates of the monsters sent while they are tp-ing around the map.
  2. Who said I don't have one? I don't even know how the conversation got to this point but my idea is pretty simple, loop timers are completely un-necessary to do what OP wanted and most of the times are just worthless when the same thing could be implemented in C++ without the performance overhead. If you want to continue using loop_timers for simple things feel free, just know that one day it MIGHT bit you in the ass ( remember that for each player in your case it's another 10x loop_timers ), 100 more players is another 1000x loop_timers running. Complexity is a thing, look it up. Throw everything I gained into the trash? Guess I'll have to do that since some random told me on the internet, oh boy there goes my Compute Science diplome into the trash can. I don't need a "Developer" tag to feel superior or to know how good of a developer I am. Most of the "source-sided permantently active timers" are of high times or only happen once, they're not in a loop. The worst case that I know of Looped Events/Timers hard-coded on source are the regen events which I've been trying to think of a good way to refactor them.
  3. lmao you can't be serious. You seriously think that? Every loop_timer is a event more for the game to process, not to speak whatever happens inside the timer body itself is code executed by the game core To think that loop_timers don't affect Game performance is ludicrous and outright stupid. Not to mention if those loop_timers are never cleared they will run until the game core process gets shutdown or you run out of memory
  4. You're pathetic. Yes, performance is important in Metin2, at least server-side it can be improved or at least not made worse. A single "instanciated" server timer in combination with many other server_timers used when it isn't needed will surely lag out the server. Plus, there's no reason to use LUA in this context, it is utterly un-necessary, and needless to say your solution only works on a dungeon AND with a single monster ( you used unique ). Don't come here saying I'm making fun of myself, I have a lot more experience on this area than you do, I'm sure.
  5. @Syreldar Holy shit you just gave the worst possible solution regarding performance that I could think of. In CHARACTER::StateBattle(char_state.cpp) do a check for mob1_vnum and if below the percentage you want, you can spawn the mob2 with CHARACTER_MANAGER::SpawnMob. For more information look for dwSummonVnum from TMobTable and see how it is implemented, it seems to be closer to what you want to implement
  6. You don't have to refactor the whole affect system, you can "fix" it with a fix similar to OP's one, just not exactly the same. EDIT: I tried reproducing that bug on my source, but neither the "Sword Aura" nor the "Heal" invokes ComputePoints()
  7. Can you be more explicit about what you want help with? I didn't quite understand what you mean by "increasing exp"
  8. @VegaS You need to consider that there are more items that can drop that are not in the mob_drop_item.txt file. Keep that in mind.
  9. I didn't offend you, or did I? I wasn't criticizing you, nor offending you. I was saying that the way you mentioned wasn't the most correct way and that it could be improved. I'm sorry that you took it so deeply. And in case you thought I only criticized because I was selling, you're wrong. I only planned on working on this system right after reading this thread, I had no interest in this before I opened this thread.
  10. I'd just do the right way, send the information from server. And I'm working on it, if someone wants to buy it, let me know.
  11. I disagree with this method, you'd have to copy the drops' file every time.
  12. The only problem I can see is either the SQL connection not being open yet OR there's something wrong with your libmysqlclient
  13. We need to see the AsyncSQL.cpp from libsql if you want us to help
  14. Please don't. AES is reversible, passwords shouldn't be encrypted, they should be HASHED
  15. 1 word. Bitbucket, you can create private repos for free.
  16. Please tell me you're kidding. You gotta be kidding. AES is Encryption, not Hashing. You should hash a password, not encrypt it. That means that if your database is compromised, the hackers will be able to get all the passwords in plaintext.
  17. Well, it's quite common for python systems to use constinfo.py to store data, but that usually causes to things to stop working when a player has multiple clients open, since it appears that the constinfo data is shared between clients, or so it was in the old clients, but I'm pretty sure that it will still happen, give it a try
  18. This will work terribly if a player decides to open 2 clients on the same machine at the same time
  19. What features did you use that require C++14?
  20. You shouldn't use strdup,it is deprecated, use _strdup instead. [Hidden Content]
  21. maybe its just the console that can't display those characters, perhaps try compiling in UNICODE mode
×
×
  • Create New...

Important Information

Terms of Use / Privacy Policy / Guidelines / We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.