lynx

You'll have to disable the ifdefs that give this compiler hint: __attribute__((aligned(4)))

git rebase -i HEAD~5 and then choose s for squash instead of p(ick)

Might be easiest to create a new branch, if you want to submit a PR. git checkout master git branch turnips git pull --squash . your-old-branch And then submit turnips.

For what you mentioned, the approach with area animations (even if they're just static images) is probably easier, since you don't have to redo the TIS. Harder from the artistic point of view though, since it would take more preparation of the sprites (one layer per each, more fuss when you don't want to just overlay).

Nothing, both approaches have always been available.

Of course, why would it be different? If you're adding it, not editing, you'll have to convert it to the BAM format before use (same tools apply).

It involves changing a few obtuse files (WED, TIS) or adding new area animations (and potentially changing the searchmap if you want to affect walkability). The latter is probably simpler and is definitely doable in DLTCEP, possibly also in the nicer NearInfinity.

Thanks, updated. It's true for older engines as well; it just doesn't all happen in the action itself, so perhaps that's why it was undocumented.

How about typedefing it as usual? std::basic_string<wchar_t>

Yep, that's fine. If the exit status is 0, it should pass.

I don't know anything about this system, but the retroarch approach looks good. If you want to add a test, you can run the minimal test. Here are two ways the bots do it: https://github.com/gemrb/gemrb/blob/master/.travis.yml#L49-L50 (right after build, from the build dir) https://github.com/gemrb/gemrb/blob/master/.appveyor.yml#L94-L100 (works also later)

Thanks to Luke, this is now on IESDP (as soon as the build finishes).

Cool. Have you submitted it upstream? keep-old in GLOBAL_WRITABLE_FILES is not really ideal, since then there won't be any updates. Eg. the next release brings two more config keys. Users should copy the sample configs before editing.

I don't know, you're the one on haiku. If there are no docs, I'd open an issue on their tracker.

Ideally it'd go in some central repo, so other haikuers could install it directly, but from what I see, Haiku only has some small 3rd party sites.

Why or how does make install fail?

With a non-crt screen this is indeed to be expected. With the next release at least the game window will resize though. In the meanwhile, if the build was made with sdl2, you can just resize the windowed mode window and it will linearly scale.

Nothing changed, hence there's no reason to repeat the same conversation yet again. Just leave it be.

Continuing the exploration for iwd1. Neither ielister or ieparse detects any save game difference besides the starting gold, but that was an expected possible outcome, since the iwd2 offset would put it in unknown territory. However, comparing the files manually confirms there's no other difference, so for iwd1, GAM is not affected. Loading a HoF save without nightmare mode on in the ini reverts it back to normal. Meaning the HoF state wasn't saved anywhere else in iwd1.

No. Like the name suggests, it's the list of instant actions (as opposed to blocking). Nothing special.

If you don't have sound, then you probably didn't build any of the two audio plugins. Probably didn't have the dependencies installed (openal or sdl_mixer).

Looking at its code, weidu doesn't care if totsc is installed. But widescreen might, since it needs exe offsets to know what to hack. That part is of course useless for gemrb, but the mod may insist. The next release will have inbuilt widescreen support, so the mod won't be needed any more. With the current release the best you can do is run in windowed mode and resize the window, but that will of course stretch things.

Sounds like you're trying to run a prebuilt binary for a different architecture. Unless there are builds out there for arm, you'll have to compile weidu yourself.

Heh, I thought this was something new in ees, so I didn't even bother checking our code. But it matches.

I imagine with long delays and interspersed blocking actions this is expected behaviour if it's just using game time to modulo against.