A comment to POL under Linux and dynamically linked executables

[OWHorus]

Hello,

I am just trying to use the newest POL core under Linux. I have Debian wheezy on our server.

If you look into the docs how to compile, confusion starts. There is something about vagrant, which seems to be out of date (?).

I tried to use Ubuntu 14.0 LTS on a VM, and managed to compile. Also a helpful user here provided a link to a release compiled under CentOS.

Both releases are unusable, because the needed libraries are not here. For CentOS-binaries the libcrypt.so is the wrong version, for the Ubuntu compiled executables more is missing. I used GCC-4.8, which probably is the reason. Every damned Linux-distro uses more or less ancient libraries, every one has different defaults. If you have a server with email, apache web, POL, mysql, and a lot of other services, you cannot simply advance to the next release, which in Debians case would be jessy. It is a lot of work, and we all have limited time for this hobby.

So - is it really necessary to dynamically link? This forces us all to build the build environment on the system we currently have on our servers. Compiling on other systems like CentOS or Ubuntu is out because of the library confusion.

Under Windows you can build POL with an easy to use script, and it runs. Is this not possible under Linux??

I will try now to build under Debian wheezy, the necessary tools should be there. But dynamically linking for an application, which should run on every Linux beyond a minimum version is impractical, I think. This also questions the 'stable development environment' which is advocated with Vagrant (but no longer used I think?). There seems to be only the option to compile yourself on your system, with all the troubles this may bring, and it either forces the POL developers to think deeply about what they use, or to force users to upgrade their servers with the latest release immediately, what no server admin will want to do.

As a side note: The distro which is generated after the building process provides the new libraries in ./lib, but they have the wrong names, you need to symlink them to lib***.so.99. I do not know if this is the usual way, but I can live with this...

With statically linked executables the dependencies are much lower, and it seems to be much more practical. But maybe I am wrong...
Dynamically linking also makes it practically impossible to have a downloadable release for Linux. So every single POL user has to go through this, if she or he is able...

OWHorus

[bodom]

Hi OWHorus,

the docs have been neglected for a very long time, but I'm spending a good effort lately to update most of them.

If you look into the docs how to compile, confusion starts. There is something about vagrant, which seems to be out of date (?).

Please tell me which file are you referring to, so I will try to update it.

At the moment, updated build documentation is in the README.md.
If you look at my fork on github, there is also a slightly updated version of it, that also explains how to unpack boost.

I do not know about Vagrant status, but I'll try to ask and update the docs accordingly.

---

About the build, I've successfully built both on latest 15.10 Ubuntu and 14.03 LTS. I've never tried wheezy and unfortunately I've already upgraded all my servers to jessie so I can't try it easily now (it's a quite straightforward upgrade for a maintained LAMP system, but I understand most people tends to forget about updating their servers, making the upgrade process a pain when a new release comes out... that's OT). Let me know if you need to know about jessie.
Anyway, being a linux user since a very long time, I understand your point when you say that a statically linked binary is more practical. I am not a C++ dev, but I'm pretty sure there is a good reason behind this choice.

The built library names were correct in my case, but the are not in lib, but in bin instead: you need to copy all the symlinks for the "cascading" naming system to work.

Please post the steps you are following and the error you get so that we'll see if I can help.

[OWHorus]

Hi bodom,

I built yesterday successfully on wheezy. At least it compiled, linked and built the release - will post details and hints.

At this time it looks as if one particular script runs wild which could be a core problem, since the same script runs on Windows 7 (with the same POL core). But I will look into this.

I will also try to give input for Linux documentation, at least as far as I understand it - which sadly is not very far...

And it is not true, that I have nothing better to do during the holidays - but if you try to import snow tiles (a lot of them), which was done every year for years, and your server crashes immediately after this, it is time to do something...


Have nice holidays!

OWHorus

[Chaos]

Hi,

Thanks for your feedback. We have already discussed this thread aside of this board.
If you still have compile issues, it would be interesting to see which outputs you have.

(But I have a deadline in January. So, I can update things only after this date.)

Best regards,
Thomas.

[Nando]

Hi OWHorus,

I'll just extend a bit on Chaos' answer.

We recently changed the build system on linux to use cmake because the makefiles were terrible to work with. Besides the potential bugs due to different files being linked on linux vs windows, it was hard to make any changes on filenames or folders. The end goal is to use cmake to generate the VS projects as well, ensuring consistency across platforms.

