Split: Re-scaling experiment

[another_commander]

Could you please post a patch? I'd like to update the related branch on github with the latest changes.

To generate a patch file, just execute this from the root folder of your oolite checkout that contains your changes:
git diff > mypatch.diff

In case the patch file is too big to post here, you could always send it by email to another_commander at oolite point org.

As for testing, I could generate an unofficial binary once the branch has been updated to allow anyone interested to download and test for themselves. We could even consider making it official in the future, but before getting anywhere near that, we need to have a lot of testing done (as well as consensus that the rescaled game is better than the current one) and a binary based on 1.83 could help tremendously.

[Redspear]

Sure, I'll be happy to...

Got to get some time at the PC first and undo some of my other changes (jump ranges et.al.)
Fingers crossed I'll have labelled everything

Yes, it definitely needs more testing.
Have there been any changes to fuel scooping/sun skimming since 1.80?

Hope to be able to post some time this week (sorry for delay).

[Day]

:-p :-p :-p

[Redspear]

I've posted the patch to a_c, so fingers crossed I've managed to remove all of my other tinkerings beforehand.

(The patch itself would make a very long and boring post here... even by my standards )

[another_commander]

The patch is now on github. Redspear, can you please double check it to be sure I didn't miss anything?

A Windows binary containing the current results of the experiment will be uploaded sometime tomorrow. Stay tuned.

[Redspear]

