2026-04-18T00:02:41  <OpenMW-bridge> <cmaugust> Why is the hardcoded destination tolerance 64? Is it to give some wiggle room if 0 can't be reached?
2026-04-18T00:16:33  <OpenMW-bridge> <wareya> probably has something to do with the turning radius
2026-04-18T13:22:56  <OpenMW-bridge> <e1sid> Why specifically 64 I don't know, possibly something related to how it's in the vanilla engine. But there has to be some non zero value. Otherwise an actor may never reach destination going around. Actually it does not have to a constant, it may depend on the actor speed like the value we use for a path point tolerance. Basically the distance an actor can move by in a single frame + some gap:
2026-04-18T13:22:57  <OpenMW-bridge> https://gitlab.com/OpenMW/openmw/-/blob/fa0d59e52d130a037531db419cc8cbd67ac9e585/apps/openmw/mwmechanics/aipackage.cpp#L41 .
2026-04-18T13:24:38  <OpenMW-bridge> <e1sid> Do not rotate an actor in the frame when it reached the destination.
2026-04-18T15:08:34  <OpenMW-bridge> <exalted_sun> 😈 <- me thinking about opening an issue and figuring out how to Liquid Glass support ify the macOS icons
2026-04-18T15:39:55  <OpenMW-bridge> <exalted_sun> Oh sorry I mean work item 🙄
2026-04-18T16:21:28  <OpenMW-bridge> <daisyhasacat> Do it
2026-04-18T18:34:41  <OpenMW-bridge> <exalted_sun> Why does OPENMW_OSX_DEPLOYMENT exist? Wouldn't we just...know to build for apple if on apple? Why is there a distinct setting for this?
2026-04-18T18:35:05  <OpenMW-bridge> <exalted_sun> it doesn't seem like it should exist—we don't have such logic for windows/linux'
2026-04-18T18:39:01  <OpenMW-bridge> <qlonever> I don't think that's a good idea for PfP because she's able to wander just fine in Morrowind.exe
2026-04-18T18:40:01  <OpenMW-bridge> <qlonever> ask hrnchamd:todd:
2026-04-18T19:22:20  <OpenMW-bridge> <exalted_sun> unclear if possible since we are targetting before 26. 🤷 The info is pretty meager. ehehehe
2026-04-18T23:22:16  <OpenMW-bridge> <anyoldname3> I think it's just one of the inside-out-and-back-to-front Mac packaging things. Either it's entirely superfluous, or it's used to toggle between having the binaries runnable from the build directory versus requiring the DMG to be packaged because of one or more of the many things where packaging-time decisions get baked in at configure-time for no good reason.
2026-04-18T23:25:27  <OpenMW-bridge> <exalted_sun> I don’t see why we wouldn’t want the dmg always to be made when building. The apps are made and usable ish without the dmgs anyway
2026-04-18T23:25:58  <OpenMW-bridge> <exalted_sun> Like when you run the make package command the build dir has the apps in it and the dmg which of course has the apps in it too
2026-04-18T23:26:38  <OpenMW-bridge> <exalted_sun> Eventually I’ll make a MR to remove it and do other stuff, when I get back to my strange Liquid Glass journey  Does anyone have a non 26 Mac?
2026-04-18T23:29:03  <OpenMW-bridge> <exalted_sun> By usable ish I think since like the deps aren’t copied in you can’t like delete the dep folder without it blowing up or something IIRC. I may be misremembering this completely
2026-04-18T23:52:34  <OpenMW-bridge> <anyoldname3> For all other desktop platforms, you can just ./openmw straight after running the build command (although for Windows that's because before_script.msvc.sh copies the deps into place, which should really be CMake's job) and the same binaries are suitable for packaging, too. I think some of the paths the MacOS binaries look at end up baked in by CMake, potentially based on OPENMW_OSX_DEPLOYMENT, so the binaries for
2026-04-18T23:52:35  <OpenMW-bridge> local development aren't necessarily suitable for packaging and vice versa. At the minimum, it toggles CMAKE_INSTALL_RPATH_USE_LINK_PATH.