Repository structure for Outpost2Dll, OP2Helper, & sample scenarios

[Vagabond]

Angellus has been doing some interesting work in the Blank level template with comments source code on Github. https://github.com/OutpostUniverse/LevelTemplate-Blank-Comments

We identified there is a problem with using submodules right now on scenario development. Since both a new scenario and OP2Helper both depend on Outpost2DLL, you would have to add 2 modules of Outpost2DLL to a scenario to make it work.

I propose that we collapse Outpost2DLL, OP2Helper, HFL, and all 3 scenario templates into a single Git repository. Not sure what that repo should be named yet.

This basically steals some of Angellus' directory structure and slightly modifies it.

The directory structure would be:

 * Outpost2DLL
 * OP2Helper
 * HFL
 * HFL-IUnit
 * ScenarioTemplates
    * TemplateWithoutComments
    * TemplateWithComments
    * Hooville

Pros
 * When you want to create a new scenario, you simply add a single submodule to your scenario that contains all the helper projects and sample code you need.

 * Outpost2Dll, OP2Helper, HFL, and the scenario templates are all tied together in one repository. So you cannot download a specific version of OP2Helper and then grab a different version of Outpost2DLL. They would be tied to the same repository, and grabbing a previous version of the repository would keep all projects in sync to the previous version.

 * We probably should not be releasing new versions of any of these projects unless they remain synced together. IE if a version of Outpost2DLL does not work with OP2Helper, we should be making sure it works with the other projects mentioned here as they are critical to creating new scenarios. Currently to test, you would have to download an awful lot of repositories and hook things together manually.

 * This will reduce the repository count in Outpost Universe on Github. We are currently pushing quite a few, and if we start adding a bunch of individual scenarios, it is just going to grow.

Con

 * When you want to work on say op2ext, you are downloading and including all the scenario templates and OP2Helper that you don't need which clutters the directory structure some.

Curious what others think.

-Brett

[leeor_net]

What about setting up a CI solution that checks all of that whenever you make a change?

[Angellus Mortis]

What about setting up a CI solution that checks all of that whenever you make a change?

I support any solution that automates things.

I personally like them being separate repos. If we have multiple repos that need checked out, I would rather us automate the process then combining the repos back into a monolithic one. I can throw together a simple shell script you can run inside of Git Bash (on Windows, or just a Terminal/console on everything else) that automates the process.

EDIT: I just threw this together really quickly: https://github.com/OutpostUniverse/OP2-Workspace

I threw in the workspace file I had for VS Code, but we could add a Visual Studio solution file as well to auto open all of the projects as well.

EDITEDIT: So I might have just went and fully automated the whole set up. The install script from above can fully install Visual Studio 2017 Community Edition or Build Tools for Visual Studio for you on Windows. I have the non-Windows (Linux/Mac?) about half way done. I just have to configure the env vars and put them in your ~/.bash_profile.

[Hooman]

Ahh yes, the practical problems that crop up when people actually try to use stuff.

This is good though, I'm glad people are working on this problem.

I would propose keeping the levels separate from the API projects. I would not be terribly opposed to combining the API projects into a single repo:

Repo1:
  API/
    Outpost2DLL
    Outpost2App
    OP2Helper
    HFL
    HFL-IUnit
Repo2:
  LevelTemplate
Repo3:
  Hooville
...

Each level could go in its own repository, each one referencing the API repository as a submodule.

I think it's reasonable to have the API projects kept in sync with each other. I don't think it's so reasonable to try and keep all possible levels, released or unreleased, in sync with API changes. I think that's an area we need a version boundary.

[Vagabond]

Hooman,

What are you thinking for workflow when creating a new scenario? Would someone fork the blank template, then rename it? I've never tried this in GitHub, although I know you can rename repos...

Adding the APIs as a submodule to the scenario would typically place it in a subdirectory. So the repo would look like:

ScenarioRepo
 - APIS directory (submodule)
 - Scenario files

This seems fine to me.

Leeor, yes I think have CI setup would be a good idea. I haven't researched using Appveyor to build multiple projects  yet, so not sure of the feasibility.

-Brett

[Hooman]

Yes, fork and rename.

Or probably more likely, clone it locally, rename the folder, and go from there. They wouldn't need to fork on GitHub, or create a GitHub repository until they are ready to share.

Correct on the scenario repo layout.

[Vagabond]

I have been putting some work on a new scenario. I would like to put it on GitHub which means we will have to make some sort of decision.

I'd like to create a repo called Outpost2SDK. The purpose of the repo is to hold all the dependencies needed for creating a new scenario.

It seems like there were some questions about merging all the projects into one repository. As a compromise, it can include the following as submodules:
    Outpost2DLL
    Outpost2App
    OP2Helper
    HFL

I have never successfully used HFL-Iunit in my level designs so I would probably leave it out until someone else can hook it properly.

I need to bring in odasl.h and odasl.lib as well. Do we have any problem with these being on GitHub? You can see them at: Outpost2SVN\LevelsAndMods\trunk\API\Outpost2Dialog\odasl

I looked over Angellus' script for setting up a scenario. Maybe I'm being a bit of a baby, but I don't see myself using the command line client to script the process. Angellus, will this script add the full git repos for each of the library projects as submodules?

Thanks,
Brett

[Hooman]

That seems like a reasonable organization. Collect all the APIs into a single repo as submodules, which can then be included as a single submodule.

I'm not certain about the odasl project. Maybe speak to Arklon or BlackBox, as they are more familiar with it. Might also be good to speak to Leeor about copyright issues. He seems to be a little more versed on that topic. Another point of comparison, does that project differ from the Outpost2DLL project in any significant way?