FFS3 for T5

[Malenfant]

Originally posted by robject:
</font><blockquote>quote:</font><hr />Originally posted by far-trader:
It does? How? The only way to avoid [the near-C rock] problem is limit the maximum speed (not thrust) of the drives or maybe restrict them to operating only in a gravity well.

Marc is seriously thinking about slashing M-drive thrust outside of a gravity well to something painfully low.</font>[/QUOTE]Of course, that means knowing what the gravity field strength is at a given distance from an object. Or is Marc just going to say "beyond X distance, it don't work" again, which (like jump drive's 100D limit) is in reality a completely arbitrary limit that has absolutely nothing to do with gravity at all?

 

[Malenfant]

Originally posted by Andrew Boulton:
A few things have just occurred to me:

- if people really can't handle a bit of maths or don't need the detail, there's no reason why they can't simply use LBB2 or HG - the results will be *roughly* the same, and good enough *for them*.

It also occurs to me that if people "can't handle a bit of maths" then they really shouldn't be trying to design spaceships at all . Maths is pretty much inescapable in any design sequence - even the relatively simple effect-based ones used by Dream Pod 9 for their Silhouette system has some maths in it.

 

[Scott Martin]

Originally posted by Anthony:
Ideally, the costs for components would be fixed to deal with TL differences; components which aren't as efficient would be cheaper. For example, under high guard, you might set it so TL 15 PPs are 3 MCr/dton, TL 13-14 are 1 MCr/dton (2 MCr/EP), TL 9-12 are 0.5 MCr/dton (1.5 MCr/ep), TL 7-8 are 0.3 MCr/dton (1.2 MCr/ep).

Why?

Should I have paid less in 1988 for my 486 so that it woulod be cost-effective in comparison to the notebook that I'm currently using? (which I paid far less for) Should a condetorre in 16th century spain get a "rebate" because his wheellock is so much less effective than the hunting rifle I can buy in Wall-Mart?

Technology makes things cheaper. Be aware of this before you try to "level" the playing field, because technology by its nature acts to "unlevel" the field.

That's why companies (and nations) *do* research and development.

Scott Martin

 

[Andrew Boulton]

Originally posted by Malenfant:
It also occurs to me that if people "can't handle a bit of maths" then they really shouldn't be trying to design spaceships at all . Maths is pretty much inescapable in any design sequence - even the relatively simple effect-based ones used by Dream Pod 9 for their Silhouette system has some maths in it.

I made a similar point elsewhere - we don't need to dumb-down FF&S3 because only gearheads will buy it in the first place.

 

[Border Reiver]

I suppose it's about inclusiveness.

You don't want to scare folks off with byzantine formulae but then you don't want to alienate gearheads with oversimplified design sequences.

Although MT's and Striker's design sequence was riddled with errors it did manage to attract all sides by extensive use of charts and a low math quotient compared to things that were to follow.

Out of interest, what were the major flaws with FF&S2 other than bad layout?

 

[Andrew Boulton]

Originally posted by Border Reiver:
I suppose it's about inclusiveness.

That's why the plan was to have

A. A detailed system (improved FF&S2)
B. A simplified, modular system derived from A
C. Plenty of pre-designed ships

The modules from B could be used with A, and to modify the stock ships.

Out of interest, what were the major flaws with FF&S2 other than bad layout?

IMHO, the lack of standard modules.

 

[whartung]

Originally posted by Andrew Boulton:

</font><blockquote>quote:</font><hr />
Out of interest, what were the major flaws with FF&S2 other than bad layout?

IMHO, the lack of standard modules. </font>[/QUOTE]I bough FF&S 2 back in the day (it's in a box somewhere), but the unforgivable formatting issues made it an immediate non-starter. It was also a very dense book.

FF&S 1 is much less dense with it's interspersed with tables, picture, and side bars explaining the tech sub-systems.

However. it suffered by being very general with its categories. Things like Sub Light drives covered everything from turbo props to thruster plates.

It also could have done a better job with the individual design sequences. I think a chapter laying out a starship, a chapter building a tank, with cross references to the build details would have helped as well. Then you have "books within the book" so that folk interested solely on a single topic (which a novice more likely is) can bear down and focus on those components that affect their design rather than the rest of the book.

I understand there were space contraints, but it would have made for a easier to use system, IMHO.

And Andrew is correct is that it needed more pre-built components: starship weapons, tank guns, even a rolling chassis or starship frame would be nice. Makes it easier to jump start the process without have to learn every design sequence in the book day one.

Today, the hot tip, assuming they're going to still be constrained by book size, is that they can sell the book, but publish a solid "users guide" on the web with better notes and examples. Mind, It shouldn't be REQUIRED to use the book, but it would be a nice so that early designers can use to jump start the process. Once you've been through it a couple of times it's not so bad.

Heck, even a blog by one of the authors would suffice. "Today we're designing a tracked AFV with a 100mm gun" and walk through the process. They could also have a "module of the week" on the web as well. "100mm TL-9 CPR gun"

The key there is dedication to keep the site going.

 

[Andrew Boulton]

Excellent idea.

 

[GypsyComet]

Originally posted by Andrew Boulton:
</font><blockquote>quote:</font><hr />Originally posted by Border Reiver:
I suppose it's about inclusiveness.

That's why the plan was to have

A. A detailed system (improved FF&S2)
B. A simplified, modular system derived from A
C. Plenty of pre-designed ships

The modules from B could be used with A, and to modify the stock ships.

</font>[/QUOTE]Ideally there's a "B+" layer in there as well, providing exposure to the design constraints felt unnecessary in B but addressed in A, while retaining the modular approach of B where possible. If B is the two CT systems (B2 and HG) and A is Striker, then B+ is MegaTraveller (which presents the user with a lot more options than HG, but is still largely composed of bits built with Striker).

Personally, I'd prefer that 'A' not be a "whole ship" sequence at all (though it may need to be a "whole" sequence for non-spacecraft), leaving that task to B+. 'A' would mostly be the component-level sequences, adding detail and choice to B+ on a section-by-section basis. For example, 'B' does only turrets and leaves out mass and all but the most basic power constraints. 'B+' adds a list of bays and spinal mounts, while bringing power, mass, detailed control, and surface area into the arena. 'A' provides the rules for "from scratch" turrets, bays, and spinals to drop into 'B+'.

The advantage here is that 'B' can be brief enough to go into the main rulebook along with lots of 'C'. The format for the higher level stuff can vary based on specific page counts, but could easily be either 'B+' and even more 'C' in one volume and 'A' in a third, or (my preference) 'B+' and 'A' in one book with a couple examples of 'C', reserving the full ride 'C' for a third and further volumes. If you've done it right, you don't have to revisit the 'C' designs presented in the main rulebook (alongside 'B') because an appendix in 'A' presents all the big modules used in 'B' in their gory detail.

So how is having 'B+' and 'A' in one book different from just having 'A', 'B', and 'C'? Mostly conceptual, but going with the B+ scheme means a shallower learning curve. The *really* gory details of component design remain optional at all times, since they aren't necessary to use the "all design constraints" design sequence, but instead drop into it as needed by the user.

 

[Anthony]

Originally posted by Scott Martin:
Why?

Should I have paid less in 1988 for my 486 so that it woulod be cost-effective in comparison to the notebook that I'm currently using?

Can you buy a 486 today? If you could, what would you pay for it?

Trade exists in the Imperium. Inferior products do not continue to be made unless they are substantially cheaper than their replacement.

 

[Anthony]

Originally posted by atpollard:
X mass tons per displacement ton isn't that unreasonable. Yes it looses some accuracy, but who wants different performance ratings for a ship with full jump tanks vs empty jump tanks, full vs empty cargo hold, and all of the possible combinations.

A 10% margin of error in ship stats is acceptable. A factor of 5 error is not.

 

[atpollard]

Originally posted by Anthony:
</font><blockquote>quote:</font><hr />Originally posted by atpollard:
X mass tons per displacement ton isn't that unreasonable. Yes it looses some accuracy, but who wants different performance ratings for a ship with full jump tanks vs empty jump tanks, full vs empty cargo hold, and all of the possible combinations.

A 10% margin of error in ship stats is acceptable. A factor of 5 error is not. </font>[/QUOTE]In a typical warship, half of the volume could be fuel and in a typical merchant ship, half of the volume could be cargo. So a warship would, realistically, have very different performance characteristics before a jump (with full tanks) as compared to after the jump (with empty tanks). Given the highly variable density of cargo (grain vs. uranium), the performance of merchant ships would, realistically, have very different performance characteristics depending on the cargo or empty hold. I question how much detail is too much. Should performance be recalculated after every fuel hit in combat or at each port for a merchant ship? What is the benefit of a system where precision far exceeds accuracy (I know the design mass to the gram, but the actual mass is +/- 5000 tons)? At what point does the effort render the game unplayable?

No matter what you decide to do, the tradeoffs will affect accuracy, precision and playability. Whatever benefits one factor will hurt one of the others A very high precision (detailed initial calculations) and very high accuracy (recalculating when the data changes) will dramatically hurt playability. High precision (detailed initial calculations) without high accuracy (recalculating when the data changes) will add complexity without gaining any true realism. It is my personal opinion that the use of an assumed average density per unit volume (X mass tons per displacement ton) is a reasonable loss in precision for the gains in playability.

Ninety percent of the benefit of variable density could probably be achieved with 1 percent of the complexity by using two ratios of mass tons per displacement ton: one for light (probably civilian) ships, and one for heavy (probably armored-to-the-max) ships.

Those are my thoughts.
Good luck.

 

[Scott Martin]

or simply use volume-based maneuver drives, where "X" volume and power result in "Y" accelleration for a given volume.

Mass no longer matters for any "basic" starship function (Maneuver or Jump) and is only an issue if you need to determine if a ship sinks or floats (density calculations)

Note that for ships with a significant percentage of volume devoted to armour, the medium that you may be determining if it "sinks" in could be the asphalt of a low-tech landing pad...

Does this sound like CT / HG to anyone?

However "realistic" it may be, I don't want to force my players to make several trips to orbit with heavy materials, then load them into the hold, push (slowly) for the jump limit, jump, and make several trips down from orbit because their M-Drive can't lift a full hold of something heavy (for example any kind of machinery)

This also kills a significant chunk of the drive for modular compatibility because people need to design *the modules* to have a specific density, which adds yet another level of complexity to the mess (and helps explain why there aren't many "modular" components from TNE forwards)

Scott Martin

 

[Andrew Boulton]

Stick with voluume-based drives, with mass-based as an optional rule for mas(s)ochists.

 

[sgbrown]

Originally posted by Andrew Boulton:
Stick with voluume-based drives, with mass-based as an optional rule for mas(s)ochists.

I like the two table approach.

My first shot at a "logical reason" [GM excuse]for two tables -

Volume Based Drive Numbers are "governed" drives and are the standard throughout known space.

Mass based drive tables are the same drives with the governors overridden.

Details:
In standard design, drives are sized based on a g rating to dton ratio with the assumption that the mass to be accerated is equal to the corresponding volume of bonded superdense hull plating. Drive controls are computerized and governed such that the pilot gets consistent results from the drives regardless of cargo and fuel loadout. (Ie He inputs desired acceleration vs % of drive output)

It is possible to override this governor to get better performance from the craft, but this is a non-standard - and typically illeagle - modification. Whether legal or not, overiding the drive settings will void the manufacturers warrenty due to the potential to cause drive overload.

Most governors are tied to the ships grav compensators - and all of them are tied to internal engine compensators designed to optimise the performance of the drive. The modification overwrites key parts of the machine code used for this tie and replaces these values. Significant engineering and computer skill as well as time is required to perform this modification sucessfully and it is automatically erased during the annual maintenance period as part of drive calibration (ie the governor calibration is reestablished and any overrides will have to be redone). Additionally, if you want to sell the ship or hire a new pilot, you'll have to recalibrate the governors as well thus removing the modification.

Because of these complications, it is rare to see governors overridden for drives onboard civilian or commercial craft.

It is against official 3I policy for the governors to be tampered with on 3I ships or vehicles. Rumors that the 3I naval and marine units routinely override the governors are unfounded. In fact all 3I military maintenance shops are required to submit verification that the governors are functioning properly as part of verification that the annual maintenance has been completed.

 

[robject]

As a side note, it seems that FFS1 and 2 are extremely similar regarding weapons design... and they're not that far apart on the craft design front, either.

 

[robject]

When I hear people talk about using FFSx to make components, I think of the lists in MegaTraveller. How much pain is it to build components in FFS2, for instance:

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Component Volume(kl) Cost (Cr)
--------------------- --------- ----------
Regional radio
Planetary radio
System radio commo

VDistant PEMS
Continental PEMS
Interplanetary PEMS
Interstellar PEMS

VDistant AEMS
Planetary AEMS
FarOrbit AEMS

HP Densitometer, 1km
Neutrino Sensor, 10kw
FarOrbit EMS Jammer </pre>[/QUOTE]

 

[Allensh]

I was a playtester on both versions of FF&S, despite not being much of a gearhead myself. I still have a PDF of the final manuscript of FF&S2..the one with the formulas written correctly and in the chapters where they make the most sense, not shoved into the back and typoed out of existence.

Having said all of this, I really prefer modular systems for building ships and vehicles. Something like the modular ship construction rules in GT, or a upgraded High Guard would be just fine for my needs. Too much complexity makes it really hard for us average non-gearhead types to actually get any use out of a book.

Allen

 

[robject]

I so agree. Give me a list of off-the-shelf plug-and-play components. I suspect FFS2 could have given us that -- components designed using its rules for use by everyone else.

For instance, regional, planetary, and system comms. They're in FFS2, and in fact they're Table 190 through 193. What I want is those tables used to form a "standard stuff at TL14 or TL15" table. A layer on top of those tables.

Regional is maybe 1000km?
So that's no volume at all, about 1 kilowatt, and
maybe KCr8.

Planetary is probably 50,000km.
That's about 0.009 cubic meters... i.e. no volume at all, for spacecraft. About 100kW, and Cr100,000.

For "System", I guess the option in FFS2 is 1000 AU. That's 0.05 cubic meters... i.e. no volume at all, for smallcraft or spacecraft. It needs 200kW and Cr150,000.

So:
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Component Volume(t) Cost (Cr)
--------------------- --------- ----------
Regional radio/1kW - 8,000
Planetary radio/100kW - 100,000
System radio commo/200kW - 150,000</pre>[/QUOTE]

 

[robject]

Next stop, PEMS.

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Component Volume(t) Cost (Cr)
--------------------- --------- ----------
VDistant (50km) PEMS - 10,000
Continental (5000km) PEMS - MCr2.5
Interplanetary (1AU) PEMS apparently abso-freaking-lutely huge
Interstellar (2pc) PEMS apparently abso-freaking-lutely huge </pre>[/QUOTE]Hmmm, FFS2 doesn't have interstellar PEMS. Perhaps it erroneously assumes that I want 1 meter resolution at 2 parsecs. So how do I fix that? Do I need to look for a formula containing arc-seconds and trigonometry?

Bah. At this point, I revert to the meta-tables I cobbled together from MegaTraveller:

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Package Vol MCr UEP* ActObjScan/Pin PasEngScan/Pin PasObjScan/Pin
--------- --- --- ----- -------------- -------------- --------------
Vehicle - .15 311 Diff/Diff Form/- -/-
Vehicle+ - .46 6214 Diff/Diff Rout/- -/-
Basic - 0.5 653 Diff/Diff Rout/- -/-
Commerce - 1.0 654 Rout/Rout Rout/- -/-
Survey 0.5 2.5 65443 Rout/Rout Rout/Rout Simp/Rout

UEP: 12345
1: Radio range
2: PEMS range
3: AEMS range
4: Neutrino power (logarithmic)
5: Densitometer pen (logarithmic)

Ranges:
1 VDistant
2 Continental
3 Planetary
4 FarOrbit
5 Interplanetary
6 System
7 Interstellar

* Universal Electronics Profile String.
I think I'll scrap the UEP. Too bulky.</pre>[/QUOTE]</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Component Volume(kl) Cost (Cr)
--------------------- --------- ----------
Regional radio 0.0002 500
Planetary radio 0.0014 30,000
System radio commo 0.014 KCr 150

VDistant PEMS 0.002 20,000
Continental PEMS 0.01 KCr 100
Interplanetary PEMS 0.014 KCr 140
Interstellar PEMS 0.032 KCr 320

VDistant AEMS 0.01 KCr 100
Planetary AEMS 0.028 KCr 280
FarOrbit AEMS 0.06 KCr 600

HP Densitometer, 1km 7.0 MCr 1.5
Neutrino Sensor, 10kw 0.2 KCr 110
FarOrbit EMS Jammer 0.12 MCr 1.2
EMMask 2% MCr 7.0/t</pre>[/QUOTE]