bluap

I committed the needed changes to git. The client should compile and work with anything other than v2.11.

Which distro are you using? On Arch for example, I have installed the old version and will hold the package until the updated version arrives. If you build your own package, most packages will support installing into the /usr/local tree which would be picked up by the build and at runtime, hopefully. If not you may have to remove the old package too.

Thanks for finding the problem with my additional checks, that could have lay hidden for ages. Glade you fixed your audio, we'll need to keep a look out for that.

Wow, that's an unintended consequence of adding the return value check for the read_actor_defs() call! I've had a quick look at what you have found and I think you found a long standing bug. If the statement: if (!have_sound_config) return 0; returns zero, the defs for sound are never loaded, even when you enable sound later. I would suggest we just remove the check completely which will fix part of the long standing bug and also fix the issue you have with return value check for the read_actor_defs() call failing too. Edit: Perhaps safer for now, leave the have_sound_config and return 1 to just prevent the error. I'll check some more later, but what do you think?

I just tested again and it works fine for me. Sorry to ask but, are you sure you were pointing at the new libxml2 headers when you compiled? If the conditional compiles is not included the higher threshold will not be set in actor_defs.c. Everything will compile but the defs will not load. #if LIBXML_VERSION >= 21200 xmlCtxtSetMaxAmplification (ctxt, 100); #endif You can also test the library is working using xmlint: $ which xmllint /usr/local/bin/xmllint $ cd ~/eternallands/actor_defs xmllint --noent actor_defs.xml actor_defs.xml:143: parser error : Maximum entity amplification factor exceeded, see xmlCtxtSetMaxAmplification. &elf_female; $ xmllint --noent --max-ampl 100 actor_defs.xml ... outputs the expanded xml

That's the commit version I tested with of libxml. Can you confirm you are using the correct library at runtime? On Linux that would be ldd on the binary.

I've tested the new version of the library (2.12 not yet released) and using the new ability to set a higher threshold does fix the problem. I've committed the change but stick with version 2.10 of libxml2 until 2.12 is released. Version 2.11 will never work and I've made compiling against that version fail.

The issue I logged has been looked at and the libxml2 devs have already made a change that should allow us to fix our issue. The actor defs are tripping the new "Protection against entity expansion attacks" and the change is to allow setting a higher threshold. I'll test it tomorrow and report here. https://gitlab.gnome.org/GNOME/libxml2/-/issues/581

It could be. I've tried looking at this but I have no idea when its needed. Adding it to the top of the actor_defs.xml does parse, but we still get the error. I've created an issue on the libxml2 repo. We may get some pointers there: https://gitlab.gnome.org/GNOME/libxml2/-/issues/581

I've been trying to fix this for a while now but so far unable. As I said above, I think there may be more than one issue. I've committed the possible fix for reading files but actor defs still fail to load. I added proper detection of this and a pointer to this thread in the error logging. I'll keep trying but help from someone more familiar with libxml2 would be great. I may create an issue on their bug tracker but suspect its and EL problem.

Very sad news indeed. She was very active in LNX guild for a while, made it a fun and pleasant place to hang out and always a pleasure to talk too.

The 2.11.x series of libxml2 has new protections for "entity expansion attacks" which we appear to be triggering with the el xml files. I'm looking into this but cannot find fix a solution so far, it will hit us eventually on other platforms, not just arch based. There is also a change to the way custom loaders work with libxml2 that triggers another issue that I have fixed (I think). Building a static binary unfortunately requires a lot of work as you need to build all the libraries yourself making static versions. I have scripts to do this and still intended to publish them to my EL build methods repo once they are cleaned up a bit. There is a flatpak package that works on Arch and Manjaro, and other distros, available in the flatpak store. I publish a development version too (needs updated to the latest git) that you can install by enabling the flatpak beta channel.

Definitely not wasting time. I was testing using one of the package builds which works. But if I compile my own. I have the same problem with the new version of libxml. I'll look into why that is in case its something we're going in the client that is no longer supported.

Looks like its opening. Perhaps the xml parse fails. Do the contents look OK? This is my checksum; md5sum languages/en/strings/console.xml b635aa251c0d017e095fba0cc3118bca languages/en/strings/console.xml

Perhaps you could try using strace to see what's happening: strace ./el.x86_64.linux.bin.static 2>&1 | grep console.xml You may need to install strace.