Page 7 of 11
Posted: Sat Jan 16, 2010 5:22 pm
by CheeseRedux
Ahruman wrote:CheeseRedux wrote: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.)
Posted: Sat Jan 16, 2010 7:45 pm
by _ds_
CheeseRedux wrote: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
Posted: Sat Jan 16, 2010 8:10 pm
by CheeseRedux
After fiddling around some more, I've managed to find a formula that approximates a linear progression without totally gimping the Kirin:
F(x) = 0.7*aTan(x-1) + 0.6*x^0.5 + 0.4
From our example set, this gives the following table:
(Original table included for reference)
Code: Select all
buzzer-player: 0.08 0.05
adder-player: 0.13 0.12
moray-player: 0.22 0.22
morayMED-player: 0.22 0.22
ferdelance-player: 0.28 0.28
asp-player: 0.32 0.32
cobramk1-player: 0.51 0.51
boa-mk2-player: 0.98 0.98
cobra3-player: 1.00 1.00
boa-player: 1.04 1.04
python-player: 1.20 1.20
anaconda-player: 2.31 1.96
kirin-cv-player: 22.64 4.32
kirin-xm-player: 22.67 4.32
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.
Posted: Sat Jan 16, 2010 8:36 pm
by JensAyton
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.)
Posted: Sat Jan 16, 2010 9:15 pm
by CheeseRedux
Ahruman wrote:
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.
Posted: Sat Jan 16, 2010 10:03 pm
by another_commander
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.
Posted: Sat Jan 16, 2010 11:10 pm
by DaddyHoggy
another_commander wrote: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.
Hear! Hear!
Posted: Mon Jan 18, 2010 1:33 pm
by Diziet Sma
JeffBTX wrote:another_commander;
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)
Posted: Mon Jan 18, 2010 2:03 pm
by Diziet Sma
_ds_ wrote:Sendraks wrote: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.
Posted: Mon Jan 18, 2010 9:17 pm
by JeffBTX
Diziet Sma wrote:JeffBTX wrote:another_commander;
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.
Posted: Tue Jan 19, 2010 7:51 am
by Diziet Sma
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..
Posted: Tue Jan 19, 2010 10:50 am
by Kaks
_ds_, if you want to commit your patch, I'll be quite happy to add a couple of tweaks to it afterwards!
PS: no tweaks to the mass formula though...
Posted: Tue Jan 19, 2010 11:21 am
by Eric Walch
Kaks wrote:PS: no tweaks to the mass formula though...
Why not? I think the subentities mass still could do with fixing:
Code: Select all
mass += 20.0 * [(ShipEntity *)subent volume];
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.
Posted: Tue Jan 19, 2010 4:21 pm
by _ds_
Eric Walch wrote:Kaks wrote:PS: no tweaks to the mass formula though...
Why not? I think the subentities mass still could do with fixing:
Code: Select all
mass += 20.0 * [(ShipEntity *)subent volume];
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).
Posted: Tue Jan 19, 2010 4:23 pm
by _ds_
Kaks wrote:_ds_, if you want to commit your patch, I'll be quite happy to add a couple of tweaks to it afterwards!
PS: no tweaks to the mass formula though...
Right… some ships' densities are just going to have to be set suitably