For some reason I rescaled turret ranges by 0.33 rather than the 0.5 that lasers were rescaled by (can't recall why).
That's probably undesirable behaviour and so some of the alterations in ShipEntity.m might be better adjusted ('corrections' in bold and underlined):

@@ -448,7 +448,7 @@ static ShipEntity *doOctreesCollide(ShipEntity *prime, ShipEntity *other);
}
if (isWeaponNone(weapon_type) && hasTurrets)
{ // safety for ships only equipped with turrets
- weaponRange = 10000.0;
+ weaponRange = 5000.0;
}
else
{

My fault again but this also looks like some more victims of the same mistake:

@@ -4692,7 +4692,7 @@ ShipEntity* doOctreesCollide(ShipEntity* prime, ShipEntity* other)
jink = kZeroVector; // almost all behaviours

// TODO: good pilots use behaviour_attack_sniper sometimes
- if (getWeaponRangeFromType(forward_weapon_real_type) > 12500 && range > 12500)
+ if (getWeaponRangeFromType(forward_weapon_real_type) > 6250 && range > 6250)
{
behaviour = BEHAVIOUR_ATTACK_SNIPER;
}

@@ -11538,7 +11538,7 @@ Vector positionOffsetForShipInRotationToAlignment(ShipEntity* ship, Quaternion q
}
if (isWeaponNone(weapon_type) && hasTurrets)
{ // no forward weapon but has turrets, so set up range calculations accordingly
- weaponRange = 10000.0;
+ weaponRange = 5000.0;
}
else
{

[Redspear]

Not an error as such but rather something that didn't work as expected (based on experience with earlier versions).

- planet_zpos *= [planetDict oo_floatForKey:@"planet_distance_multiplier" defaultValue:1.0];
+ planet_zpos *= [planetDict oo_floatForKey:@"planet_distance_multiplier" defaultValue:5.0];

5.0 is a 'placeholder' value that seems to achieve the desired effect of approx. double witchpoint distance relative to the size of the planet (so planet appears twice as far from the witchpoint).

[another_commander]

OK, here we go: The Rescaling Experiment Build 01 for Win32/64, based on current v1.83, can be downloaded from here:
Oolite Rescaling Experiment - Build 01 - x86/64

Just unzip the folder contained in the zip file to your hard disk and run the oolite.exe as usual. The build contains all that is needed (no external OXP required this time). I would recommend trying it first without any OXPs just to see what it feels like when run unmodified, then add expansions one at a time if you wish and see how it goes.

In this build, planets should feel much larger, stations and big ships should feel bigger than before, small ships should feel smaller than before. Distances should feel bigger, but travel time should be more or less similar to what we have now. Test and let us know what you think. Is it OK for you? Does it succeed in generating a better sense of scale? Do you notice any changes to the AI that could be related to the change in sizes? How is sun skimming and planet diving like?

This build does not contain the changes mentioned a couple of posts earlier by Redspear. Most likely there will be another one with those modifications applied for comparison reasons, but for now let's see what we can get with what we have got.

Big props and thanks to Redspear for this contribution. This is something that was definitely worth attempting, if anything, to prove that with enough dedication and persistence, anything can be possible. Hopefully we can take it further now, based on the input received.

Finally, for those who are worried about downloading random binaries from the Internet, here is the VirusTotal report on the released file:
https://www.virustotal.com/en/file/8a5e ... 458488013/.

[Cody]

<chortles> Perhaps it's me, but it plays havoc with spara's Nav-MFD as regards destination planet distances. Not too surprising, that.

Blips on the scanner move very jerkily with this build, and scanner_non_linear = yes; and scanner_ultra_zoom = yes; don't seem to work - is it me?

[Redspear]

<chortles> Perhaps it's me, but it plays havoc with spara's Nav-MFD as regards destination planet distances. Not too surprising, that.

Not tried it with that one but, as you say, not entirely surprising.

Blips on the scanner move very jerkily with this build, and scanner_non_linear = yes; and scanner_ultra_zoom = yes; don't seem to work - is it me?

Well, the scanner is half as big (in terms of reach) as before but then the ships are half as fast as before, so I don't see why it should be more 'jerky' - I might have to look into that. Some ships being smaller might make the difference but I can't say I've noticed it myself. Do you have any other oxp's 'on the go' that could be related? HUD perhaps???

As for the two settings you mention, I must confess to not having used them.

Thanks for the feedback.

[Cody]

Well, the scanner is half as big (in terms of reach) as before...

Ahh - that possibly explains why the scanner zoom settings don't work.

Do you have any other oxp's 'on the go' that could be related? HUD perhaps???

I'm using a few OXPs from my standard trunk build, so nothing should be different - but the above may apply here too.

I've been using a sun-distance modifier for years (disabled in this build), so I've pretty much forgotten how a planet should appear whilst sun-skimming at default distances, but this seems rather too large - doesn't seem right, somehow, in a re-scaling experiment.

[another_commander]

Can't see any jerkiness on the scanner blips here and both scanner non linear and ultra zoom (hud.plist settings - not .GNUstepDefaults) work fine.

Edit: Fully agree on the planet size when sun skimming. Probably suns should be moved quite a bit further away from the planets, now that planets are 3x their default size.

[Cody]

Can't see any jerkiness on the scanner blips here and both scanner non linear and ultra zoom (hud.plist settings - not .GNUstepDefaults) work fine.

Hmm... strange! Even without any OXPs I get jerky scanner blips, and I've triple-checked my GPU settings (to match the other builds). I'll experiment further!
As for the scanner thingies, I can't get them to work - again, I'll experiment further.

Increasing default sun-planet distances definitely needs doing, yes! First impression generally feels good though.

[Redspear]

Increasing default sun-planet distances definitely needs doing, yes!

That's a good point. It was never on my 'to do' list simply because it had already been done several times by various oxps (I was busy wrestling with with the unknown )
Now that this is a sans-oxp build however (at least in terms of requirements), it makes sense to include it.

Curiously, when I get that close to a sun, the planets are very difficult to see due to the effects of the now enlarged corona; maybe I need to try it with a glare filter

The sun should be able to be moved at least twice as far and still have a comparable travel time to the default game (with no sun distance modifier). As I wanted the witchpoint to be twice as far (proportionally that is - it is actually 6.6 times further away if I remember) I made the torus drive compensate for that, so it should be able to do the same for sun distance in terms of travel time. Here, however, there's probably a case for moving it considerably further.

First impression generally feels good though.

Great! There's bound to be more stuff in there that needs troubleshooting though... I have a reputation to maintain

[Cody]

A clean re-install fixed the jerky scanner blips - no idea why, but hey!

If you're going for effective re-scaling, in my opinion suns should be at least 5x further from planets - but that may be too far for some players.