[Suggestion] Update mod example packageBuild.ts to include user/mods/ structure in archive #13

New Issue

DrakiaXYZ · 2023-09-01T15:17:41-04:00

DrakiaXYZ commented

2023-09-01 15:17:41 -04:00

This isn't technically an issue, more a request/suggestion for mod building.

Currently the packageBuild.ts script creates the zip file with the mod's named folder in the root, this makes figuring out where a mod goes when extracting a multi-step process for users (If it contains a DLL, it goes in X. If it contains a named mod folder, it goes in Y).

If the packageBuild.ts script instead built the zip with the full structure from the SPT root inside (user/mods/{modName}/...) then the install steps would be "Extract into your SPT folder".

There are a couple people in the Discord who have mentioned they may look at implementing a solution for this ticket :)

This isn't technically an issue, more a request/suggestion for mod building. Currently the `packageBuild.ts` script creates the zip file with the mod's named folder in the root, this makes figuring out where a mod goes when extracting a multi-step process for users (If it contains a DLL, it goes in X. If it contains a named mod folder, it goes in Y). If the `packageBuild.ts` script instead built the zip with the full structure from the SPT root inside (`user/mods/{modName}/...`) then the install steps would be "Extract into your SPT folder". There are a couple people in the Discord who have mentioned they may look at implementing a solution for this ticket :)

Cj commented

2023-09-02 01:36:39 -04:00

I have a solution for this here: https://github.com/dirtbikercj/SPT-BuildScript

It only has a single bug, where it doesn't delete a temporary folder created at the root of the drive of the executing assembly. it creates the path user/mods/{modname}/{content} at c:/ for example, or whatever drive it is being ran from. it will delete mods/{modname}/{content} but not the user folder its self.

Onto changes over the current solution. It comes with many improvements and quality of life features (what im known for).

The first thing users will see over the old solution, if enabled, is the ability see a git status -uno command automatically. I added this because of a project im working on with other people.

The second improvement is the ability to copy a fresh copy of your build to a development install directory everytime you run npm build, I've tested it upto ~1gb and it takes seconds.

The third and in my opinion most important for the community is the ability to create the mod zip in the correct user/mods/{modname}/{content} format. The most common problem in SPT-general is "How do i install this mod?". Well this solves that. Uniform mod creation will reduce the overall help requests and provide quality of life to users and mod developers alike. Zipping is also now optional in the build.json config

The fourth and final improvement, is the ability to start the server as a child process of the build process. It runs inside of vscode and doesn't require windows to spawn a new console for the server for dev purposes. Very useful for limited monitor space and overall its just a nice to have. This is configurable with a start delay in seconds.

It has a bonus feature thats niche, that you can disable copying bundles for some reason you would want to. Really not required, but if you wanted to rapidly test something in the preAkiLoad method over and over, could be nice to have on larger mods.

Give me feedback, or open pull requests if you have any suggestions, or bug fixes. Though its pretty solid as is. May need cleaned up a bit more.

I have a solution for this here: https://github.com/dirtbikercj/SPT-BuildScript It only has a single bug, where it doesn't delete a temporary folder created at the root of the drive of the executing assembly. it creates the path `user/mods/{modname}/{content}` at `c:/` for example, or whatever drive it is being ran from. it will delete `mods/{modname}/{content}` but not the user folder its self. Onto changes over the current solution. It comes with many improvements and quality of life features (what im known for). The first thing users will see over the old solution, if enabled, is the ability see a `git status -uno` command automatically. I added this because of a project im working on with other people. The second improvement is the ability to copy a fresh copy of your build to a development install directory everytime you run npm build, I've tested it upto ~1gb and it takes seconds. The third and in my opinion most important for the community is the ability to create the mod zip in the correct `user/mods/{modname}/{content}` format. The most common problem in SPT-general is "How do i install this mod?". Well this solves that. Uniform mod creation will reduce the overall help requests and provide quality of life to users and mod developers alike. Zipping is also now optional in the `build.json` config The fourth and final improvement, is the ability to start the server as a child process of the build process. It runs inside of vscode and doesn't require windows to spawn a new console for the server for dev purposes. Very useful for limited monitor space and overall its just a nice to have. This is configurable with a start delay in seconds. It has a bonus feature thats niche, that you can disable copying bundles for some reason you would want to. Really not required, but if you wanted to rapidly test something in the `preAkiLoad` method over and over, could be nice to have on larger mods. Give me feedback, or open pull requests if you have any suggestions, or bug fixes. Though its pretty solid as is. May need cleaned up a bit more.

Refringe referenced this issue

2023-09-20 20:39:07 -04:00

Updated Build Script #14

chomp referenced this issue from a commit

2023-09-21 10:40:12 -04:00

Updated Build Script (#14)

chomp commented

2023-12-08 09:41:35 -05:00

Should be fixed

chomp closed this issue

2023-12-08 09:41:35 -05:00

Sign in to join this conversation.