Oolite Bulletins

cim wrote:

Redspear wrote:

Is that also true for NO_DRAW_DISTANCE_FACTOR in Entity.h?

That determines when an entity is too far away to consider drawing it on screen. Increasing it will increase the derived ABSOLUTE_NO_DRAW_DISTANCE2, which you probably do need to do, but you're probably better off increasing the '2500' factor in that constant instead to be definitely larger than your largest non-planet/sun entity.

As I expect cim realised, this can also be used to make planetary rings appear from much greater distances.
The frame rate did take a hit though...

It's not necessary for the rescaling project (no models have been made any larger and scanner range has been reduced) but seeing those rings at a distance sure does look cool

Not much time for testing (as usual ) but all seems to be well, so I should be posting more code very soon.

Meanwhile, given that I have rescaled the ships by different factors, this obviously changes the game experience (and balance as Norby pointed out). Given the 3 different scaling factors for the ships, I had to decide which ones to use for the scanner and also for the weapon ranges. Here's my current set-up (I can post code changes for other options in future):

• Scanner Range x 0.5
  Ship Speed x 0.5
  Laser Range x 0.33
  Missile Range x 1

That the scanner and speeds match means that mass-locks take just as long as in the standard game and that the short-range environment of the scanner will seem just as big as before.
Shrinking the laser ranges by 0.33 means that the smallest ships will remain just as visible as before (but that fighter traders like the cobra 3 and freighters like the python will appear larger on screen).
With the fighters having their size shrunk more than their speed they will be slightly more evasive; the opposite is true for the freighters.
Missiles are now the only weapons that can reach to the edge of the scanner (and beyond...)

So this gives a slight advantage to the fighters and a (potentially considerable) combat disadvantage to the freighters. I like this; if I didn't I could have either shrunk everything by the same amount or made sure that speed reduction was proportional to model reduction. Never the less, some shipdata adjustment may be complementary to the approach I've taken.

I always found it surprising that the fighters had so many energy banks. I suppose it makes sense when you consider the size of them, but now that I've changed that...
I'm considering depriving the fighters of one energy bank each (not the Adder or Worm - which have been shrunk as much as the 'fighters'). So then a sidewinder has 2 energy banks instead of 3 (which is no less than the now larger cobra I). The Freighters I will perhaps add more energy to, or missiles, or both.

As I say, code changes can be posted to avoid all that (at folks discretion to decide which version to try) but I've only written a shipdata plist and adjusted the models for the ship rescaling as described above and here.

The great news for me is that both planet and ship rescaling are now both working as hoped (or at least appear to be) and that my game experience is significantly enhanced

dertien wrote:

However I cannot find this line in the file.

even when searching for it. I have 1.81

Any help with that ?

Found it

It's now in PlayerEntity.m
Line 2891

Thanks for the pics.. of the ships, particularly.. makes the difference in sizes very apparent.. me likes!

Diziet Sma wrote:

Thanks for the pics.. of the ships, particularly.. makes the difference in sizes very apparent.. me likes!

Glad to hear it

