lynx

Like I said, the AppImage for v0.9.0 will be like that regardless what you do. It's the latest one that shouldn't have the green. I think she's using Virtualbox (EDIT: yep), but also, she's running it from linux, so it's not comparable. Oh, do you also get the green if you try the latest windows build, on windows? https://sourceforge.net/projects/gemrb/files/Buildbot Binaries/Windows/AppVeyor/

It's designed to not need one, but it will take the one in the current dir if present. This is not something you can fix through configuration though. Now it looks like it's a limitation of the VM gfx driver and/or SDL. This is still the VM right? I tried the latest build myself, just to be sure it didn't regress, and the image behaves here as expected.

Ok, there's some pointless confusion. First, your ubuntu is new enough that the extra ppa was not necessary — you couldn't have known, since you didn't get in game yet. AppImages are like binaries, fixed, unchanging. We'd have to rebuild it with the newer sdl to get rid of the green outlines. You can grab a development AppImage and you'll see the problem is not present there. Just try reproducing the original crash with that. https://sourceforge.net/projects/gemrb/files/Buildbot Binaries/Linux/

Start it the same way as before. Oh, ubuntu has too old sdl2. If you hit that also with your own build, this is the cure until they update their software: # grab a newer sdl sudo add-apt-repository -y ppa:cybermax-dexter/sdl2-backport sudo apt-get update sudo apt-get install libsdl2-2.0-0 libsdl2-dev # again in the build dir make clean make

Heh, no. Just a bit less characteristic than usual, after the last release we did a ton of refactoring and a few more dangerous changes, so the current git version is not as stable or polished as the last release yet. And I'm about to throw a few core scripting changes at it that can potentially make it worse. At the same time it contains some very cool bugfixes, so it's harder to choose. Even has one fix specifically for the bgt start (unrelated to your troubles).

No, this isn't mod related. And while it works for me *and* at least one other BGT player (also in Virtualbox), these exceptions shouldn't be happening. You can safely comment out also gemrb/GUIScripts/bg2/LoadScreen.py:78 for the previous error. Might just hit some other SetAction then, hard to say if they're all problematic. You could also try building the 0.9.0 version, so there are no experimental changes. You can do that simply by running this in the build dir: git checkout v0.9.0 make

Shit, sorry, meant line 25 — that SetAction mentioned in the gdb log.

So like See, but without invisibility checks, LOS, but without explicit range.

At least it's clear exactly where it breaks, even if the reason is somewhere else. Try commenting out gemrb/GUIScripts/Console.py:23 just to see if that makes it pass.

The cfg and path look fine. If you hadn't moved it, the right path would be /home/darpaek/BG2 (assuming it was right in the home dir like you said), which on unixes can also be abbreviated as ~/BG2. The debugger is already paying dividends. It's an odd error, but we've seen it before, just have to hunt it down. Where/when in character generation does it go boom?

Hard to say, that's weidu complaining about something. Maybe a mod is using a very exotic path or there are shortcuts. I'd just try moving on. If it was generated, I'm also interested in the contents of the diffs dir.

It's not that simple, but yes, it's being worked on. Ubuntu (Debian) is complicated to update. Anyway, can you reproduce the crash with the new code? If so, then run gemrb via gdb, a debugger, which will then tell us exactly where and probably why it crashed: # set up the config for easier use cp ../gemrb/GemRB.cfg.noinstall.sample gemrb.cfg # EDIT this new file in build/gemrb.cfg and set GamePath to the path to the game # run the debugger via a script that does some extra magic ../admin/run.gdb ######################## # If you ever get a crash, you will be dropped into gdb's own console # type bt (short for backtrace) to get the call stack, showing what functions were executed to crash # type r to restart # type q to quit

Oh nice, you're good at this! Forget about the demo problem, this looks like one of the recent changes. I'm currently not at the latest code, since I'm in the middle of a long research, but the games themselves won't be affected by this problem. So just try them.

