diff --git a/README.md b/README.md index 482b122..d5e386c 100644 --- a/README.md +++ b/README.md @@ -1,53 +1,43 @@ # Spearhead +Hello and welcome to Spearhead! -## Contributing. +If you're a developer that wants to contribute, look at the code or understand what we're doing, feel free to read on. -I'm always happy to see contributions!
-Especially if you've found an issue, annoyance or feature that you know how to solve, fix or create!
+If you're a mission maker that wants to see the documentation and build you mission with this framework.
+It's best to go to our fully fledged documentation website: +- Stable/Main: https://spearhead.rocks +- Beta/Develop: https://beta.spearhead.rocks -### Keep it small. +## Project Structure -Keeping your contributions small and to the point helps both me and yourself.
-It'll help the PR review and the speed of improvements.
-If you have a big feature in mind? Go for it!
-Does it require an entire refactor of parts or all of the program? Maybe make sure to do step 0 first. +The Spearhead project is structured in a lot of separate files.
+While Lua isn't specifically created for it, most of it has been written with the standards of OOP in mind.
+Classes, Objects and helper methods. -### Steps (for first timers) -0. Reach out (Optional) +You're find in the `/src` folder all the files.
+They are separated in a somewhat logical order, but some things might feel out of place.
-If you want to let me know you want to do something to contribute, please do!
-Maybe I'm already working on the thing you wanted to build, or someone else is.
-Creating an issue is even better!
+### Bundling, Intellisense, Linting +In DCS the easiest way to import a script is with 1 single file, however, that's not as "maintainable". +In order to keep it maintainable we're using a self-built tool to bundle, validate and rewrite some of the lua in order to get it into a single file. +The tool is open-source here: https://git.dutchie031.com/dutchie031/DcsMissionScriptingTools.
+It has a `VSCode` extensions and two `Github Action` steps.
+If your favorite IDE isn't `VSCode` (I respect that), it might be very easy to create an extension for it, if it does allow that. -1. Fork the repository +The `VSCode` extensions comes with Intellisense as well, in the form of a full file of DCS lua type annotations.
+This gives the Lua Language Server by Sumneko (which can be used in `VSCode`) all the type definitions it needs. +When writing Spearhead code it is also important to keep our own LuaLS Annotations up to date and complete.
+Read all about those annotations here: https://luals.github.io/wiki/annotations/ -By forking you can create your own working set of code.
-Whether you keep that fork public or private is up to you!
+When a pull-request to the `develop` or `main` branches is created, before it can be merged it requires to pass the linter checks. +The first linting check is done by the Lua Language Server. It checks for whitespace and formatting, but it also checks if all types, type-checking and casts are in order. It marks unused variables etc. `.luarc.json` has all the config for those checks.
+The second linter job is with `luacheck` which first "bundles" the script, and then runs a full linter check over the bundled script.
+This is to make sure that also the bundled script does not contain any errors. -Keep in mind, forking is alright, but it's best with the intent to contribute back.
-After all, instead of having 5 slightly different versions and products, it might be nicer to have 1 much better version.
+## Contributing -2. Create a Draft PR as soon as possible! +### Setting up the project -As soon as you've found some times to create an initial version, please create a draft PR.
-That way you can let me and everyone know it's being worked on and people can see what conflicts might arise with their own changes.
- -3. Test, test, test - -With DCS and Lua there's a bunch of edge cases that are really hard to get to.
-However, you kinda need to make sure most if not all cases are caught and tested.
-Since automated testing for now doesn't seem feasible, please make sure to verify and test functionality after touching stuff.
- -4. Finalise and publish the PR. - -Finalise the PR and let the maintainers know!
-We can all have a look and discuss the changes.
- - - - -# TODO: - -- Would it be possible to generate optional markers on mission briefing locations for Tomcat / Phantom navigation? Then Jester can type it in for the pilots automatically. +If you've kept on reading I assume you either want to brwose \ No newline at end of file diff --git a/RELEASENOTES.md b/RELEASENOTES.md index 424daa2..063b3bf 100644 --- a/RELEASENOTES.md +++ b/RELEASENOTES.md @@ -5,24 +5,24 @@ ### New Features -- Issue: #41 +- Issue #41 Adds Stage Complete debug methods for local testing of the Stage flow. - #40 + PR #40 -- Issue: #35 +- Issue #35 Creating Lane option for stages. Additionally to the primary stage lane, stages can now be created in different lanes. These lanes can be used to create different stage progression flows and create different "side-stories". - #40 + PR #40 -- Issue: #37 +- Issue #37 Now enabled the mission editor to add a custom briefing to the "Buildable" missions. - #44 + PR #44 -- Issue: #42 +- Issue #42 DEEPSTRIKE now added as a possible feature. This enables to have missions active in "Pre-Activated" Stages. - #48 + PR #48 ### Bug Fixes diff --git a/src/main.lua b/src/main.lua index fe6ab7c..962d0ea 100644 --- a/src/main.lua +++ b/src/main.lua @@ -71,4 +71,3 @@ if globalConfig and globalConfig:isDebugMenuEnabled() == true then local debugMenu = DebugMenu.new() debugMenu:RegisterMenus() end -