Anyways back to the VFS. I know some of you would like it, because then you can package the AI files you need in your game and be on your way distributing just the one file.

On the surface this sounds nice but there are horrible logistics problems, you're giving yourself a convenience to save you the hassle of a small step, and then ignoring the huge problems it creates:

• A new Shard release is made, and all older Shard releases require older versions of the engine. Suddenly your game no longer works.
• The maintainer leaves, and one can no longer update the files. Imagine if EE had Shard configs in it and they needed updating? Fang expressly forbids anybody from making updates, even if it's just fixing errors. That's a mark on my reputation and a support nightmare.
• The newer version is unpopular and people play the older version
• A content dev violates rules meaning the AI has subpar performance and is incompatible with other games, e.g. a map based Shard behaviour that breaks another behaviour present in a game.
• It balks up my own release cycle. If I need to make an important refactor, I can't as I have to coordinate and synchronise all these disparate projects
• If your game is an sdz on it's own, then you're not distributing a game, you're distributing an alpha, a work in progress, or a map.

Historically, a broken AI in a game archive is not seen as justification for a new release, no matter how minor.


How you should be doing it

• Use my releases and make sure you have code in a place I can always get the latest, and prod me when you update things.
• Distribute Shard yourself under a new name e.g. "Anarchid Shard". I don't mind so long as you make it clear it's a specialisation of standard Shard.
• Bundle Shard as I provide it in an installer

http://pastebin.com/XUbmFuby

http://www.imagebam.com/image/12e76b171793985

After clicking retry, I got a dialog that said spring has crashed, breakpoint.

This is after GetResourceByName change using: http://www.darkstars.co.uk/downloads/vi ... 0.35RC2.7z

Out of date Shard is out of date, use this:

viewtopic.php?p=511903#p511903

In Taskquebehaviour(ProgressQueue) i did a slight reordering of the if's and a rename(val -> value) to allow processing of tables returned by functions (led to error otherwise).

Shard stopped playing again in Spring 88.

I'm investigating buildbot builds again with the intention of letting Shard be bundled with spring, I'll have a VS build ready soon

Here is a rebuilt shard dll file, grab the latest shard release and drop this dll in as a replacement.

Of note, this version has an experimental method on the unit object



I provide it with no instructions or guarantees at this time though feedback is welcome

Dropped the .dll in both rc1 and rc2 folder.
It loads correctly, but only the default modules not my mod specific ones(yes i put them in) and doesn't do anything.

Odd I've made no changes to the file loading code in a very long time

This build makes some minor modifications to headers ( #pagma once swapped for gcc friendly defs ), but importantly, it prints out the lua PATH variable to the console showing where Shards lua vm will look for files

maybe because of my change? but that was some time ago...

https://github.com/Tarendai/Shard/commi ... 98ee1ee177

Ah see that doesn't make a lot of sense, I'm guessing you assumed Shard read from the VFS?

This code would make Shard fail if:

• The file was in the games/maps archive
• The file was in the root directory of spring
• The file was in a folder that the skirmish AI was not present in

When developing Shard there was ( and still is ) zero documentation for how to access and read files frm the virtual file system spring provides via the API. So I made the assumption that the Shard install would be self contained, and reside in a single folder, until such a time that I could implement VFS support (which never occurred).

So if your DLL/SO is in one place, and your lua files are:

• In a valid spring data dir that is not a child of the folder Shards library file resides in
• In an sdz/sdd/sd7
• Created on the fly and inserted into the VFS by a gadget

Then that code will fail and the default will be loaded.


Again for reference: Shard does not use the VFS or and does not scan spring data dirs

Also I've added a crude check to the code that will warn if it finds that the lua lib built into Shard is not the one that I provided.

better solutions are welcome to fix issue 6 in a cleaner way.



wrong, it scans data dirs since the pointed out commit. without that, it wouldn't work on debian/ubuntu and maybe other linux distributions.

see also locatePath() from the ai interface callback.

just as note: i couldn't test my commit on windows, because of the endless loop in the lua code and i have no visual studio. (but i expected it to work, because it already loaded some lua files...)

@erik:
it expects that the files are in an ai/ subfolder, maybe thats the problem here. also a logfile would be really helpful... afaik it prints errors if a lua file can't be found.

or better: a full example how to reproduce the error/problem.

The newer build I posted prints out the full path variable for where shards lua searches for stuff

Abma, can you tell what code is executing when it goes into the infinite loop or do you not have the debugging tools to try that?

Also what happens if the VFS contains the right file, but that file is inside an archive, an sdd, or in a data dir that is not passed by the locate path function? E.g. if I have 2 data dirs, A and B, and both contain an AI folder, and I get the data dir for folder A inserted, but there is a file shard wants in folder B?

What's needed is either full VFS read access, or a full list of the data dirs placed into the lua path variable, however I do not know how I would do that.

edit: This may work but you would need to copy Shard and hardcode it, at which point why not just drop the custom versions over the top of the defaults?



When I've thought it through I'll have a solution that doesn't involve reliance on the lua paths variable at all

the infinite loop is inside lua... debugging it will only return some internal lua functions, i already did some time ago but i was ignored :-/



i'm not sure, but afaik it checks first A if the file exists there, if not, it checks B...



imo a bad solution, require should search the correct file/path itself. i used LocatePath because all others AI seemed to use that, too. AAI and E323 for example have data files, too...

maybe adding all data dirs as include paths is the cleaner way, see http://www.lua.org/pil/8.1.html but this way files from VFS can't be read.

I don't know how I'd get it to read VFS files anyway, and I agree it's not a nice solution hence why I didn't add it to github. I've another system in mind that doesn't rely on the semantics of the lua path variables at all, but it needs implementing and I haven't gotten around to it.

Also I didn't have any way of interpreting the lua internals stack trace, I don't know the internal functions well enough, so it wasn't of much use.

Engine could create the `lua_State* L` for you and fill it with engine default VFS functions. (or the other way around: AI passes engine a lua_State* and it fills it)

hmm I didn't think that would survive the trek across the ABI properly intact, and I'm guessing it would help with communicating with gadgets

[4:35:48 PM] <MelBot> <GitHub197> [spring/develop] add Shard to the win32 installer (thanks AF!) - abma