Fuel price in proportion to ship?

[DaddyHoggy]

ship mass (laden or unladen?)

See if you can get the air speed velocity into the equation too.

Personally as we don't actually know what a TC is in terms of mass (I think of them simply as a unit of unspecified capacity (otherwise if you think of them as Tons (or Tonnes) then it would imply when you buy machinery (such as a combine Harvester) it would need to be broken down into say 30 bits of equal size to fit inside one of these cannisters which is clearly nonsense) therefore even a fully loaded Anaconda (with its potentially apocraphyl 750 TCs) will have little impact compared to the actually mass of the ship (unless of course you wanted to go mad and imagine the entire cargo volume of an Anaconda filled with Gold bullion - now that might add a bit to the overall mass of the ship....).

Simplest would be to make the Cobra III the baseline (as suggested) and do it for the other ships as a ratio of this, but a ratio based on what - I have already shown the oddities of using the bounding volume - so does the code have some additional parameters/data it can use?

[another_commander]

If I am reading the code correctly, the volume of a ship is calculated as the sum of its octree's octants, so I believe it is accurate enough and not dependent on bounding box size. The mass is then calculated for a given ship as Volume * 20 * density. I believe that we have enough good information to move with setting base values for the Cobra.

[Lucidor]

Air? o_O

http://www.youtube.com/watch?v=rzcLQRXW6B0

At least DaddyHoggy seemed to get it.

[Kaks]

But - but spaceships are non-migratory.... o_O


-------------------------

Back to the discussion:

It is definitely doable, and since we've already got a way of telling a ship's mass in the code, we shouldn't have too many coding obstacles to implement the thing. However, JeffBTX comments make me wonder how many people would misunderstand the concept to begin with... I suppose it's better to wait for a few days to hear everybody's opinion first, then see if it's doable with a minimum of fuss!

[Cmd. Cheyd]

I'm not sure a linear cost symmetry is appropriate. In truth, I'd look at something more exponential. There isn't a that massive of a fuel efficiency difference between your average car (18/25 mpg) and a moving truck(12 mpg). Even moving up to an 18 wheeler only drops you to 6-8.5 mpg. Moving up to something designed to handle massive loads, say the NASA Crawler, and you drop to 0.008 MPG (yes, 42 ft / gallon).

I'm not sure of the mass of the core ships. The wiki is a little confusing. It lists some ships with a max gross mass 1200 tonnes LESS than it's empty mass. Assuming that was supposed to be max cargo, you're looking at the Boa having a maximum mass of 1700 tonnes, and a Krait weighs in at 42 tonnes.

To me, it'd make more sense to have fuel priced where it is near punitive to leave dock with an empty hold if you're flying a large cargo hauler (Anaconda, Kirin, Python/PCC, Boa/BCC, etc).

[Disembodied]

To me, it'd make more sense to have fuel priced where it is near punitive to leave dock with an empty hold if you're flying a large cargo hauler (Anaconda, Kirin, Python/PCC, Boa/BCC, etc).

I agree with Cheyd here. If this is going to have an effect on gameplay, it has to have a noticeable effect on player behaviour – even if that's only persuading players to sunskim more often.

[Poro]

Might we also roll this up into fixing another bugbear of sci-fi: that being large ships having a lower max speed than small ones?

The increased mass of a ship limits only its acceleration, not its top speed - and it would seem to be one of those facts of physics so obvious that I think it shouldn't be dismissed with 'rationalising too much' or 'this is sci-fi, live with it'.

Since the predominant reason for players caring about the speed of a ship is when they are in combat (either to escape or to chase down), and most moderate combateers use fuel injectors to gain an advantage, could we not link the ideas so that a ship of increased mass (over a Cobra Mk.III) needs to drink injected fuel at an increased rate - and can therefore only maintain the boost for a shorter period than a smaller ship?

