update image links and more them to root.

Add-Smouldering-Beach-Ball-to-Your-Project.md

@@ -16,4 +16,4 @@ If you are using Visual Studio, you can search for the package with the Package
 
 [Smouldering Beach Ball NuGet Profile](https://www.nuget.org/packages/SmoulderingBeachBall/)
 
-![visual studio package manager g.u.i.](attachments/visual-studio-package-manager.png)
+![visual studio package manager g.u.i.](visual-studio-package-manager.png)

CLI-Project-Breakdown.md

@@ -1,4 +1,4 @@
-![smoulderingbeachballcli selected](attachments/sbbcli-selected.png)
+![smoulderingbeachballcli selected](sbbcli-selected.png)
 
 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:
 
@@ -7,4 +7,4 @@ This project is a traditional .Net console program, written in F#. Within it, yo
 
 Please note, you need C++ tools installed with your Visual Studio installation. If you do not have them installed, you will not have the ability to change the console's icon. With that said, you should not need to because I have already creates and connected the icon to the system.
 
-![smoulderingbeachballcli file structure](attachments/sbbcli-file-structure.png)
+![smoulderingbeachballcli file structure](sbbcli-file-structure.png)

CLI-Validation-Overview.md

@@ -17,7 +17,7 @@ Instead of copying and pasting the code from "Validation.fs" into this page, I r
 
 As you work your way through the file, try keeping the relationship between "Validation.fs" and "ConsoleCommands.fs" in mind. Everything in "Validation.fs" aids "ConsoleCommands.fs" and nothing else.
 
-![smoulderingbeachballcli file flow](attachments/sbbcli-file-flow.png)
+![smoulderingbeachballcli file flow](sbbcli-file-flow.png)
 
 As a general rule, "Validation.fs" consists of three "sections". They are:
 

Command-Methods-Overview.md

@@ -45,7 +45,7 @@ let ``list-colours`` () =
 ```
 To help explain what the above code, please consider the image below.
 
-![command-method binding example](attachments/command-method-binding-example.png)
+![command-method binding example](command-method-binding-example.png)
 
 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:
 
@@ -54,7 +54,7 @@ It is not essential to include the help attributes but they do provide help for
 
 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:
 
-![command-method matching run-time command](attachments/command-method-matching-run-time-command.png)
+![command-method matching run-time command](command-method-matching-run-time-command.png)
 
 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:
 

Console-and-Library-Tests-Overview.md

@@ -5,11 +5,11 @@ Instead of going through both of the main testing files (I.E. "ConsoleTests.fs"
 
 The general structure for each file is the same. Each one has a module called `PropertyTests` with "helper" functions at the top of them. It is worth pointing out both of these modules live in name-spaces. This is what allows both "testing" files to use the same module name. If you are wondering why I did it this way, it is because it makes it easier to read the Test Explorer. For now, the only unit tests you will see are in "ConsoleTests.fs", residing in the `UnitTests` module.
 
-![visual studio's test explorer](attachments/visual-studio-test-explorer.png)
+![visual studio's test explorer](visual-studio-test-explorer.png)
 
 As an aside, I have kept the "helper" functions next to the actual tests for a reason: to avoid "over-engineering". It seemed a little excessive to "modularise" everything with such a small amount of tests. Although, I admit this approach will need to change if the repository grows in the future. If/when that time comes, TestCentre will need refactoring. So, keep this in mind if you decide to add your own changes/features.
 
-![test files basic structure](attachments/test-files-basic-structure.png)
+![test files basic structure](test-files-basic-structure.png)
 
 One way to denote a property test from a unit test is by looking at their attributes. If a test has `[<Property>]` next to it, it is a property test. If a test has `[<Fact>]` next to it, it is a unit test. For example,
 
@@ -35,8 +35,8 @@ let ``Can create an image with a full overlay`` () =
 
 As stated in other parts of this wiki, make sure you have a folder called "SavingTestArea" within TestCentre. If you do not have this folder on your machine, a lot of the tests will fail. This is because TestCentre uses it as a place to save and check the images it creates. To help you check, below is a diagram showing you what the TestCentre project should look like.
 
-![testcentre file structure](attachments/testcentre-file-structure.png)
+![testcentre file structure](testcentre-file-structure.png)
 
 The easiest way to add this folder to TestCentre is by right-clicking on TestCentre in Visual Studio's Solution Explorer. From there, head to *Add -> New Folder*. Having said that, you can add the "SavingTestArea" to TestCentre with File Explorer if you want. This is because Visual Studio does not need to know exists. You just need it on your machine.
 
-![add new folder screenshot](attachments/add-new-folder-screenshot.png)
+![add new folder screenshot](add-new-folder-screenshot.png)

Creating-the-Input-Loop.md

@@ -22,9 +22,9 @@ How C.W. creates and manages the input-loop is out of this wiki's scope. Althoug
 
 Here are examples of what is displayed at run-time when you pass `true` or `false` into the `liaison.Run` command, mentioned above.
 
-![console with assembly info](attachments/console-with-assembly-info.png)
+![console with assembly info](console-with-assembly-info.png)
 
-![console with no assembly info](attachments/console-with-no-assembly-info.png)
+![console with no assembly info](console-with-no-assembly-info.png)
 
 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:
 

Introduction-to-Smouldering-Beach-Ball.md

@@ -6,7 +6,7 @@ As an aside, the console program is a traditional .Net console program and does
 
 I set the solution up with the console program and TestCentre referencing the (NuGet) library. To help you get a sense of what I mean, here is a diagram showing the relationship between the projects.
 
-![s.b.b. project references](attachments/sbb-proj-refs.png)
+![s.b.b. project references](sbb-proj-refs.png)
 
 ## Why this Repository Exists
 
@@ -22,4 +22,4 @@ There are three types of images you can produce with S.B.B. and this applies to
 
 It is important to note you can change the colour of the "border" and "placeholder frame" as a well as the main colour.
 
-![image examples](attachments/image-examples.png)
+![image examples](image-examples.png)

Repository-Breakdown.md

@@ -6,8 +6,8 @@ The code-base in this repository is a typical Visual Studio solution. Within the
 
 The solution's main project is the .Net Standard library, called "SmoulderingBeachBall". This is where you will most likely want to start your exploration into the code. The other two projects are secondary but important parts of the solution. There project names are "SmoulderingBeachBallCLI" (the console program) and "TestCentre" (the testing library). To help you grasp how they all fit together, please consider the images below.
 
-![solution overview](attachments/solution-overview.png)
+![solution overview](solution-overview.png)
 
 The image below shows how each project is referenced within the solution. SmoulderingBeachBall and SmoulderingBeachBallCLI are referenced in TestCentre; And, SmoulderingBeachBall is referenced in SmoulderingBeachBallCLI. This leaves SmoulderingBeachBall referencing none of the other two.
 
-![s.b.b. projects ref's](attachments/sbb-proj-refs.png)
+![s.b.b. projects ref's](sbb-proj-refs.png)

SmoulderingBeachBall-Project-Breakdown.md

@@ -1,11 +1,11 @@
 This project is a .Net Standard 2.0 library, written in F#. Within the project, you will see six files although you will work with three of them most of the time.
 
-![s.b.b. selected](attachments/sbb-selected.png)
+![s.b.b. selected](sbb-selected.png)
 
 "AssemblyInfo.fs" and "SmoulderingBeachBall.fsproj" are files you will usually find in a standard F# project. "ScratchPad.fsx", on the other hand, is not. The purpose of "ScratchPad.fsx" is to test out this libraries code using F# Interactive (FSI). All code is "ScratchPad.fsx" is "throw-away" code.
 
-![s.b.b. file structure](attachments/sbb-file-structure.png)
+![s.b.b. file structure](sbb-file-structure.png)
 
-![scratchpad relationship](attachments/scratchpad-relationship.png)
+![scratchpad relationship](scratchpad-relationship.png)
 
 As an aside, when working with the source code, I ask you stick to using Visual Studio. The reason why is because it is possible to work with **this project** in something like Visual Studio Code. If you do that, though, the remaining two will not load properly. And, the repository will clog-up with extra project/configuration files.

SmoulderingBeachBalls-Flow.md

@@ -1,6 +1,6 @@
 To help you get up to speed on the way Smouldering Beach Ball works, please consider the following image:
 
-![](attachments/sbb-general-flow.png)
+![](sbb-general-flow.png)
 
 The way it works is you construct a "spec" using the code in "Domain.fs" and pass it to an appropriate function in "Services.fs". From there, "Services.fs" hands it off to "InternalServices.fs". This is after doing some preliminarty checks first. After that, "InternalServices.fs" creates the placeholder image based on the "spec". It then reports it status to Services.fs which, in-turn, forwards that on to the consumer of the NuGet package. It is important to note, the output will either be an expection or unit (`()`). If it is unit, that means the image was created successfully and is saved in the location specified. In other words, no news is good news.
 

TestCentre-Breakdown.md

@@ -2,7 +2,7 @@ This project is a traditional .Net (4.7) library, written in F#. Its main purpos
 
 Within the project, you will see six files and one folder. Although, you should only need to work with two of them. They are "ConsoleTests.fs" and "LibraryTests.fs".
 
-![testcentre selected](attachments/testcentre-selected.png)
+![testcentre selected](testcentre-selected.png)
 
 The "AssemblyInfo.fs", "TestCentre.fsproj" and "packages.config"
 files are all standard files. You will find them in most, if not all,
@@ -10,11 +10,11 @@ F# based (traditional) .Net libraries.
 
 "Script.fsx" contains code I will go over a little later. Although, if you know how to work F# Interactive (FSI), you will already know how to use this file. There is not much code in it and you can avoid using at all it if you want.
 
-![testcentre file structure](attachments/testcentre-file-structure.png)
+![testcentre file structure](testcentre-file-structure.png)
 
 As there names imply, "ConsoleTests.fs" and "LibraryTests.fs" houses the tests of their project's namesake. So, "ConsoleTests.fs" contains the tests for the console (SmoulderingBeachBallCLI) project. And, "LibraryTests.fs" contains the tests for the library project (SmoulderingBeachBall).
 
-![testcentre split overview](attachments/testcentre-split-overview.png)
+![testcentre split overview](testcentre-split-overview.png)
 
 The folder ("SavingTestArea"), provides an area for TestCentre to actually save the images it produces. If you do not see it in your solution, you might need to create it yourself. This will become clear when you run the tests, because they will fail. If you need to add "SavingTestArea" to your copy of TestCentre, make sure it matches the location in the above diagram.
 

The-CLIs-Flow.md

@@ -1,6 +1,6 @@
 To help get you up to speed on how SmoulderingBeachBallCLI works, please consider the the image below.
 
-![smoulderingbeachballcli general flow](attachments/sbbcli-general-flow.png)
+![smoulderingbeachballcli general flow](sbbcli-general-flow.png)
 
 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.
 
@@ -13,7 +13,7 @@ The reason the project is set-up this way is because I built it with Console.Wat
 
 At a basic level, C.W. is a NuGet package which helps you write command-based console programs. From a **distance**, C.W. programs look **a bit like** MVC programs. The basic structure of a C.W. program looks like the image below.
 
-![console.waterworks flow](attachments/console.waterworks-data-flow.png)
+![console.waterworks flow](console.waterworks-data-flow.png)
 
 For C.W. to operate as it does, it needs to rely on certain things. They are:
 
@@ -39,4 +39,4 @@ To keep things simple, I recommend you only work within "Program.fs", "Validatio
 
 It is worth pointing out "Validation.fs", also, provides "helper" functions. This is because the program, as a whole, is not that big/complicated. If the program grows its feature-set and complexity, this file will need refactoring. So, keep this in mind if you decide to work with the source code.
 
-![smoulderingbeachballcli file flow](attachments/sbbcli-file-flow.png)
+![smoulderingbeachballcli file flow](sbbcli-file-flow.png)

The-Domain-Name-Space.md

@@ -8,7 +8,7 @@ Together they describe how your placeholder image will look.
 
 To help you become more familiar with them, it might help if you think of them like Matryoshka Dolls (I.E. "Russian Dolls"). The reason why is because of how the types interact with each other. The `ImageSpec` holds an `OverlaySpec` which holds an `OverlayType`. Granted, this is a high level overview but this relationship is an important part of knowing how to use SmoulderingBeachBall (S.B.B.)
 
-![domain-types relationship](attachments/domain-types-relationship.png)
+![domain-types relationship](domain-types-relationship.png)
 
 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:
 
@@ -32,7 +32,7 @@ If you would like to read the actual source code in `DomainTypes`, you can do so
 
 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:
 
-![overlays examples](attachments/overlay-examples.png)
+![overlays examples](overlay-examples.png)
 
 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:
 

Unit-and-Property-Tests-Overview.md

@@ -5,7 +5,7 @@ Within TestCentre, you will see a collection of unit and property tests. Each ty
 
 It is worth pointing out TestCentre uses xUnit's Test Runner for Visual Studio. This means you can use Visual Studio's Test Explorer -- which shows you the project's (unit and property) tests with a graphical user interface (G.U.I.). If you are unsure what that is, below is a screenshot of what it looks like.
 
-![visual studio's test explorer](attachments/visual-studio-test-explorer.png)
+![visual studio's test explorer](visual-studio-test-explorer.png)
 
 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.
 

Using-the-Console-Program.md

@@ -16,15 +16,15 @@ I will assume you have downloaded the console program or cloned the repository a
 
 When you start the console, you will see something similiar to the image below.
 
-![console at start](attachments/console-with-assembly-info.png)
+![console at start](console-with-assembly-info.png)
 
 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://git.abbether.net/craig.oates/Smouldering-Beach-Ball/blob/master/SmoulderingBeachBallCLI/cheat-sheet.pdf) (the repositories version)
 
-![console with help command](attachments/console-with-help.png)
+![console with help command](console-with-help.png)
 
-![console with cheat-sheet](attachments/console-with-cheat-sheet.png)
+![console with cheat-sheet](console-with-cheat-sheet.png)
 
 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:
 

_Siderbar.md

@@ -1,4 +1,4 @@
-![sidebar logo](attachments/sidebar-logo.png)
+![sidebar logo](sidebar-logo.png)
 
 ## Table of Contents