Skip to content

Working with and developing SEToolbox

midspace edited this page Oct 8, 2018 · 15 revisions

Developer/Build Requirements

I haven't started using NuGet for these things, but it is a consideration.

To develop this code, the following must be installed.

  • Space Engineers Game
  • 7Zip - used in Build script on Setup project, to generate a .Zip of all release files without an .MSI.

There are two options. Visual Studio 2015 or 2017. The options for Visual Studio 2017 are not 100% confirmed, as they have not been tested with a clean PC.

Resources

These don't need to be installed (But we need to be aware of any updates. Best to "Follow" the projects on GitHub to check for any new releases):

  • HelixToolkit (for opening 3D mesh files, and displaying).
  • All other references are nuget packages, and require your visual studio to download before compiling.

Local references

When references the Keen assemblies from your installation of Space Engineers:

  1. Copy Main\SEToolbox\global.targets to Main\SEToolbox\user.targets.
  2. Open the user.targets file.
  3. Modify the MainPath to indicate the path to SpaceEngineers in the Steam directory on your computer.
  4. Make sure to close and re-open the solution in Visual Studio as it does not refresh automatically when a linked .targets file is updated.

Independent development

Some projects are signed with a strong name key file.

The is no need to remove or turn off the signing on the "SEToolbox.ImageShaders" and "SEToolbox.ImageLibrary" projects as they are not currently password protected.

Debugging

Unable to view or inspect any of the MyObjectBuilder objects from the Space Engineers assemblies?

Because of how the assemblies are loaded, sometimes Visual Studio does not allow you to inspect the MyObjectBuilder objects. To force it, there are a few lines in the CoreToolbox.cs. They are approximately at line 159, and have the string "//#warning Force the local debugger to load the Types allowing inspection." Uncomment those lines, and these will allow you to code inspect the SE Types.

Cutting a Release

Generally the release goes a lot like this. Testing the changes:

  1. Keen release their major update.
  2. I read the change log (which doesn't always include all changes) and watch the video.
  3. There may be posts on the forum regarding issues launching or running SEToolbox already. (A very good indication of what might need fixing).
  4. Allow Steam to download the Space Engineers update.
  5. Make sure you have the latest source on SEToolbox. Set the configuration as "Debug", and make sure all tests pass. If there are major changes to Space Engineers, the tests will fail.
  6. With multiple people working, this would be time to create any issues on GitHub, and label it properly. Update to SE Release 01.034.007 or Breaking changes in SE 01.034.007 or similar.
  7. Clean your solution, then Compile and check for issues.
  8. Fix any bugs caused by the update. Test any parts of the application that may be affected. The usual trouble areas are, the drag-drop stops working between two running Toolboxes, the Component List may not show up, browsing for existing save games does not work.
  9. Run all tests, and make sure they pass.
  10. Run the T4 template in "SEToolbox\Interop\SubtypeId.tt". The resultant output (when comparing to the previous version) will indicate any new cubes (somewhat exciting).
  11. Updated the version information in "SEToolbox\Properties\AssemblyInfo.cs" and "SEToolboxSetup\Product.wxs". They should match. The number is described in the AssemblyInfo, but I'll repeat it here. The first 3 numbers to match the current Space Engineers release. The Forth number to indicate my own build of SEToolbox to match that release. Always check the current version by running Space Engineers.
  12. Switch the configuration to "Release". Run the tests again.

Building for Release:

  1. Open Windows Explorer and browse to the directory holding your SEToolbox source. In the root directory where the "readme.txt" is a "build.bat". Simply run the build.bat.
  2. The build should run without any issues (red lines of text). If there are red lines, you will need to investigate if it is either a code problem, or a build problem and solve as appropriate.
  3. Rarely there may be an issue from the LIGHT.EXE which is part of the wix compiler for the .msi package. If this occurs, simply try again.
  4. A successful build will appear in the "bin" folder that will automatically be created. One .msi and one .zip file.
  5. Install the .msi.
  6. Test the installation, and run SEToolbox from the Start menu to make sure it works.
  7. Extract .zip, and make sure it works also.
  8. If everything is good, check in the changes to GitHub.

Releasing:

  1. Go to SEToolbox downloads, and click Draft a new release.
  2. Add the tag version v#.###.###.#. Name the release title SEToolbox ##.###.### Release #, where # is the version numbers. These numbers are picked up in SEToolbox when it checks for updates by using Regex, so the format has to match (4 numbers in that arrangement, but not expressly that number of digits).
  3. When typing up the release notes, it helps to look through any code changes since the last release.
  4. Drag and drop the .msi file .zip file into the attach binaries by dropping them here. You may have to wait a short period as it uploads.
  5. Now hit "Publish".
  6. Go to the Keen thread for SEToolbox.
  7. Post an update to the thread. Add any discussion and photos you think are necessary.

Release stats

There is an github API for release stats (number of downloads), but you need to make a webpage. There are a few external sites that have created them already, so you check out our release stats here:

https://www.somsubhra.com/github-release-stats/?username=midspace&repository=SEToolbox

https://tooomm.github.io/github-release-stats/?username=midspace&repository=SEToolbox

Keen Software House releases

Living in Australia, Keen usually do their release around 2~5AM Friday my time.

Not helpful at all, as I get up and go to work, and can't look at any issues until I get home, unless I sneak in a bit of time at work to look at any compile issues. Fixing any content that requires me to open and play the game so that has to wait until I get home.