This would still maintain the advantage of smaller ships having a greater chance of "getting away", yet not spit in the face of basic space physics (I know I know, it's a sci-fi game ).

I've heard of the 'fast-travelling pieces of matter' explanation as the reason for decreased top speeds for larger ships, but... really? There would be more hull to absorb the damage in a larger craft, so how would it be a limiting factor, provided that repairing such micro-damage is not being implemented in the game?

Why not just cap the top speeds, and as well as engines on larger ships needing more Quirium to jump, they also consume more to inject? As far as I can see you would still have smaller, less consumptive ships retaining an advantage.

And as Disembodied said, sun-skimming would have increaded importance.

[Thargoid]

About different grades of fuel: it might just be possible via oxp.... maybe never let the fuel rise above 5 ly if sunskimming... (it should be doable with timers, but not too sure), and if the last refuelling was done at a supadupa special station, have the tanks refilled by 1/3 of the distance, once we enter the tunnel. I wonder if a certain Thargoid might entertain the idea...

I could be persuaded to modify the Fuel Station OXP to simulate "better" fuel, although I'm not sure what would be the best way to do it. Trying to simulate higher Octane (equivalent) fuel via script and timers etc would be a nightmare I think (given it can be used for jumping and for injectors, although it probably only makes sense to have the improvement for injectors).

I'm not keen on fuel "suddenly appearing" in the tank when docking or something like that - as mentioned elsewhere such fuel should either make the injectors last longer (ie be self-replenishing to some percentage script-wise) or ideally make the ship go faster (or perhaps even link with the maintenance requirements?).

[Lucidor]

Might we also roll this up into fixing another bugbear of sci-fi: that being large ships having a lower max speed than small ones?

Since Elite spaceships flies like aeroplanes, I think that the the Elite universe is filled with aether, and therefore the large ships' speed is limited by aether resistance.

[Poro]

Since Elite spaceships flies like aeroplanes, I think that the the Elite universe is filled with aether, and therefore the large ships' speed is limited by aether resistance.

I always thought that was because people simply find it more intuitive to fly like that, rather than any external 'aether' necessitating it.

If it matches the way terrestially evolved pilots already think, and makes ships more cost effective (only one main engine rather than crustated with maneuvering trusters) then it makes sense to have ships constructed in such a way, with a computer auto-compensating for speed alterations.

P.S. If memory serves, this 'computer auto-compensation' explanation has already been generally accepted in another thread, though I can't link to it yet.

[JensAyton]

Anywho, this is getting way too detailed! All I had in mind was price per ly worth of fuel to be affected - roughly - by the overall mass of the ship.

What we really need is a finite element analysis to determine how spaceodynamic each ship is. ;-)

Might we also roll this up into fixing another bugbear of sci-fi: that being large ships having a lower max speed than small ones?

No. Redefining the flight model or the characteristics of core ships is out of scope for Oolite. Redefining the price model for fuel is not, since Elite didn’t define the fuel cost for anything other than the Cobra III.

Supporting OXP fuel types that alter injector characteristics would be relatively simple, and doesn’t cause any problems with respect to the 7 LY limit. The basic outline would be something like:

• Identify fuel by a new equipment property is_fuel instead of the EQ type, allowing multiple fuel types.
• Also add properties injector_multiplier (default: 7.0) and injector_burn_rate (default: 1.0). Also add corresponding properties to ships.
• When refuelling, blend the ship’s injector multiplier and burn rate with those of the fuel in proportion to the amount of fuel added. For instance, if you have 35 units of standard fuel and top up with 35 units of (9, 0.8) fuel, you’d end up with an (8, 0.9) fuel in your tanks.
• Anyone suggesting we need a more complex model for fuel blending will be summarily shot.

I officially volunteer to not implement it. :-)

[Thargoid]

And when you don't, I shan't roll it up into Fuel Station OXP.

Deal?

[DaddyHoggy]

Anywho, this is getting way too detailed! All I had in mind was price per ly worth of fuel to be affected - roughly - by the overall mass of the ship.

What we really need is a discrete element analysis to determine how spaceodynamic each ship is.

Might we also roll this up into fixing another bugbear of sci-fi: that being large ships having a lower max speed than small ones?

