Split: Re-scaling experiment

[Redspear]

Yeah, I remembet that story but (seemingly like yourself) can't quite place its origin.

Was the original hand written?
Did someone forget their glasses?
Was it a case of too little coffee on the day?
Or was it entirely accurate and as intended?

Certainly the descriptions regularly appear to be at odds with the dimensions.

Oolite took the obvious (and arguably sensible) route of inheriting the dimensions (with the odd tweak) as well as the descriptions and so we have 'one man fighters' wider than 'the largest known freighter' from the core shipset (the krait and anaconda respectively).

I've already changed the sizes to be less jarring but being able to free myself from them entirely seemingly yields more satisfactory results.

Will need to tweak it for the largest ships however to 'rein them in a little'.

[cbr]

hmmm.

Let's take the cobra3 as (26) 100% and rescale some ships accordingly to their crude scale ( anaconda 234/26 >> 900% ).



hmmm, lets take in account volume.

say cob3 consists of a box 4w x 2h x 3d = 24 + 2 (nose) = 26cs ( cs=crude scale size/volume)



Now rescale per volume.
If the viper, cobra3 and anaconda were of the same buildstyle these would be their comparable sizes. Use the biggest ship to rescale to aprox. max docksize ( see high/height and width )

[Cholmondely]

A bit on relative ship sizes (nice to be able to talk about a conceptual issue rather than a coding one )...

TLDR: ignoring the ship dimensions I based size on description and made a table (see below)

A reminder for anyone who's new here: this thread isn't about trying to rationalise scales in oolite (honest! ) but rather trying to hide their glaring irregularities whilst playing the game.

Here's a link from the Ian Bell website that purportedly represents the guide notes he wrote for the Elite player's manual.

There's a few little gems in there that didn't make it into the finished product (moray pilots with latinised 'fish fingers', how many missiles can a mamba carry? 2) or were just reworded slightly such as was the case for this entry:

ORBIT SHUTTLES
are large unarmed craft which run cargo between the planet and its orbitting space stations. The naughty old player can shoot these and reap a rich harvest of cargo canisters. Of course, the space station might have something to say about it....

Large? It's amongst the smallest by recorded dimensions, about the size of a worm (in game worm, not the garden variety).

From the manual this time:

ORBIT SHUTTLES
These unarmed and often unmanned craft are built under license in every planetary system. Based on a prototype developed by Saud-Kruger AstroDesign, they are used for cargo ferrying between planet and space station, but can be modified to hospital ships, or orbiting prisons. Favorite targets for small-time criminals, because of their instantaneous release of cargo canisters, they are often followed by single fighter patrol ships.

Orbiting prison? Hospital (not medical) ship? and with 60TC capacity (as recorded in elite manual) and a crew of 6. This thing should be pretty big shouldn't it?

What if I completely ignored the recorded dimensions of the ships and instead focused on their descriptions, could size be reassessed almost entirely?

A strict formula is likely to be so debatable as to be of questionable utility but a guideline of some sort might help.

It can carry up to 100 passengers, and has a cargo capacity of 10 tonnes undefined bulk.

Interpeting this sentence from the manual to mean that 1TC storage soace can accomodate up to 10 passengers, I now have a guide.
OK, so they're Gal Tonnes and not necessarily metric tonnes but given the use of grams and kilograms in the 4th millenium, I'm guessing it's not too far away. Besides, it doesn't need to be accurate, just proportianal and functional.

