kujeger

I think the game already kind of tracks this, as idle characters get the [...] icon above them.

Basically what it says on the tin -- I'd love to be able to set the game to automatically pause when one of my characters is is dle, as that is never a good thing.

I have the same issue. Specs: Radeon RX480 mesa 18.0.2 kernel 4.16.13

Ah, I'd totally forgotten about that feature. I'll update my post, it's a much nicer workaround.

That depends on GOG's packaging for the game, but if there's similar problem you could possibly add something like this to the top of the script: export LD_PRELOAD=$LD_PRELOAD:./PillarsOfEternityII_Data/Plugins/x86_64/libSDL2-2.0.so(you'd have to make sure the path to libSDL2-2.0.so matches)

I reported this back in the BB as well, but figure it's OK to repost it here, along with a workaround. Essentially, if your OS version of libSDL2 does not match the one needed by the game, the libAkSoundEngine.so library freezes and the game gets stuck at a black screen with 100% cpu use. A workaround is to add this line under Launch Options in steam: LD_PRELOAD=$LD_PRELOAD:./PillarsOfEternityII_Data/Plugins/x86_64/libSDL2-2.0.so %COMMAND%(Original thread: https://forums.obsidian.net/topic/95886-linux-unable-to-start-game-hangs-on-black-screen/ ) edit: soulsource has another, neater workaround:

Hi! this is still a problem in the latest backer beta (beta 4). I spent a little time digging into it this evening, and this is what I've found: $ ldd PillarsOfEternity2_Data/Plugins/x86_64/libAkSoundEngine.so [..] libSDL2-2.0.so.0 => /lib64/libSDL2-2.0.so.0 (0x00007f001ceb0000) [..]this library is dynamically linked against SDL2, and the version seems to be 2.0.4. Never versions of SDL2 breaks things (in fact, removing libAkSoundEngine.so allows PoE2 to start, albeit with many fun bugs).libSDL 2.0.4 is included in the steam runtime, and a copy is actually shipped in the PoE2 dir as well: ./PillarsOfEternity2_Data/Plugins/x86_64/libSDL2-2.0.so (well, almost, it's missing the ending '0') With that, a workaround can be done by starting PoE2 with an LD_PRELOAD: LD_PRELOAD=./PillarsOfEternity2_Data/Plugins/x86_64/libSDL2-2.0.so ./PillarsOfEternity2 A "proper" fix would probably be to statically link libAkSoundEngine to libSDL2, which would ensure things work automagically.

Bump -- hope this is/can be registered in the bugtracker

Bump -- I hope this is something that could be resolved before the next BB update

Hi, PoE2 hangs immediately after pressing "Play" in steam (or directly running the PillarsOfEternity2 executable). It simply shows a black screen, and uses 100% cpu in a loop. I have to forcefully kill -9 it in order to shut it down. On my intel iGPU machine, I can get it running by starting steam with STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 . Unfortunately, I cannot do this on my amd GPU machine, as steam is unable to start because of driver problems (it is unable to load radeonsi_dri.so and swrast_dri.so) . I am running on Fedora 27. I would guess PoE2 is unable to start because of differing system libraries that probably should be bundled with the game, as the default for steam is to use system libraries -- it is likely that PoE2 will have problems on other modern distros as well (or future versions of existing ones). Pillars 1 works without any problems. It is basically the same problem that is reported here: https://forums.obsidian.net/topic/95320-linux-intel-game-hangs-on-start-with-100-cpu-usage-and-nothing-drawn-to-screen/ (which was marked as "solved" with the steam workaround). Full terminal output is: $ ./PillarsOfEternity2 Set current directory to /home/kujeger/Games/Steam/steamapps/common/Pillars of Eternity II - Public Beta Found path: /home/kujeger/Games/Steam/steamapps/common/Pillars of Eternity II - Public Beta/PillarsOfEternity2 Mono path[0] = '/home/kujeger/Games/Steam/steamapps/common/Pillars of Eternity II - Public Beta/PillarsOfEternity2_Data/Managed' Mono path[1] = '/home/kujeger/Games/Steam/steamapps/common/Pillars of Eternity II - Public Beta/PillarsOfEternity2_Data/Mono' Mono config path = '/home/kujeger/Games/Steam/steamapps/common/Pillars of Eternity II - Public Beta/PillarsOfEternity2_Data/Mono/etc' Preloaded 'ScreenSelector.so' Preloaded 'libAkFlanger.so' Preloaded 'libAkHarmonizer.so' Preloaded 'libAkPitchShifter.so' Preloaded 'libAkSoundEngine.so' Preloaded 'libAkStereoDelay.so' Preloaded 'libAkTremolo.so' Preloaded 'libMcDSP.so' Preloaded 'libSDL2-2.0.so' Preloaded 'libsteam_api.so' Player data archive not found at `/home/kujeger/Games/Steam/steamapps/common/Pillars of Eternity II - Public Beta/PillarsOfEternity2_Data/data.unity3d`, using local filesystem