I have more of course
(Like someone overly fond of his holiday snaps, I hope you'll indulge me )


The cargo scoop test...


Never been so happy to scoop a tonne of food

Docking... I think I might just make it...

Is that Welsh I see there? Nice one Griff

Now for a real show of scale difference... Anaconda hunting in an Adder!

Thar be the beast! Lurking just beneath the station...

See that forth engine on the Anaconda?...

...That's actually me in an Adder!

The fly-by...





Felt like I was overtaking a star-destroyer

1.80 rescaling (both for systems and ships) is essentially done. Just got to tweak the thargoid scanner (nearly forgot... )

Words fail me.. that is just.. WOW.

Kudos and much respect.. fantastic job, Redspear!

Redspear wrote:

1.80 rescaling (both for systems and ships) is essentially done. Just got to tweak the thargoid scanner (nearly forgot... )

Any chance of a patch against current trunk or (maybe even better) a pull request on github when this is all officially complete? It would be really cool if your changes could be activated via either a compile switch or a user defaults option, too.

another_commander wrote:

Redspear wrote:

1.80 rescaling (both for systems and ships) is essentially done. Just got to tweak the thargoid scanner (nearly forgot... )

Any chance of a patch against current trunk or (maybe even better) a pull request on github when this is all officially complete? It would be really cool if your changes could be activated via either a compile switch or a user defaults option, too.

I agree. It would be very awesome.

Redspear wrote:

With the fighters having their size shrunk more than their speed they will be slightly more evasive; the opposite is true for the freighters.
Missiles are now the only weapons that can reach to the edge of the scanner (and beyond...)

So this gives a slight advantage to the fighters and a (potentially considerable) combat disadvantage to the freighters. I like this; if I didn't I could have either shrunk everything by the same amount or made sure that speed reduction was proportional to model reduction. Never the less, some shipdata adjustment may be complementary to the approach I've taken.

I always found it surprising that the fighters had so many energy banks. I suppose it makes sense when you consider the size of them, but now that I've changed that...
I'm considering depriving the fighters of one energy bank each (not the Adder or Worm - which have been shrunk as much as the 'fighters'). So then a sidewinder has 2 energy banks instead of 3 (which is no less than the now larger cobra I). The Freighters I will perhaps add more energy to, or missiles, or both.

I'm not entirely convinced that tweaking ship's stats, other than size, is a good idea at this point.. perhaps it would be better to leave energy banks, etc, alone until more extensive playtesting can be done by a larger group of testers. Any potential issues could then be discussed and changes tried out.

another_commander wrote:

Redspear wrote:

1.80 rescaling (both for systems and ships) is essentially done. Just got to tweak the thargoid scanner (nearly forgot... )

Any chance of a patch against current trunk or (maybe even better) a pull request on github when this is all officially complete? It would be really cool if your changes could be activated via either a compile switch or a user defaults option, too.

Agreed.

I'm not entirely convinced that tweaking ship's stats, other than size, is a good idea at this point.. perhaps it would be better to leave energy banks, etc, alone until more extensive playtesting can be done by a larger group of testers. Any potential issues could then be discussed and changes tried out.

Agreed.

Diziet Sma wrote:

Words fail me.. that is just.. WOW.

Kudos and much respect.. fantastic job, Redspear!

Sincere thanks for your continued support Dizzy. Ever since I first revealed my plans for this project, the encouragement has certainly helped with motivation

another_commander wrote:

Any chance of a patch against current trunk or (maybe even better) a pull request on github when this is all officially complete? It would be really cool if your changes could be activated via either a compile switch or a user defaults option, too.

Oh yes, I think so. There are a few changes to navigate with the current trunk but I think I've already caught most of them. From a personal point of view, if that were to happen, it would be EXTREMELY cool. So glad you're interested, thanks

Not a clue how to use github yet, but how hard can it be?... right?

Diziet Sma wrote:

Redspear wrote:

I'm considering depriving the fighters of one energy bank each (not the Adder or Worm - which have been shrunk as much as the 'fighters'). So then a sidewinder has 2 energy banks instead of 3 (which is no less than the now larger cobra I). The Freighters I will perhaps add more energy to, or missiles, or both.

I'm not entirely convinced that tweaking ship's stats, other than size, is a good idea at this point.. perhaps it would be better to leave energy banks, etc, alone until more extensive playtesting can be done by a larger group of testers. Any potential issues could then be discussed and changes tried out.

Me neither (nice use of italics by the way ).
Yeah, that's no problem, sensible even. That part is just a shipdata-overrides.plist so it can be released as an oxp for people to tweak however they want.

Thanks also to Zireal and Tichy for your interest and feedback

Redspear wrote:

Not much time for testing (as usual ) but all seems to be well, so I should be posting more code very soon.

A complete up-to-date list of all the code changes would be very helpful.. I've just cloned the git repository in anticipation of compiling and testing this..

And if I understand correctly, you've also made some significant changes to one or two plists.. making them downloadable via a box.com account may be the simplest way of distributing those..

What about a diff and have it as compiletime option (like --with-plist-tweaks).

Anyway, your rescale experiment is great, Redspear. The anny/adder shot is is fabulous.
In case you need another tester running a Linux box count me in.

Thanks Dizzy, thanks Amah

OK, so the stuff you've seen so far was from 1.80 rather than current trunk (still tinkering with that one).

It might help if I list here the necessary adjustments and then edit this post as I am able to confirm them for 1.81.
I've split it into 3 different parts. Each one relies only on the code changes within it but if you like the idea of part II then you should probably have part I in order to really get the benefit.

Part I: System Rescaling

Part I on its own will give you a bigger system but that will only be apparent when you're involved in sun-skimming, planet-falling and searching for the station. Things are bigger but the only obvious advantage is in making the planet to station size ratio look more believable.

• Make planets, suns and moons bigger

  OOPlanetEntity.m - line 106 wrote:

  collision_radius = radius_km * 33.0; // Scale down by a factor of 100, original value 10.0

• Adjust planet size on F7 screen

  OOStellarBody.h - line 53 wrote:

  #define PLANET_MINIATURE_FACTOR 0.0005 // original value 0.00185

• Increase torus drive multiplier (I know this works differently for 1.81 but early tests suggest I'd still need to adjust it)

  PlayerEntity.h - lines 299 & 302 wrote:

  #define MIN_HYPERSPEED_FACTOR 64.0 // original value 32.0
  #define HYPERSPEED_FACTOR 64 // original value 32

• Increase torus drive decelleration

  PlayerEntity.m - line 2658 wrote:

  float deceleration = (speed_delta * delta_t * HYPERSPEED_FACTOR * 2); // original has no * 2

• Reduce mass-lock radius for planets and suns

  PlayerEntity.m - line 2891 wrote:

  double factor = ([stellar isSun]) ? 1.4 : 1.0; // original values 2.0 : 4.0

• Adjust sun-skimming parameters for non-player ships

  oolite-populator.js - lines 1474 & 1480 wrote:

  t[0].heatInsulation = 20; // original value 6
  gs.heatInsulation = 20; // original value 6

  oolite-priorityai.js - line 2029 wrote:

  (this.ship.heatInsulation > 1000/this.ship.maxSpeed || this.ship.heatInsulation >= 40)); // original value 12

Part II: System Rearrangement

Adding Part II will make a big difference to the appearance of the system, in that the changes made in Part I will now be more apparent from a distance. There is a sense of space being bigger.

• Double planet distance from witchpoint

  Universe.m - line 893 wrote:

  double planet_zpos = (24.0 + (Ranrot() & 3) - (Ranrot() & 3) ) * planet_radius; // 9..15 pr (planet radii) ahead // original value 12.0

• Increase torus drive multiplier (needs to be doubled from value in Part I)

  As above but double values for both min hyperspeed and decelleration multiplier

• Halve orbit of station

  Universe.m - line 1121 wrote:

  stationPos = HPvector_subtract(stationPos, vectorToHPVector(vector_multiply_scalar(vf, 1.5 * planet_radius))); // original value 2.0

• Bring nav beacon closer to station

  oolite-populator.js - line 119 wrote:

  coordinates: system.mainStation.position.add(system.mainStation.vectorForward.multiply(5E3)), // original value 10E3

• Widen the space lane (not necessary if combining with ship rescaling)

  Universe.m - line 117 wrote:

  #define LANE_WIDTH 102400.0 // original value 51200.0

• Enable large objects to appear at much greater distances

  Entity.h - line 46 wrote:

  #define ABSOLUTE_NO_DRAW_DISTANCE2 (25000.0 * 25000.0 * NO_DRAW_DISTANCE_FACTOR * NO_DRAW_DISTANCE_FACTOR) // original values 2500.0

Part III: Ship Rescaling

Part III adjusts the ships themselves. Because the ships have been sized differently, if you're piloting a ship that has been halved or reduced to a third in size then that factor will also make systems appear even larger. So for that adder pilot, the anaconda appeared 3 times bigger than in the standard game but a planet would appear around 10 times bigger. As the cobra III has been halved in size, many players would experience planets 6.6 times bigger than they are used to. Cargo pods will appear rather small if you're in an anaconda...

• Reduce the scanner Radius

  Entity.h -lines 50 & 51 wrote:

  #define SCANNER_MAX_RANGE 12800.0 // original value 25600.0
  #define SCANNER_MAX_RANGE2 163840000.0 // original value 655360000.0

• Prevent 'lollypops' from appearing outside the scanner

  HeadUpDisplay.h - line 42 wrote:

  #define SCANNER_SCALE 128 // original value 256

• Reduce laser ranges (now possible via oxp)
• Rescale ship models (oxp)
• Adjust shipdata and halve speeds (oxp)
• Another doubling of the torus multiplier to account for those reduced speeds

  As above but double values for both min hyperspeed and decelleration multiplier (cumulative with part II)

• Adjust Thargoid scanner radius to new scaling (oxp)
• Adjust turret range

  ShipEntity.m - lines 418 & 10822 wrote:

  weaponRange = 3300.0; // original value 10000.0
  weaponRange = 3300.0; // original value 10000.0

• Adjust ship behaviour to new ranges

  ShipEntity.m - lines 4404, 4734, 4953 & 13166 wrote:

  if (getWeaponRangeFromType(forward_weapon_real_type) > 4125 && range > 4125) // original values 12500
  else if (range < 4950) // original value 15000
  if (range < 1500) // original value 3000
  double range2, nearest2 = SCANNER_MAX_RANGE2 * 10000000.0; // 1000x typical scanner range (25600 km), squared. (Added an extra 0. Redspear)

With the exception of the very last one, all of those changes have now been coded for 1.80. Whilst it's true that I haven't sat watching computer piloted sun-skimmers go about their business, everything else has been tested. Many of these code changes will be the same for 1.81 but some have moved, many within the same file and some to other files. Nearly all of these migrations have been tracked and will be confirmed here soon.

It's possible that I've left out some other tweaks that I've done but I can add to this post as I recall them. For example, there's some mysterious stuff I did in January, before my 5 month break, that makes little sense now; I think it was just some early fumblings but I might have another look.

I hope to flesh this out as much as possible over the weekend.

This list is now complete in at least as far as my current testing has revealed.
I expect further alterations but I am not currently aware of the need for any.

Just got to get my head around Github and then we're off

Very promising project, Redspear. I was following this thread from very start and now really itching to get my hands on the branched code for some play testing. If you could provide details about where to point my git to pull down the changes I will be happy to do that.

Thanks and Good work Commander!
VSFC