Unfortunately, the changes may have evidenced some bugs. If you have reproducible bugs, would be good to have a description of the steps and the difference between expected and observed behavior so I can try to reproduce them here. Bonus points if you can test different commits to see when it shows up.

By the way, Vagrant is used in the project as a standard environment for testing the core and discussing bugs. Which problems did you have with it?

Enjoy the holidays!

[OWHorus]

Hello all,

and thanks for your answers!

I will post later more, but here a short report, what I did - and why. [If you think tl;dr - read the last 2 or three paragraphs ]

We use on our world the snow mode from UO, but as you know, it is not very beautiful, since the borders are ugly. So we did (around 7 years before) something: We only use a smaller part of the map, where players live and can move freely. It seemed feasible to add the borders, I wrote a script to support this, and after a bit of work it looked nice. We have now scripts to delete all snow tiles - for the other seasons - and 2 scripts to export and import the tiles, so that we can change fast. There are around 120.000 snowtiles. For years we switched 'weather' to snow effect and then imported the snowtiles. There are several fixes necessary, but all in all this works well. In spring I export all snowtiles, delete them and switch to spring.

But this year our trusty POL server (compiled under Debian to 32 bit, since 64 bit had bugs and was not recommended, POL.099 from around 2012, from SVN) refused: For no obvious reason the import of the snow tiles went well, but the server crashes immediately after the import. Every time, and also on another machine. No idea, what causes that. We had in the over 2 years we use it only 2 crashes, one unexpected, another a known crash when you use a certain item. This is not too bad I think. So I did not switch to winter this time - and the server continues to run. But something is fishy! This worked for years, and or worldfile is not bigger or smaller.

To look for the bug in the old POL version makes no sense, and would take me days - so the only solution is to change to the newest POL core. First problem was the script (see my post from March this year, data overflow), but I found a solution and now it compiles. (It did compile under the older POL version, but not with the last POL version).

The build for Windows went problem free, using the scripts provided and an installation of Visual Studio 2012 on Windows 7.

Next I tried to build the core for Linux (Debian wheezy). First I took a look on Vagrant, completely unknown to me. I installed it on Windows 7, my home and development PC. But when I found, that essentially it does nothing more than creating a dev environment in form of a V-Box Linux I decided to build the Ubuntu Linux an VirtualBox myself. Yet - the version installed (from Vagrant and docu) is Ubuntu 12.x LTS, and Ubuntu wants to update, since it is now 14.x. I installed the latest Ubuntu LTS, installed the libraries and was able to build - but see above - no luck with the libraries..

One caveat is cmake: Cmake from Ubuntu (from the package) did not work. I installed the latest version from Cmakes website, and this is the best solution if you only want it for POL build.
Every Linux distro has the /usr/local tree, and the PATH includes /usr/local/bin by default. So I would recommend to use the cmake-XXX.sh installer, a shell script which includes the binaries and installs cmake. Works nice - here the steps:
Use wget to download the file directly from Cmakes website and store it somewhere were you can access it as root. Then go to /usr/local and run it with /bin/sh. Agree to the license and the say NO, when it ask if it should use the prefix 'cmake-XXX'. It will install directly to /usr/local/bin and other folders in /usr/local and can be used!

Next I built the boost libraries. Boost I know from other projects - it is PITA to build. On no system I tried it built without problems, but this does not seem to matter. Curious...
After this you can build POL, using the scripts provided. A bit unclear is how to 'make clean', maybe it would be a good idea to provide a script to do this? (See above, the hints from @aderal work well).

But then I saw the library mess...

Now I have a new Debian 64 wheezy VM here, specifically for POL build and testing. I will upgrade this VM to jessie, when I can take the time to upgrade our server, which is a longer task. So - I have now a build environment which fits our server.

I build again today - and ran the server on this VM. It seems to work, but there is a problem: On certain places the client hangs. You must kill it. I will look into this, no idea what exactly happens. But all the things, scripts and so on seem to run. I also need to look into core changes, since there will be probably small fixes necessary for the newer version.

Another hint: I always copy worldfiles from Linux to Windows, sometimes back to Linux too. I use WinSCP, and since worldfiles are textfiles I selected 'text mode'. This causes problems!
A Windows save (full world) transferred to Linux and started with POL has curious problems. They seem to come from ObjectProperties (via GetObjProperty), which - while set correctly - seem to be read incorrect. So certain sound objects with repeating sound did not sleep, because the timing values were incorrect, they went run away. There were values for sleep times, read via GetObjProperty from the item, which were <undefined> afterwards.

