# Welcome
This archive contains all of the source files used in the production of [Rider on the Storm](https://www.fimfiction.net/story/516959/rider-on-the-storm).  
I also go into some detail about the programs I use for any who are interested.  

# License
All included text files and other non-code documents are released under the [Creative Commons BY-SA 4.0 License](https://creativecommons.org/licenses/by-sa/4.0/legalcode.txt), and all included source code and scripts (if they are present) are released under the [3-Clause BSD License](https://opensource.org/licenses/BSD-3-Clause).  
The full text of each respective license can be found in the `COPYING.TEXT` and `COPYING.PROG` files at the root of the archive.  

# Programs Used

### [FocusWriter](https://gottcode.org/focuswriter/)
One of the best distraction-free word processors I've used.  
This is what I use primarily to write prose stories.  

### [Xed](https://github.com/linuxmint/xed)
The standard text editor that ships with Linux Mint, based on [gedit](https://wiki.gnome.org/Apps/Gedit).  
I use it to author greentext stories, jot-notes, and snippets of code.  

### [Zim Wiki](https://zim-wiki.org/index.html)
A powerful and performant personal wiki system, written in Python and extensible with plugins.  
I use it primarily to take jot-notes and to organize and document much larger stories that require it.  
Zim saves all of it's documents to plain .txt files, so Zim is not required to read the wiki pages.  

### [LibreOffice](https://www.libreoffice.org/)
A full-featured open-source office suite.  
In particular, I use the Calc application to compose spreadsheets and lists for larger stories that require them.  

# Directory Structure
This is mostly self-explanatory, but I'll include my rationales anyways.  
I strongly suggest setting your file browser to sort by date and time instead of filename, so you can see the chronological order of each file.  

###### `./Private`
This directory is automatically excluded from the archive you've received, and contains stuff that for whatever reason I didn't wish to include with the public release.  
If this directory exists in the archive you've received, I have fucked up big-time and you should probably laugh at me.  
###### `./Published`
If present, this directory contains a copy the publicly available version of the story that was downloaded from the website(s) hosting it.  
Typically, this will be present for Fimfiction stories, but not for greentext stories.  
Unless otherwise noted, the copy of the story in this directory is always the final, authoritative version.  
###### `./Archive`
This directory contains previous iterations and revisions of all documents I didn't want to delete, including (but not limited to) old production documents, and even entire Zim wikis.  
Really, anything goes here: I try to delete as few things as possible.  
###### `./Programs`
If present, this directory contains, well, _programs_ and scripts I used to help create, format, or otherwise assist with the story.  
###### `./Wiki`
If present, this directory contains this story's Zim wiki. Only used in larger stories.  
Zim creates a _lot_ of files and subdirectories as part of it's normal operation, so sectioning them off in a separate folder is always a good idea.  
###### `./Production`
This directory houses the documents used to write the actual story, and is divided into these subdirectories:  
###### `./Production/Original`
Contains the source documents for the story.  
###### `./Production/Planning`
If present, contains the lists and spreadsheets used to structure and plan the story. Only used in larger stories.  
###### `./Production/Final Export`
Whenever I publish chapters to a given platform, such as Fimfiction, the raw marked-up text of the chapter is copied from the editor screen and into a text file in this directory.  
I do this for completion and archival purposes. Plus, backups are always nice to have!  

# Writing Process
My writing process changes quite a bit, depending on if I'm writing a greentext or a prose story. Most of the time I write by the seat of my pants and don't do any additional planning beyond using my memory and going with my gut, but for longer and more intricate stories where that isn't an option (or if I just get sick of re-reading constantly), I have a different workflow for those, too.  
Note also that none of the below is an ironclad rule: I experiment constantly with different programs and methodologies, and I describe some of those experiments in their respective sections.  

### Greentext
In Xed, I set my editor's theme to [DarkerMate](https://github.com/ricardograca/gedit-themes) and set the syntax highlighting to Diff, which makes the greentext render as, well, _greentext._ This is an old trick I discovered back in around 2018-2019 to make reading and writing greentext a much better experience, and works across a range of editors.  
My editor's font is typically set to [DejaVu Sans Mono Book](https://dejavu-fonts.github.io/) (as package `fonts-dejavu-core` in Ubuntu/Debian distributions).  
###### Past Experiments
I've used other text editors such as Notepad++ and Vim/Neovim to write greentext before, and they work just as well. So long as they have the ability to set syntax highlighting to diff, any text editor will be good for reading and writing greentext.  
If you're (considering) using Vim/Neovim to write, you can use these options to enhance your experience:  
```
:set wrap
:set lbr
:set tw=0
:syntax enable
:set filetype=diff
:colorscheme desert
```

### Prose
In FocusWriter, I typically clone the "Old School" theme and alter it to my liking, usually to green text on a black background with some spacing, indentation, and margin adjustments for my display.  
I then set the font to either [Comic Neue](http://comicneue.com/)  or [Liberation Serif](https://github.com/liberationfonts/liberation-fonts) (as packages `fonts-comic-neue` and `fonts-liberation2` respectively in Ubuntu/Debian distributions), depending on the tone I want to subconsciously set for my story. You'd be surprised how a change in font can change how you look at your own words!  
###### Past Experiments
I've used other rich text editors such as [AbiWord](http://www.abisource.com/), [ghostwriter](https://ghostwriter.kde.org/), [yWriter](http://www.spacejock.com/yWriter7.html), [Manuskript](https://www.theologeek.ch/manuskript/), LibreOffice's Writer, and even Zim wiki pages before, but I usually spent so much time either fiddling with options and annotations or being annoyed at the non-WYSIWYG editors that I never wound up getting very much done, and that's assuming they weren't either feature-incomplete, slow, or buggy, and thus inadequate for the task.  
That said, AbiWord was a very pleasant and lightweight experience, if a little quirky and outdated, and I may end up using it to write my longfics in the future due to it's unobtrusive annotation support. I may also experiment with it's collaborative editing features as well if I ever require an editor that isn't myself.  
I also really liked Manuskript, but the UI, general quirkiness, general software immaturity, and my lack of need for a Scrivener style editor pushed it away for me. Which is a shame, because it is genuinely really useful and is a fantastic FOSS replacement for the likes of Scrivener! If I didn't already have systems in place to document characters, settings, and more, I could absolutely see myself using it instead despite all of it's weirdness.  

### Longer Stories
Longer and more complex stories utilize both Zim wikis for collecting and organizing information, and spreadsheets for arranging and pre-planning scenes, chapters, and entire arcs and acts.  
The wiki contains everything you would expect a wiki to contain: character information, powers, locations, and more. Organization of these wikis tends to mutate from story to story on an as-needed basis. Images may also be attached to and embedded within wiki pages, and Zim also has plugins for adding clickable tables of contents, adding a tagging system for pages, and even adding tables and full GraphViz diagrams to the pages, all without being obtrusive and distracting.  
Zim is also a very good program to take jot-notes in: besides being quick and having a plugin to provide a distraction-free fullscreen editor, my notes can take advantage of wiki features such as hyperlinks to a given note's fully fleshed-out page in the wiki, as one example of the utility provided by taking notes in a Zim page.  
Furthermore, Zim pages may be exported, either individually or as a whole package, to your choice of HTML, Markdown, and even LaTeX and reStructuredText markup with selectable and customizable theming. It even includes an integrated web server to share your wiki on your local network.  
Planning is not done in the wiki, however: that is done in separate spreadsheets.  
The primary spreadsheet is used to plan each scene in the story. My current system is structured like so:  

| Chapter Name | Chapter Number | Scene Number | Perspective | Description                           | Time Taken | Total Time |
| ------------ | :------------: | :----------: | :---------: | ------------------------------------- | :--------: | :--------: |
| Sample Text  | 1              | 1            | Anon        | The giant faggot OP posted            | 1m         | 1m         |
|              |                | 2            | Nito        | /mlp/ was ruined for everyone forever | 2m         | 3m         |
| Bottom Text  | 2              | 3            | Anon        | OP strikes again                      | 1d         | 1d3m       |
|              |                | 4            | Scruffy     | **(USER WAS BANNED FOR THIS POST)**   | 37m        | 1d40m      |

Information in this spreadsheet is filled out on an as-needed basis. Chapter names, for example, are not required until it comes time to publish, nor are chapter numbers until I decide which scenes should be part of a chapter.  
Periodically, the spreadsheet is broken up into multiple different arcs or acts with a highlighted horizontal line of cells, which itself contains a short synopsis of the arc or act in the description column. The scene and chapter numbers reset to one at each of these breaks.  
I shamelessly stole the idea of spreadsheeting for my stories from [Randy Ingermanson's snowflake method](https://www.advancedfictionwriting.com/articles/snowflake-method/) of writing, and I can see why he uses it: it works really well!  

###### Future Experiments
I am still investigating and playing with spreadsheets and lists, and will likely make use of more of them as my process further evolves and matures.  
I have also played around with mindmapping software for my stories as well, using both [Compendium](http://projects.buckinghamshum.net/compendiuminstitute/) and [Heimer](https://github.com/juzzlin/Heimer), but I was not able to integrate them well into my workflow at the time. That may change in the future as I continue to experiment.  

# Publication
Again, the process of publication changes depending on whether I am uploading a greentext or a piece of prose.  

### Greentext
First, the text of the source files is copied and pasted verbatim to a paste service. Then, the same block of text is pasted into a separate temporary document to be broken up into blocks of around 2,000 characters, while making sure the breaks flow well. Once that is done, I then visit the /mlp/ thread the story is intended for, and begin posting each 2,000 character block until I am finished.  
The paste service I currently use is [PonePaste](https://ponepaste.org), which is explicitly made for MLP stories. In the past, I used [Pastebin](https://pastebin.com) as my service of choice, but the website began a site-wide purge of it's content in 2020 that privated and deleted a vast swath of existing greentexts, including mine. You better believe I moved my shit off after that.  
/mlp/ has a 3,000 character limit per post, but it used to be 2,000, and I still write around that assumption. Other imageboards have different character limits and usually have better formatting options. /mlpol/, for instance, has a 6,000 character limit and allows for BBCode-style formatting tags.  

### Prose
I copy and paste the text straight from FocusWriter and into the Fimfiction editor. However, doing this does not preserve any of my formatting.  
While this could certainly be considered an annoyance, especially for longer chapters, I actually use this as a very valuable final editing pass while I reinsert all of my formatting by hand. I have caught numerous errors and have rewritten multiple sections of text by doing this, even if it takes on average an extra half an hour for a 5000-7000 word chapter.  
Once I have published the chapter, I then re-enter the editor, copy the reformatted text, and paste it into a separate text document under `./Production/Final Export` for archival purposes.  

###### Future Plans
In the future, I plan to convert the final exported version from Fimfiction into multiple different formats for other platforms, such as Markdown for Ponepaste or other paste services. Currently I am working on an experimental `sed` script to do this, but I may eventually just settle on using Pandoc with BBCode input added to do the job as well. NIH syndrome is a tough mistress.  
I have no plans to fix the issue of my formatting tags being lost upon copying and pasting into the Fimfiction editor.  

# Technical Details
For greentexts, plain .txt files are all you need.  
For prose, I primarily use RTF documents, as RTF is a simple and universally compatible format that also compresses well due to its pseudo-plaintext nature.  
It should be noted as well that AbiWord's native .abw format is a flat XML file.  
Zim saves to a hierarchy of folders and .txt files, centred around your notebook file. Because of that, you'll always want to store your Zim wikis in a separate directory to prevent it from interfering with other folders.  
Spreadsheets are saved to the .fods format. This is identical to a standard .ods file, but is saved to a single flat XML document instead of a ZIP container file, which has a far inferior compression algorithm compared to 7-Zip's PPMd algorithm.  
Speaking of 7-Zip, this archive is created using the following command, using `p7zip` on a *NIX system:  
` 7z a -t7z -m0=ppmd ~/export.7z . -xr\!Private `  
PPMd is used as the compression algorithm due to it's specialization in compressing text. Given only text and default settings, it will typically produce archives twice as small as maximum LZMA2 compression. I've been careful to choose file formats that are text-based instead of container-based to take advantage of the high compression ratio.  

# The End
Thanks for stopping in! I hope some of this information was useful or interesting to you.  
If you have any questions or suggestions, I always welcome them! I only ask that you ask publicly on the blogpost you downloaded this archive from, so everybody can participate and benefit from the answers!  
You can keep track of me on both [Fimfiction](https://www.fimfiction.net/user/379364/HK-FortySeven) and [PonePaste](https://ponepaste.org/user/HK-FortySeven), and I usually lurk the [/aie/ threads](https://boards.4channel.org/mlp/aie) if you want to say hi. If you want to reach out more privately, you can also contact me via [Matrix](https://matrix.to/#/@hk47:mlp.chat) or [E-mail](mailto:hk-fortyseven@protonmail.com). No PGP, sorry: it a hassle to deal with, and is a bad fit for my horseword threat model.  
