Newtonian Aurora

[bean]

Certainly agree with you.
The numbers I calculated were a compromise between current Aurora, where mass=weight, and an (albeit bad) reallife example; indeed, a compromise heavily shifted to current Aurora.
In the same vein, the crew housing would only be changed in the general direction of realism;

This would save Steve a bunch of work, as he'd only need to use one general multiplier for now.
Sure, ultimately, the best solution short of calculating material densities would be to have A specific size to weight ratio for every ship parts, with crew compartments and empty fuel tanks being rather light, and engines being rather heavy;
But he's got so much awesome stuff to get his head around, I suppose we should be happy with what we get, so I figured a small change has a lot higher chances of being easy to implement, and thus be well recepted.

On second thought, my calculation obviously had the error of not factoring armor, which would be 100% weight.
This could actually be interesting, an Armored ship will become noticeably slower, but not necessarily much bigger.

I just don't get why you're bringing it up at all.  He's decided on a density, and you're asking him to change it.  And I will remind you that things like average density are highly variable, based on setting.  If you're going with a highly nautical model, then it will have densities that are somewhere above .5.  AVT used .25, and I could see something nearer to life using .15 or so.  The point is that Steve has made his decision, so stop badgering him about it.

[HaliRyan]

Byron, you need to stop jumping down people's throats. He's bringing it up because he wants to discuss it, in the thread for discussion about Newtonian aurora.

[UnLimiTeD]

Steve has made the decision that he doesn't want to simulate material density.
I on the other hand argue for a weight multiplier that would simulate a ships structure not being from pure, solid metal, no matter what the actual material would be.
His argument was that calculating densities was too much work.
Thus, I created a simple, though not very accurate, calculation that should be nearly no work, and would get close enough to the truth to be a valid description.
It's fine if you disagree, but if he does, be so kind and let him tell me himself, because he certainly didn't so far.

After all, he changed fuel consumption to match valid exhaust velocities based on 100% weight, he could just simulate 70% weight be reducing that by 30% again.

@Hali; That's pretty much my motivation, thanks for summing it up so coherently.

[Yonder]

True, and how long has it taken to put all that together.
It wasn't in a few hours.  The data and programs took a long time to generate.

What does the time that the program took to generate have to do with anything? Unless you are arguing that every time a firing solution needs to be calculated the Midshipmen will have to develop the software to calculate the shot from scratch? As far as the data for the models, that does take time to collect, however even on immediate arrival to the system you have a lot of information available to you for reasonable simulations.

And even with modern computers, the 'fudge factor' still exists.  If we could calculate these things exactly, we wouldn't still be guessing most asteroids' orbits.  We would also be able to fire two part 'penetrators' at comets and asteroids from Earth orbit.  Trust me, we still need to make a LOT of course corrections on the way to shoot something as big as an asteroid that we have been watching for years.

Guessing asteroids orbits is a fundamentally different problem though. You aren't trying to guess where things will be in an hour, or three hours, or a week, you are trying to guess where things are going to be (in the case of Apophis) 32 years later.

I am not sure exactly what shooting 'penetrators' at comets and asteroids has to do with this. There are a lot of reason we are not destroying asteroids, and a lack of knowledge of orbital mechanics isn't one of them. We don't have orbital weapons platforms for one, which is in my mind the biggest thing missing from that plan.

If we did have huge orbital cannons, however, it would be a lot easier to hit comets with those than what we are doing now. Take the Stardust mission, our piddly little weak modern engines took it out of Earth orbit in the beginning of 1999. It came around Earth again in 2001 for a gravity assist (once again because of our piddly little Earth engines), it didn't get to its comet until 2004, five years after it was launched. So yes, a five year mission does require quite a bit of course correction. If that asteroid interception was made with a slug launched at 40km/s then it would have hit within a few days, long before a problematic amount of uncertainty could accumulate.

[Yonder]

Steve, have you put any thought into divorcing the active and passive part of the active sensors? I often have a "watchship" with both active sensors and enormous Thermal and EM sensors. It would be neat if the "EM Sensitivity" part of the Active Sensor strength could take advantage of the purpose built EM sensors on the ship.

[bean]

Steve has made the decision that he doesn't want to simulate material density.
I on the other hand argue for a weight multiplier that would simulate a ships structure not being from pure, solid metal, no matter what the actual material would be.

Um, the density he's assuming is something on the order of .5 tons/cubic meter.  Metals start above 2 ton/cubic meter, and go up from there.  What you're asking for is a lower density.
For some reason, I can't find the original discussion on the topic.  I asked too, and he said that he liked the number he had.
I have been thinking about a reasonably simple way to model a ship's density, and I'll post the results in a bit.

What does the time that the program took to generate have to do with anything? Unless you are arguing that every time a firing solution needs to be calculated the Midshipmen will have to develop the software to calculate the shot from scratch? As far as the data for the models, that does take time to collect, however even on immediate arrival to the system you have a lot of information available to you for reasonable simulations.

