lynx

I bet it doesn't cover GemRB. As is tradition with engine projects, the full name is a mouthful: Game engine made with pre-Rendered Background.

Ok, so this is all as expected. IESDP updated. there's also an area_diff_3 spawn ini key btw.

I was using the current iesdp description of the format. I guess it was copied over from bg2 as a starting point. iesh didn't have it either, so I added it yesterday just for this investigation. Thanks for the verification!

The recent discussion with Endurium and digging through the archives made me wonder how HoF is persisted. It's enabled by an ini option, but once a game is started, it is HoF forever, so the information must be saved somewhere. It'd be natural to have it in the saved GAM, so I started a new iwd2 game and saved, then enabled HoF and did the same. iediff showed these differences, but only one stood out — I suspect HoF mode is toggled by what is "Saved locations offset" at 0x6c of the GAM header in IESDP (and that it just didn't have it): I haven't tried to verify this though. I guess the easiest way would be to set it back to 0, move to a new master area and see if the enemies are beefed up or not.

First, I made a mistake up there: nightmare mode is HoF mode (toggled in config.exe, saved to ini). I was hoping it would just swap out the creatures, either all being in the area already or doing it when looking them up. But for eg. 10gobd, there are no such beefed up versions shipped. Your confirmation here helps again, thanks. CheckAreaDiffLevel is interesting. It's used for either harsher AI or scaled up scripted spawning, so it'd be odd if it had a static outcome (something for an iwd2 unfinished business mod). The fact that the same area scripts check for all three levels shows that the level was set by the engine. Did you read this thread? It says it's unreliable, but based on party level:

I can confirm much of this — I was looking into it in 2013 apparently and we haven't changed our implementation since. I would not call those first fields level overrides though; or do you have some result that they actually change the levels of creatures? Currently we just treat them as an oddly saved bitfield for matching against the actor difficulty margin at 0x2f. Seems to have worked quite fine — before, of course, all actors were there, so there were many too many, especially visible in the early orc maps. What we don't do is look at the game difficulty at all yet. I thought perhaps the levels had something to do with nightmare and HoF mode, but good to know that it's actually for the normal range. I also wonder why they used so many fields, when one in the actor structure would suffice.

The default is 16, though.

yeh, g3 never fixed the broken redirects. Updated, thanks.

These are basic bitwise operations, nothing specific to weidu, so look that up.

I'd play the original first for sure.

It supports much higher numbers, so it's more likely you're doing it wrong or weidu has a bug. Infinite supply is a separate stored toggle.

You already opened an issue for this. The PR draft looks fine, just please change tabs to spaces, so it's consistent with the rest of the file.

It's a tweak mod, so almost anything can go there. I've asked CreevsDak to merge the old ones, so it's easier to install and extend. If you know weidu, a new component is welcome. Just those 2s need to be changed to 1s and it's done.

you set the default to off, that's how. gemrb.ini is still a prominent place, especially since it means gemrb-tweakpack can then do the modifying for you.

Nah, it would break pst. That's more something for gemrb.ini.

I think so, pst would be hard to play otherwise.

khelban12, is that all for IA or are there any vanilla fixes in between? btw, the walking speed stuff is tracked here: https://github.com/gemrb/gemrb/issues/129 (waiting for kmfrick to finish the pathfinder upgrade) Gwendolyne: space is for foot circle size and searchmap blocking — so mostly visible as the circle size. palette of 1 skips the special handling used for two-character suffixes (like with the bears) and only checks if a global color mod is needed size of 0 skips equipment animations for all; where set it's for getting the same thing; only two animation types use it We want to move to pst-style system eventually, since there are many exceptions all over the place and this is one of the most annoying pieces of code we have. I can't imagine how horrible the original must've looked with all the hardcoded logic for this. Partly we managed to extract it (that's how dltcep got this feature), but it's a lot of custom work and testing on top. All the games share the same types, so some may not have interesting representatives in bg2. There are many animations that look identical to a clean type and then it doesn't have the casting stance, missing some orientations or some other crap. Like yetis vs winter wolves (ca). We're a bit fragile in that regard, so bad animations usually don't get drawn and so they're easy to spot. So if some creatures and their animation types don't make sense to you, please make a list — you know the animations much better and it could be worthwhile for us to double check them. 5 we would call clown-colored, for obvious reasons, but the type names are generally pretty boring: https://github.com/gemrb/gemrb/blob/master/gemrb/core/CharAnimations.h#L68

no, you need to fix the first problem, namely KitName being wrong already when creating a character.

Ok, so it's the same problem and it's just gnomes. Must be the original limit of specialist mages to illusionists for them ... somehow leaking.

1. Race has nothing to do with it, so that sounds fishy. Try adding some debug prints to gemrb/GUIScripts/bg2/GUICG3.py, before if AlignmentOk.GetValue: print 111111, i, KitName, CommonTables.Aligns.GetValue (i, 4), AlignmentOk.GetValue (KitName, CommonTables.Aligns.GetValue (i, 4)) 2. I don't remember such problems with my monks, but file a bug, at least it is easy to reproduce.

Yes, exactly.

Yeah, we don't care about the exe mods. Any relevant changes can be coded properly, if needed. Most of the patching, I imagine, is for the iwd/pst animation types, which we don't need at all. So yeah, after all the changes in question, things should work out of the box. If they don't, we just need to fix them (like if you introduce a yet non-existent animation type, let's say out of 16 stitched bams). I'm sure our players will let us know. BTW the fact that nobody knows what the 1PP deva glow patch is annoying, since they're still broken for us, even in vanilla: https://github.com/gemrb/gemrb/issues/134

Great! It's a bit trickier, since the place of insertion in the table matters — it's sorted by animation ID: https://github.com/gemrb/gemrb/blob/master/gemrb/unhardcoded/bg2/avatars.2da AT1-AT4 are the various armor levels, TYPE is animation type (you can't know this), SPACE is the foot circle size, PALETTE is for clowncolored/specials, SIZE I forgot (maybe for equipment placement on the paperdoll). @zelazko, @Caillean and maybe @khelban12can hook you up with the rows to be added. They have to be inserted in the right spots, since animation ids have ranges with shared properties. But INSERT_2DA_ROW can insert anywhere, so it's mostly a chore. The next weidu version* will have "ENGINE_IS gemrb", but since the file name is unique, maybe that's not needed. Since I guess the IA release will come sooner than the weidu one, you can test for avatars.2da existing (you can't know the path, so maybe through a test with COPY_EXISTING). If it is, you know you have recent enough weidu and gemrb and can do the patching. Otherwise just do nothing. But I'm sure you know much more weidu than me, so perhaps there are better ways ... * gory details here, but as a mod author you don't need to care about this, it will be magic: https://github.com/WeiDUorg/weidu/issues/153

parameter2? https://gibberlings3.github.io/iesdp/opcodes/bg2tob.htm#op12

Oh, it's still in active development? Then it could patch our table as well. Who is the maintainer now?