Once again I'm struck by the Oolite version of Hofstadter's Law: That Cobra3 is not a small ship!
And here I thought the Oolite version of Hofstadter’s Law was “no, there still isn’t a new ‘stable’ release.”
And once again I need to clarify, instead of just writing clearly the first time...
Hoofstadter's Law: The Cobra MkIII is bigger than you think, even when you take into account Hoofstadter's Law.
For reference sake (and to give the hard-working gremlins at Google some rest):
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
(While appropriate, the "still no stable release" is well covered by the original Hofstadter's Law. The size of the Cobra, otoh, always comes as a surprise.)
"Actually this is a common misconception... I do *not* in fact have a lot of time on my hands at all! I just have a very very very very bad sense of priorities."
--Dean C Engelhardt
The huge leap from the Anaconda to the Kirins is more puzzling though. I would never have thought the Kirin would weigh in at almost 10x the mass of an Anaconda. Is it the complexity of the model that does it?
No; I think that it's the number of meshes (one, ignoring turrets), giving one bounding box which is quite wide and has a lot of empty space. Break up that mesh, and you get more boxes and an overall lower volume.
I've been juggling some numbers, but have so far not come up with anything I'm completely satisfied with; Closing the gap between Anaconda & Kirin is easy enough, but it also reduces the Anaconda's factor below 2x, which seems a bit low to me.
I'll keep fiddling around some more.
Maybe what we want is, to calculate a suitable value for each ship's mass, some formula involving the volume and surface area of each mesh comprising that ship. Get this right, or at least believable, and a lot of this will solve itself – and it will also fix wormhole persistence times, which are exactly proportional to my numbers
While this is better (from the Kirin-owner's perspective, at least!), it doesn't fix the underlying problem of the Kirin's mass being over-calculated by our current method.
"Actually this is a common misconception... I do *not* in fact have a lot of time on my hands at all! I just have a very very very very bad sense of priorities."
--Dean C Engelhardt
I would love to see a physical motivation of that term. ;-) (Have you tried logarithms, square roots or even cube roots? They tend to show up in real life a bit more often.)
I would love to see a physical motivation of that term. (Have you tried logarithms, square roots or even cube roots? They tend to show up in real life a bit more often.)
F(x) = 0.7*aTan(x-1) + 0.6*x^0.5 + 0.4
You should have kept reading...
I've been messing around with several root functions, varying the exponential from .2 to .9, but the problem is that I've been unable to come up with anything that keeps the Anaconda around the 2x mark without seriously gimping the Kirin.
Using a root function (+a constant) has a nice "physical motivation" in that it is the initial creation of the wormhole that takes energy; the additional energy required for a bigger wormhole becomes less relevant.
The only motivation for using aTan was to create a function that emulates a root function for values less than ~5, and then flattens out, in order to keep the Kirin from getting unduly punished by the faulty mass-calculation.
Someone fix the mass thing, and I'll fix the formula.
"Actually this is a common misconception... I do *not* in fact have a lot of time on my hands at all! I just have a very very very very bad sense of priorities."
--Dean C Engelhardt
I honestly think there is nothing to fix in the mass calculations in Oolite. Mass of a ship is calculated from the sum of its octree's octants' volumes, so it is accurate enough and is deliberately set to be twenty times the product of octree volume and density. Plus (and I know I'll probably get some heat for this), I don't see why we should be so worried about the Kirin specifically or any other OXP ship for that matter, especially since the density of a ship can be adjusted to compensate for apparently excessive mass default values.
I honestly think there is nothing to fix in the mass calculations in Oolite. Mass of a ship is calculated from the sum of its octree's octants' volumes, so it is accurate enough and is deliberately set to be twenty times the product of octree volume and density. Plus (and I know I'll probably get some heat for this), I don't see why we should be so worried about the Kirin specifically or any other OXP ship for that matter, especially since the density of a ship can be adjusted to compensate for apparently excessive mass default values.
Thanks for the info/reply... I will past that into my "forum docs".
JeffBTX, ever considered making that document available to download? It would make interesting reading for many here, I think.. (I realise it's an ongoing work-in-progress, but you could maybe update the download version every week or two)
Most games have some sort of paddling-pool-and-water-wings beginning to ease you in: Oolite takes the rather more Darwinian approach of heaving you straight into the ocean, often with a brick or two in your pockets for luck. ~ Disembodied
Disembodied - I like the idea of having the fuel cost/consumption attribute being in the plists, especially as it gives individual control to both creators and players to assign stats that they think fit the overall feel of the ship. Certainly if the attribute was in plists, I'd be going to town on a number of vessels to ensure their fuel consumption was closer to "Chelsea Tractor" than "Hybrid Car."
Me too. I have a patch which adds a key 'fuel_charge_rate' which takes a float ("<real>", in XML plists); as this value is increased, fuel scooping becomes slower and fuel costs become larger, both linearly. Feedback welcome…
As I was reading through this thread (came to it when it was already 7 pages long) I was thinking to myself that this implied sun skimming in a big cargo hauler should take proportionately longer to accomplish.. (those big tanks on an 18 wheeler take a while to fill) and I'm glad to see this patch seems to address this point.
I like the concept of this discussion, I hope it gets implemented.
Most games have some sort of paddling-pool-and-water-wings beginning to ease you in: Oolite takes the rather more Darwinian approach of heaving you straight into the ocean, often with a brick or two in your pockets for luck. ~ Disembodied
Thanks for the info/reply... I will past that into my "forum docs".
JeffBTX, ever considered making that document available to download? It would make interesting reading for many here, I think.. (I realise it's an ongoing work-in-progress, but you could maybe update the download version every week or two)
Hehehe... it's very user UNfriendly. It's a big TXT file that I copy everything into that of interest to me, that I notice in the forum.
Along with my own (incomprehensible) comments.
I do this "on-the-fly".
Every now and then I attempt to categorize the information... I put in bold "headers", cut and paste / move info around in it.
There is a natural tendancy for me to add LESS to it as time goes on, as I get experience in the game. I do this for almost every new game I get - at first - but eventually I clean up the directories and delete these TXT files; usually at my 2nd or 3rd archive to DVD+R.
Well, if you like, when you think it's relatively "done" send me a copy, I'll pretty it up a bit, convert it to PDF and put it up on box.net..
Most games have some sort of paddling-pool-and-water-wings beginning to ease you in: Oolite takes the rather more Darwinian approach of heaving you straight into the ocean, often with a brick or two in your pockets for luck. ~ Disembodied
It uses no density parameter. With small subs no problem, but some ships have big subs. e.g. with the torus stations only the small core is main entity but all rings are subs.
Dizet Sma wrote:
I was thinking to myself that this implied sun skimming in a big cargo hauler should take proportionately longer to accomplish..
When I would build a fuelscoop for a big ship, I would design the collection entrance bigger so it fills up in the same time as with a small ship.
It uses no density parameter. With small subs no problem, but some ships have big subs. e.g. with the torus stations only the small core is main entity but all rings are subs.
They could have their own densities, I suppose…
Dizet Sma wrote:
I was thinking to myself that this implied sun skimming in a big cargo hauler should take proportionately longer to accomplish..
When I would build a fuelscoop for a big ship, I would design the collection entrance bigger so it fills up in the same time as with a small ship.
That could push up the cost of scoops; why should a scoop for an Anaconda cost the same as for an Adder? And if bigger scoops are present, then it's also reasonable to require less accuracy when scooping cargo.
But if this is changed then, since smaller ships would have smaller scoops, it ‘becomes possible’ for the smallest ones to be able to scoop fuel but not cargo, even if they can carry cargo (consider scoop size against cargo container size).
(Have you tried logarithms, square roots or even cube roots? They tend to show up in real life a bit more often.)