Reasonable simulation and able to hit a planet with an unguided projectile are fundamentally different things.  I'm in agreement with him on this.  For that sort of thing, you need very accurate models of the star system involved.  One of the reasons for midcoure corrections is to allow them to largely ignore those sort of perturbations. 

I am not sure exactly what shooting 'penetrators' at comets and asteroids has to do with this. There are a lot of reason we are not destroying asteroids, and a lack of knowledge of orbital mechanics isn't one of them. We don't have orbital weapons platforms for one, which is in my mind the biggest thing missing from that plan.

He's talking about missions like Deep Impact, where they hit the comet with a penetrator to see what was inside.  His point is that if we had the sort of models you refer to, we could just shoot them out from earth orbit, instead of having to make course corrections on the way.

If we did have huge orbital cannons, however, it would be a lot easier to hit comets with those than what we are doing now. Take the Stardust mission, our piddly little weak modern engines took it out of Earth orbit in the beginning of 1999. It came around Earth again in 2001 for a gravity assist (once again because of our piddly little Earth engines), it didn't get to its comet until 2004, five years after it was launched. So yes, a five year mission does require quite a bit of course correction. If that asteroid interception was made with a slug launched at 40km/s then it would have hit within a few days, long before a problematic amount of uncertainty could accumulate.

That's not true, though.  Wild 2 has a diameter of 5 kilometers.  At closest, it comes within about 7.2*10^7 km of earth.  Your penetrator would take about 500 hours, or nearly three weeks to get there.  If there was a sideways drift for whatever reason of an average of 1.39 mm/s, the penetrator would miss.  That sort of drift could occur from any number of sources.  Hitting a planet is easier because the planet is bigger.

[bean]

My thoughts on component density:
First, I want everyone to understand.  I do not want this in the first version of Newtonian Aurora.  It looks wonderful as is, and I don't want Steve to delay getting it ready.  This is merely my suggestion for how to implement a relatively simple density system.
Divide all components into one of the following categories:
1. Armor:  Infinite density.  In reasonable cases, the volume of armor is negligible.
2. Habitation: .15-.25 tons/m3.  This is any place that humans spend a bunch of time.  Crew quarters, bridge, flag bridge, passengers, troop transport bays, cryo modules.  I'm not sure what to do about drop bays.
3. Fuel.  I'm not qualified to comment on the density of exotic and currently unknown substances.
4. Void spaces.  .25 tons/m3 fully-loaded.  Hangar bays and cargo holds.
5. Equipment: .75-1 tons/m3.  This covers everything that doesn't fall into another category.  Engineering, weapons, electronics, engines, terraforming modules.  Anything that is mostly metal.
I tried to keep the number of types low to limit complexity.  This is just an idea for future designs, and the numbers will probably have to be changed.

[Mormota]

I have been thinking about FTL travel and deep-space sensors, and realised that something is wrong.  If we can create sensors that can see enemy ships travelling in a certain radius, how come we lose contact with our ships going FTL?

[TheDeadlyShoe]

His argument was that calculating densities was too much work.
Thus, I created a simple, though not very accurate, calculation that should be nearly no work, and would get close enough to the truth to be a valid description.

It's not just work to code in, it's work for players.  There needs to be some gameplay value from it other than more details is better. Personally, armor having zero (or very low) volume is the only thing I can see having gameplay value.  And it's simple/straightforward. 

[bean]

It's not just work to code in, it's work for players.  There needs to be some gameplay value from it other than more details is better. Personally, armor having zero (or very low) volume is the only thing I can see having gameplay value.  And it's simple/straightforward. 

More work for players?  How?  This would be hard-coded in, and all you would see is that for a given mass, you get a bigger cargo ship then warship.

[Steve Walmsley (OP)]

I know you've probably reached a decision there, but for the sake of argument, I'm not quite dropping it yet. 

I can accept the argument that modeling the density of materials would go too far, in the same sense that you didn't want to incorporate regular materials for the sake of not getting it overly complicated.
However, you could easily abstract it.
Given the current code, you could just reduce the mass of the ship by a percentage, based on an arbitrary value, for example the weight to volume ratio of a space shuttle.
Given the raw data here, I've calculated a base value for it, using the following assumptions:

As length, I picked 32 meters, which is close enough given it's obviously not a cube, and omits part of the fins and all that jazz.
Given the rather inaccurate data provided by that site, I just assumed it to be 5x5 in height and width, which is probably a rather generous assumption.

With 32*5*5 (I have this mad feeling of totally missing something right now), I got a total of 800 cubic meters; given that I fully expect to miscalculate something here, let's just assume half of it.

However, the full load of the shuttle seems to be, according to wikipedia, around 109 tons.
So, to take the middleground between what is in game now and the cheap calculation I just pulled off, you could reduce the weight of a ship by roughly 35%.

This would change the given freighter from:to:

Code: [Select]

Atlas class Freighter    6,105 tons standard     32,105 tons full load      35,393 tons volume      28 Crew     431.1 BP
Length 220m     Armour 1-176     Sensors 1/1/0/0     Damage Control Rating 1     PPV 0

Now, I obviously don't know too much about the subject, but I think this wouldn't be too much coding effort, and as with the exhaust problem before, you could just change the fuel consumption to account for that; In this case it would probably go down a bit again.