After a night of sleep I had the idea to copy 'binary', i.e preserving the Windows CR/LF instead of LF only. POL reads these files nicely, and the problem is gone! When POL later saves again, the save files have only LF under Linux, and then POL can read them again - without troubles. So - do not convert!

I also tried to build the Lunix 32 bit POL (using the script in bin-build). Does not work! I installed the multilib support and have all the libraries in 32 bit, and boost is compiled in 32 bit too. But it stubbornly tries to link against the 64 bit libraries.

So far my report...

OWHorus

[Turley]

Just two quick notes:
You don't need to build boost we are currently only using header only libs.
Vagrant is just for windows developer like me who need to quickly check the build under Linux. And this gives us the chance to have a defined environment which works from scratch. That's why it's not mentioned in the readme.md

[bodom]

Mhhh, I see some confusion in your build procedure, let's proceed by gathering some crucial info:

1. When you say "this does not work", please also copy/paste the error message you get, or it will be almost impossible to help you.
2. cmake: cmake from ubuntu package worked fine for me on both the old and the new distro. Installing from source may only lead to unnecessary troubles. I suggest you to clean the manual install and proceed with the packaged one. If it does not work, please post the exact error message you get.
3. boost: are you using the boost version shipped with POL? Are you following the unpack procedure I've suggested in my previous post? If it does not work, please post the exact error message you get.
4. clean: a simple "make clean" works for me (i didn't check if it deletes everything, but at least it runs).
5. client hangs: do you have any error message on the console when client hangs? Which version of the client are you using?
6. core changes: you must read the core changes and adjust your script accordingly: it's boring, I know...
7. wordfiles: I've been copying wordfiles from windows to linux and vice.versa so many times. It works like a charm. I suggest you prevent your sofwtare to alter them during the transfer (I was using dropbox instead). Anyway, in my experience, changing line endings does not affect the result. Do you have a precise example of the problem you get as a consequence? Which property do you read? how was it supposed to be? Which value do you get instead? How does it appear in the worldfile?
8. 32bit build: in my experience, the 64 bit build is now the default and more stable one. Unless you have a reason to do it, I suggest you leave the 32 bit one apart.

Hope this will be helpful

[OWHorus]

Hello,

1. When you say "this does not work", please also copy/paste the error message you get, or it will be almost impossible to help you.

Cmake did not work for me (either Ubuntu or Debian, packet version. Debian has as usually an ancient version...). Did not work means it did not find the Boost Libraries, which I had unpacked (bzcat boost.....tar.bz2| tar xv in the directory where it is, unpacks into boost-xxx directory). I tried building Boost - there are two build scripts, and during build several targets were not updated. But I already suspected, that these parts are not used.

2. cmake: cmake from ubuntu package worked fine for me on both the old and the new distro. Installing from source may only lead to unnecessary troubles. I suggest you to clean the manual install and proceed with the packaged one. If it does not work, please post the exact error message you get.

See above. And I did not install from source! The installer (cmake-3.4.1-Linux-x86_64.sh) is the binary distribution (it has the binaries encoded). And it works fine under Ubuntu or Debian.

3. boost: are you using the boost version shipped with POL? Are you following the unpack procedure I've suggested in my previous post? If it does not work, please post the exact error message you get.

Yes - there is a big boost...tar.bz2, this I used.

4. clean: a simple "make clean" works for me (i didn't check if it deletes everything, but at least it runs).

Ok - will try this - obviously it has to be given in bin-build? I tried it under pol-core - no Makefile found.

5. client hangs: do you have any error message on the console when client hangs? Which version of the client are you using?

I have to look into this in the evening. If you move around suddenly the client hangs and is spammed with a lot of packets from the server, which hangs it. It remains unresponsive and has to be killed via task manager. But it could be a script which runs wild, in the place where this happens many objects which give sounds, animations and emotes are situated. But - it works fine with our old server and also it works with the new server under Windows. But I have to look where the packets come from. I already have a packet log, must look into it.

6. core changes: you must read the core changes and adjust your script accordingly: it's boring, I know...

I do not find that boring - I always look where scripts could be improved using new features like string.format(). Also sometimes scripts have to be changed a bit, especially if they control packets directly. But it takes a bit of time.

7. wordfiles: I've been copying wordfiles from windows to linux and vice.versa so many times. It works like a charm. I suggest you prevent your software to alter them during the transfer (I was using dropbox instead). Anyway, in my experience, changing line endings does not affect the result. Do you have a precise example of the problem you get as a consequence? Which property do you read? how was it supposed to be? Which value do you get instead? How does it appear in the worldfile?

Like I said: I had used text mode (WinSCP is essentially a secure FTP), and in text mode FTP always changes the line endings. If I use binary mode, the file is copied as it is. I only wanted to mention it. Now that I know this, it is no problem.
We have an invisible item, called a 'sound spawn'. Staff can use the item (and see it obviously) and configure it. Essentially it plays a sound, and to do that, it has a control script. This control script reads the configuration from the item, in the form of CProps. The minimum and maximum delay in seconds is stored in two CProps on the item itself. This values seem to be wrong.

Code: Select all

        // Read and check the values
        minrespawndelay := GetObjProperty(spawn,"spawner_minrespawndelay");
        maxrespawndelay := GetObjProperty(spawn,"spawner_maxrespawndelay");
        // If invalid, deactivate the sound spawn (no sound id, no times)
        if ((soundids) && (minrespawndelay) && (maxrespawndelay >= minrespawndelay))
          SetName(spawn, "Sound Spawn ("+ soundids +")");
        else
          SetObjProperty(spawn,"spawner_enabled",0);
        endif
       .....
        // Calculate respawndelay, it is ensured above that it is always > 0 (var is defined above)
        respawndelay := minrespawndelay + RandomInt((maxrespawndelay+1) - minrespawndelay);
        // <--- From here on respawndelay is <undefined object>! Seen with a print command, since I wanted to see
        // the delays. I also tried to set the variable to a value (var respawndelay := 1;), so it should 
        // never be undefined.
        // The variable is defined at the start, outside of the loop. An no, it is not shadowed in the loop.

The code fragment above runs in a loop, which is a bit more complicated, since the script also has to look for changes in its configuration while running. But it is clear, that after setting the variable respawndelay it should not be undefined! And the variables minrespawndelay and maxrespawndelay are checked if they are invalid. If one of the CProps does not exist, one (or both) variables become <error> and the if condition fails, the CProp 'spawner_enabled' is set to zero and the spawn deactivates itself (not shown in the code fragment). These spawners are in use for years now...
I suspect, that with the changed line endings (I did not analyze, how they are changed, btw.) one or both of the values read from the CProps becomes somehow invalid, but do not work in the check below, where they look normal. So respawndelay is somehow changed. But since it works now, I will not analyze it more...

8. 32bit build: in my experience, the 64 bit build is now the default and more stable one. Unless you have a reason to do it, I suggest you leave the 32 bit one apart.

Ok - only wanted to try it. The server is 64 bit, so no problem.

OWHorus

[bodom]

1,2,3. boost libraries are to be unpacked in lib (cd lib; tar xjf boost_1_55_0.tar.bz2), minimum cmake version... unfortunately I see the versions shipped with Debian are older. Mybe installing the package from sid is a more clean solution, but I've already solved this, let's move on. I will have to try a build on Debian myself soon, so I will update you with my experience

4. yep, make clean inside the bin-build folder

5. What type of packets? You could start a packet log in the old server and then in the new one, then compare them to see what's different in the streams (assuming the client stays the same). Once again, which client version? I am asking because old clients are known to hang on more easily when the player enters an area with a lot of items (that's a bug that we always had on my shard, and we only solved it by migration to a newest client)

7. most probably respawndelay ends up being undefined because some operands were undefined. Try printing all the operands (maxrespawndelay, minrespawndelay, RandomInt((maxrespawndelay+1) - minrespawndelay)) and you should then be able to backtrace the problem. They are probably not checked/casted correctly before that line.

[OWHorus]

Hello,

1,2,3 - yes, I unpacked them where the .tar.bz2 file is - it is in lib. The unpacked files go to lib/boost_.../, I did this correct.

5) Preliminary, since I need to further look into this: Our UO is UO-ML, client 5.06a. If the client is hung by the server (see below) there are no messages in pol.log, no errors at all. The client is hung, because POL sends masses of packets, the packet log file grows to around 1 MB and more in a few seconds! This happens in a place with a lot of items, there are sound-spawns and effect tiles (walkon tile which gives an emote to the player who passes.) But there are no problems at all with our current core, not under Windows at home, and not on the Linux server!

