Jump to content
×
×
  • Create New...

masodikbela

Premium
  • Posts

    205
  • Joined

  • Last visited

  • Days Won

    28

masodikbela last won the day on April 17 2020

masodikbela had the most liked content!

About masodikbela

  • Birthday 06/23/1997

Informations

  • Country
    Hungary
  • Gender
    Male

Recent Profile Visitors

8,748 profile views

masodikbela's Achievements

Community Regular

Community Regular (8/14)

  • Reacting Well
  • Dedicated Rare
  • Very Popular Rare
  • First Post
  • Collaborator

Recent Badges

617

Reputation

3

Community Answers

  1. Well as far as I know its not really a good practice to use UDP and TCP together (its better to use only one) except if it really make sense. In our case the main connection would be the UDP one, so we should somehow find and bind the TCP connection to the same stuff in order to keep a track to our main character, which is necessary for example handling normal chat packet (need position to only send that to the nearby players). Well its always hard to start these kind of things and there is not much help I can provide for this. Maybe the best way to do it is just to start right away coding something. It could be an already public system or anything, the key is to have a goal, like "whenever I kill a monster I want the server to give me an item and write me something in the chat". Then you just split it to subtask like: How can I catch if a character dies? How do I know it was killed by a player? How do I know the dead character was a monster? How do I give item to a character? How do I send a chat message? And by doing this you can already see various parts of the server, including CHARACTER class, ITEM class, some netcode and many others. Oviously the more complicated the idea the more parts of the server you can explore that way.
  2. Huhh thats a little bit too much to ask. Back in its time the solutions they made for various problems were acceptable due to the hardware limits, but nowadays the whole server is utterly trash. The question is more like what is okay for modern needs. But to be a little more specific, here is some of the most annoying problems: No serverside checks for some critical game mechanics. There are numerous stuff that depends on the client, and therefore can be easily faked. For example when you attack, the client calculates the positions your attack would hit, and there is only a distance check on serverside if you really hit that entity. There is no other kind of checks, like combo, direction, or more fine tuned stuff. Nowadays it should be completely independent from the client, the server should determine every attack/movement, and the client should just receive the results. No standard packet protocol. The game uses some homemade messy hardcoded tcp network code, where the headers/packets can be messed up easily. Something like google protobuf should solve this problem. Also due to the use of tcp there are noticable delays in movement/attacks so that should be replaced with reliable udp aswell. The cores are single threaded (except the mysql working threads) and to spread the load across the cpu multiple cores are being used (so it means that best case you have one map / cpu core (which obviously very rare in production servers)). But on farmmaps especially on server openings there are large amount of players and sometimes it noticeably draws performance, and literally nothing you can do about it, since you cannot make it use more cpu threads. Because of this higher cpu clock speed is usually prefered over more cpu threads when selecting hardwares for metin servers.
  3. Except /reload p (because it reloads the protos too) its safe to use on live server, if you don't have any new system or adjustment related to those stuff (so considering you use the basic files its safe).
  4. ? Yes, the low-effort but working solution is this indeed. The difference between my suggestion and the "fix" from the other topic is that the latter just masks the problem making the client call render even if the client is minimized, so it uses all the functions it normally does, wasting the resources on something that nobody can see. The former one just calls the effect update which is a cpu-only task, and while normally its one of the performance bottlenecks, still doesn't use much resources on its own (without the other render calls). Well not sure what else can I add here, the lowest effort but working solution is the one you asked about. I won't write the code for you and basically I told everything you need for that. Its literally pasting one single line which updates the effects to the place where the game should render, but skips it only because the client is minimized. So here are your clues, its now time to split up and investigate.
  5. The content in that topic can be visualized in a single gif: The problem with the "speedy effects" after maximizing a minimized client lies here: As you can see the elapsed time is measured since... well... the last time the effect got updated. You might say that hey, thats ok... well it would be, but if you take a look at the messy game loop inside PythonApplication.cpp you will notice that the call for effect updates is only present in the RenderGame function, which is a render function as its name implies it, and its only called when the game is rendering. And since the game doesn't render anything if its minimized, the time for the effects basically stops, and when the game starts rendering again, it will resume it from that point when it got minimized. You might rightfully say that okay, but that doesn't explain the reason why is it "speedy" for a long time, since the time difference should be huge for only one call, then it should return to normal because the m_fLastTime got updated at the end of the function. And at this point I'm officially out of definitive answers. The real reason might be one of the following: On the first "big" time difference after maximizing the client destabilizes the effect instance, messing up the emission/decorator update on a weird way, making the following n updates unstable as well. The custom timer class is more than weird, it has a "real time" mode and a "custom time" mode, but as I see only the "custom time" mode is used, which works like advancing the timer every time the main loop is called. Since the advancing is always called (its in the update part, not the render part) I somewhat doubt that this is the real reason. Using a different timer (potentially std::chrono) here in the effect update would quickly evaluate this case. In short, fixing it could be done by: Using a maximum value for the elapsed time (like it cant be larger than 1/60). This would solve the "speedy" issue, but would cause another bug, making some effects stay longer alive (if you minimize the client). Calling effect update even when the client is minimized. This would make the client use somewhat more resource when its minimized, but would still use way more less resource compared to the "fix" in that topic. Digging a bit more deeper, finding more accurate solutions. (The effects are stateless, or at least it really seems so, so it should mean that the effect should work with any given "elapsed time" at any point, but like I said this might be violated somewhere. The effects are not stateless, since the particle positions are based on the last position + elapsedTime * acceleration.)
  6. After so many years a fully finished @Zerialcollab? 🤔

     

  7. Me upon opening the topic: https://static.wikia.nocookie.net/darkestdungeon_gamepedia/images/3/38/Vo_narr_town_backstory_19.ogg
  8. And this would be the moment when I would just send back his money and block from skype. (probably somewhere between around the 5th or 10th call in a row)
  9. I've tried various ways to keep the lambdas somehow, but always ended up having extra references to self because of it. Never really liked lambdas in python anyway so I gave up on making them work easily so didn't dig much deeper than that. But of course this doesn't mean that its not possible to keep them so the best way to do some tests, try out some ideas and come to a conclusion.
  10. Detailed information about #6: As you all aware, the resource loading is not async. (like @IceShiva said it earlier) There are 2 types of resource loading: Ask the packer tool itself (eterpack) directly for some file (this could be any type of file). This method will always block, so it does not cache, and by default (using eterpack) it always read from the disk (it uses mapped files so its a little bit better than directly reading from the disk, cus some sections could be already cached inside the OS). Ask the resource manager to load a resource. Only some type of data can be used here (images, .sub, .mdatr, .fnt, .gr2, etc). There are also 2 scenarios: If the resource already exists inside the cache, it will directly return with the loaded data. If the data is not yet loaded, #1 happens, but it will cache the data. There is a time limit for unused resources to keep them cached. Once the limit has been reached and still nothing uses it it will unload the unused resources. The problems When a new player arrives the motion files are not cached (not the .gr2 files), so for every player it will try to use method #1. When you meet a new player/mob with uncached models (armours, weapons, hairs, etc) the game will use #1 due to the reason explained in method #2 scenario #2. A proper solution: Make it async! This would mean that you have to provide a callback every time you ask for something. You will have to change lots of stuff, mostly in python part, to handle async loading correctly. For example the python UI sometimes depends on other element's size. If the image is not yet loaded, then it would mean that its size is 0x0. You could however for example tell the UI that okay, preload the images first, then if everything is loaded then you can build the interface. Here is an example:
  11. I know him for 10+ years now, we've started to learn programming kinda at the same time. He has been working on anticheat solutions for 5+ years now, restarted his projects multiple times, and finally HackTrap appears to be a fine-grained result to all his work. I was also the first customer of HackTrap (and still using it), and nobody managed to fix any bot/hack on my server so far. You should also search for "HackTrap" on the bob forum to see slait's reactions, at least for a good laugh.
  12. I know him for 10+ years now, we've started to learn programming kinda at the same time. He has been working on anticheat solutions for 5+ years now, restarted his projects multiple times, and finally HackTrap appears to be a fine-grained result to all his work. I was also the first customer of HackTrap (and still using it), and nobody managed to fix any bot/hack on my server so far. You should also search for "HackTrap" on the bob forum to see slait's reactions, at least for a good laugh.
  13. In the building section in the docs it says that only the following boost packages are required: boost-convert boost-log boost-system boost-filesystem But cmake cries for boost-program-options too, that should be corrected.
  14. Sounds good. It would be also a good idea to create a way to add bots or something, simulating actual players/connections for performance testing. For example building a very lightweight console client while developing the features that you can run on bsd servers to simulate 1-2k or more players, or if there will be separated processes for player instances on server side this may won't be even necessary.

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.