Engine changes (LuaJIT)

So I've been experimenting with the engine a lot recently. Not just the engine, but developing for it too (Unit Level Ups). I've come to realise two things:

1. Lua is quite slow. This hasn't really been a problem for Zero-K outside of 32-player lobfeasts, but for Unit Level Ups I'm starting to realise it's quite hard to make everything extendable, maintainable and performant. Often, one of those three is sacrificed.
2. Lua has a 1.6GB (or somewhere abouts) memory limit. Again, not a problem for Zero-K, but as more units, content and mods are added we're going to get quite close to the memory limit.
(CORRECTION: LuaJIT used to have a 1GB memory limit, but with the 64-bit GC it now does not. Lua's memory limit is 4GB I believe, I just got confused. But LuaJIT 2.1's GC can handle lots of memory a lot faster)

LuaJIT will fix both these issues: its 64-bit garbage collector is capable of handling much more memory, and it has a built in JIT compiler (which can be disabled if we encounter sync issues- its interpreter is also much faster than Lua 5.1's)

That's why I've started a LuaJIT fork: https://github.com/pts1667/spring

I've made some progress, but it still doesn't compile on Windows (native nor cross-compile) due to (a) LuaJIT not supporting cross-compile to a 64-bit Windows target yet (I don't think you can link PE objects in MinGW) and (b) Spring build system not supporting MSVC. This will take significant work so if anyone wants to help please PM me.

Don't expect anything yet, though. Currently with the basic testing I have done I think it works. No idea if it syncs. Make sure to configure with -DNO_CREG=TRUE

I'll try to do a build on Linux when I have time. If jit code writes anything synced, we should expect desyncs however.
I don't own any up-to-date MS compiler so no win testing here.

Good news!
There is now a Windows (untested) and Linux release of the LuaJIT fork, so you can test it for yourself:

https://github.com/pts1667/spring/releases/tag/105.1.0

To test on linux with Zero-K:
1. extract and run the executable (just 'spring' in the bin folder) once to init folders. Doesn't matter where you put it
2. copy <ZERO-K INSTALL FOLDER>/games/zk-stable.sdd to ~/.spring/games/ (if folder doesn't exist make it)
3. copy some maps from <ZERO-K INSTALL FOLDER>/maps to ~/.spring/maps/
4. rest should be self explanatory

To test on windows with Zero-K, just repeat the above but place in My Games/Spring/games and My Games/Spring/maps (I think...)

GoogleFrog when I try to use the lobby it seems to crash Lua-side (as in it defaults to the basecontent UI), something about 'customkeys' which is something changed in 105. Also I get C# errors.

I just assumed it was the lobby since the engine used is 104 and every version up represents non-BC API changes. Launching it standalone seems to work fine.

I've updated the release, but only on Linux due to my MXE environment messing up or something. This one actually turns on the JIT... which I embarrassingly forgot to do (it relied on the interpreter beforehand, which is still very fast). It now works with the lobby as well, or at least it should.

Again it's here: https://github.com/pts1667/spring/releases/tag/105.1.0

To use it with the lobby (Linux):
'cd' to the Zero-K folder
type 'mkdir engines/105 && wget -qO- https://github.com/pts1667/spring/releases/download/105.1.0/spring-build-maintainence.tar.xz | tar xvz - && cp -a ./spring-build-maintainence/. engines/105/ && rm -rf ./spring-build-maintainence'
this will download and extract the engine ver.

type 'cd engines/105 && cp -a bin/. ./ && cp -a lib/. ./ && cp -a share/games/spring/. ./ && touch done.txt && cd ../../'

this will set up the folders

type 'Zero-K_linux64.sh rapid://zk:test 105', this will launch zk (could also use zk:stable instead) on the engine ver you just downloaded

(note I haven't actually tested these commands yet, but this is "generally" how I set it up)

To use it with lobby (Windows):
idk