Wyk3d

Yes but keep in mind that no matter where you put the terrain data load/unload code, it may be called from two maps, hence threads, at the same time since one of the main points of this system is not to have duplicate terrain data for each instance of the maps. So you definitely need a proper locked reference count at load/unload but multiple threads should still be able to read the data without any locking while it's loaded.

Actually there are legitimate reasons to have anti-cheat. Software that does not resist invalid input is bad software .. and we just want to make good software. For this reason you will find several anti-cheat features already in mangos. Most of the stuff that you get from patches were not added either because they were too slow, too ugly, not split up into smaller parts or just nobody was interested ..

That means that was the last update you already applied and it's not letting you apply it again (to prevent you from causing damage in some cases), it means you can only update your DB any further with the next update, the one which requires your current one.

Read the GDB guide in the stickies on how to provide good logs, it's good if you also provide the server log, but without gdb in this case it's useless ..

Skirnir, I did change the repo link after I talked to freghar and found that this one is much better done but I tested the original one and it worked just fine. I did test exactly what I wrote and it gave me exactly what I wanted immediately. EDIT: ok the new one does work but is set up a bit differently atm, you need to run gitk with "gitk --all" .. after that it's the same, enter it in the search field and it's not at all unfair because you find what you want immediately, and you don't have to copy paste the SHA, you can do what you want, reset to it, by right clicking on it as i wrote above. So doing it with git is very fast and works just fine. You have an initial download of ~35MB (which at this new link can come with over 2 MB/s) and you have every single revision since the project was created on your hard drive. You will especially feel the difference when you later want to change to other revisions, which is practically instant in GIT but can take a lot of time on svn because you need to do more downloading. EDIT: remember you need to search for @3000 not 3000 ! ofcourse there are many revs with the number 3000 in the message, but only one with @3000.

Your "deep searching" is just .. start gitk, type "@3000" in the search field, hit enter, right click the commit, select "Reset .. branch to here".Or you can use "git log --grep=@3000" to find the SHA then "git reset --hard SHA"

No he meant really old revisions. The normal repository that you get does not contain revisions before ~7000. You do what pelle told you but you first need to clone from freghar's archive: git clone git://repo.or.cz/mangos-git.git

Maybe he's not talking about mobs which don't always drop something, but about mobs which never drop anything. That particular bug was fixed recently.

