Because SmoulderingBeachBall (S.B.B.) is a .Net Standard 2.0 library, you can use it in traditional .Net and .Net Core projects. To add it your project (as a NuGet) enter the following command into your package manager console;
Because SmoulderingBeachBall (S.B.B.) is a .Net Standard 2.0 library, you can use it in traditional .Net and .Net Core projects. To add it your project (as a NuGet) enter the following command into your package manager console:
If you are using Visual Studio, you can search for the package with the Package Manager. If you would like to see a list of available versions and do not have access to the graphical user interface (G.U.I.), you can visit S.B.B's NuGet package. You can do that by clicking the following link;
If you are using Visual Studio, you can search for the package with the Package Manager. If you would like to see a list of available versions and do not have access to the graphical user interface (G.U.I.), you can visit S.B.B's NuGet package. You can do that by clicking the following link:
This section is for people with experience using SmoulderingBeachBallCLI. If you are new to the program, I recommend you stick to the verbose commands for now. When you are familiar with them, feel free to return. You can view the verbose commands using the following link;
This section is for people with experience using SmoulderingBeachBallCLI. If you are new to the program, I recommend you stick to the verbose commands for now. When you are familiar with them, feel free to return. You can view the verbose commands using the following link:
This part of the wiki focuses on the command-line interface (C.L.I.) part of the solution. This projects name is "SmoulderingBeachBallCLI". There is little in the way of altering featuring or writing code. Instead, the main focus is on consuming the features already created in SmoulderingBeachBall (S.B.B) via the console program. If this is not what you are wanting, I suggest you use the following links;
This part of the wiki focuses on the command-line interface (C.L.I.) part of the solution. This projects name is "SmoulderingBeachBallCLI". There is little in the way of altering featuring or writing code. Instead, the main focus is on consuming the features already created in SmoulderingBeachBall (S.B.B) via the console program. If this is not what you are wanting, I suggest you use the following links:
- ["As Source Code" section](Source-Code-Home) (if you want to add/change features to the "SmoulderingBeachBall" repository)
- ["As a NuGet" section](NuGet-Home) (if you want to use "SmoulderingBeachBall" in your project)
This project is a traditional .Net console program, written in F#. Within it, you will find eleven files but you will spend most of your time in three of them. The name of these files are "Program.fs", "Validation.fs" and "ConsoleCommands.fs". "App.config", "AssemblyInfo.fs", "SmoulderingBeachBallCLI.fsproj" are all standard project files. If you have worked with a .Net project in Visual Studio in the past, you will have seen these types of files before. "cheat-sheet.pdf" is, as the name suggests, a cheat sheet. You will see it used as part of the `cheat` command in "ConsoleCommands.fs". The remaining three files are "AppIcon.rc", "AppIcon.res" and "icon.ico". For the most part, you should never need to touch these files. They are, also, files you will not normally come across in a project like this. The reason they are here is because the provide a way for F# console programs to have their own icons. Unfortunately, F# does not cater to this very well. So, "AppIcon.rc" and "AppIcon.res" are needed for you to see "icon.ico" at run-time. If you would like to know more about ".rc" and ".res" files, please use the following links;
This project is a traditional .Net console program, written in F#. Within it, you will find eleven files but you will spend most of your time in three of them. The name of these files are "Program.fs", "Validation.fs" and "ConsoleCommands.fs". "App.config", "AssemblyInfo.fs", "SmoulderingBeachBallCLI.fsproj" are all standard project files. If you have worked with a .Net project in Visual Studio in the past, you will have seen these types of files before. "cheat-sheet.pdf" is, as the name suggests, a cheat sheet. You will see it used as part of the `cheat` command in "ConsoleCommands.fs". The remaining three files are "AppIcon.rc", "AppIcon.res" and "icon.ico". For the most part, you should never need to touch these files. They are, also, files you will not normally come across in a project like this. The reason they are here is because the provide a way for F# console programs to have their own icons. Unfortunately, F# does not cater to this very well. So, "AppIcon.rc" and "AppIcon.res" are needed for you to see "icon.ico" at run-time. If you would like to know more about ".rc" and ".res" files, please use the following links:
- [A link to the Stack Overflow question I found which got me started on my path to icon-including enlightenment](https://stackoverflow.com/questions/26841947/changing-f-application-icon)
@ -6,12 +6,12 @@ The type of validation this file provides is **complimentary** to what Console.W
The reason why is because C.W. does the type checking automatically. So, it seems foolish not to use it.
If you would like to know more about how C.W. performs its validation checks, please use the following links;
If you would like to know more about how C.W. performs its validation checks, please use the following links:
- [Console.Waterworks -- Coercion Type List](https://gitlab.com/craig.oates/Console.Waterworks/wikis/Coercion-Types-List)
- [Brittle Fish Wiki -- Writing Command-Methods in F#](https://gitlab.com/craig.oates/Brittle-Fish/wikis/Writing-Command-Methods-in-F%23) (provides specific information for F# projects)
Instead of copying and pasting the code from "Validation.fs" into this page, I recommend reading the actual file yourself. You can view it using the following link;
Instead of copying and pasting the code from "Validation.fs" into this page, I recommend reading the actual file yourself. You can view it using the following link:
@ -19,7 +19,7 @@ As you work your way through the file, try keeping the relationship between "Val
IMAGE OF VALIDATION AND CONSOLE COMMANDS RELATIONSHIP.
As a general rule, "Validation.fs" consists of three "sections". They are;
As a general rule, "Validation.fs" consists of three "sections". They are:
1. Creating `ImageSpec`'s
2. Parsing string input (colours, paths, Etc.)
@ -27,7 +27,7 @@ As a general rule, "Validation.fs" consists of three "sections". They are;
It is worth pointing out two and three reflect the nature of console programs (I.E. text based). Also, I limited the `colourList` as a way to keep things simple. The console does not provide a way to look at the colour before confirming it. And, people tend to find remembering "blue" a lot easier than `#068BEC`. Having said that, the main (NuGet) library, allows you to specify your colours using RGB values. So, you can hook it up to a graphical user interface if you want.
If you have not viewed the code in "Validation.fs", here a quick look at the available colours users can use with the console project;
If you have not viewed the code in "Validation.fs", here a quick look at the available colours users can use with the console project:
Without going into too much detail, a "command-method" is a function within the `ConsoleCommands` module. The name "command-method" is inaccurate here but I have kept it to remain consistent with Console.Waterworks (C.W). If you would like to know more about command-methods, I recommend you read the following wiki entry;
Without going into too much detail, a "command-method" is a function within the `ConsoleCommands` module. The name "command-method" is inaccurate here but I have kept it to remain consistent with Console.Waterworks (C.W). If you would like to know more about command-methods, I recommend you read the following wiki entry:
- [Console.Waterworks Wiki -- Writing Command-Methods](https://gitlab.com/craig.oates/Console.Waterworks/wikis/Writing-Command-Methods)
For command-methods to work properly, there are several things they need. Which are;
For command-methods to work properly, there are several things they need. Which are:
1. There us a module called `ConsoleCommands` in the project.
2. The module must live in a name-space. (The module is this project resides in `Commands`.)
@ -10,7 +10,7 @@ For command-methods to work properly, there are several things they need. Which
4. If using C.W's "help" attributes, you must reference the `Console.Waterworks.Attributes` name-space.
5. Command-methods must be a function (I.E. include unit/`()` in function definitions).
Please note, this list is not complete. With that said, the extra stuff is more to do with using C.W. in a C# project. If you would like to know more about using C.W. with F# and how it differs from using it with C#, checkout the following link;
Please note, this list is not complete. With that said, the extra stuff is more to do with using C.W. in a C# project. If you would like to know more about using C.W. with F# and how it differs from using it with C#, checkout the following link:
- [Brittle Fish Repository](https://gitlab.com/craig.oates/Brittle-Fish)
@ -47,16 +47,16 @@ To help explain what the above code, please consider the image below.
IMAGE OF COMMAND-METHOD BREAKDOWN
It is not essential to include the help attributes but they do provide help for the end-user and future developers. For more information about the help attributes, please use the following links;
It is not essential to include the help attributes but they do provide help for the end-user and future developers. For more information about the help attributes, please use the following links:
- [Console.Waterworks Wiki -- Using the "Help Attributes"](https://gitlab.com/craig.oates/Console.Waterworks/wikis/Using-the-%22Help-Attributes%22)
- [Brittle Fish Wiki](https://gitlab.com/craig.oates/Brittle-Fish/wikis/home)
The name of the command-method is what the end-user must enter into the console. If the command-method requires input arguments, the end-user must provide them, as well. For example, please consider the following image;
The name of the command-method is what the end-user must enter into the console. If the command-method requires input arguments, the end-user must provide them, as well. For example, please consider the following image:
SCREENSHOT OF C-M MATCHING CONSOLE INPUT
If all has gone well, you should be able to work your way through "ConsoleCommands.fs" and understand it. With that said, you will come across functions which appear to have no explanation for why the exist. If you dig around a little bit, you will notice these functions are either situated in "Validation.fs" or the .Net Standard library (I.E. "SmoulderingBeachBall"). Use the following links for more information;
If all has gone well, you should be able to work your way through "ConsoleCommands.fs" and understand it. With that said, you will come across functions which appear to have no explanation for why the exist. If you dig around a little bit, you will notice these functions are either situated in "Validation.fs" or the .Net Standard library (I.E. "SmoulderingBeachBall"). Use the following links for more information:
Instead of going through both of the main testing files (I.E. "ConsoleTests.fs" and "LibraryTests.fs"), I will provide an overview of how they work. If you want to make your way through the source code you can do so by using the following links;
Instead of going through both of the main testing files (I.E. "ConsoleTests.fs" and "LibraryTests.fs"), I will provide an overview of how they work. If you want to make your way through the source code you can do so by using the following links:
That snippet of code is all what is in "Program.fs". Once you know what is happening in here, you should never need to look at this file much -- if at all.
What is happening is a new `CW_Liaison` object is created and is told to `run`. This is where C.W. creates the input-loop which runs indefinitely until the end-user closes the console (or the program crashes). The first argument passed into `run` refers to the name-space of the `ConsoleCommands` module. In this case it is `Commands`. The second one refers to the information displayed in the console when you run it. When set to `true`, the console displays information found in "AssemblyInfo.fs". If you use `false`, the only thing you will see is the prompt. You can check the name-space of the `ConsoleCommand` module via the following link;
What is happening is a new `CW_Liaison` object is created and is told to `run`. This is where C.W. creates the input-loop which runs indefinitely until the end-user closes the console (or the program crashes). The first argument passed into `run` refers to the name-space of the `ConsoleCommands` module. In this case it is `Commands`. The second one refers to the information displayed in the console when you run it. When set to `true`, the console displays information found in "AssemblyInfo.fs". If you use `false`, the only thing you will see is the prompt. You can check the name-space of the `ConsoleCommand` module via the following link:
How C.W. creates and manages the input-loop is out of this wiki's scope. Although, if you would like to know more about how is is created, you can use the following link;
How C.W. creates and manages the input-loop is out of this wiki's scope. Although, if you would like to know more about how is is created, you can use the following link:
@ -26,6 +26,6 @@ IMAGE OF ASSEMBLY INFO IN CONSOLE.
IMAGE OF NO ASSEMBLY INFO IN CONSOLE.
Up above, I said I would elaborate on why the end-user's commands must match the name of the commands in the `ConsoleCommands` module. I will do that but not here because it ventures a little too far off topic for this section. So, I have created a dedicated section for it. You can access it with the following link;
Up above, I said I would elaborate on why the end-user's commands must match the name of the commands in the `ConsoleCommands` module. I will do that but not here because it ventures a little too far off topic for this section. So, I have created a dedicated section for it. You can access it with the following link:
This section is for those wanting to add SmoulderingBeachBall (S.B.B.) to their project, as a NuGet package. If you are more interested in using the features without writing any code, head over to the "As a Command-Line Interface (C.L.I.)" section. If you want to add new features or improve the existing ones in S.B.B., head over to the "As Source Code" section. The links for those are as follows;
This section is for those wanting to add SmoulderingBeachBall (S.B.B.) to their project, as a NuGet package. If you are more interested in using the features without writing any code, head over to the "As a Command-Line Interface (C.L.I.)" section. If you want to add new features or improve the existing ones in S.B.B., head over to the "As Source Code" section. The links for those are as follows:
- ["As Source Code" section](Source-Code-Home)
- ["As a Command-Line Interface (C.L.I.)" section](CLI-Home)
@ -2,7 +2,7 @@ As you might have noticed, there is a F# script file included in TestCentre. For
At this moment in time, "Script.fsx" provides code for you to delete any/all files in the "SavingTestArea" folder. With that said, you should only need to use it if the images are not deleted after running the unit/property tests. If that is the case, that usually means there is a problem with the tests or the projects they are testing. Either way, you should look into it.
If you are unfamiliar with using F# scripts and F# Interactive (FSI), please use the following links;
If you are unfamiliar with using F# scripts and F# Interactive (FSI), please use the following links:
This section focuses on the source code within the project called "SmoulderingBeachBallCLI". This is the console project which provides users with a way to uses the features in "SmoulderingBeachBall" without the need to write code. If you would like to know more about the other projects, please use the following links;
This section focuses on the source code within the project called "SmoulderingBeachBallCLI". This is the console project which provides users with a way to uses the features in "SmoulderingBeachBall" without the need to write code. If you would like to know more about the other projects, please use the following links:
- [SmoulderingBeachBall](https://gitlab.com/craig.oates/Smouldering-Beach-Ball/wikis/SmoulderingBeachBall-Home) (.Net Standard 2.0 library)
This section is for those wanting to work with the repository's source code. If you are more interested in using Smouldering Beach Ball's features via NuGet or the CLI, use the following links;
This section is for those wanting to work with the repository's source code. If you are more interested in using Smouldering Beach Ball's features via NuGet or the CLI, use the following links:
- ["As a Command Line Interface (C.L.I.)" section](CLI-Home) (if you want to use the console program which comes with this repository)
- [“As a NuGet” section](NuGet-Home) (if you want to add SmoulderingBeachBall to your project)
This section focuses on the source code within the "TestCentre" project. As the name implies, this project houses the unit and property tests for the the other two projects. If you would like to know more about the other projects, please the following links;
This section focuses on the source code within the "TestCentre" project. As the name implies, this project houses the unit and property tests for the the other two projects. If you would like to know more about the other projects, please the following links:
- [SmolderingBeachBall project (.Net Standard 2.0 library)](SmoulderingBeachBall-Home)
The way it works is the console receives input from the end-user. The console parses that input and matches it with a "command-method" in "ConsoleCommands.fs". When the command-method finishes its task, it returns its result to the console. That's the simple version at least.
The reason the project is set-up this way is because I built it with Console.Waterworks (C.W.). I will not go into too much detail here about how C.W. works here. Instead, I will give a basic overview. If you would like a more detailed breakdown, please use the following links;
The reason the project is set-up this way is because I built it with Console.Waterworks (C.W.). I will not go into too much detail here about how C.W. works here. Instead, I will give a basic overview. If you would like a more detailed breakdown, please use the following links:
@ -15,21 +15,21 @@ At a basic level, C.W. is a NuGet package which helps you write command-based co
IMAGE OF C.W. FLOW.
For C.W. to operate as it does, it needs to rely on certain things. They are;
For C.W. to operate as it does, it needs to rely on certain things. They are:
1. It controls the input-loop from within `main`.
2. The is a module called `ConsoleCommands` within the project.
3. `ConsoleCommands` must reside in a name-space.
4. There are functions which are `public` and `static` within the `ConsoleCommands` module.
As an aside, I wrote C.W. with C# and without F# in mind. Because of this, some of the code is this (console) project looks a little "off". If you would like to know more about using C.W. in an F# environment, please head over to another repository of mine. Its name is Brittle Fish and it is a tutorial/wiki for F# developers wanting to use C.W. It, also, points out potential pitfalls you might run into when using C.W. with F#. You can find Brittle Fish with the following links;
As an aside, I wrote C.W. with C# and without F# in mind. Because of this, some of the code is this (console) project looks a little "off". If you would like to know more about using C.W. in an F# environment, please head over to another repository of mine. Its name is Brittle Fish and it is a tutorial/wiki for F# developers wanting to use C.W. It, also, points out potential pitfalls you might run into when using C.W. with F#. You can find Brittle Fish with the following links:
- [Brittle Fish Repository](https://gitlab.com/craig.oates/Brittle-Fish)
- [Brittle Fish Wiki](https://gitlab.com/craig.oates/Brittle-Fish/wikis/home)
End of aside.
To keep things simple, I recommend you only work within "Program.fs", "Validation.fs" and "ConsoleCommands.fs". Although, once you understand what is happening in "Program.fs", I cannot foresee you venturing outside the other two. How these files work together is as follows;
To keep things simple, I recommend you only work within "Program.fs", "Validation.fs" and "ConsoleCommands.fs". Although, once you understand what is happening in "Program.fs", I cannot foresee you venturing outside the other two. How these files work together is as follows:
1. The `main` function in "Program.fs" creates an input-loop at run-time. This allows the end-user to enter commands.
2. C.W. then parse the input with the command and passes it to the relevant command-method in "ConsoleCommands.fs" when it has finished.
Within `Domain` is a module called `DomainTypes`. (This is what is actually set to "auto-open".) In `DomainTypes`, you will find three types which are;
Within `Domain` is a module called `DomainTypes`. (This is what is actually set to "auto-open".) In `DomainTypes`, you will find three types which are:
1. `OverlayType`
2. `OverlaySpec`
@ -10,7 +10,7 @@ To help you become more familiar with them, it might help if you think of them l
IMAGE OF THE RUSSIAN DOLL RELATIONSHIP
Having said the above, you can circumvent all this by setting the "overlay" property to "None" when creating your `ImageSpec`. For example, take a look at the following piece of code;
Having said the above, you can circumvent all this by setting the "overlay" property to "None" when creating your `ImageSpec`. For example, take a look at the following piece of code:
```f#
let spec =
@ -24,25 +24,25 @@ let spec =
It is, also, worth pointing out you do not need to specify the file name (A.K.A. the "final part") of the `filePath`. This is because S.B.B. does it for you. Instead, you only need to specify the folder/place you want the image written to. (Perhaps "directory" might have been a better choice.)
If you would like to read the actual source code in `DomainTypes`, you can do so by using the following link;
If you would like to read the actual source code in `DomainTypes`, you can do so by using the following link:
This type describes what type of overlay you want on your placeholder image. `Border` adds a border around the sides of your image and `Full` adds an "X" across the image. The colour of "X" will be the same as the border. Here are some examples;
This type describes what type of overlay you want on your placeholder image. `Border` adds a border around the sides of your image and `Full` adds an "X" across the image. The colour of "X" will be the same as the border. Here are some examples:
IMAGE OF BORDER IMAGE
IMAGE OF FULL IMAGE
When it comes to creating an `OverlayType`, you tend to not make a "standalone" version. Instead, you will usually specify the type when you create an `OverlaySpec`. For example;
When it comes to creating an `OverlayType`, you tend to not make a "standalone" version. Instead, you will usually specify the type when you create an `OverlaySpec`. For example:
```f#
// The definition of the type.
@ -63,7 +63,7 @@ let overlaySpecWithFull =
### OverlaySpec
Use this type to describe how you want the complete overlay to look. You will use this in conjunction with the `OverlayType`. You can use the above examples to help you get a grasp how to use/create `OverlaySpec`'s. With that said, here is how I defined `OverlaySpec`;
Use this type to describe how you want the complete overlay to look. You will use this in conjunction with the `OverlayType`. You can use the above examples to help you get a grasp how to use/create `OverlaySpec`'s. With that said, here is how I defined `OverlaySpec`:
```f#
type OverlaySpec =
@ -77,7 +77,8 @@ This type describes the whole image. Before you can use it, though, you must def
As an aside, you could create/define the "overlay" whilst creating the `ImageSpec`. But, I would argue against that. The reason why is because it makes it hard to read -- well it did when I was in the middle of writing S.B.B.
Here are some examples of how you would create an `ImageSpec`;
Here are some examples of how you would create an `ImageSpec`:
Within TestCentre, you will see a collection of unit and property tests. Each type of test uses their own testing library. For unit tests, I have used xUnit and I have used FsCheck for the property tests. If you are unfamiliar with either of these libraries, please use the following links;
Within TestCentre, you will see a collection of unit and property tests. Each type of test uses their own testing library. For unit tests, I have used xUnit and I have used FsCheck for the property tests. If you are unfamiliar with either of these libraries, please use the following links:
- [xUnit](https://xunit.net/)
- [FsCheck](https://fscheck.github.io/FsCheck/)
@ -9,6 +9,6 @@ IMAGE OF VISUAL STUDIO TEST EXPLORE.
As you can see, it is a good way to determine what tests are passing and failing. On top of that, it highlights how the tests are organised within TestCentre.
For more information about Visual Studio's Test Explorer, use the following link;
For more information about Visual Studio's Test Explorer, use the following link:
- [Visual Studio's Test Explorer](https://docs.microsoft.com/en-us/visualstudio/test/run-unit-tests-with-test-explorer?view=vs-2019)
For more in-depth examples, have a look at "ConsoleCommands.fs". In here, you will find "real world" examples of this library in use. You can, also, check out the "Snippets" section for more examples. Links to those places are as follows;
For more in-depth examples, have a look at "ConsoleCommands.fs". In here, you will find "real world" examples of this library in use. You can, also, check out the "Snippets" section for more examples. Links to those places are as follows:
@ -33,7 +33,7 @@ As a consumer of S.B.B., you will not have access to every part it. Instead, you
IMAGE OF PARTS YOU USE.
Because `SmoulderingBeachBall.Domain` automatically opens, you might get a false impression about the main component you will use. You might think the `ServicesSmoulderingBeachBall.Service` module is where you will spend most of your time. This is a red herring. The reason why is because `Service` does only one thing: make the Image. Granted, it is a two-step process, which is "make image" and "save/commit/write image". But, they are practically two sides of the same coin. To help demonstrate that, please consider the following code;
Because `SmoulderingBeachBall.Domain` automatically opens, you might get a false impression about the main component you will use. You might think the `ServicesSmoulderingBeachBall.Service` module is where you will spend most of your time. This is a red herring. The reason why is because `Service` does only one thing: make the Image. Granted, it is a two-step process, which is "make image" and "save/commit/write image". But, they are practically two sides of the same coin. To help demonstrate that, please consider the following code:
The console program this repository provides is a traditional .Net 4.7.1 console. It does not come with an installer and I wrote it in F#. On top of that, I built the program with Console.Waterworks (C.W). What that means is you operate the console by entering commands and arguments. From your perspective, this will not feel vastly different from most console programs. Although, there are slight differences and even more in the source code. If you would like to know more about C.W., you can do so by using the following links;
The console program this repository provides is a traditional .Net 4.7.1 console. It does not come with an installer and I wrote it in F#. On top of that, I built the program with Console.Waterworks (C.W). What that means is you operate the console by entering commands and arguments. From your perspective, this will not feel vastly different from most console programs. Although, there are slight differences and even more in the source code. If you would like to know more about C.W., you can do so by using the following links:
- [Console.Waterworks
@ -10,7 +10,7 @@ The console program this repository provides is a traditional .Net 4.7.1 console
I will assume you have downloaded the console program or cloned the repository and built it. For information on how to get SmoulderingBeachBallCLI on your machine, you can use the following link;
I will assume you have downloaded the console program or cloned the repository and built it. For information on how to get SmoulderingBeachBallCLI on your machine, you can use the following link:
- [Add SmoulderingBeachBallCLI to Your Machine](Add-SmoulderingBeachBallCLI-to-Your-Machine)
@ -18,7 +18,7 @@ When you start the console, you will see something similiar to the image below.
IMAGE OF CLI AT START
From here, you can begin entering commands. Before you do, it is worth pointing out two things. The first is you can see a list of all the available commands by typing "help" into the prompt and pressing *ENTER*. The second thing is the program has a built-in "cheat-sheet". The quickest way to access it by entering "cheat" into the prompt. When you do that, you will see a cheat-sheet appear on your desktop. You can, also, use the following link;
From here, you can begin entering commands. Before you do, it is worth pointing out two things. The first is you can see a list of all the available commands by typing "help" into the prompt and pressing *ENTER*. The second thing is the program has a built-in "cheat-sheet". The quickest way to access it by entering "cheat" into the prompt. When you do that, you will see a cheat-sheet appear on your desktop. You can, also, use the following link:
- [Cheat Sheet PDF](https://gitlab.com/craig.oates/Smouldering-Beach-Ball/blob/master/SmoulderingBeachBallCLI/cheat-sheet.pdf) (the repositories version)
@ -26,20 +26,20 @@ IMAGE OF HELP COMMAND.
IMAGE OF CHEATSHEET.
If you go through the "help" section, in the console or PDF, you will notice most of the commands have input arguments. From your point-of-view, they are typical input types (E.G. `int`, `string`). There are limitations, though. The most notable one being the converting from (console) text to other (non-`string`) types. If you would like to know more about these limitations, I recommend you use the following link;
If you go through the "help" section, in the console or PDF, you will notice most of the commands have input arguments. From your point-of-view, they are typical input types (E.G. `int`, `string`). There are limitations, though. The most notable one being the converting from (console) text to other (non-`string`) types. If you would like to know more about these limitations, I recommend you use the following link:
I will not go into too much detail about the limitation because it is essentially a C.W. concern. And, you should not notice it for the most part. Although, if you are wanting to work with this projects source code, I highly recommend you use the above link.
If you do not want to use the cheat-sheet or the built-in "help" command, you can view the list of available commands with the following link;
If you do not want to use the cheat-sheet or the built-in "help" command, you can view the list of available commands with the following link:
- [Console A.P.I.](Console-API)
After a while, you should start to get proficient with SmoulderingBeachBallCLI. When you
do, the command names might start feeling a little clunky and long-winded. If
that is the case, you can head over the aliases section. The link for that