So this is a core problem, I think. The packet log is much too long to post, but here is a short example, which shows the problem:

Code: Select all

[12/22 21:04:01] Logfile opened.
Server -> Client: 0x1C, 65 bytes
0000 1c 00 41 01 01 01 01 01  01 00 03 b2 00 03 53 79   ..A..... ......Sy
0010 73 74 65 6d 00 00 00 00  00 00 00 00 00 00 00 00   stem.... ........
0020 00 00 00 00 00 00 00 00  00 00 00 00 49 2f 4f 20   ........ ....I/O 
0030 6c 6f 67 20 66 69 6c 65  20 6f 70 65 6e 65 64 2e   log file  opened.
0040 00                                                 ........ ........

Server -> Client: 0x6D, 3 bytes
0000 6d 00 08                                           m....... ........

Server -> Client: 0x65, 4 bytes
0000 65 ff 00 00                                        e....... ........

Server -> Client: 0xBC, 3 bytes
0000 bc 03 01                                           ........ ........

Server -> Client: 0x76, 16 bytes
0000 76 00 00 00 00 00 00 00  00 00 00 00 1c 00 10 00   v....... ........

Server -> Client: 0x78, 65 bytes
0000 78 00 41 00 00 01 52 01  90 00 00 00 00 00 00 04   x.A...R. ........
0010 0d 00 01 59 f5 13 f8 17  11 03 58 ab ff ba 2f c3   ...Y.... ..X.../.
0020 04 5a 27 4b 00 04 70 05  59 f5 13 f6 20 3c 0b 46   .Z'K..p. Y... <.F
0030 30 8a d6 0e 75 15 59 f5  13 fb 20 4f 16 00 00 00   0...u.Y. .. O....
0040 00                                                 ........ ........

