Starship construction software

[Zparkz]

For those of you who know me as an infrequent poster on the TML I have metnioned there that I am writing software to construct starship by the process given in BL and FF&S lending a few things from FF&S2.

At the moment the feature list contains
- Thrust to weight ratio to calculate maneuver G
- Editable weapondatabase
- Adding custom crew
- Adding custom components that cannot be constructed with this software
- Customizable damage location charts
- Saving files in xml format
- Supplies/galley
- Cargo handling equipment
- Alternate internal gravity systems

The software is at the moment about 30% finished.
Finished systems are:
Hull calcs
Electronics
Communications and sensors
Engineering (85%/a few bugs need to be squashed)
Beam weapons

I would like to get some input on what potential users would like to see. The software is being written in VB.net I will probably make the source code available for others for converting to other formats.

 

[aramis]

THe alternate LS from FF&S2, and T-Plates being handleable.

T4 rating output would also be a nicety.

 

[Antony]

Also the planetoid rules from FF&S2 which FF&S1 does not cover at alll would be useful

 

[Zparkz]

Planetoids are already added. Allthough with a twist as the hull parameters are calculated a bit differently in FF&S2

I don't distinguish between planetoid hull and buffered planetoid hull. Rather you select how many armor points you desire, then hull thickness is calculated from there. Most plnaetoids would probably need some sort of reinforcement to prevent it from cracking during maneuver stress. And yes it will also be unstreamlined.

 

[Antony]

That is pretty much how I did my planetoid ship. No difference between normal and buffered planetoids. After discussions on the COTI No spinal weapons, though parallel ones are ok (no real limit on these as the hull is assumed to be roughly spherical)

Possibly a limit on max G's dependent on the hull material. Can a rock 200m across make a 6G turn without stress breaking it up?

 

[Zparkz]

I would say that depends on internal structure which would probably be of the best type material available at that TL. However how much extra structure that needs to be added is not determined at this moment.

Either way, hull material for a planetoid ship will take up so much space that internal space gets very limited. So maneuver drives and reaction mass will be very limited.

I would envision two types of hull. Spherical and cigar formed.

 

[Zparkz]

Another feature I am thinking about to add is robotic brains with skills to the controls section. Thus giving a starship a frame of independent operation depending on its skills.

In a way Traveller canon does not directly support this, but I would like to think of the starships as more independent from the crew in certain ways. Think HAL 9000.

What are your thoughts?

 

[Uxi]

Look up Annti's spreadsheets. Save you from reinventing the wheel, probably, at the very least.

You integrate deckplan design and maybe some rudimentary exterior CAD-type stuff and I'll DEFINATELY be interested.

 

[Zparkz]

I have looked at it, and I prefer my own. Mine is not better, but I prefer it. However my motivation to make a spesific software for this is to simplify several steps that are not so simple to do in a spreadsheet.

Hit locations for one, possibility to refine/adjust/modify the data file later in a third party program as the datafile will be in xml format.

Possible tie-in with a possible future starship combat software.

I am not that good in programming to include CAD style editing of inerior/exterior features. However if someone is willing to do an add-on be my guest. However I have not come far enough in the work to include saving to XML or setting up damage tables.

 

[TheDS]

Dude!!! Just how serious are you in this matter? Like, in the past, have you completed large projects, or (like most of us) do you get bogged down and give up half way through?

Next Q, do you have the supplemental rules? The errata, Challenge 75, RC Equipment Guide, Striker 2, Virus Fleets, and World Tamer's Handbook, for instance? I presume you have FFS2, since you mentioned it. PM me or email me about this.

Next Q, will you consider adding things that were missing in the original book, like for instance wet ships? I got the GURPS vehicle designer a few months back, to give me an idea on how to do this for my own FFS3 project, but it's written only slightly better than FFS2, so it took Herculean efforts to read it all the way through. Stupid me, I got stuff on the inaccuracy of Pulver's formula to figure out wet-ship speed, did some digging, and found out that the real life stuff is so complicated, they tell you to build a model and test it! Jerks! Maybe if I took a hydrodynamics class I could get at least some ESTIMATIONS, but I just couldn't get anything useful off the web with my apparently limited Google-fu.

At least I got a couple interesting threads going about it.

Next Q, how TNE will this be? For the most part, FFS encouraged the designer to use whatever they wanted, but focused on official material. For instance, they outlined various types of FTL equipment, after detailing jump drive. So I guess what I mean by that is, if I want to assume that jump drive uses so much fuel because it's actually water mass for storing waste heat (also another real good thread) and not physically consumed or dumped overboard, am I going to be able to do it? I want to do this for regular reactors too. Unrefined fuel would be water with impurities that cannot hold as much heat as water can, for instance (or whatever we decide our working fluid will be). Hydrogen turns out to be a lousy means of cooling, and it is mentioned all over Traveller material. Anyway, that's a discussion for elsewhere, not here, I just want to know if I can do it.