No. Redefining the flight model or the characteristics of core ships is out of scope for Oolite. Redefining the price model for fuel is not, since Elite didn’t define the fuel cost for anything other than the Cobra III.

Supporting OXP fuel types that alter injector characteristics would be relatively simple, and doesn’t cause any problems with respect to the 7 LY limit. The basic outline would be something like:

• Identify fuel by a new equipment property is_fuel instead of the EQ type, allowing multiple fuel types.
• Also add properties injector_multiplier (default: 7.0) and injector_burn_rate (default: 1.0). Also add corresponding properties to ships.
• When refuelling, blend the ship’s injector multiplier and burn rate with those of the fuel in proportion to the amount of fuel added. For instance, if you have 35 units of standard fuel and top up with 35 units of (9, 0. fuel, you’d end up with an (8, 0.9) fuel in your tanks.
• Anyone suggesting we need a more complex model for fuel blending will be summarily shot.

I officially volunteer to not implement it.

That's exactly the kind of sound reasoning I was hoping for and exactly what I hoped could be done!

If I am reading the code correctly, the volume of a ship is calculated as the sum of its octree's octants, so I believe it is accurate enough and not dependent on bounding box size. The mass is then calculated for a given ship as Volume * 20 * density. I believe that we have enough good information to move with setting base values for the Cobra.

This is what I hoped and why I asked if the code had access to more data than was available simply in the wiki which gave only the bounding box. Cool!

@Poro - I hear what you say, but think of this for a moment - the ships in Oolite/Elite clearly don't follow anything we understand to be "normal"/"real" physics so we have explained this using handwavium of several orders vaguely describing a special engine that somehow propels the ship through space in a way that is inertialess and reactionless and non-fuel consuming (except for using injectors), etc, so lets imagine that these engines envelop the ship in which it is mounted in some special field that allows all of these effects to be explained - lets imagine that a certain sized/powered engine can envelop a ship of a certain size and/or certain mass and thus allow it to move at a certain speed with a certain acceleration and deceleration. Put the engine in a bigger/"heavier" ship and that field is spread thinner thus limiting top speed because at higher speeds normal physics would start to impinge on this special field and its seemingly magical properties. For lots more money you can put in a bigger, more powerful engine but the cost to performance ratio is exponential in relationship, so to move something like the Aurora at Kirin speeds would require and engine many thousands of times more expensive/powerful than that in the Cobra Mk III.

[Disembodied]

always thought that was because people simply find it more intuitive to fly like that, rather than any external 'aether' necessitating it.

If it matches the way terrestially evolved pilots already think, and makes ships more cost effective (only one main engine rather than crustated with maneuvering trusters) then it makes sense to have ships constructed in such a way, with a computer auto-compensating for speed alterations.

P.S. If memory serves, this 'computer auto-compensation' explanation has already been generally accepted in another thread, though I can't link to it yet.

It depends what you mean by "generally accepted" ... Aegidian, for example, has given his support to the phlogiston theory, a variation on the aether. But the "auto-compensation" theory has its supporters, too: but as with so much else there isn't any one single canon, even with something as basic as the underlying physics of the universe (mind you, I've never heard a good explanation from the "auto-compensation" adherents of how no fuel is ever used in normal spaceflight ...). You are, within large limits, free to pick your own universe.

What it comes down to is gameplay. We choose the characteristics we want for the game, for reasons of fun, and – as long as they're technically and practically possible – invent the explanations afterwards. In the case of the core game ships, this means emulating the behaviours inherited from the original Elite – which was a fun game.

Physics is great, but it has no business poking its nose into a game unless it's helping make it more fun. Frontier stands as a terrible warning to everyone as to what happens when games designers get too interested in "realism" at the cost of entertainment.

[Lucidor]

Physics is great, but it has no business poking its nose into a game unless it's helping make it more fun. Frontier stands as a terrible warning to everyone as to what happens when games designers get too interested in "realism" at the cost of entertainment.

I guess that is generally accepted among the patrons of this site, but there are those who like the flight mechanics realistic. And I'm one of them. But I enjoy Oolite too.