@power12: that is a lot more complicated than necessary .. Fatty is doing it right (with the exception that you don't need to clone again to get new changes), you should stop thinking in the old svn way of getting a patch that you can apply and learn how to pull/fetch+merge from remote branches.

No, advertising in signatures is not ok. I would edit your username too if I had the right. We definitely will not accept any patch with server advertising anywhere in the files. Author names, maybe but it's generally accepted that we don't change the copyright notice just set the user as the author of the commit. If multiple users need to be thanked they are listed additionally in the commit message.

The low level socket stuff is managed by the ACE library in its own way on separate threads but on the higher level the incoming messages (WorldPackets) are queued and processed on world update, outgoing ones are not.The world is split into many "grids" and each grid into cells. Only the cells near the player are checked for creature visibility. When something moves, everything in range (visibility distance) gets notified. Only the grids near any active objects (players + some special creatures) are updated. If grid unloading is enabled or at the beginning, only those are loaded too (with terrain info + creature spawns). Creature position can be given by its current position and/or its destination(s). When a creature is moving you just send a destination, set its speed and the client interpolates the rest.

That particular case can still be solved by determining that trash mob when entering the instance and storing that information without generating any other loot and then use it later, though one could imagine more complicated situations ..

For some creatures whether it drops anything is random so you cannot determine it in advance without actually generating the loot or at least storing the result of the rand()s and it's probably not worth optimizing for only those where you can. It is only faster if the creature is not looted and i think the creature is more likely to be looted if it always drops something.

I see .. then indeed it should be moved to creature death.

Why ? It makes perfect sense to only load the loot when really needed i.e when someone actually clicks to loot. There's no reason to follow the way it's done on official when you can do it better ..

The way I see it, there's no such thing as complete security, it's all about how many people are able to break it and how many are willing to put forward the time and effort to do so. While there are ways to get around IP and MAC restrictions, those methods are not accessible to everyone. The people who you ban are usually not hackers but stupid kids who don't know about these things. And when it comes to proxies it's hard to find good ones if you don't know where to look. Best you can hope for is extremely low bandwidth, huge latency and no guarantee of uptime. So the offenders might come back but they won't be able to actually play the game through a proxy.

Great info, could you try with 8 cells ? I'm particularly interested in seeing how the cpu usage changes with the same visibility distance and 4/8/16 cells, and whether the pattern changes as you try the same for low vs high distances. Oh and did you have 4 cells before adding patch ? If not, what is you cpu usage without the patch but 8 cells ?Theory is that there's a tradeoff, more cells might (depending on whether or not the distance is close to a multiple of the cell size) mean a smaller area to check, but it also means more cell relocations and we don't really know how much of an effect those have, it's assumed to be small but .. Also note that the patch changes the default visibility distances to much higher as such it is very unlikely that to reduce cpu usage compared to the previous. It does make small radius searches like AOE, traps etc run much faster which although not dominant might account for some cpu usage reduction with the same distances.

The visibility settings in the config ?

and So you are saying that for the same visibility distance, 8x8 cells means lower cpu usage than 16x16 ?

Better than what ? Is it better than just using 8 or 16 MAX_NUMBER_OF_CELLS and no cell walking algorithm instead of the current 4 ? And with the cell walking algorithm, which is better 8 or 16 ?

Hopefully soon it will not matter . But yeah currently if you have more cells they become smaller and with that the maximum visibility distance decreases.

That is just wrong, with that setting instances will unload immediately when you leave them, and worse, if you come back it will need to load back again, resulting in actually increasing the load.

A player has smooth, continuous movement on the client side, but it only sends its current position to the server periodically. The frequency of these position updates is low enough that the server has plenty of time to do other things.Similarly when a creature moves a destination is chosen and every 50 ms its position is shifted closer to it. In this case however, the server only needs to send the destination and speed of the creature at the start of the movement, and the client can interpolate the rest. So where the client sees a smooth movement, the server sees a series of small shifts 50 ms apart. So for example if you are running from a creature and you have lag, you may be sending position update less frequently but the creature is still moving towards you with same speed, so even if on the client you see you've outrun the creature, on the server it may have caught up to you and killed you.

You really don't want to go back to the problems caused by using the stat values loaded from the DB. The calculation needs to be done whether there is a separate field for it or not, making sure everything works correctly. So loading the value is a completely unnecessary overhead. This is not a tradeoff between space/cpu usage, both are just made worse by having the fields. Saving the values can on the other hand be useful to external tools and i think making a config option to enable that (even if never loaded by the server later i.e an unnecessary performance overhead for those who can afford it) might be something that can be discussed.

I don't think what is currently being done with the data blob can be called playing smart.. Not only is the vast majority of the data in it already contained in other tables, a lot of it actually needs to be regenerated at login to avoid bugs. Even in a text file, it's better to only store things once, and not store things you don't need.For example, initially the stats were just loaded at login from the data blob but that caused an endless stream of bugs and data corruption so now it is calculated at login from other fields instead, meaning the value is loaded from the DB, then discarded/overwritten. There are some parts of the data field that could use additional caching, like the set of worn items at login (you only need their displayid, it's faster to load one blob than process all the items separately, but not if the blob is as large as it is now), but those can be dealt with separately. The benefits of removing the blob are clear, a lot more performance in the cases where only parts of the blob were needed. While frontends relying on the current form of the data will need to be changed .. no doubt everyone will find that extracting the information from other fields / tables will be much easier than constantly needing to check field offsets, no need to change the information in several places when it changes and most importantly no more need to update the offsets when the client version changes.