Server -> Client: 0xDC, 9 bytes
0000 dc 00 00 01 52 00 09 63  67                        ....R..c g.......

Server -> Client: 0xDC, 9 bytes
0000 dc 59 f5 13 f8 00 00 00  04                        .Y...... ........

Server -> Client: 0xDC, 9 bytes
0000 dc 58 ab ff ba 00 00 00  01                        .X...... ........

Server -> Client: 0xDC, 9 bytes
0000 dc 5a 27 4b 00 00 00 00  01                        .Z'K.... ........

Server -> Client: 0xDC, 9 bytes
0000 dc 59 f5 13 f6 00 00 00  03                        .Y...... ........

Server -> Client: 0xDC, 9 bytes
0000 dc 46 30 8a d6 00 00 00  0f                        .F0..... ........

Server -> Client: 0xDC, 9 bytes
0000 dc 59 f5 13 fb 00 00 00  04                        .Y...... ........

Server -> Client: 0x20, 19 bytes
0000 20 00 00 01 52 01 90 00  04 0d 00 00 00 00 00 00    ...R... ........
0010 00 80 00                                           ........ ........

Client -> Server: 0x34, 10 bytes
0000 34 ed ed ed ed 04 00 00  01 52                     4....... .R......

Server -> Client: 0x6D, 3 bytes
0000 6d 00 00                                           m....... ........

Server -> Client: 0x1A, 20 bytes
0000 1a 00 14 d1 0c 8d ca 16  47 00 01 80 01 c0 01 1d   ........ G.......
0010 00 00 00 20                                        ... .... ........

Server -> Client: 0xDC, 9 bytes
0000 dc 51 0c 8d ca 00 00 00  01                        .Q...... ........

Server -> Client: 0x1A, 20 bytes
0000 1a 00 14 d1 0c a1 59 16  47 00 01 80 01 c0 01 1d   ......Y. G.......
0010 00 00 00 20                                        ... .... ........

Server -> Client: 0xDC, 9 bytes
0000 dc 51 0c a1 59 00 00 00  01                        .Q..Y... ........

Server -> Client: 0x1A, 20 bytes
0000 1a 00 14 d1 1e 0a 8d 16  47 00 01 80 01 c0 01 1d   ........ G.......
0010 00 00 00 20                                        ... .... ........

Server -> Client: 0xDC, 9 bytes
0000 dc 51 1e 0a 8d 00 00 00  01                        .Q...... ........

Server -> Client: 0x1A, 20 bytes
0000 1a 00 14 d1 1e 0a 90 16  47 00 01 80 01 c0 01 1d   ........ G.......
0010 00 00 00 20                                        ... .... ........

