Author Topic: Repository structure for Outpost2Dll, OP2Helper, & sample scenarios  (Read 137 times)

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 723
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

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2019
    • LairWorks Entertainment
Re: Repository structure for Outpost2Dll, OP2Helper, & sample scenarios
« Reply #1 on: October 09, 2018, 07:22:34 AM »
What about setting up a CI solution that checks all of that whenever you make a change?
- Leeor
LairWorks Entertainment

Titanum UFO's

Offline Angellus Mortis

  • Full Member
  • ***
  • Posts: 146
Re: Repository structure for Outpost2Dll, OP2Helper, & sample scenarios
« Reply #2 on: October 09, 2018, 05:08:40 PM »
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.
« Last Edit: October 09, 2018, 08:38:44 PM by Angellus Mortis »

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4530
Re: Repository structure for Outpost2Dll, OP2Helper, & sample scenarios
« Reply #3 on: October 10, 2018, 12:58:37 AM »
Ahh yes, the practical problems that crop up when people actually try to use stuff. :P

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.

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 723
Re: Repository structure for Outpost2Dll, OP2Helper, & sample scenarios
« Reply #4 on: October 10, 2018, 06:02:04 PM »
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

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4530
Re: Repository structure for Outpost2Dll, OP2Helper, & sample scenarios
« Reply #5 on: October 12, 2018, 01:08:09 PM »
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.