Also, I have worked on sensor profiles a bit, and would like to know if I can have a more detailed sensor profile. Simply basing sensor profile on overall size, modified by emissions and EMM, just doesn't do it for me. I have 3 basic profiles (minimal, maximal, and typical) and these are modified by a number of factors, to reduce munchkining a bit by making the final result harder to predict and therefore to munchkinize.

Seeing as how this COULD be used to run a combat simulator, one needs to be able to handle things without having to rely on commenting. Case in point would be the Clipper Ships. These things have so many possible configurations, it's not even funny. What is the solution? In the books, they made use of a TON of comments (several pages, effectively, describing all the modules and a few sample combinations), but in a program of this nature, this isn't necessarily possible. Though you could create a module as an ITEM, like a laser gun, it would have (potentially) as many statistics as a regular ship (indeed, you can design a ship to be a module). This will be a tough one to figure out, and I invite you to not think too hard about it until it's time, but I thought I'd mention it in case you'd already found a solution and was dying to share it with us, if only some dunderhead would ask.

 

[Zparkz]

Thanks for your lengthy reply.

I hope to finnish this work before summer, but I am tied down by Real-Life[tm] issues to, and will possible take some evening courses over the new year. But I intend to make it happen. I know everything about being bogged down. My Gvurrdon Campaign book available from my Traveller web site took me more or less 10 years to finish, even when 80% of the material was finished when I started.

First of all I a more familiar with TNE FF&S than T4 FF&S and will adhere quite close to the former due to this. I will stick to starship and spaceship design. There will be possible to design weaponmounts limited to spinal mounts lasers, PAWs, Missiles, repulsors, tractors.

Planetary weapons like CPR and Fusion guns will not be covered in this software, but there will be possible add different items designed outside the software and add them in a modular fashion.

I have been thinking about modular designs like the clipper and have not come up with a solid solution yet.

When it comes to alternate tech, I'll add that to the design sequence in a limited fashion. The aim is to conform more or less to OTU. Making a program cover every aspect of FF&S are just too much.

 

[TheDS]

K.

I was more mentioning FFS2 in the same way that you did, that it had some improvements to a lot of things, and would still be quite compatible with TNE/FFS1. FFS2 loses major points for being so bloody hard to read, and serves as an example (to me) of how NOT to do something. Especially poingiant when it's close to the way I WOULD have done it. I try to learn from mistakes, even when they're not my own. Anyway, I just wanted to make sure you had one.

I am sure a lot of people will argue that CPR and fusion are still usable in space, but under the right circumstances, not as the prevalent weapons they were in earlier editions. What's a great anti-boarder weapon? A CPR gun near your docking hatch. No energy signal to detect, and from the outside it looks like any other hose attachment for cooling or whatever. Only problem is if densitometers have really high resolution and are cheap enough to be standard equipment on a pirate ship. Other problem is if this secret gets too widespread, someone will develop a counter to it.

There are other circumstances to use these weapons, but I won't go into them here.

As long as there is a way to add them as modules or something (which appears to be the case) at a later date, I am happy.

Modability is the key, I believe. As long as a person can easily add things to your system, it will not disappoint; people will have only themselves to blame for not USING the tools, if you make them.

At any rate, do you need some one to look over what you've got? Generally that's what people ask for when they're announcing projects such as this. While not a modern programmer, I have done it in the past and have half a clue what's reasonable to ask for and what's not.

My first suggestion, if you have not already done it, is to use comma seperated values for your modules/tables (or something along those lines), so that a person can easily import into Excel or something, generate a table, and then export it to CSV. I use Excel extensively when making tables for games, and know of others who do this as well.

Each item in each list should have - among all its other stats and descriptors - a unique IDtag, so that in the main chart detailing the ship, behind the scenes you can simply reference the files with the parts in them, rather than having to copy the whole thing. Sure, you'll want to copy the important stats: name, volume, mass, energy, cost, number, and a couple others into the main ship sheet, but the niggling details and descriptions can be left on the tables and called into the program when needed. Saves room on the hard drive that way.

Of course, on printing out, a person wants all those niggling details, but that won't take up any extra space once it's been compiled together and printed out and discarded.

For user interface, I like to see tooltips for things so that I don't HAVE to press them to find out what they do, or in the case of menus, unless the function is obvious, it should bring up a small window for receiving instructions/parameters and a one-liner about what the function is. For instance, PRINT needs parameters and you don't necessarily want to print the instant you hit that button, but Enable Toolbar doesn't do much and so needs no dialog. Just examples off the top of my head.

Lastly, something i find important, I like resizeable windows and small borders. I dislike huge or non-existant borders and fixed windows. Now and then, I like to alter my screen font size, and non-resizeable windows don't react well to this at all. Allowing copy/paste is an excellent idea too.