Furthermore I'll be assuming that extra crew means extra equipment, both of which will take up extra space. Equipment could be enormouisly variable (and perhaps automated for the presumably solo pilot in oolite) but again, for convenience I'll be assuming that each crew member after the first (plus the equipment they're supervising) is equivalent to 2TC.

Minor adjustments for weapon references and presence/absence of a hyperdrive and what would we get?

Maybe something like this :



Remarks are all from the manual or Ian Bell's notes.
I've marked any changes I've made in red and they are as follows.

Krait and Mamba

10TC seems quite a lot for a 'one man fighter', especially with the mamba having space added as an afterthought. For comparison the cobra mk I trading vessel has the same ammount of cargo space and (unlike either of these two) a hyperdrive. I'm going with either an unlikelt '1.0 TC' or a (perhaps only slightly less unlikely) '1o TC' with an ornate full stop eventually making it into a zero. Remember: this isn't a search for truth on my part but rather convenience and a more varied and interesting ship population.

Anaconda

Was it 750 TC? Could it have been 250 TC? Or, perhaps more likely, 150 TC?
Python: 100 TC
Boa: 125 TC
Anaconda: ?
Personally, I think 150 fits best given that they're all supposed to be able to dock within a slot that was (in Elite) the bane of inexperienced cobra pilots.

Crude size

Of questionable merit this one when it comes to game sizes but I'm not trying to represent things accurately (with those numbers how could an anaconda pilot ever be expected to scoop a cargo pod?), just to hide the fact that I'm cheating. Maybe once we get to the largest vessels I could reduce or ignore the modifier for crew. Not every crew member need be attending to an essential piloting function. Announcers on an anaconda, 'butlers' on a fer de lance, doctors/prison guards on a shuttle.

Anyway, I'm not quite sure what I'm going to do with this yet but I do quite like the idea of some orbital prisons and hospitals popping up, perhaps with an AI that remains stationary until attacked (escorts perhaps?) And one man fighters that are actually small (costing them an energy bank or two I suspect).

Just to say - I really like the way you are approaching this. I'm sure, there being so jolly many different aspects of this game, that there will be matters which end up as problematic. That's life! But at least you have a good approach to conceptualising it all!

[Redspear]

hmmm, lets take in account volume.

Yes, lets! They're not pancakes!
I think you might have squared in your first image (x9 length and x9 width which) would actually be 8,100% rather than 900% I believe.

Don't forget that it's a guideline. I wasn't expecting it to be directly transferable within game, as I pointed out here:

A strict formula is likely to be so debatable as to be of questionable utility but a guideline of some sort might help.

...and with reference to the numbers in particular here:

Crude size

Of questionable merit this one when it comes to game sizes but I'm not trying to represent things accurately (with those numbers how could an anaconda pilot ever be expected to scoop a cargo pod?), just to hide the fact that I'm cheating. Maybe once we get to the largest vessels I could reduce or ignore the modifier for crew. Not every crew member need be attending to an essential piloting function. Announcers on an anaconda, 'butlers' on a fer de lance, doctors/prison guards on a shuttle.

Imagine that the whole 'scale' is stretchy but rather than applying the stretch evenly (like with a simple divide or multiply by 2) that it could be flattened out at the extremes (like a logarithm). How extreme or mild I might need to make the effect will depend upon game as well as aesthetic considerations but it's already yielding some interesting insights (to me at least) which I was just about to create a new thread for...

Meanwhile, consider if you like that the 'crude size' was just a 'score' to grant each ship a 'grade' for their size (as I have already marked on the chart).
So the anaconda doesnt necessarily need to have nine times the mass of the cobra mk 3 for this table to be useful, it just needs to be three sizes larger. How big one chooses to make each of those size increases would be not necessarily need to reflect 'crude size' but rather the ship groupings derived from such.

e.g. I could use this table and only require an anaconda (enormous) to be 8 times the size of a worm (tiny) vs a cobra 3 (large) at 5 times the size of a worm; if I wanted to but then that might be a bit silly wouldn't it?

[Cody]

Subvert: (transitive) To upturn convention from the foundation by undermining it.

Question: could this 're-scaling experiment' be described as subversive?

[Cholmondely]

Subvert: (transitive) To upturn convention from the foundation by undermining it.

Question: could this 're-scaling experiment' be described as subversive?

If you are describing the state of affairs from the perspective of Oolite, it might be subversive.

If you are describing the state of affairs from the perspective of Elite, it might be reversive.

If you are describing the state of affairs from the perspective of common sense, it is a breath of fresh air.

[Redspear]

Subvert: (transitive) To upturn convention from the foundation by undermining it.

Question: could this 're-scaling experiment' be described as subversive?

Could or should?

I think I've made my intentions quite clear on several occasions. No desire to usurp or threaten anyone else's version of oolite, just to share a little of mine.

It could be argued that this whole thing intrudes less upon the game than anything that's available from the download manager. Despite that I think it became apparent quite early on that some had VERY strong feelings about this. Some seemed to feel paradoxically threatened and yet simultaneously that I could never achieve my aims. I'd love to have done this whole thing by oxp but that door wasn't open to me.

The only way this thing could ever realistically succeed at the subversion defined above would be via dev consensus and adoption. That's something I have little power over and furthermore have little desire to achieve.

Many here have been playing oolite longer than they ever played elite, perhaps even to the extent that oolite now is 'elite' to them and all is (more or less) as it should be. That may not be a position that I share but it is a position that I respect. I recognise that oolite represents something of a 'safe-space' for many and even changing to oxz format was fraught with debate and (for some) upset.

Others have hoped for this experiment to 'become' the future version of oolite and whilst I may have responded positively to such (it's a compliment of a sort if nothing else) I don't recall ever pushing for it nor do I believe that I should.

There were numerous ways I could have answered this question. I opted for the way in which I think I should have answered this question.

I hope that puts some at ease and at least adds a modicum of clarity .

[Cody]

Could or should?

Oh, definitely 'could'. And for the record, I wasn't having a dig!

[Redspear]

Just to say - I really like the way you are approaching this. I'm sure, there being so jolly many different aspects of this game, that there will be matters which end up as problematic. That's life! But at least you have a good approach to conceptualising it all!

Belated thanks.

Could or should?

Oh, definitely 'could'. And for the record, I wasn't having a dig!

So it's 'could' and good

[Cholmondely]

Getting very close now...



Only real issue with making one build instead of two is the compulsory alteration to the scanner (from an effective 25.6km to 20km). I think it's worth it however as it contributes to halved masslock times with the suggested values and even shaves a quarter off times with the familiar values. Better yet, it means other values can be tweaked to each player's taste.

I'll post some comparison pics in the screenshot thread shortly but if something is too big / too small for anyone's preference then there'd be room to tinker. There are a few considerations however as I haven't come to these values purely on a whim.

• Freighter pilots are not the most spatially aware when it comes to docking (Boa pilots appear especially challenged in this regard - likely on account the expanded 'bottom' of such vessels). Scaling the worst offenders to a lesser value than the station seems to help
• If speeds exceed fighter sizes then combat can get a whole lot more challenging
• If speeds get up to x2 then be prepared for the occasional accident upon launching
• If stations get above x3 then freighters occasionally have trouble navigating around the buoy, never mind docking

There are a few other things to consider when tweaking the above but all seems to be working and docking traffic is manageable again.


I said I'd been working on a new scanner...



Undoubtedly a bit rough around the edges but functional and fun.

Easiest way to read it is to consider the brighter area in the centre as the scanner we're familiar with, whilst the outer area displays 'lollipops' as normal but they won't be able to masslock you from there. For example the left and righmost ships displayed on the scanner cannot masslock the player in their current positions.

An obvious concern might be that it could be confusing to occasionally torus past some ships at great speed and yet not others. I think the inner circle actually makes that rather clear. In fact, I find it causes less confusion when something masslocks the player on the very edge of the scanner and yet once the player has stopped it has drifted off the edge, with this scanner however, there's another 10km worth of display area for within which it can be located.

Inner area 20km
Outer area +10km

More scanner, less masslock: me likes

To be clear this is just a fun idea that I consider worth posting. It does relate to the rescaling in that it fits well with the reduced scanner I'm using but (unless surprisingly well received) it won't be in the build.

This looks absolutely super! Well done, sir!

Any chance of turning it into an oxp? What changes to the vanilla game code would be needed?

[Redspear]

This looks absolutely super! Well done, sir!

Any chance of turning it into an oxp? What changes to the vanilla game code would be needed?

Pfffftttt...

Well, the HUD component actually is an oxp but it only works because of source code changes (two, IIRC).
Scanner range can be set for non-player ships by oxp I think but definitely not for the player ship, so that would need to change first.

There's another one that sets the scaling (rather than the size, if I'm saying it right) of the scanner. When it matches the range then you have a conventional scanner (in function at least). When it exceeds the range you then have a scanner that functions similar to the one I have described.

What you would also have in that second scenario is a semi-readable mess on your screen, consequently my crude but functional scanner overlay to turn that 'bug' into a 'feature'

Oh and thanks, I'm glad you like it.

[Cholmondely]

What you would also have in that second scenario is a semi-readable mess on your screen, consequently my crude but functional scanner overlay to turn that 'bug' into a 'feature'

if by semi-readable you are talking of the screen shot above, I find it perfectly sensible. I do appreciate that there will be difficulties in judging the z-axis for the 20km mass-lock zone. That might be fixable. Or maybe have two scanners. Or just accept it is only good for 2 dimensions...

Whatever. But if I notice something in the larger zone, I have a chance to avoid it before it impacts on my Dynamic Response Uridium Injection Dilator...

[Redspear]

if by semi-readable you are talking of the screen shot above, I find it perfectly sensible

Imagine the screenshot without the duller red parts of the scanner (in other words: just the inner, bright red zone).
You'd then have lollipops appearing off scanner - that's what I was referring to as 'semi-readable' and without a tailored HUD, you'd get either that or... no marker for the border of the masslock zone (the bright red oval you can see in 'my' HUD).

So the HUD looks strange because it was designed to fix that problem.
Does that make sense?

[Redspear]

Oh dear...

Trying to update this with the latest version of oolite and...

[position.cylinder.error]: Trying to generate cylinder position in range 906043.692376 long with exclusions 1234800.000000 and 253347.281250

Similar message for sun radius until I returned to the default plist values

Obvious error would be to have stretched things too far but they are no larger than in my last (successful) build detailed on p.44 of this thread.

As I go a double checking for any typos on my part, could anything have changed recently that might be relevant?

EDIT: Dug up some old lane stabilisation tweaks and got it working again. Will need to check on those 'suns' however...

[Redspear]

Got suns working again and, even better, I made them bigger!

Finally looked into scaling them independent of planet sizes and it seem to be working fine meaning that I no longer need to overrule their unique values in planetinfo.plist

Thanks to oxp developments elsewhere, I can keep the scanner, stations and speeds at their default values.

• x 0.2 reported distances
  x 1 stations, ships, speeds: broadly oxp friendly
  x 5 (up to) asteroids
  x 10 planets
  x 15 space lane
  x 30 'suns'
  x 32 max torus speed, torus decelleration
  x 60 sun distance