IP lock, my bad (in my native language it is the other way around).
Intellectual Property lock. ARM, x86(intel), x86_64(amd) have such extremely strong locks in countries where those are legal to be enforced.
It is said they literaly deny anybody else to use their ISAs unless there is a super strong power struggle and/or a giga-enormous amount of $$$ in the bargain.
it's not an emulator -- it's a (very realistic) re-implementation of the desktop using standard JS and CSS. Flash is run through Ruffle. Edge opens pages using native iframes.
Essentially the browser split comes from the usual browser split: discrepancies in JS and CSS implementations
This means the developer hasn't tested it on Firefox. Platform compatibility is way better than it used to be but you still occasionally get differences in supported APIs or interpretation of the standard.
One of the biggest factors for any flight simulation add-on is performance, and so most of the major add-on developers are building C++ modules (compiled to WASM) to eek out as much performance as possible. My understanding is that it's also possible to write some things in JavaScript (and perhaps TypeScript), but performance takes a hit. I would assume Lua falls into that same performance trap, as I know Lua can be used for X-Plane add-on development, but it's (again) considered the less performance-centric approach as compared to C++.
I recall at least one add-on developer for X-Plane (Zibo [1]) migrating some of their Lua code over to C++.
DLSS also blurs the cockpit displays quite badly when there's anything moving on them (airspeed/altitude tape, etc.). It looks like temporal blur, which is interesting because the same blur doesn't happen with their TAA (*temporal* anti-aliasing) implementation.
Yeah, DLSS looks great outside the window and for people enjoying GA and VFR it's all good. For airliners with digital displays it is harder to use, as like you said it blurs. They did talk about using some form of stencil/exclusion around cockpit displays but I think that didn't go anywhere as yet.
As a team they have a pretty tough job because the audience is all of the place for a title like that, as in people with 'I can see my house!' being made happy vs 'My pressurization gauge cross-bleed reading is below the Boeing B738 manual official figure, unplayable'.
I wonder if they made the same silly mistake I did and just used the 'runtime/engine name' as title of their crash report window. E.g. all games that were based on the Nebula3 engine displayed smth like "Nebula3 Assertion" in the popup window which is opened when an assert is hit or on a general crash.
It didn't take long after release that every crash in the game was because of that damn "Nebula3 Engine!?!!1", even though almost none of those crashes happened down in the engine code, but somewhere up in the game logic :)
In any case, opening up a game for modding means the game needs to be prepared for a flood of poorly written and optimized mods, no matter whether the mods are scripted via a scripting language like Lua, compiled to WASM or native code. At least (unlike directly loading native DLLs), WASM gives you all the tools to catch errors without crashing the entire game process. The tricky part is to design the plugin runtime system in a way that such errors are easily recoverable without having to restart the whole flight-sim session.
As far as I've seen, it's generally just the WASM modules that crash, and not a full sim crash to desktop (CTD). But considering the WASM modules are usually running all of the aircraft logic, systems, flight control computers, etc. then it tends to mean a complete flight loss since you can't... well... control the aircraft anymore. I'm not sure what kind of automatic restart logic exists for crashed WASM modules, if anything. It would be interesting to see if module crash recovery is possible.
