Separate C++ and Lua into 2 repositories

[tomjn]

Currently this repo contains a native C++ AI, and the lua component. This won't work going forward with gadget AIs as it means duplication.

So I'd like to separate out the lua AI portion and have it as a submodule, so that it has 1 canonical source, rather than a native AI, and a gadget AI copy that need constant merging

@abma what needs doing at the Spring engine side of things to ensure this continues to work? There are reports that the EvoRTS submodule is working but not the BA/BAR submodules, I imagine changes will be needed for that too? What do you recommend?

[tomjn]

/cc @eronoobos

[abma]

what needs doing at the Spring engine side of things to ensure this continues to work?

a stable spring release should be done before changes at the infrastructure delay a release.

• documentation needs to be updated (wiki, ...)
• travis / buildbot scripts needs be fixed
• ...?

basicly not much: i still see me asking myself: why are these lua scripts submodules? wouldn't it be better to directly integrate them into the game and then make shard load it from the game?

[tomjn]

A lua gadget AI has bootstrapping code that the native AI doesn't have and
vice versa. Coupled with the fact the gadget AI isn't in a 100% state, and
that there are advantages and benefits to a native AI, separating out the
AI this way simplifies things and avoids a mess
On Tue, 21 Jun 2016 at 16:10, abma notifications@github.com wrote:

what needs doing at the Spring engine side of things to ensure this
continues to work?

a stable spring release should be done before changes at the
infrastructure delay a release.

• documentation needs to be updated (wiki, ...)
• travis / buildbot scripts needs be fixed
• ...?

basicly not much: i still see me asking myself: why are these lua scripts
submodules? wouldn't it be better to directly integrate them into the game
and then make shard load it from the game?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Tarendai/Shard/issues/102#issuecomment-227471235, or mute
the thread
https://github.com/notifications/unsubscribe/AADl55zpYP4Pnh4De4gP3DiefmQ67uaPks5qN_79gaJpZM4I6xY8
.

[abma]

How is the gadget AI then loaded/run? is there an (basicly) working example?

[eronoobos]

https://github.com/eronoobos/ShardSpringLua & https://github.com/eronoobos/Balanced-Annihilation-Shard-LuaAI

[abma]

when the ai is updated a commit has to be made to the game?

(this makes the diff VERY low to having it in the same repo)

[eronoobos]

I don't follow, but you made me realize that while https://github.com/eronoobos/ShardSpringLua/tree/master/luarules/gadgets/ai contains just the base Lua files, https://github.com/Tarendai/Shard/tree/master/data/ai contains the game configurations, too. Making those two directories one repository would still reduce my headache of manually copying from one to the other, but if a game repository on github wanted to use that repo as a submodule, they would have to make a pull request just to update their own config, even if that config was its own repository. That mess seems worse than the current mess.

I suppose, @tarendai, the directory structure could be changed to something like ai/base/ and ai/config/, if we changed shard_include? Not sure if that's a good idea or not

[abma]

I don't follow,

the game depends on a specific ai version: when the ai needs an update, the game has to be updated, right?

[abma]

in other words:

what needs to be done for the

1. ai dev
2. game dev
3. engine dev
4. player for

for updating the ai?

[eronoobos]

when the ai needs an update, the game has to be updated, right?

yes, of course. but that's true of any Lua AI

if we're talking about the C++ Skirmish AI, then it's the engine that needs to be updated

[tomjn]

For the moment the native C++ AI is the prime version of the AI, and the most fully featured. This may change in future, but we have a AI, written in lua, that works with an API, and 2 implementations of that API ( LuaAI and NativeC++Wrapper ).

Bundling the AI and the Native C++ wrapper is causing organisational and structural issues for the development of the Lua AI implementation ( where most of the future interest in the AI lies as far as the spring engine is concerned ). To maintain momentum I'm eager to proceed as soon as possible.

in other words:

what needs to be done for the

ai dev

Remove the AI from this repo and add a submodule to its new location

game dev

At the moment, nothing, that part hasn't been resolved, and isn't relevant to the engine build process or the Shard native C++ API implementation

engine dev

Adjustment of the build process to ensure that all submodules are pulled in during build process, or reassurance that this is already the case

player for

Nothing, the immediate result for them would be the same as before

for updating the ai?

Business as usual

Content devs who want to use the 100% lua implementation of Shard will have to work with a partial API until it's fully implemented, and will need to take the needed steps to set it up in their games, but this has no bearing on the engines build process. Including the necessary parts to make Shard work as a LuaAI inside this repository would mean additional manual steps, complicated processes, and a significantly higher barrier to entry and support burden. Currently the best version of Shard for gadget LuaAI is in a forked repo that could never be merged directly into this repository, duplicating efforts

[abma]

that doesn't answer my questions: what needs to be done to update (with submodules) in the future when the ai changes for the involved persons?

imo its a lot more work for several people in comparison to having it in one repo.