Starting steam with STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 steam worked around this problem for me. edit: this is probably not related to specific GPUs, but rather the version of libraries in distros. I'm personally running Fedora 27, and have this happen on both Intel and AMD GPUs.

Yeah, I am talking about the latter case. Most commonly you will be able to write to the game's data directory since you either installed PoE somewhere in $HOME or you have sudo-rights, but that's just an assumption that happens to usually be true. It did bite me in the ass, leaving me to set up some symlinks to work around it. The right way to do it is to read/write any user-specific or user-provided content from $XDG_DATA_HOME or $XDG_CONFIG_HOME, like is already done with savegames and config files. Should be done for both Windows and macOS as well.

Currently the only way to add portraits is to drop them directly into the game's data folder, which is not a great way of doing it -- it requires that the user be able to modify the game files, which is not necessarily the case. This should be done by reading additional portraits from the user's data folder used by the game, like e.g. savegames. On linux at least this path could be something like $XDG_DATA_HOME/PillarsOfEternity/portraits (saves are at $XDG_DATA_HOME/PillarsOfEternity/SavedGames/) I realize PoE is not the biggest focus with PoE2 in full production, but it would be a nice fix to have. Certainly it should be done for PoE2 at least.

The right forearm is misaligned when wearing a Fine Plate on a (human) female:

Storage and download requirements of pre-rendered maps are no doubt an important aspect when deciding what resolution they are in when shipping the game. Would optional downloadable area maps/backgrounds in higher resolution be something you'd consider? Many of the maps in PoE look a bit poor because of their row resolution when I play the game, so optional post-release downloads for those with disk to spare and high-resolution monitors would be very nice.

Would you be willing to share some HW/OS details of those machines (e.g. gpu vendor, os platform and version)?

(still present in 3.0 beta)

hello~~ as I understand it, there's been problems reproducing this. I don't know if that's because it's not happening at dev machines, or if you're just not noticing it, but here are some convenient ways to reproduce it no matter what display you have. Just so there's no doubt, here's an example at 2560x1440 and 2560x1600. This is for linux, as I don't know how to arbitrarily set the resolution of a panning view on windows. I assume there exists tools for windows as well. In any case, since I have this happening under both windows and linux regardless of hardware, I don't think it matters that much. I'd suggest doing this on a 1920x1080/1200 display, but 2560x1440 will also do. Displays that are natively above 2560x1440 won't work well using these instructions (perusing the xrandr manpage though will give you good pointers). First off, start a terminal window. Then type xrandrthis should give an output similar to this: HDMI1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 59.95*+ 1920x1080 60.00 50.00 59.94 1600x1200 60.00 ..and so on. What you need is the identifier of the "connected primary" display, in this case HDMI1. If your display is not natively 2560x1440, run this command (NB! This will not work if your display is natively ABOVE 2560x1440!): xrandr --output HDMI1 --panning 2560x1440(substituting HDMI1 for the identifier you found above. You can also use substitute 2560x1440 with an arbitrary resolution to see what resolutions work correctly in Pillars of Eternity)you should now have a panning display of 2560x1440. Moving the cursor to the edge of the screen will scroll it around. Now, start PoE and make sure the resolution selected there is 2560x1440. Start a new game, or load an existing game and levelup a character. You should see a quite upscaled character model. This is actually easier to see if you're running on a display with a "low" native resolution (e.g. 1920x1080). Exit PoE, and re-run the xrandr command with another panning resolution (e.g. 2560x1600): xrandr --output HDMI1 --panning 2560x1600Start PoE again, make sure the in-game resolution is 2560x1600, and start a new game. Observe that the character model is now sharp and clear. To disable the panning, run xrandr like so: xrandr --output HDMI1 --panning 0x0I've consistently reproduced this on entirely different hardware, using AMD, Intel and nVidia cards. Here are screenshots of some different resolutions. Particularly 2560x1440 vs 2560x1600 are very good to look at, as they are almost the same size -- only the height is different, and poe handles that difference by padding at the bottom and top of the screen, which means they should otherwise look identical: Closeup at 1920x1200 Closeup at 2560x1440 Closeup at 2560x1600 1920x1200 2560x1440 2560x1600 I hope all of this makes it easier to see the issue, and reproduce it using your own hardware. If there are any questions around this, I'll be happy to answer and/or test as necessary (by forum post, PM, email or anything really)!

beep boop there been time to look at this? :hopefulface:

Since ultra-wide screens are becoming more common (especially the curved variants), checking if 3440x1440 also is problematic along with 2560x1440 would probably be worth it.

Anyone had the time for a look?

Any chance for 3.0 and the white march part 2?

Well, this is embarrassing. You're entirely correct, don't know what I did to make me think it is still bugged. Thanks for fixing it

Still the same in 2.03 beta, so guess not

Noticed that this is still bugged in the 2.03 beta