Using GitHub for Outpost 2 mission development

[Vagabond]

I've been playing with GitHub for Outpost 2 mission generation.

https://github.com/OutpostUniverse/OP2MissionSDK

https://github.com/Brett208/OP2MissionYukonTrail

OP2MissionSDK is a container for the other required submodules. Currently, HFL and OP2Helper do not contain Outpost2DLL as submodules in themselves. So if you were to download either one, you would not be able to compile. If you download OP2MisisonSDK, the 3 projects exist in the same folder structure as they do on the SVN repository. So they will all compile fine.

This has pros and cons. The pro is that you don't have multiple copies of Outpost2DLL in the same solution (one for HFL, one for OP2Helper, and one for the custom mission itself). The con is that you cannot download OP2Helper standalone and compile it. I think another pro is that all projects will use the same version of Outpost2DLL. IE, you don't have to worry about HFL being on an earlier version of Outpost2DLL than OP2Helper (assuming we ever update Outpost2DLL again). If others want to use OP2MissionSDK to develop scenarios, we can discuss other architectures.

I was going to setup an automated build as part of OP2MissionSDK that built HFL, OP2Helper, and Outpost2DLL. Apparently you have to create a matrix or something with appveyor and I gave up for the time being. As an artifact of this research, Outpost2DLL has an automated build in OP2MissionSDK.

I also stuffed odasl into OP2MissionSDK, so you can create custom modal dialog boxes for custom colony games.

We may want to encourage a specific GitHub tag for Outpost 2 missions. Maybe outpost-2-mission? This would make finding missions easier in the event that someone develops a mission and doesn't want to cede control of it over to Outpost Universe.

I haven't pushed this scenario to Outpost Universe. Partly due to embarrassment. I generally right mildly substandard code. But in scenarios I write plain awful code because I treat it as a script hybrid and don't plan to reuse it. (Except I end up wholesale pasting sections from old scenarios for new scenarios).

[leeor_net]

This has pros and cons. The pro is that you don't have multiple copies of Outpost2DLL in the same solution (one for HFL, one for OP2Helper, and one for the custom mission itself). The con is that you cannot download OP2Helper standalone and compile it. I think another pro is that all projects will use the same version of Outpost2DLL. IE, you don't have to worry about HFL being on an earlier version of Outpost2DLL than OP2Helper (assuming we ever update Outpost2DLL again). If others want to use OP2MissionSDK to develop scenarios, we can discuss other architectures.

Sounds to me like the pros far outweigh the cons. This is the sort of thing I wanted to do in the past... it lead to an argument about directory structure and "This is how it's always been done" so I kinda left it alone. That was years ago though so either way I think this is exactly the direction we should be going in.

I was going to setup an automated build as part of OP2MissionSDK that built HFL, OP2Helper, and Outpost2DLL. Apparently you have to create a matrix or something with appveyor and I gave up for the time being. As an artifact of this research, Outpost2DLL has an automated build in OP2MissionSDK.

We may want to encourage a specific GitHub tag for Outpost 2 missions. Maybe outpost-2-mission? This would make finding missions easier in the event that someone develops a mission and doesn't want to cede control of it over to Outpost Universe.

Acceptable to me.

I haven't pushed this scenario to Outpost Universe. Partly due to embarrassment. I generally right mildly substandard code. But in scenarios I write plain awful code because I treat it as a script hybrid and don't plan to reuse it. (Except I end up wholesale pasting sections from old scenarios for new scenarios).

Mission code doesn't have to be beautiful, it doesn't even have to be good... really it just needs to work. I'd say push it so we can have a modern example of a working mission using the current code base. Changes/cleanup/grooming can be done after the fact.

Besides, I've written some real stinkers myself. Just take a look at the OPHD code base... there are parts of it that wish I hadn't done the way I did... but they work until they can be refactored. So don't feel bad... we're all human... and we write shitty code... with bugs!

[Hooman]

This actually looks like a good way to organize the projects. Rather than have a level include every library as a separate submodule, it can just include the SDK project, which wraps everything together, and with consistent version numbers. I rather like this solution.


I'm not too sure what the build matrix stuff is about. I don't think you actually need that for what you are doing. Generally a build matrix is used when you're compiling for multiple architectures, or have different configurations of the same project that you want to build in parallel. I don't think you need that here. All you need is dependencies to be specified so all projects are built together in the proper order (some of which may be in parallel, but they're different projects). In that case, they all build in a single job, rather than having a matrix of jobs.


Agreed that we could use a common tag. Hopefully something short and easy to remember. I'd prefer to avoid hyphens if possible. I would like a setup where people can design their own levels without needing to be a part of OPU. I'd like to preserve the self-serve nature of GitHub.

[leeor_net]

Agreed that we could use a common tag. Hopefully something short and easy to remember. I'd prefer to avoid hyphens if possible. I would like a setup where people can design their own levels without needing to be a part of OPU. I'd like to preserve the self-serve nature of GitHub.

Forking me thinks.

[Vagabond]

Glad to see the warm response for OP2MissionSDK in the forums.

Hooman and I updated the LevelTemplate repository to use OP2MissionSDK. Some minor improvements to Outpost2DLL have been percolating. Once these settle, I think we should look at repacking an easy to use template like Leeor did a few years ago. Not sure how much use that got, but worth updating I think...

The downside to our current submodule of submodule approach is that changes to a library take a lot of steps to complete. After merging the change in Outpost2DLL, we have to pull and update OP2MissionSDK's copy of Outpost2DLL. Then we have to update LevelTemplate's copy of OP2MissionSDK. I'm definitely feeling the extra admin required to work in it.

[Hooman]

I definitely understand what you mean about the extra admin work. Though when I stop and think about it, that does actually seem to be the correct way of managing things.

Glad to see updates being made to these projects, and getting a package up on GitHub that can basically be forked and used as a base for new levels, without a bunch of external configuration.

[leeor_net]

... Once these settle, I think we should look at repacking an easy to use template like Leeor did a few years ago. Not sure how much use that got, but worth updating I think...

As far as I know there was no use for it. There was very heavy resistance to what I tried from a former administrator. Though now that that's part of the past we can do whatever.

Definitely for Windows developers it would be awesome to be able to have a 'binary release' ready to download with project files set up and ready to go. Of course the end user would have to tweak directories for debug but we can make a wiki article out of it.

[Hooman]

You know what, GitHub should already provide a zip download option for the latest version of a project. It's tied in with the clone button, where you get the URL to clone from. Users can choose to either clone, and have a working local Git repository to work from, or download a clean zip to have just the project files.

Though maybe it would be more user friendly to new developers if they found a link from our site to download a zip file?

As for instructions, we could put a README.txt right in the project with instructions on how to get started, or links to resources for more advanced topics.

[leeor_net]

There's the Make a Release option which does that automatically -- compresses a tag and done. Can see it on the OPHD releases section, same deal.