One of the things that drew me to the Swarm Cycle was the incredibly rich environment these roughly fifty authors have created within the 291 stories on SOL, ASSTR, and which includes a number of unpublished titles, and written since Thinking Horndog started out with "Average Joes" in 2007.
Of course that means that I need to make sure that I'm being consistent with all that as I'm writing. I don't want readers to think "hey, it was different in that other story I read" and I wouldn't want to disrespect other authors by having my stories conflict in incompatible ways. For example, if a rifle in story "A" shoots bullets, but in another I say that same rifle shoots laser beams, haven't I just demonstrated to the author of story "A" that I don't value his contribution?
That's where I found myself when I was on Chapter 8 of "The Troubled Celestial River." I discovered that a weapons system on a ship had previously been established to be entirely different than what I thought it was, and those specific "facts" of that system were rather important to the story. I was building a narrative on something that was "wrong," so I needed to back off and get it "right" before I went further.
Now imagine yourself as needing to research such a huge body of works to find out a very few specific details. Google? Nope. Use SOL's search feature? Terribly unwieldy, and the stories aren't all on SOL anyways. Oh, I've got an archive all in epub format, maybe I can search on that? Nope.
That left me with a couple of options. I could depend on the availability of the other authors on the mailing list to answer questions they probably regard as unusual at best, in hopes they'll accurately remember the contents of all these stories and be able to talk about details involving the specifics of ship's weapons systems. These are great guys, but omniscient they're not. They could suggest a few stories I could read that might answer the questions I had, but asking for more than that is foolish.
I could also depend on the resource they use to document the "universe" to have the answers I needed. Well, if you've ever seen how eager folks like engineers are to fully document their creations, you'd think their dedication to such a task to be amazing compared to how authors like to document their works. The documentation isn't comprehensive about technical details, wasn't always well-organized, and maintenance of the repository had fallen to a far-distant priority behind actually writing stories. It had a decent amount of broad information, but real deep details, not so much.
If this was a problem for me, I thought it might be a problem for some others, so on Labor Day I started trying to solve this underlying issue so that not only could I find information I was looking for on my own, but everyone else could as well.
I converted story archives to text format, I wrote python scripts to do context-sensitive searches within that archive to find references to keywords. I wrote other scripts that could analyze a story and give me some idea of what it talked about and the level of technical detail it went into. Then I started plugging the output of these scripts into the repository, so if you wanted to find out about "missile launcher" you not only could read what the repository had to say about it, but you could read the top twenty most relevant paragraphs that talked about them across all those stories.
So now every time I have a question, I have some scripts that can help me either find out the answer, or point me to precisely the story I need to review to find it. And I can share my results, so if anyone else has that same question, all my research is available to them.
Yeah, back in the day I used to be a computer geek, so if I can solve a problem with code, that's what I do.
So now I can get back to writing. I have some major revisions (at least to me) to do, and once I get the seven chapters previously posted squared away, I can resume moving forward. And the next time I have a strange question, I don't have to spend two weeks doing software development and data management before I can get an answer, so this should not only make things move more smoothly, but I hope it's going to improve my final product.
I'll bet the (thoroughly amazing) DiD folks are going to be contacting me next. No, I don't need to add volunteer data management guru to the list of things I do.
SGTStoner