critto

corretto works, oracle works, temurin fails (same error). Screens for system info output on the main NI screen for the first two are attached (in case it's useful, and my own as well). coretto: oracle: mine:

Sure, here it is: https://drive.google.com/file/d/1cYxsb-d3EifpYtF0iaHjZdIX5QhECIVH/view?usp=sharing There must be some difference in build environments. I'm doing mine on a M1 Max machine running Sonoma 14.1, with Java 21.0.1. Would be great if somebody else could test the two different builds and report the results.

This one crashes too, with the same error stack trace.

Hey argent77. So, the new release seems to be crashing on arm64: Application Specific Information: References to Carbon menus are disallowed with AppKit menu system (see rdar://101002625). Use instances of NSMenu and NSMenuItem directly instead. I can send you a whole stack-trace if you wish, but it looks like generic Apple crash report stuff. I did my own build locally, using the latest jar, and it runs fine.

Here's arm64 build of the version 2.4-20231231: https://drive.google.com/file/d/1P-8Y-yBmG3Mnqk_8Tcd7Vwugr6cYjX2l/view?usp=sharing

Great I'll subscribe to the repo on github, to try and stay up to date with the new releases.

OK, so l've managed to produce a packaged app that installs and runs well on my system. If someone wants to give this one a go, here's a temporary link: https://drive.google.com/file/d/1zqqK1maA3sRXICmAR5j5kUPD7PsYrGTh/view?usp=drive_link

What does the process entail, exactly?

I've started seeing a similar issue a few months ago after I'd updated to one of the newer packages. The app tries to open but fails silently. Running "open NearInfinity.app" fails silently. Then I've tried to run NearInfinity.app/Contents/MacOS/NearInfinity and got a java exception stack trace, failing to find libharfbuzz. So I installed and symlinked it into the expected location, and now I get the following exception: Exception in thread "main" java.lang.UnsatisfiedLinkError: /Applications/NearInfinity.app/Contents/runtime/Contents/Home/lib/libfontmanager.dylib: dlopen(/Applications/NearInfinity.app/Contents/runtime/Contents/Home/lib/libfontmanager.dylib, 0x0001): Library not loaded: /usr/local/opt/harfbuzz/lib/libharfbuzz.0.dylib Referenced from: <D7FA2D64-D161-374E-A9D5-C5A565497B9F> /Applications/NearInfinity.app/Contents/runtime/Contents/Home/lib/libfontmanager.dylib Reason: tried: '/usr/local/opt/harfbuzz/lib/libharfbuzz.0.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/harfbuzz/lib/libharfbuzz.0.dylib' (no such file), '/usr/local/opt/harfbuzz/lib/libharfbuzz.0.dylib' (no such file), '/usr/local/lib/libharfbuzz.0.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/usr/lib/libharfbuzz.0.dylib' (no such file, not in dyld cache) Looks like the end of the road to me. It seems that the current NearInfinity app was built for Intel architecture. Running the jar file directly, however, works perfectly well, so I do that instead as a workaround.

That's a neat trick, thanks.

Got it, thanks. One mystery less.

Did I understand correctly that this is an observed and proven behaviour? This explains why people some time report stuff like a portrait icon getting stuck on a character's portrait even if the character saved against the harmful effect. And then you sit and wonder, how did it ever happen.

Hello, everyone. So, I was investigating an observation that a player has made regarding the behaviour of the game (BG2: EE) when multiple copies of the same spell are put into a spell sequencer. For example, Flame Arrow has a damage effect that does half the damage on a successful saving throw. In my tests, I've seen the creature that has been struck with 3xFire Arrow from a sequencer make only one successful saving throw against the first spell (that was shown in the combat log) but get half the damage from all three instances, judging by the numbers. In another test, I've had a sequencer with 3x Polymorph Other hit a creature. Combat log would sometimes show only a single successful saving throw message, and sometimes two. If that happened, none of the spells would affect the creature. So, what is going on here, exactly? My current hypothesis is that the engine rolls a single saving throw during a particular time frame (a round?) and uses the rolled value against all spells that require this particular kind of ST. Any insight? Cheers

feature/v7 is the main branch. But I believe that @SparrowJacek wanted to take a look at it himself first (Jacek, correct me if I'm wrong). But thanks for the offer, if you do find the time to send a MR, we'd appreciate it. No, I'm still doing the primary maintenance and slowly working on v7 whenever I get a minute. But Jacek has been helping out a lot with various new changes to graphics and animations, as well as doing some of his own patches to the main branch and experimenting in separate branches, such as the recent v6.6-beta.

Hi folks. The other replies are correct, it's hardly compatible with anything. Small mods could probably get away with being installed on top of IA, but I'm pretty sure something would become broken or would not work as intended. It might just not be noticeable at first glance. Yeah, it was not tested extensively. People played with it numerous times, but didn't report anything gamebreaking. I guess they did not run into this particular bug. A bit more, actually, but you're not far from the truth Seems like there's an issue with the mail delivery, password recovery isn't the only thing that does not work. The animation thing was an experiment, compatibility wasn't the primary consideration at the moment, but there's no harm in fixing it, I guess. Thanks for pointing that out. As for the overwriting, yes, it's a legacy issue with the mod. Ever since the mod was ported to EE, all of the new changes were mostly done by patching things. Overwriting stuff is a legacy issue, as mentioned above, the one that I am not sure how to fix efficiently. There's too much stuff inside to convert everything by hand, and my attempts to automate the procedure didn't get past the early prototypes. Granted, I didn't try very hard, for there seemed to be little payoff for all the required effort.