lynx

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?

Did you cut out the actual error? Was this the first python error in the log?

ok, finally came back to this. Implemented: - 321: simple stuff, like many other similar filters on various effect params. - 324 && 326: copies of the iwd2 opcode, so just took some moving around and exposing to other games. I've also extended them with the few new pseudostats EEs added. Untested, but should work fine.

You could use regular expressions to first deal with ActionOverride, then make a second pass for the rest. Or make your life hard and do both with one complicated expression. Before reviewing all the changes, of course. But wait, it this over the whole game or your mod files?

Widescreen is a mod for the original games allowing you to play them at almost any desired resolution. v3.08 is a minor maintenance update without new resolution bugfixes or game features. Mod Page Forum Download Readme

No major changes, so don't expect new features, new supported exes or fewer bugs. Until the mod page is updated, you can grab the release from here: https://github.com/Gibberlings3/widescreen/releases/tag/v3.08 Changelog: Added Project Infinity support (AL|EN). Updated Brazlian Portuguese translation (Felipefpl). Bumped license from LGPL 2 to 2.1 (Mike1072) Removed obsolete GemRB mode (lynx) Updated to latest best practices and g3 style (lynx) Updated documentation (lynx)

If -1 works like that, that's more like an autohit than bypassing armor.

What it says, but in iwd2 ("brilliant" weapons). The one you found must be just garbage luck.

I wanted to move some ancient IESDP topics to its archival subforum, since the way things were set up, it's a sort of a TODO list. If you can mass unarchive things in that forum that would be great. If you have to do it one by one, let's not bother.

Seems to work here, but my firefox is older, at 80. On a related note, is there a way to move archived threads? I don't get the option in the moderator actions.

I didn't find a mention in the book about IE games, so perhaps it was in some interview. :s

Well, in this case we just reuse a scripting action to save on code duplication. The originals often did the same. This is the only "code relations" thing we have, but of course you could use external tools to generate graphs: https://gemrb.org/Engine-overview.html

I have a vague memory of an "aha!" moment, so perhaps it was answered somewhere.

The former, as the point of the action is not "attack for a tick", but "attack". There are other ways to interrupt it as well though.

Not all actions are "instants", meaning they get executed immediately. The so called blocking ones are internally executed until their job is done. See this high level comment: https://github.com/gemrb/gemrb/blob/bf7148b4ac21fb053a4d9689d0226dba3fc01b13/gemrb/core/GameScript/GameScript.cpp#L21 Also IESDP has some details on the data side: https://gibberlings3.github.io/iesdp/scripting/actions/index.htm https://gibberlings3.github.io/iesdp/file_formats/ie_formats/bcs.htm

Sounds familiar, maybe ToBEx?

Everything in the announcement, but there's also a technical overview here: https://github.com/gemrb/gemrb/wiki/Subviews---Origins-and-Summary-of-Changes

The GemRB team announces the availability of GemRB 0.9.0! The long awaited subviews branch was a true monster. But the quest to lay it to rest has now been successfully completed, among other things modernizing the GUI, drawing and input handling. More in the full release announcement: https://gemrb.org/2021/06/18/gemrb-0-9-0-released.html

The GemRB team is proud to announce a new major release. Check out the details here: https://gemrb.org/2021/06/18/gemrb-0-9-0-released.html

Well you can't just hack it like that. You'd also have to undefine SUPPORTS_MEMSTREAM. So, do I understand correctly that cmake finds mmap.h for you, but you don't have mman.h anywhere? Where is your mmap defined then? .