Closed RomanHargrave closed 7 years ago
I'd hold off on making it compatible with the beta right now, as i'd rather it be vanilla on the beta, as much as I like WolfHUD. That and the fact that the Linux beta simply doesn't work.
But yeah, let's see if BLT4L can once again be more up-to-date than the regular BLT, even if it is for a short period of time.
That and the fact that the Linux beta simply doesn't work.
Well, we don't even have a beta executable for linux right now...
Yeah. GG Overkill.
Well, you'll be pleased to hear that blt4linux works on the latest beta update...somehow.
Not entirely surprising. They apparently still don't strip symbols for the Linux binary. Since LuaJIT uses the same api most of our hooks should have continued working.
The issue would come in if Overkill's custom newstate changed, or if we need to hook additional APIs that are now being called.
"They apparently still don't strip symbols for the Linux binary." Is that a good thing or bad? or is it classic Overkill laziness.
Is that a good thing or bad?
It's a great thing.
In a modern operating system, symbols are information that allow the OS runtime to "patch" function calls to a library instead of including the function body in the program. In short, this allows applications to use libraries.
This means that developing BLT4L is a lot simpler than BLT4W because we don't have to find the necessary function definitions by knowing what portion of a routine looks like ahead of time, we can just ask the linker to tell us where it put the routine with a given name.
Okay, gotcha. So we have, for no better use of any other term "accidental compatibility" with the new LuaJIT backend?
According to Overkill, the underlying Lua runtime has changed to LuaJIT.