load lua code from game archive

[abma]

for tomjn#102 to work nicely it should be pulled from the game archive:

i.e. the game archive has a folder "Shard" which contains all the lua files.

[abma]

CircuitAI seems to have this functionality (partly at least):
https://github.com/rlcevg/CircuitAI/blob/2d3274e198152d0f0e916dec697a07e67292f521/src/circuit/setup/SetupManager.cpp#L544

https://github.com/rlcevg/CircuitAI/blob/2d3274e198152d0f0e916dec697a07e67292f521/src/circuit/setup/SetupManager.cpp#L633

[tomjn]

This won't happen:

• loading from the VFS is not something the wrappers implemented, and I haven't the time or interest to build those wrappers and maintain them myself
• It suddenly becomes very tempting to reference gadget code, leading to a support burden for "why doesn't this Spring API work?!"
• Game devs interested in Shard already have a way to bundle their game code inside the archive, by running Shard as a LuaAI. This has been done with great success by EvoRTS
• Updates to Shards APIs would break older games with older versions of code to run with Shard, requiring forks to preserve older game play but update Shard code, breaking replays in the process. Not an issue if the games contain their own copy of Shard
• In all honesty, any dev work I do with Shard these days is done as a LuaAI, if it was up to me I'd either kill the C++ component or work on adding Starcraft support. It'd be great instead to allow LuaAIs to load native modules through a simpler more generic API where a bulk of info is passed and a response can be gotten asynchronously. This way I can do things like pass a heightmap and passibility map to a module and have it figure out voronoi and convex hulls with standard libraries

I can see the allure of this feature, but it's really a can of worms waiting to be opened, and anybody wanting to work with Shard should be doing it as a LuaAI