Oh, one other thing I thought of. It should be able to link into various things. For instance, maybe I typed out a real good summary of my ship, but don't want to import it into the data file. (You don't really want large blocks of text winding up in a single cell in Excell anyway; it doesn't like more than 255 characters at a time.) Or say I want to add a picture or 10. Or say I want a weblink pointing to my website full of designs. Well, I'd like to attach these things, and I'd like, if I want, to have a thumbnail for these links, and I'd like, if I want, to position them where I want on the page.

Other than that very last thing, it shouldn't be too hard to do this, as you're only linking another file. To save you the hassle of coming up with a pisture-display software, simply allow the user, in Prefs, to specify the viewer they'd like to use. I for one use ACDC3 since it's clean and handles everything, though I can tolerate Paint, which handles very little, but at least it's still the most useable such program I've used not on an Amiga.

 

[Zparkz]

The software are being programmed in VB.net
For the moment I have only considered a full save file with all the pertaining data about the ship/craft. But as the file will be in XML format it should be easy to filter the content if is is needed for something specific like a third party deckplan designer or something.

Unfortunately the window is fixed size, and most items will be self-explainable.

For other types of weapons, they may be designed seperate then go to the modulary section and add its values there.

As I am not a programmer by vocation, this will not be a professiona software for sale, but a tool for those who want to crank out starships easily and without much hazzle with a spreadsheet and so on.

Full support will be given to printing and screen display (web page or something similar).

Even as I am not currently working towards the kind of tool you are asking for, I appreciate your input as it gives me something to implement after a working version 1.0 is ready.

I also intend to release the source code when the software is ready for others to toy with and port to other platforms if needed.

 

[Falkayn]

Originally posted by Zparkz:
I also intend to release the source code when the software is ready for others to toy with and port to other platforms if needed.

Cool, that would be much appreciated.

I decided to do my T20 design software as a spreadsheet mainly to ensure that if I ever lost my enthusiasm it could be picked up by others and completed/tweaked.

And I AM a software developer by trade.

 

[MR TEK]

I DON"t like speadsheets from user prospective. They are clunky, hard to reset, unless you provide a very carefully thought outt and easily accessable clear button.

And unless you mticulusly lock every formula cell, sonner or later I enter something over the top of a formula. And if you do go to all of that trouble you just killed their SOLE virtue. They are no longer easy enough to change to make up for all of their shortcommings.

Besides which, unless a GREAT deal of work is done to format and lay them out, they always look amiturish.

I will use one if NOTHING else is available, but these days with even an old version of Visual basic and access, a trained monkey can produce a far superior product that looks professional, and in less time too. And import and export into files usable by other applications can be added almost as a after thought.

I have done projects large and small in multiple laguages and programming enviornments. Somewhere I may even have my old High Guard excel sheet from the '80s but I would not care for anybody else to suffer with it, no matter how much I cleaned it up.

 

[RainOfSteel]

Originally posted by Mr TeK:
I DON"t like speadsheets from user prospective. They are clunky, hard to reset, unless you provide a very carefully thought outt and easily accessable clear button.

Just FYI:

The original spreadsheet can be saved as a template. To &#147reset&#148, close it without saving, and open a copy of the template (if necessary, save the new document as the same name as the previous document, overwriting it).

 

[RainOfSteel]

Originally posted by Falkayn:
I decided to do my T20 design software as a spreadsheet mainly to ensure that if I ever lost my enthusiasm it could be picked up by others and completed/tweaked.

And thank you for doing so!

(For both making it, and making it easy to maintain.)

 

[Falkayn]

Originally posted by RainOfSteel:
And thank you for doing so!

(For both making it, and making it easy to maintain.)

You're welcome!

But I agree with Mr Tek, spreadsheets can be a painful, ugly tool to use. That's why I created a master sheet which should be copied within the workbook in order to create a new ship, and the cells can be unprotected without a password. I also spent a lot of time trying to get it to look good, and making export/print functions that work nicely (into RTF and HTML).

 

[tne_gm]

Do you have an idea for the XML format, or is that a future consideration. I have often thought that there should be a standardized list of tags for XML for characters and ships and weapons and etc. That would make it so much easier to transfer items to a website for example, or to reverse engineer someones design.

Anyway, if you have a format, I'd like to see what you have in mind. If not, I'd be interested in helping out coming up with the layout.

Thanks
Paul

 

[Zparkz]

The XML format isn't nailed properly down yet. I need to read up on it and run some tests. it alsi depends on what information I am going to need to include in the file.

But basically it will be something like this:
<ship>
<various stats like weight, price, size etc>
</various stats like weight, price, size etc>

<Armamants>
</Armamants>

etc

</ship>

Help and advice are most welcome as XML are quite new to be and the instructions in the VB.net suite are hard to follow sometimes. At least until I get a better grip of things.