But why?! Can you test with the reclaim behaviour I bundled? That should act as a reliable test case of wether reclaiming works or not

Default one has a bug that goes away by replacing:


but even after that it does nothing but Echo that its updating(which i put there to see if the script is called at all).

To test it I do this:



In ym last tests when I released RC2, reclaim orders were given, but they had an area command at the correct location of size zero.

Well even if i make it a small area command around the target feature i can see the correct order when selecting the unit in observer mode, the problem is the unit is just not doing anything.

Does it have a radius? If so, this is most troubling, it may be in the C++ API, or I may not be using the API correctly hmmm I'm not sure

It has a dotted line connecting it, a radius but does not move at all (in some rare cases a nonsensical movement towards the spot it was built and back and then stops).


Notsoballsey does work just fine tough.

NotSoBallsey issues reclaim commands? Or do you mean you don't get your cryptic error regarding Internal() ?

Notsoballsey reclaims as intended, the new version broke it somehow.

I'm in the process of rebuilding Shard for 0.83, Abma and Hoijui have helped me fix some issues I had, now I just need VS10 builds of certain libraries e.g. Boost

it is 83.0, not 0.83

One moment while I grieve for Mr. 0's demotion from major to minor magnitude

I'm currently facing rather irksome problems trying to compile Shard under Visual Studio

It seems that when I say #include "lua.h" I now have:

• The lua.h bundled with spring
• the lua.h bundled with Shard
• The lua.h in the C++ Wrappers

i think i fixed the second thing, but i need more context for the first one.
best... give whole log.
there is no lua.h in the C++ wrapper, and i guess youd rather use your own (Shards), and not the engine one. maybe you can do it right, by defining the right include dirs.

No no, the Lua.h in the wrappers isn't the lua.h in the lua VM, it implements the springai::Lua wrapper class I'll check when I'm back home

ahhh right :/ stupid, stupid windows!
well...
i guess the solution is, to make sure you include the wrappersources with a prefix path, as in, instead of Lua.h, you include Wrapper/Cpp/Lua.h. of course the spring cmake scripts wolld have to generate that prefix path...
will also have to look into this later, when i am back home. hit me if i seem to have forgotten.

Is there a version of shard that works with Engine version 83?

No, if there was I'd have released it.

Currently the AI interface is incompatible with VS2010 and refuses to compile. V84 of spring brings fixes that should fix the majority of the problems, but this does not fix all the issues, and Shard still fails to compile under VS2010.

The last progress I'm aware of was Hoijuis fix for the stdbool.h issue, which exposed a further issue regarding const correctness and undefined values.

Well, there is the version that works for 0.83 for OS X. Of course, who knows what version it is. All the AIInfo calls it is "dev".

That'll be git master, which is included when you try to build Spring from git master. Seems the OS X build bundled shard in too although I don't mind that as I can't build it for OS X myself anyway. Shard should build on OSX and linux. Its Visual Studio 2010 & Windows I'm having trouble with.

Got a dll courteousness of buildbot and hoijui pointing me to it, but all it does is spam this:
[f=0000000] <SkirmishAI: Shard 3.0-Easy (team 0)>: added UnitHandler module

Enough to the point that in 30 seconds, infolog ended up having 37k + lines.