Sandbox is our in-house R&D system

While your welcome, and infact encouraged, to use it for development of the Bearsampp program is it NOT for use as your daily driver!  It's strictly a R&D system.
There are a few things that are very unique to Sandbox and require important consideration.
ANY branch other then main should be considered alpha and highly likely to break everything.  Using sandbox requires patience and understanding how things function.
I'll attempt to explain things but nothing will replace experience.  Even Jacob and Bear have been slapped by sandbox more then once!

How to setup sandbox

Setting up sandbox is not difficult but the steps are exacting.

Using Sandbox is alot like any other repo in that you do a git clone and your on your way... EXCEPT there is a requirement that you do these steps in the following order.

1. your expected to be familiar with how to use a git aware IDE.  Your welcome to use the cli but these instructions are designed for an IDE.
2. clone the branch "main" into your working directory
3. switch to the branch "release"
4. rename the branch "main" to anything
5. using the "remote" branch feature merge the remote "main" branch on top of the local "release" branch
6. rename the local "release" branch to "main"
7. delete the branch you renamed main to 
8. you should now have a single local branch named "main"  In this branch is a full working version of the "Sandbox" version of bearsampp including all unique iconography.
9. start up Sandbox and test that everything works.  If so you're ready to do R&D

Firing off a bombing run

Doing a bombing run is fun and scary at the same time.  This is a large commitment of drive space so if your on anything smaller then a 64gb drive, and not at least usb 3.0 you should probably not do this!!!
So now that your worried, lets put our bomber jacket on and punch that pickle.

1. This couldn't be simpler.  Make sure your on the "main" branch.
2. if this is a fresh install of Sandbox then remove all branches from your local except "main"
3. go to the sandbox repo release for bomber payloads and download all the files there.
4. use the extract.bat and unzip all the files
5. put the bin in the root of sandbox and do NOT overwrite

Why bother with Sandbox?

Jacob and Bear had several "discussions" over the merits of sandbox. It was conceived and matured by Bear as a safe environment to test the numerous changes that were upcoming without endangering our "core".
Bear had nuked his installation of core that was his daily driver more then once and with dozens and dozens of fixes coming it was important that there was some simple way for things to be done.
You have to understand that when Bear thinks something is "simple' you should probably be scared! LOL

He's put a lot of thought and effort into what is maturing to be a great system, in his mind, for R&D.  When everything is fully matured making a merge on sandbox will auto create a pr & merge onto core.  This will facilitate the ability to roll out a new version of core very quickly, with the comfort in knowing everything has been tested thoroughly.  There will still be a final test of the "build" of course but it should always be painless.

Breaking something in sandbox is as trivial a fix as deleting, or fixing, that branch and starting fresh from main. None of the day-to-day file changes that happen in core while testing effect Sandbox.  It's completely isolated from the runtime(s).  This is one of its major strengths.  Your commits are completely and intentionally restricted to the "core" system.

What's it been like using Sandbox?

While Jacob has struggled with Sandbox, ALOT, Bear has been able to make it shine!
He uses it daily when making the changes that make Bearsampp mature.  PR's are created from those changes, tested, most of the time by Jacob, and then merged into main when they have been successfully tested.
It's a tool that if/when more developers come onboard they will have a reliable and fully tested method of doing things to further the program along.

Can't I just use normal Bearsampp?

Yep! BUT, DON'T COME COMPLAINING TO BEAR WHEN YOU BOMB YOUR INSTALL!  Don't think it can't happen to you, or "meh, easy to fix if it happens".  You couldn't be further from the truth.  Just recently Jacob bombed EVERY version of Bearsampp on his computer during testing of an encryption system.  The hours of effort and frustration he spent trying to figure it out was not for the faint of heart.  Jacob, to his merits, stuck with the battle and after many HOURS found out the real issue and its original cause.  Bear had to admit to Jacob he would've never figured it out and that's not the first time or even second or third that something like this has happened.  Jacob's tenacity, experience in IT has been instrumental in the growth of Bearsampp.
Furthermore using our main repo for R&D actually endangers our main repo because the rollbacks WILL happen!  It takes a minimum of one to two hours to roll out a new version of Bearsampp WITHOUT anything going wrong so the lower the chances of something failing the better.

How long does it take to restore Sandbox when it bombs

Ideally? 30 seconds. IT SHOULD be as simple as destroying the branch and moving forward. But in the chance you have to nuke and start over, given a decent net connection, its a 15 min fix.

How exactly do I use Sandbox?

So, just like any other project you develop, you've created a branch, you've done some kind of an improvement to Bearsampp and your ready to fire it off. Great, one thing you'll notice is the iconography for Sandbox is different then for Bearsampp. This is by design. The color is a warning to you that your using a system designed for things to go wrong.
Run through the appropriate steps to test the changes you've made.  Assuming those work then check EVERY function in Sandbox.  The more thorough you are in this step the less work on everyone else who has to do the same thing to test your "fix".  Lastly fire up localhost and make sure everything there works.  Check the links, iconography, spinners, everything!
If everything looks ok, then commit, and create a pr.  If you are part of the "Qodo" team, which you most likely are, there's no need for anything other then a title for the PR.  PR-Agent Pro will do all the heavy lifting.  Then just sit back and wait for the merge of your effort.  Remove your local branch once your pr has been merged and start on the next issue.  Don't be like Bear and forget to switch to main & creating a new branch before starting on the next thing.  If you need some documentation on how the api works, then check out our API docs.