I think that'll be the fastest way to make progress then. - set up the VM - install some linux on it (I suggest (k)ubuntu, just so it'll be easier to install other software) - either copy the game folder inside or make the outside visible inside (probably possible, not a VM guy) - install build tools and gemrb dependencies, on ubuntu: sudo apt-get install git cmake make clang libsdl2-2.0-0 libsdl2-dev libopenal1 libopenal-dev python-is-python2 libpython2.7-dev gdb - finally you can download and build gemrb by opening a terminal and running: git clone https://github.com/gemrb/gemrb.git; cd gemrb; mkdir build; cd build; cmake ..; make; sed -i 's,GameType=.*,GameType=auto,' ../gemrb/GemRB.cfg.noinstall.sample - then you can run gemrb without installing it from the same build dir by issuing: gemrb/gemrb -c ../gemrb/GemRB.cfg.noinstall.sample /path/to/the/game/dir # this is the example with the included demo, one directory higher: gemrb/gemrb -c ../gemrb/GemRB.cfg.noinstall.sample ../demo - you're now running the latest development build — check if you can still reproduce the crash as a start

That's definitely not normal and eg. I can't reproduce the Firehair crash. Too basic a thing to go unnoticed, even in development builds. As for the other problem, never heard of that either. Could almost be anything. It'd be good to get to the bottom of this, but debugging on windows is a pain, so I don't know if you're willing to go through the hassle. You'd need to build from source, find and use a debugger. So far we have docs only for the first part. Do you have access to a linux box or VM?

No, we need to implement it. There was some partial support, but for all intents and purposes, no, it doesn't work. Download the actual fatter font family member.

Those that only replace data should work out of the box. Widescreen comes to mind and I'm pretty sure some big font mod worked fine before. For the fonts, best use a bold/heavy variant of the family and it will look much better. The bitmap fonts are thicker by default and it really matters at the default small size. Look at this comparison if you don't believe me: https://github.com/gemrb/gemrb/issues/1274

We don't touch it, so something must've went wrong during some mod install. fonts: it's the NORMAL one, but it will affect more than just the message window.

First, what version of GemRB are you using? Our current limit is at 450000, but may get refactored — I was just memory conscious when last bumping it. Empty string entries are not problematic ... unless the mods use them and expect them to be non-empty. Check which strrefs Finch is using and if they're blank. fonts.2da: you either need: bigger font BAMs — no need to change the 2da if the names match and the size column has no effect replace them with TTF fonts (see website)

it's a bitfield, so 7 is already enough to cover all three. I think we used to have a fourth bit (and then we just turned it on always), that's why the config file defaults to 15. GUI: that mod relies on exe hacking, so for sure many of its things won't work. Btw, ctrl-w to consolidate visible loot under the mouse cursor. It will get sorted, merged, way easier to deal with. IMHO also better than the loot bar.

It is documented, just that the field is currently split, so you don't see that in the bit list. Not sure which is correct, but it remains just a cosmetic / usability issue.

It's a bitfield, that's why the numbers can grow fast. But we have to find some better way, maybe store it within the game config. We'll see what's best once we have a proper launcher. 4 (third bit) enables direct opening of bags, the item description is skipped.

Yes.

I don't see what goes wrong and I also forgot this window is the same regardless of resolution. This should fix the wrong table being used (first python warning) diff --git a/gemrb/GUIScripts/LUSpellSelection.py b/gemrb/GUIScripts/LUSpellSelection.py index f24600afb..5340abc54 100644 --- a/gemrb/GUIScripts/LUSpellSelection.py +++ b/gemrb/GUIScripts/LUSpellSelection.py @@ -174,7 +174,7 @@ def OpenSpellsWindow (actor, table, level, diff, kit=0, gen=0, recommend=True, b # adjust the table for the amount of spells available for learning for free # bg2 had SPLSRCKN, iwd2 also SPLBRDKN, but all the others lacked the tables - if SpellLearnTable == "MXSPLSOR": + if SpellLearnTable == "MXSPLSOR" or SpellLearnTable == "MXSPLSRC": SpellLearnTable = "SPLSRCKN" elif SpellLearnTable == "MXSPLBRD": SpellLearnTable = "SPLBRDKN" So you get the correct new spells amount on levelup. I doubt it will affect your gui error though.

Hmm, you can try commenting out the line 155 in GUIScripts\LUSpellSelection.py (in wherever you unpacked gemrb). I suspect the data — what resolution are you playing at?