Though, now that I think about it, crew spaces should probably handle only half as many persons after that model, maybe 2 or 3 per ton.

As for railguns, does that mean we'll have to expect the muzzle velocities to go down by an order of magnitude? After all, a somewhat similar change was enacted on engines to keep with the realism.

Already built into Newtonian Aurora is that the volume of a ship in cubic metres = 10x mass in tons. This is will be too low for some ships and too high for others but it will suffice as an average. As a comparison, Traveller TNE uses volume m3 = 14x mass in tons. Of course, mass will change significantly during the game based on how much of the maximum fuel load is carried or whether a cargo ship is actually carrying any cargo, so the volume - mass ratio of a ship will change a lot during the normal course of play.

I could calculate individual volume - mass ratios for every component but my reasons for not doing so are as follows:

1) It would be a lot of work, especially in terms of the research required to create reasonable ratios for each component. If I was not going to research it enough to come up with reasonable ratios then what would be the point.
2) Even though different components would have different mass ratios, ships tend to use the same type of components. Engines, armour, weapons, crew quarters, fuel, etc. So even though the individual components may vary, warships would probably have similar average mass-volume ratios anyway.
3) When you see the TCS of a ship with a fixed mass-volume ratio for its full load mass, you will have a reasonable idea of the capability of the ship. Otherwise, I would just display the diameter of the contact in metres, which to most players wouldn't be that useful. They would like an idea of what they are facing. If they were an experienced naval officer, they may know how TCS generally related to possible mass ranges for different ships of different nations. However, they aren't and most players will want 'Sensor Reading' = 'General Idea of Ship Capability', and in Aurora terms 'Ship Capability' is closely related to mass. If they need to know mass they need to know how volume relates to mass without a lot of calculations.
4) Most importantly, having different mass ratios for different components wouldn't significantly affect gameplay. Players are unlikely to design their ships any differently based on the mass/volume ratio of the components. If you want an escort DD then you will pick the components you need and select engines based on how much mass you need to propel. You won't care about the volume during design. Volume changes will affect the chance of a hit but not by a great deal and certainly not enough for you to make different decisions during design, especially as it is likely that ships of a given role, such as warships, would probbaly have similar mass-volume ratios anyway.
5) With 4) in mind, I really don't want to expend a lot of effort on something that might add more realism but would have very little impact on gameplay. Gameplay in this context being the addition of difficult decisions related to the volume of a component.

Volume is included because I am using it as a baseline for to hit chances and the impact of nukes. It isn't intended to have a significant effect in gameplay.

Steve

[Steve Walmsley (OP)]

I suppose their geo sensors should be made less effective, or drone geo sensors should require a special tech, or ship-based geological surveys will never be used.  Unless that is exactly what Steve wants.

There isn't any difference between ship geo sensor tech and missile geo sensor tech. There is simply geosurvey tech, which is based on a rating per ton. That will be the same whether it is a on a missile or a ship.

Steve

[Steve Walmsley (OP)]

I can see a lot of advantage to buoys. The survey ship won't have to decelerate at each target - the buoy will decelerate itself.    Buoys were the first thing to pop to mind when thinking about surveying under a newtonian scheme. 

Furthermore, it's looking like fuel efficiency/fuel carried will be the limit on survey ships, not sensor efficacy.  Ironically better sensor tech would improve buoys way more than it would improve ships...  assuming you can just make a lighter buoy, anyway. 

Yes, buoys will be very useful and yes, fuel efficiency and capacity will be vital for long-range survey ships.

Steve

[Steve Walmsley (OP)]

Actually the question would be to which extend buoys or drones can be programmed? What would you need essentially? Atleast "Moveto" and "Survey object". If Steve feels fancy he could even write a up a code that calculates how much the rocket would need to accelerate/decelerate 2times to get there and back again (minus the Oldman, Lizardchicken and the sequels McGuffin).

Bear in mind there are no drones or buoys in Newtonian Aurora in the same sense as Standard Aurora. There are only missiles. However, you can send a missile on a zero-zero intercept, which means it will accelerate and then decelerate to rest, so you can create a 'single stage survey drone' with an engine, reactor and sensor, or you can deploy a missile with a reactor but no engine as a second stage. Unlike Standard Aurora though, you will still need a zero-zero intercept because the second stage will start with the same momentum as the first stage.

Steve

[Steve Walmsley (OP)]

Steve, have you put any thought into divorcing the active and passive part of the active sensors? I often have a "watchship" with both active sensors and enormous Thermal and EM sensors. It would be neat if the "EM Sensitivity" part of the Active Sensor strength could take advantage of the purpose built EM sensors on the ship.

I did consider it. In the end I went the simplified version, partly because fire controls use the same component type and design process as active sensors and I didn't want to have active sensors and fire controls to be sharing the same receiving antennae, as that isn't the case in reality. It might also mean I would have to account for the receiver picking up reflected pulses from other transmitters. In the end I decided a single combined unit was a lot less trouble . BTW I recently posted the updated active sensors in the Rules thread.

Steve