I hope this post finds you well, healthy, and safe as we navigate these troubled times. Luckily for us, we’ve managed to avoid any illness (other than allergies are hitting us hard) and everyone has remained employed. I worked from home before this all hit and the only real change from my day to day routine is that I now have to supervise school work for my kids. Of course that means less time to work on gaming projects. My wife is a college professor and for her things, actually improved in some ways as she could still go into her office but doesn’t have as many distractions every day. It has been a strange time and hopefully we all pull through it without too much damage.
Looking Back
Despite everything going one, I managed to get a new post out every week. The last post (Starship Construction in the Frontier) was only an hour late. I had actually finished it the night before but forgot to queue it up and then was busy in the morning. Otherwise, we had the usual Detailed Frontier Timeline post to start the month followed by the miniature post, this time about the Agriculture Ship. The final post of the month, which was part of the RPG Blog Carnival, was an update to my star sector map generator, this time adding in a graphical user interface making it easier to use.
Now, back at the end of last month, I talked about doing a post on the True Yazira secret society. Which you may notice I didn’t get to. That was actually a conscious decision. That post will probably come in June, when I’m hosting the Blog Carnival with a theme of “Organizations”. But more on that next month.
The other major thing that happened this month was that I finished and published the next issue of the Frontier Explorer. Issue 28 represents seven full years of publishing, even including the year we took off. If you haven’t gotten a copy, jump over to the Issue 28 page on DriveThruRPG and grab one. As I’m writing this, there have already been over 600 downloads of the issue. I’m quite happy with how it turned out.
Otherwise, most of my other behind the scenes activities were completely obliterated by the changes and school closings due to COVID-19. I haven’t even looked at my book. I also didn’t do any work on migrating or updating the websites. The other thing that suffered is my modeling efforts. I didn’t get a chance to work on any new models this month. There were also a few days when I fell a little bit behind on some of my timeline posts on Twitter but I got caught back up and back on track. Although I do need to sit down and get a little bit ahead of that project.
Looking Forward
This month will start with the usual Detailed Frontier Timeline post. The second post will probably not be a new model. I hope to have one later in the month but I don’t think I’ll have one ready by then. Instead the second post will probably be a spin off of my starship construction post. I’ve been thinking a lot about that and had some good discussions on Facebook and I’ve got another post in the work looking at the logistics and economics of space travel, again looking at how that affects the number of ships to expect in the setting. I have no idea what the final post of the month might be as the topic for next month’s Blog Carnival is still TBD. I guess we’ll find out together.
The other thing that will be starting this month is that I’m going to start running an on-line Star Frontiers game. I’m going to shoot for a weekly game but it might end up being bi-weekly instead. We’ll see how that turns out and I’ll probably be posting on that as we go along. If nothing else, I’ll be generating maps and adventures and can post those once the players have finished with them. It may also end up as an actual play podcast if the players are willing to let me record and post it.
The work on the Space Kids RPG hasn’t started yet so that may also begin this month. Nick Landry, who is producing the game, is working hard and may get to the point where he needs my input. At this point, I’m just waiting on him.
What have you been working on this last month? Are there things you’d like to see me post about? Let me know in the comments below.
Way back in issue 10 of the Frontier Explorer (has it really been over 5 years?!?) I wrote an article entitled “How Many Ships Are There?” (p.27) where I examined the number of starships that could be supported in the Frontier given the stated number of starship construction centers and the ship construction and maintenance rules. The answer came out to be around 1500 ships, not a lot to spread around the 17 systems and Spacefleet.
Starship construction image by Scott Mulder
In that article I talked about some of the implications of that small number and some of the ways you could increase the number of ships flying around. If you haven’t already read that article, I recommend you do so as I’ll be building on some of the work there. Although it’s not necessary to follow along.
While I’m very much in favor of small ship numbers, I think that even this is too small for the setting and in this post I’m going to examine the numbers and methods of ship production and maintenance and see what impacts that has on ship numbers.
At least part of the desire to look at these numbers stems from some campaign background work I’m doing related to the Second Sathar War and how the Frontier would respond to the new Sathar incursion. So let’s get started.
The Baseline
To start with, we need to have an idea of what the base production and maintenance rate in the Frontier is so we can see how changes we make affect that.
When I wrote the article for the Frontier Explorer, I created a Python program that would simulate the starship construction centers, their waiting queues, and handle all the book keeping. That is how I generated the numbers for that article. So the first step was to dust that off and get familiar with the code again. If you’re interested, it is in this GitHub repository. There is no documentation and it’s really rough but you’re free to play around with it.
There are actually two different programs in there. One is the simulation I used for this post and the Frontier Explorer article and the other is one I’m using to keep track and generate the sathar starship construction efforts for the Detailed Frontier Timeline project. Both are really rough (although I do have some unit tests). Caveat emptor.
Since we’re just going to be looking at variations, I’m not trying to reproduce the exact numbers from the Frontier Explorer article. In fact, I’m going to use a very different distribution that gives me more ships as a baseline than the number from that article.
For this article, the distribution I’m going to use is one that has roughly equal numbers of ships hull size 1 to 10 (~6.6% each) and then falling off beyond 10 so that there is only about a .5% chance of building a HS 20 ship. This weighs the distribution toward smaller ships. As I pointed out in the original article, the smaller the average hull size of the ships flying around the Frontier, the more ships the canonical starship construction centers (SCCs) can support. The average hull size of ship produced is 6.5.
I’m also making a few other assumptions. First, I’m treating these all as civilian ships, so any ship can be built at any SCC as long as it is less than that SCC’s maximum hull size limit. Also, I’m not factoring the hull availability rules into the simulation. I’m assuming any size hull is always available. Finally, I’m ignoring the “only system ships” restriction on the smaller Class III construction centers. I’m only interested in counts, not types.
The other “feature” of the simulation is that it doesn’t really handle the queuing of hulls waiting to be built in the best manner. It simply looks at the available space and finds the next ship in the list that will fit. What this means is that larger ships tend to get passed over as there is never any room for them. This also tends to skew the ships sizes toward the smaller hull sizes over time.
Image by Scott Mulder
With this ship distribution and those assumptions, the SSCs listed on page 9 of the Knight Hawks Campaign book can support about 2300 ships. Which is already a significant improvement over the 1500 ships from the original article. If you’re curious, reversing the distribution (ramping up to HS 11 and flat thereafter, only allows the system to support about 1250 ships).
Supporting More Ships
Now with that baseline, let’s look at increasing the number of ships we can support. There are several factors that go into the final number: total capacity, ship size distribution, construction time, and maintenance time.
I’m not going to play with construction time. That actually would have little effect on the total number as the steady state is purely based on the other factors, which are somewhat related to each other. Let’s look at some options.
Double the Number of SCCs
Image by Scott Mulder
The canonical set of SCCs has a total capacity of 510 point of hull size across the nine lists construction centers that can be under construction or in maintenance. Let’s start by just doubling that number. Let’s add 9 more SCCs across the Frontier that are clones of the existing nine. We’ll keep the other parameters the same and start up a new simulation.
Running the simulation with the increased number of SCCs results in the Frontier being able to support about 4100 ships, and increase of 1800 ships of about 80%. It doesn’t double as the increased capacity allows a few more larger ships to get built right at the beginning and the average hull size of ships produced jumps from 6.5 to 7. Since the average HS is larger, the total number is less than 2x based on the 2x capacity.
Planetary Small Ship SCCs
What if we try increasing capacity in another way. Instead of just cloning the existing SCCs, let’s give each planet a small SCC that can only build ships up to HS 5 and can handle 20 hull size points of ships at a time. This represents each planet being able to build and maintain it’s own fleet of shuttlecraft and small system ships separate from the main SCC.
If you drop those 22 SCCs (I didn’t give one to Volturnus) into the Frontier, that adds in another 440 hull size points of capacity. Since we should skew to smaller hull sizes being built, we would expect to get a good increase in the number of ships, possibly more than double. Unfortunately, that isn’t what happens. since we didn’t change the distribution of ships we’re drawing from, these small SCCs get underutilized. The total only goes up to about 2400.
I think a bit of this is a queueing problem so let’s just run a simulation with only those new SCCs, but using the same input distribution. I this case we get the system sustaining an additional 300 ships with an average hull size of 3. Still not exactly what I was expecting.
But that distribution doesn’t really make sense. And I think there is still some sort of bug in my code that isn’t doing the queuing properly. So let’s give these smaller SCCs their own queue and distribution. We’ll only pick ships from HS 1-5 for them to build and just make it a flat 20% chance of each hull size. Running that simulation give us that the smaller SCCs can support ~7000 additional ships with an average hull size 2.9. Dividing that between the 22 planets gives us an additional ~320 ships per planet.
That definitely points to something strange happening with the queue when using all the SCCs in a single run. It’s supposed to be dropping the larger ships that are getting passed over after a while but that doesn’t seem to be happening. Or at least not fast enough to fill the smaller SCCs. I’m definitely going to have to look into the queue system I’m using and this may impact the baseline numbers as well (increasing them).
But that means that adding in these small SCCs at each planet increases then number of ships that we can have flying around from 2300 to nearly 9300, an increase of 400%. They are mostly small ships but that may be what you need for all the transport to and from the surface of the planet and within a star system.
Reducing Maintenance
The previous 2 variations just looked at increasing SCC capacity. What if we look at simply reducing the amount of maintenance that a ship needs in a SCC. If ships have to spend less time in the SCC for repairs, then that space is available for new ship construction.
The KH rules say a ship needs to come in every year for 1d10+HS days of repair. And every year they don’t adds a 5% chance of failure of a critical system on a jump and when they do finally get in adds 1d10 days of repair per year missed.
Let’s reduce that. For this try, we’re going to say that they only have to come in once every five years, and that it is still only 1d10+HS days of work to get the maintenance done. Maybe routine maintenance by the crew is enough. Maybe there are dedicated “repair yards” that can handle the work the other years. Whatever the reason is, we are not tying up the limited SCC space with ships undergoing maintenance. We’re going to jump straight to five year so we can see if this is a large effect or not.
Going back to our baseline configuration with just the canonical SCCs and the original ship distribution, this new maintenance requirement results in a new ship count of 6500 ships with an average hull size of 7.0. That’s an increase of ~280%. So we’re getting more and slightly bigger ships. I knew going in that the maintenance was the true bottleneck. I didn’t get quite as many more ships as I was expecting but it’s a significant increase.
However, the simulations I’ve been running only simulate 100 standard years. That’s usually more than enough time to reach a steady state and longer than the history of the UPF at the time of the Second Sathar War. Interestingly, in this simulation, it never really reached that steady state, the numbers of ships were still going up at the end of the simulation. So for fun, I rand both the baseline and the low maintenance option again for a 200 year simulation.
In that case, we did reach a steady state of the number of ships in the low maintenance simulation of 8500 ships with an average HS of 7.1. The baseline sim only went up to 2850 ships with an average HS of 6.25. We got more ships but on average they are smaller. So the low maintenance option represents an increase of 300% over that new baseline. But it’s going to take the Frontier some time to get to that level.
Conclusions
As expected, increasing the number of SCCs increases the number of ships that can be supported. The simulations have given some number to those increases. What I wasn’t expecting was the impact the queuing system I was using would have on the outcome. Obviously a queue that generates ships of the appropriate size for a given SCC distribution can have an effect on the final numbers.
What we found was that just doubling the number of SCCs with the same capacity profile basically doubled the number of ships. That’s probably a good rule of thumb. But if we increase the capacity and limit the ships to smaller hull sizes, we get a huge increase in the number of ships. Limiting the ships to HS 5 or less and with only an 86% increase in production capacity, resulted in a 400% increase in the number of ships.
The other unsurprising bit was that reducing the amount of maintenance required resulted in more ships being supported, I was expecting a nearly linear increase but that wasn’t the case. At least partially because we ended up with more of the larger ships which reduces the total capacity. What was surprising was in the low maintenance model, 100 years of simulation wasn’t enough to reach a steady state on the number of ships.
The truth is, you can have as many ships flying around as you want. If you have more, you can add flavor to your game to describe the extra ship construction capacity any way you want. Then just take the rules as written as the resources available to the PCs. There is more capacity out there, they just can’t access it.
What’s Next?
There are still more things to explore on this topic. Probably the most obvious is looking more closely as the algorithm I’m using to queue up the ships. That apparently has a bigger impact that I was realizing. It was supposed to model the process described in the rules for getting a ship into an SCC but maybe it’s not doing that well enough.
The other aspect might just be the ship distribution I’m generating. Another area to explore is looking more closely at the number and types of ships that are out there flying around and building up a “realistic” distribution based on that. I have looked at that issue in the past and maybe will do a post about it. It produces a different distribution than the one I used here but I’m not sure I really captured everything.
Another thing to consider is the distribution of SCCs. I did some fairly arbitrary changes for this article just to look at gross effects. A more nuanced look at increased capacity might be interesting.
What ideas do you have? Are there specific things you’d like me to explore? Let me know in the comments below.
So I sat down last week with the intention of working on a new spaceship model but I just wasn’t feeling it. On the other hand, I’ve been doing a fair amount of coding at work and was in the programming mindset. I’ve been thinking about getting back to working on my Second Sathar War (SSW) game but wasn’t quite up to tackling that yet. So I decided to dust off the Star Map Generator that I’d been working on (and used to create the Extended Frontier Map) and add a graphical user interface (GUI) to it in order to make it a little more user friendly for non-programmers.
Since the code is written in Python, and I’m already familiar with the wxWidgets GUI framework from my work on the SSW game, it made sense for me to use the wxPython framework, which is just wxWidgets for Python. Since I’m seriously considering converting the SSW program over to Python, this would give me a bit of practice.
Also, this post is going to be my entry for the RPG Blog Carnival this month. The exact topic is “To Boldly Go” hosted by Codex Anathema and is on the topic of exploring the planes and other worlds. It’s couched in terms of Spelljamers and from a fantasy perspective (common with the blog carnival) but I thought, if you’re going to be exploring new worlds, you need a map. So I’m tossing this tool out there for people to use in making their maps.
Building the Basic GUI
The first step was to just implement a basic interface over top of the existing code. The main goal here was to allow the user to specify the various map parameters that up until now, I’ve had to write into the code whenever I wanted to run the program. I’ve never implemented a way to pass those parameters in when it starts. That ability is actually issues number 3 (Add command line parameters) and number 4 (add configuration file option) on my list of open issues. This interface doesn’t solve those issues, but it does provide a workaround.
Building an interface that just accepts some input and stores the values is pretty straightforward and in just a short time (after getting my development environment all set up), I had the basic interface.
It didn’t do anything yet, but could accept the input of all the parameters you need to set to generate a map. Let’s talk briefly about each of those parameters.
Map width – This is just the horizontal size of the map. If you’ve seen any of the maps I’ve made with the program, it’s just the number of boxes wide the map will be. The units are light years (this will be important shortly).
Map height – The vertical height of the map, again in light years
Map thickness – This is the z dimension of the map or how thick of a slice of space you are looking at, again in light years. This is the total dimension just like the width and height. The program will split that into a maximum positive and negative value for use in system generation.
Stellar density – This is a measure of the number of stars that should be placed on the map. The units are star systems per cubic light year, which is why the number is so small. The default value (0.004) is roughly the stellar density around the Sun. If you want your map to a parsec (3.26 ly) per square instead of light years, and keep the same approximate density, you’d use a value of 0.138 (a factor of almost 35). That will be a very crowded map.
Text scale – As I’m writing this I realized this is mislabeled. While the setting here does affect the text size that is printed on the map, it also affects the size of the stellar symbols printed as well. The default is 1 and that is what I used on the Yazira Sector map. However, I used a scale of 1.5 on the Extended Frontier Map.
Output map filename – This is the name of the output map image file. It will be an SVG file and should have .svg as its extension.
Output data filename – This is the output file that contains all the coordinates, names, and spectral types of the stars generated as well as the list of jump routes generated. It’s just a text file and you can call it anything you want. I typically use the same same as the map file but with a .dat extension so I can keep track of them together.
Input data filename – This field is left blank for a randomly generated map. If you specify a name here, the program will try to load that file and use it to generate the map. The file should be the same format as the output data file. This allows you to randomly generate a map, then tweak the data file and have the program redraw the map with your modifications. This is how I made both the Yazira Sector map and the Extended Frontier Map. If the file specified doesn’t exist, the program will probably crash. Or at least not do anything.
Print Z coordinate – This just tells the program whether is should print the z-coordinate (distance above or below the plane of the map) on the map itself. You can see what that looks like on the Yazira Sector Map. I had it turned off for the Extended Frontier Map.
I initially implemented those boxes as simple text boxes but realized that the first five really needed to read in values so I changed them in the code. I should probably change the Input data filename field to be an Open File dialog so that it guarantees that the file is actually there. I’ll need to add that to the open issues.
Finally I added the code to properly process the buttons. Clicking “Generate Map” will do exactly that and write the files to disk in the same directory where the program is located. Clicking “Reset Values” will change all the input values back to the defaults if you’ve made changes.
Making the Program Distributable
By adding the GUI to the program, you need even more setup to run it. Before, you just needed a Python installation as it was pretty vanilla code, but you still needed to install Python. Now, in addition to Python, you need to have installed the wxPython distribution as well. Since I wanted to make this easily usable by non-programmers, I wanted it to just look like another program you that click on and run. So I started looking for ways to package it up for distribution.
It turns out there is a great little Python program called pyInstaller. It takes your program and bundles it up with all the code and files it needs to run and puts it into either a single program file (.exe file) or a folder with all the bits you need and an .exe file to launch it. You can then just distribute it as a zip file, users can unpack the zip file, and run your program.
I tried it out and sure enough, it just worked. You could click on the .exe file and the program would run. Here’s that version of the program. Just download the zip file, extract it somewhere, and run the StarMapGen.exe file.
It works fine, but everything is done behind the scenes and the files are created on disk in the directory where you launched the program.
Adding in the Map
The next step was to add in a map display. I mean, what good is having a graphical interface if you don’t get to see the map?
This is where I ran into the first snag. It turns out that the current release version of wxPython (4.0.7) doesn’t have the ability to read in an SVG file and display it. It can write one if you’ve created your image from it’s primitives, but in my case, I’m writing the SVG directly and just want a display. Luckily, the current development version of the package (4.1.0a) does have that capability.
Normally I try to stick with the released versions of packages, but after looking around, all the other options for displaying SVG files required more packages to to be added to the dependency list and in the end, used the same backend that I would have to install for wxWidgets. So I bit the bullet and upgraded to the head of the development channel. Since pyInstaller grabs everything you need and packages it up, I wasn’t too concerned.
So I wired everything up so that when you click that “Generate Map” button, in addition to creating the map and writing the files, it would then load up the file in to the panel on the right hand side of the GUI. Unfortunately, it ended up looking like this:
Initial map display in the program
Notice anything missing? It’s supposed to look like this:
Full map render in Inkscape
All of the stars and text were missing. Not very satisfying.
Fixing the Stars
For the stars, the SVG code uses a series of radial gradients to create the limb darkening and glow effects and maybe the default renderer just couldn’t handle those yet. After all, it was the development version of the software.
So I started digging. Since the default renderer wasn’t working, I looked for alternatives. The package gives a couple of other options for renderers, the best one being based on the Cairo package. This is the same package that I saw being recommended for rendering when I was searching around earlier. I didn’t really want to pull in another dependency but after trying everything else and failing, I added that in. Unfortunately, that didn’t work either.
However, after some testing, I was able to run the wxPython demos and found that it could render radial gradients. A lot of the sample images had them and the images were created by Inkscape, which I had based my code off of. So it had to be an issue in the code I was writing for the image.
After much experimenting with simple images and trying to render them, I finally discovered that the old Inkscape code I based the SVG data on just wasn’t up to snuff. I originally wrote that code in 2015 and things had moved on. Luckily, it didn’t take much to fix it, I just had to add two additional parameters to the gradient specification to get it to work (cx="0" cy="0" if you’re wondering).
When I next ran the program, the stars appeared!
Render with fixed gradient code. Notice I’m reading in the old data file so I get the same map. Also this renderer makes the grid lines finer so they don’t show up as easily in the small screen capture. They are there though.
Fixing the Text
Next up was to figure out why the text wasn’t rendering.
In the SVG file I’m writing, the labels are all rendered as <text> elements. You’d think that would just work but it wasn’t. After the experience with the gradients, the first thing I checked was my implementation. I went into the new Inkscape and exported a simple SVG with just a few characters. That wouldn’t render.
Next I tried some other on-line SVG code generators to create some <text> elements. Those wouldn’t render either.
I then went looking at the sample SVG files from the demos. In every case, it seems that the text in those files were not stored as <text> elements but rather had been converted from text to paths. In other words, they were no longer text but rather drawings.
It appears that the renderers don’t handle the <text> element. This is a bit of an issue because I want to be able to edit the text as needed. Mostly I’m just moving it around, but sometimes I want to be able to change it as well. And once it’s a path instead of text, you can’t edit the characters. Plus I eventually want to allow the user to specify the fonts used on the map (That’s even an open issue, number 5). I like the defaults I’m using but users should have options.
I could have the program write the paths for the text, it would just require hard coding in the paths for the various characters. Currently there are just 23 characters used across two fonts but I don’t really want to do that as that makes it harder to use different fonts or add in additional characters.
In the end, I decided to pass on this issue for now and revisit it at a later date. The full file written out by the program has the text in it, you just don’t see it in the preview at the moment. When I revisit this, I have several options from just building a library of character paths, writing code to do the conversion from text to paths, or even writing code for wxWidgets to do the text rendering natively. There is also the option to use the native wxWidgets primitives to generate the map and then using its ability to write SVG files to make the map file. All will probably be explored.
After taking a pass on generating text, I did make a banner image for the program to load that rendered the text as a path so you could see it. This now what you see when you load the program.
Program start up screen
Adjusting the Display
The last thing I wanted to tackle in this version was resizing the display. You may have noticed that all the maps I’ve shown so far have been square. But you don’t necessarily want a square map. Otherwise, why allow specification of both a height and a width?
By default you get the display shown in the pictures above. However, I wanted the user to be able to enlarge or reshape the window and have the map expand (or shrink) to fill as much of the space available as possible. This required playing a bit with the layout engine in wxWidgets.
If you notice, in the very first image, the region on the right has a little border around it with the “Map” label. I had intended to keep that border but the layout element that makes it will only resize in one direction and I couldn’t come up with a way to make it stretch in both. It may be possible but I wasn’t finding it and it wasn’t that important. In the end I went with a different element that did stretch the way I wanted, I just lost the border. Which really isn’t that big of a deal.
Now when you generate a map it will scale the map to fit in the available space and then you can resize the window and it will expand or shrink as needed to keep the whole map visible. Here are some examples.
First just a new square map. It fits just fine since the map area was already square.
Next, let’s make the map 30 light years wide. When we hit the “Generate Map” button, we get a view like this:
It’s all there, but has been shrunk down to fit in the space provided. But now we can grab the side of the window and stretch it out a bit to make everything fit.
Packaging Woes
At that point, I was going to package it up as a distributable program and add it to the blog post so you could grab it and play with it. Unfortunately, the addition of the extra dependencies for some reason caused pyInstaller to fail and not make a proper program that I could share. I think it’s just not finding the Cairo rendering library. It has tools to handle that, but I haven’t had time to sit down and figure it out. I finished this last night and am writing this post just an hour before it gets published. Look for an update later this week with the program once I figure it out.
UPDATE:
I got the packaging working. You can grab the version of the program that does the proper rendering of the stars from this link:
Just download it, extract the contents of the folder, and run the StarMapGen.exe file.
Getting the Code
That said, if you’re comfortable installing Python and the dependencies, you can get the code from my StarMapGen GitHub repository. This version of the program is sitting on the master branch. You’ll need to also install the cairocffi Python package and follow the instructions on this page to get the development version of wxPython. Once you’ve done that, the StarMapGen.py script is the main file for the GUI version of the program. makeMap.py is still the command line main program.
What’s Next?
There are a lot of things still left to do and work on. Already identified is the issue of the text rendering in the preview and some of the existing open issues.
A bug that I noticed with the GUI is that if you specify a data file to load, if it’s not square, it doesn’t get scaled properly in the display when rendered and loaded. That will probably be the first issue I track down.
Other improvements include adding a parameter to allow you to turn on and off generation of the jump routes and if you are making them, another parameter that specifies the maximum distance that the program will use to connect systems (currently set to 15 light years).
I also want to add some features to the GUI to include instructions, the ability to save parameter sets, and specify a random seed for map reproducibility.
Finally, I need to do some refactoring of the code to clean it up and document it better.
I’ll be working on this more in the coming weeks so expect to see updates in the future. If you’d like to help out with the code, feel free to clone the repository, make changes and submit a pull request.
What do you think of the program as it now stands? Are there features you’d like to see? Let me know your thoughts in the comments below.
I had originally planned to start in on the models from the Privateers boxed set after I finished the freighter from the Federation ships box, but a discussion on the starfrontiers.us site put agriculture ships in my brain and, since we had some silhouettes and a counter for these ships, I thought I might make a model of one of those first. Let’s look at these ships.
First of all, here are the images we have to work with:
The black and white drawing is from page 7 of the Knight Hawks Campaign book and the inset is the counter.
Both of these images show a long, spindly fuselage, a bit of a structure at the bow, behind the domes, and at the tail, and of course, the big agricultural domes themselves.
Now, you can debate as to whether or not these ships actually make sense or not. Especially as depicted here. And that’s part of what the discussion on the starfrontiers.us site was all about, but they are included in the game so I figured I’d take a crack at making a model. While I’ll stick with this basic idea, I’m going to make a few changes.
The Model
Here’s an image of the final Ag ship model. As you can see, it differs a bit from those silhouettes. Let’s talk about what I did.
First, I decided to make this model a hull size 10 ship, which for these types of ships, is a little on the small size. The rules say that Ag starships are typically hull size 8-16 while system ships have hull sizes in the range of 10 to 20.
As pictured in the silhouette images, the ships seem to have a single large chemical engine mounted at the tail. That sort of makes sense for a system system ship but just barely. If they are just floating out there collecting sunlight, then everything is growing in zero-gravity. On the other hand, if you want some sort of gravity in the ship, you need to be constantly accelerating (no artificial gravity in Star Frontiers). In the latter case, chemical drives don’t really make sense. So I decided to give the ship ion engines instead. For the model, I used the same engine design I created for the minelayer miniature. It the same size (a Class B engine), but I used two struts to attach them to the hull in this case.
The other difference with the engines is that I used three of them instead of just one. The ship construction rules call for three engines on a hull size 10 ship so that is what I went with. I guess a single Class C engine would do the trick but let’s stick to more standard designs for now.
Like the images, this model has a long, skinny fuselage. But it’s kind of hard to see as I added a bunch more to the ship. The bit at the end is modeled on the tail of the ship in the black and white image. You can’t see it in the model image above but the section right under the domes is also thicker like in the silhouettes. And I also used the same style bow.
I modeled the domes on the image from the black and white image rather than the counter and just put four of them on the ship. On a larger ship, I would probably keep them the same size and just add more of them as is represented on the counter.
The main difference between my ship and the images is that I added some large storage tanks below the domes, and piping to connect them. I figure this is where the extra nutrient solutions, air, and water are stored as they are cycled through the domes. I also figure this area contains the processing machinery.
Another thing I added was lights on the underside of the bow. If you click on the model image above, you can just see them. There is one pointing at each dome. These are powerful, full-spectrum lamps that can be turned on to provide illumination to the domes when the ship is not pointed directly at the sun. Or maybe they are used all the time. If you’re flying around the system, constantly keeping the ship at 1 g, there are going to be many times that you don’t have the domes pointed at the star. In any case, they are a small feature on the model.
This model was created at 1/3000th scale, or 3 meters on the ship equaling 1 mm on the model. This is the same scale I used for the sathar Destroyer and CDCSS Nightwind and roughly the scale of the UPF Frigate, Destroyer, & Minelayer. When I start making a new set of ships after finishing the privateers, the models will all be made at that scale. The fuselage of the ship is 240 meters (80 mm) as is standard for a HS 10 ship. It’s a lot skinnier than a typical HS 10 ship, 15-20m diameter compared to 40, but I figure the extra hull goes into the domes and the storage tanks. With the engines added, the model is 92.67mm long, giving the ship a total length of 278 meters. Across the widest point of the domes it is 56.66 mm or 170 meters.
Printing
With the model complete, it was time to print it. The image at the right shows the hull size 10 Agriculture ship (black) next to the Nightwind freighter (green) and sathar destroyer (red, painted). Unfortunately, the black resin prints don’t photograph very well.
For the most part, the print came out very well. But it needed a lot of supports under the domes. For this print, I printed it upright, just as pictured (and how I’ve printed all the other ships) and used the default supports that the printing software supplied. Unfortunately, that wasn’t quite enough support under the domes. Mainly, the supports could have been placed better and on the edges of the domes, not just the underside. The result was that the physical shape of the underside of the domes is a little warped, rounded were it should be flat and angled. I think in the future, I will print the model at an angle, tilted 30-45 degrees. It will require much less support material and the surfaces will come out better as the printer has issues with large horizontal surfaces that are not touching the build plate.
Up Next
Next up is working on the Privateer models. I haven’t done any modeling recently due to all the life changes resulting from the COVID-19 pandemic but will be getting back to it in the next week or so as life has finally settled down to somewhat of a routine.
I also plan to revisit this ship in the future and create a HS 20 version with more domes. That will probably have to be printed in parts as I don’t think a full scale HS 20 ship will fit on my printer, It’s a bit larger than my print volume, at least printed vertically.
Like all the other models, I’ll be adding this to my Miniatures Price Table if you want me to print you one, and putting the model up on DriveThruRPG on my 3D Models page if you just want to grab the model file and print it yourself.
What do you think of the Ag Ship. Have you ever used one of these in your game? Share your thoughts in the comment section below.
This was a busy month on the Frontier (and beyond). The HSS History’s Hope finally overcomes their misjump issues only to be ambushed by an unknown assailant. A strange computer virus nearly destroys the Moneyspider, and the ships of the Discovery Squadron, on their way home, engage and destroy a sathar raid in the Zebulon system.
As always, you can follow along daily on the Star Frontiers Twitter feed if you don’t want to wait for the monthly summary.
Date (FY)
Events
61.020
Castuss Wallorr (yazirian), the sape handler on the Moneyspider, is launched out of the ship on a lifeboat. His distress call causes the ship’s roboticist, Daqor Klarr (vrusk) to snap and have to be restrained. (SFAD5)
61.021
– Baralou Ap-Reaverchan (yazirian), Moneyspider’s astrogator, is killed in a sudden explosion in the life support system on Snobol, the asteroid the ship is tethered to. (SFAD5)
– On their return to the Moneyspider from Snobol, the elevator fails and the crew that responded to Baralou’s distress call are severely injured. (SFAD5)
– In the confusion of the elevator crash, Daqor, sedated in the Moneyspider’s medical bay, is killed by an overdose of anesthesia. (SFAD5)
61.022
Calculations mostly done, the HSS
History’s Hope begins accelerating for its jump back to the YS01 system.
61.023
– The Moneyspider’s security robot malfunctions and starts shooting holes in the gas tanks holding the filtered toxins from the planet’s atmosphere. The life support system is also malfunctioning and not filtering the air. Fiator Geauis (dralasite), ship technician is killed due to a sabotaged gas mask. (SFAD5)
– Ellen Coopermann, as the only survivor of the original crew is the prime suspect, but she convinces the rescue party she is innocent. She begins to believe the rescue teams account of the Matrix and works to help them eradicate it. (SFAD5)
61.024
After many weeks of behind the scenes deals and increasing discontent over the practices of the Groth Energy Corporation, the creation of a new entity is announced, the Consolidated Nebula Energy Group (CNE) (ZG), formed by the merger of the three largest independent energy producers on Groth. All smaller energy producers are invited to join.
61.025
– Despite their best efforts, the techniques that worked on Jetsom aren’t working to destroy the Matrix on Moneyspider. (SFAD5)
– Looking through the Captain’s Computer/Robot System’s Manual Ellen learns that Baralou, the astrogator is listed as one of the ship’s robots, which means it was not her body recovered in the explosion on Snobol. Baralou becomes the prime suspect of all the deaths. (SFAD5)
61.026
– The Sathar starship construction center in OFS111 completes a light cruiser.
– Her secret discovered, Baralou attempts to eliminate Ellen and the rescue team. After a running fight through the ship between the surviving crew members and Baralou, who is aided by the ship’s robots and automated defense systems, Baralou is neutralized. (SFAD5)
61.027
– The Discovery Squadron arrives at Faire in the Capella system. They spend three days on the planet before heading on to Zebulon.
– The HSS History’s Hope successfully jumps into the YS01 and begins decelerating. Jump calculations are begun anew for another attempt at the jump to the YS02 system.
– With Baralou gone, the remaining crew on the Moneyspider slowly begin to make progress on destroying the Matrix from the Moneyspider’s systems. (SFAD5)
61.028
An attempt is made to
sabotage the Minotaur (Theseus) shipyards. It is foiled due to increased
security after PGC shipyard attack a few months ago.
61.029
– Deceleration nearly complete, the HSS History’s Hope is set upon by an unidentified, armed vessel that does not respond to any attempts to communicate. While obviously of Frontier origin, the vessel is not one that the crew has seen before. An SOS is broadcast via subspace radio to the Frontier.
– In the ensuing fight, the HSS History’s Hope’s engines are severely damaged but a lucky shot by their gunner sends the assailant spinning out of control, ending the fight. The crew rushes to fix the engines and get underway before the assaulting ship can repair itself and return.
61.030
– Having remained undetected as they drifted through the outer system, the sathar ships in the outer Kazak system begin slowly changing their vector for a jump to Zebulon.
– Just hours before the relief ship arrives at the Moneyspider, the crew eradicates the last vestiges of the Matrix from the ship. The remaining crew board the relief ship to head back to the Prenglar system. (SFAD5)
61.031
With the “fall” season approaching CDC
decides that winters are too harsh to keep the crew on Alcazzar (Rhianna) and
stop operations for the year after mining over 6.3 million credits of
resources, mostly gold. (SF4)
61.032
Repairs of the HSS History Hope’s
engines take much longer than expected. Luckily, their assailant failed to
return. The crew debates whether they should return to the Frontier for
complete repairs or push onward.
61.033
After much deliberation, it is decided that the HSS
History’s Hope will push on but not transmit their completed routes back to
the UPF for registration, but only to Histran to track their progress. Calculations are begun again for a jump to
YS02.
61.034
Repairs at the PGC shipyard (Gran
Quivera, Prenglar) restore capacity to 80%.
61.035
– Repair work on the Triad SSC continues. The construction center is now at 85% of its original capacity.
– The Discovery Squadron makes the jump to the Zebulon system and starts decelerating toward Volturnus.
61.036
– The sathar ships from OSF019 make the jump and arrive in the Zebulon system. They start decelerating toward Volturnus.
– Initial calculations complete, the HSS History’s Hope begins accelerating once again for a jump to the YS02 system.
61.037
– Sathar ships are detected by Discovery Squadron and messages are sent to Spacefleet, Pale (Truane’s Star), and Strike Force Nova announcing the sathar presence in the system.
– As the only armed vessels in the system, Discovery Squadron is ordered to intercept the sathar vessels despite being severely out classed.
61.038
The decision by Obar Enterprises to not
report the Truane’s Star-Cassidine jump route has paid off nicely. In just 100 days, they have made over 1.6
million credits in gross profits, more than double what would have been
possible before the jump route was plotted.
61.039
– Discovery Squadron intercepts the sathar ships. Whether due to a sizable skill differential or simply good luck, the smaller UPF ships manage to destroy all 4 sathar vessels. Unfortunately, the militia frigate and one of the Streel corvettes are lost while the other 2 corvettes are severely damaged.
– Realizing that they have too much force projected into the Rim, and that the sathar seem to have a way into the Frontier around the ships station in Kazak, Strike Force Nova begins a high-speed transit back to Frontier Space. Patrol Group Virgo is split off again and remains in Kazak to bolster the Rim defenses in that system.
61.040
– After making critical repairs, the remains of the Discovery Squadron begin making their way to Volturnus.
– The HSS History’s Hope successfully arrives in YS02, much to the relief of her crew. They begin decelerating and plotting the return jump to YS01.
61.041
The sixth saurian Ark Ship is completed and begins
its shakedown cruise.
61.042
Information is uncovered that the
buyout of Groth Energy may have been orchestrated by the group known as the
Investors. The reporter that uncovered the leak is found dead after falling
off of his 16th story balcony in downtown Port Loren (Gran Quivera,
Prenglar).
61.043
The Discovery Squadron pulls into orbit around
Volturnus where they start working on more repairs and resupplying the
assault scouts which had depleted all their assault rockets in the fight with
the sathar.
61.044
Strike Force Nova jumps into the Osak
system but remains near jump speed as they compute the next leg of their jump
to Capella
61.045
Deceleration complete, the HSS History’s Hope begin
accelerating for the jump back to YS01.
They are aiming to arrive high in the system to attempt to avoid the
assailant that was there last time if that ship is still in the system.
61.046
– Repairs complete, the Streel corvettes begin accelerating for a jump home to Truane’s Star. The assault scouts are ordered to stay in the Volturnus system for the time being to provide early warning and defense of that system as Spacefleet finalizes it’s plans. Discovery Squadron is officially dissolved.
– Strike Force Nova jump into the Capella system, again remaining near jump speed as they compute a jump to the Zebulon system.
61.047
Fortress Kdikit (Madderly’s Star) completed.
61.048
After much debate, and heavily swayed
by discovery of the sathar presence in OFS019 and the recent events in the
Zebulon system, the Council of Worlds authorizes additional spending by
Spacefleet to commission several new vessels.
61.049
With the go-ahead and funding from the Council of
Worlds, Spacefleet decides to exercise their development plan Sierra Foxtrot
Meteor, which builds out another Strike Force similar to SF Nova. Orders are placed for vessels from various
shipyards around the Frontier.
61.050
The HSS History’s Hope successfully
makes the jump back to YS01 arriving high in the system as desired. They
immediately begin decelerating and scanning the system for any other ships as
they start in on engine overhauls and plotting the jump back to YS02.