Server -> Client: 0xDC, 9 bytes
0000 dc 51 1e 0a 90 00 00 00  01                        .Q...... ........

Server -> Client: 0x1A, 20 bytes
0000 1a 00 14 d1 1e 0a 93 16  47 00 01 80 01 c0 01 1d   ........ G.......
0010 00 00 00 20                                        ... .... ........

Server -> Client: 0xDC, 9 bytes
0000 dc 51 1e 0a 93 00 00 00  01                        .Q...... ........

Server -> Client: 0x1A, 20 bytes
0000 1a 00 14 d1 1e 0a 96 16  47 00 01 80 01 c0 01 1d   ........ G.......
0010 00 00 00 20                                        ... .... ........

Server -> Client: 0xDC, 9 bytes
0000 dc 51 1e 0a 96 00 00 00  01                        .Q...... ........

Server -> Client: 0x1A, 20 bytes
0000 1a 00 14 d1 1e 0a 99 16  47 00 01 80 01 c0 01 1d   ........ G.......
0010 00 00 00 20                                        ... .... ........

Server -> Client: 0xDC, 9 bytes
0000 dc 51 1e 0a 99 00 00 00  01                        .Q...... ........

Server -> Client: 0x1A, 20 bytes
0000 1a 00 14 d1 1e 0a 9c 16  47 00 01 80 01 c0 01 1d   ........ G.......
0010 00 00 00 20                                        ... .... ........

Server -> Client: 0xDC, 9 bytes
0000 dc 51 1e 0a 9c 00 00 00  01                        .Q...... ........

Server -> Client: 0x1A, 20 bytes
0000 1a 00 14 d1 1e 0a 9f 16  47 00 01 80 01 c0 01 1d   ........ G.......
0010 00 00 00 20                                        ... .... ........

Server -> Client: 0xDC, 9 bytes
0000 dc 51 1e 0a 9f 00 00 00  01                        .Q...... ........

Server -> Client: 0x1A, 20 bytes
0000 1a 00 14 d1 59 8a cf 16  47 00 01 80 01 c0 01 1d   ....Y... G.......
0010 00 00 00 20                                        ... .... ........
.... this goes on and on - in a few seconds the file grew to over 1 MB!

As you can see, it all starts with me writing .startlog. Then I run around a bit in this area (with a Staff-Character) until the problem happens. Then it looks like a network lag, but does not end. (The Linux server runs in a VM on the same computer which also runs the client, so forget the network). I never had black screen problems locally, and with the client 5.06a they are extremely rare and only happen if the connection is really awful.

When the problem happens, it sends masses of packets 0xDC and 0x1A, alternating, as you can see. I want to look at the packets contents, especially the serials, but this will take a bit.

What is worse: The problem seems to exist for a while! The last official distro (2013-09-03, Ubuntu compiled), a statically linked POL which runs well on my Linux has exactly the same problem! But my self compiled POL (from around 2012, from SVN) does not have this problem, I tried to run around in the same place - no hang!
And the hang happens most frequently in the place where I test now, but it happens in other places too - only less frequently!
I think this is a serious problem, because the only way is to kill the client (a normal logoff message is all the core has to say).

Running around in an empty part of the world (only a few NPC-animals) seems to be stable. Speedhack-Prevention is off, btw, and if I say running I mean running - my character is not mounted.

That is all I can tell at the moment.

7) Since the problem does not happen anymore it has low priority for me. You are probably right - there is a variable <undefined> - but why it is not seen in the if condition just below (which should simply turn off the sound spawn) is everybodys question..

OWHorus

[Nando]

Just a quick thought: have you checked for any packethooks on 0xDC, 0x1A or 0xD6? The 2013 beta was the first one to send the 0xDC packet to clients 5.0+.

[OWHorus]

Just a quick thought: have you checked for any packethooks on 0xDC, 0x1A or 0xD6? The 2013 beta was the first one to send the 0xDC packet to clients 5.0+.

I thought of this - we have no hooks on 0xDC, and no hooks on 0x1A, but we have a hook on 0xD6, because it caused a crash (at least some sub packets). But this hook is very old - I will remove it completely, since the hook was done for POL.098. Maybe this is the reason...

I will report - thanks for the hint.

OWHorus

[bodom]

Nice the see the problems are going away one by one

Nope, with "old client" I was referring to 2.x/3.x series. We are now using 5.x too and it seems not to suffer from this problem... let's hope Nando found a solution for this one too