Split: Re-scaling experiment

[Ranthe]

For the first time, the Anaconda feels truly massive. Bring on the 750 tonnes!

Oh yeah! That's more like it!

[Zireael]

Can we haz an updated binary for this? My compiling skills suck..

[Redspear]

Hi Zireael.

Been too busy for Oolite lately but hoping to get back to it over the holidays (one year on from when this whole thread kicked off ).
Thanks to Dizzy and another_commander for their work in helping to get this stuff out there. I hope to be able to put some polish on it for the new year.

Thanks.

[Diziet Sma]

Per Zireael's request, I'm looking to update the re-scaling binaries to implement the many changes that have been made to the trunk code since I last compiled them, a task I've been putting off for a while because I knew there had been some changes that would conflict with the rescaling code.

It turned out that the conflicts in oolite-priorityai.js and ShipEntity.m were quite trivial to deal with, but the ones (well, the first one, particularly) in Universe.m are a different matter, so I'm hoping that another_commander and/or Redspear can help me out here.

Around line 890-ish, I have the following conflict:

Code: Select all

<<<<<<< Updated upstream
	double planet_zpos = [planetDict oo_floatForKey:@"planet_distance" defaultValue:500000];
	planet_zpos *= [planetDict oo_floatForKey:@"planet_distance_multiplier" defaultValue:1.0];
=======
	double planet_radius = [a_planet radius];
	double planet_zpos = (24.0 + (Ranrot() & 3) - (Ranrot() & 3) ) * planet_radius; // 9..15 pr (planet radii) ahead // original value 12.0-now 24.0
>>>>>>> Stashed changes

and around line 1150-ish, there is this (which I don't think is too problematic, tbh):

Code: Select all

<<<<<<< Updated upstream

	vf = [systeminfo oo_vectorForKey:@"station_vector"];
#ifdef OO_DUMP_PLANETINFO
	OOLog(@"planetinfo.record",@"station_vector = %.3f %.3f %.3f",vf.x,vf.y,vf.z);
#endif
	stationPos = HPvector_subtract(stationPos, vectorToHPVector(vector_multiply_scalar(vf, 2.0 * planet_radius)));
=======
	Quaternion  q_station;
	do
	{
		quaternion_set_random(&q_station);
		vf = vector_forward_from_quaternion(q_station);
	}
	while (vf.z <= 0.0);						// keep station on the correct side of the planet
	
	stationPos = HPvector_subtract(stationPos, vectorToHPVector(vector_multiply_scalar(vf, 1.5 * planet_radius))); // original value 2.0
>>>>>>> Stashed changes

For the second conflict, I'm reasonably sure all I'll need to do is change (vector_multiply_scalar(vf, [color=#FF0000]2.0[/color] * planet_radius)) to (vector_multiply_scalar(vf, [color=#FF0000]1.5[/color] * planet_radius)) in the upstream version of the code, but the first conflict has me baffled as to how best to proceed..

Help, please?

[cim]

The second one, yes, that should be correct.

The first ... planetinfo.plist now contains explicit radius and planet_distance properties for all main planets. However, to make situations like this easier, there's also a new planet_distance_multiplier property which multiplies the distance by itself.

So, the original Redspear code doubled the witchpoint planet distance, and also somewhere else did something to the "documented radius":"in game radius" conversion factor (multiplied by 3, I think?). Therefore I think what you need to do here is keep the upstream update as-is, but add "planet_distance_multiplier" = 6; to the universal section of planetinfo.plist

[Diziet Sma]

Thanks cim.. I'll give that a shot.

[Diziet Sma]

Updated 32 and 64 bit executables are now available for download.. Windows only, unfortunately, until I can figure out why the Linux versions are refusing to compile.

Both are in the same download package. If you've followed the efforts with earlier versions, note that this time there is only a single "16 and 6" version. If it proves problematic, we can further tweak the deceleration settings.

Note that these are built against the current (Fri Dec 12) 84e97c1 version of trunk.. if you don't update to at least this version before using the files, I can't speak to the results you'll get.

Per cim's remarks above, I've also packaged up a new 1.2 version of Redspear's Rescaling_Oolite_OXP with an update for the new core planetinfo.plist file.

Release Notes:

This zip contains a 32bit and a 64bit Windows executable combining Redspear's rescaling experiment code with the current (84e97c1) trunk code. It is not guaranteed to work with earlier versions of trunk. To use, you must have Oolite Trunk installed alongside your normal Oolite install, and it must be updated to the current version. If you don't already have it installed, you can obtain the current nightly build at http://terrastorage.no-ip.info/oolite/status_win64.html or http://terrastorage.no-ip.info/oolite/status_win32.html as appropriate. Make a copy of the existing oolite.exe file, and save it somewhere, so you can put it back later, if desired. Then replace it with the testing executable for your system.

Please report the results of your testing in the Rescaling Experiment thread on the Oolite BB.

A copy of js32ECMAv5dbg.dll is also included. You may need to copy this to the Trunk's /oolite.app folder as well, in order to run the game.



Due to extensive changes in trunk over the last few months, it was also necessary to update Redspear's Rescaling_Oolite_OXP, to include a small addition to planetinfo.plist. The new version (1.2) is included in this bundle.



Please remember that at the current state of Oolite Trunk, any game-save you use for testing will not load correctly under Oolite 1.80. If you wish to use your current Commander rather than starting a new test-Commander, be sure to use a renamed copy. If you start a new Commander, you may want to hack the save file to provide sufficient credits for whatever equipment you prefer to use during the test.. at minimum you will probably want injectors, so as not to be constantly sidetracked by pirates and masslocks.

Download here.

Enjoy, and good luck with your testing. Feedback, whether positive or negative, is requested.

[Diziet Sma]

Well, after 9 months of no action, I noticed that recently somebody downloaded my rescaling executables, and then the other day Fritz made a remark that got me looking this thread over once again, so I'm thinking perhaps it's time that we breathed some life back into this project, and got it working with 1.83.

Looking over the code, there doesn't seem to be too much that's changed, but I suspect that the significant changes made to the way planets (and stars) are handled since 1.82 are going to introduce some headaches.

Could cim and/or another_commander please comment on just how the system has been altered, whether this makes things easier or harder from a rescaling perspective, and what may need changing in Universe.m, OOStellarBody.h and OOPlanetEntity.m (or in other files) to get things back on track?

[cim]

Should in general be easier, but might need more work:
- bugs with display of stars a long way away or at larger sizes are fixed
- setting sun_distance_multiplier will save a lot of time on system scales
- planet z-distances are now settable from planetinfo.plist
So probably fewer code changes are needed, but more planetinfo.plist entries.

[Diziet Sma]

So instead of the old method of making a couple of changes to Universe.m and OOPlanetEntity.m, we will now need to alter every individual planetary radius, sun_radius and z-distance via planetinfo.plist?

We already have sun_distance_multiplier and planet_distance_multiplier.. I'd like to request sun_radius_multiplier and planet_radius_multiplier as well, if that's not too hard to add to the code. It would tremendously simplify altering planetinfo.plist if we could do that.

(Incidentally, I don't see z-distance mentioned in planetinfo.plist.. what exactly does that refer to? Do we need to make an additional entry for each system?)

[cim]

So instead of the old method of making a couple of changes to Universe.m and OOPlanetEntity.m, we will now need to alter every individual planetary radius, sun_radius and z-distance via planetinfo.plist?

You still have the option of patching those two files to apply the multiplier and recompiling. (For planets, you almost certainly would want to do this, as it's the scaling factor between F7 radius and in-game radius you wish to adjust)

I can have a look at adding these parameters, though.

(Incidentally, I don't see z-distance mentioned in planetinfo.plist.. what exactly does that refer to? Do we need to make an additional entry for each system?)

z-distance is the planet_distance key. It's the z-coordinate of the centre of the main planet.

[Diziet Sma]

I can have a look at adding these parameters, though.

Providing it doesn't adversely affect the F7 radius, yes please.

Thanks cim.. much appreciated!

[Day]

I'm quite eager to try this experiment! May your code be bugfree. (Ooniverse blesssing)

[Redspear]

Well, after hardly touching this in a year, I blew the dust off my code for 1.81...

Some observations:

• x8 torus decelleration balances the extra base speed (torus) but not the reduced scanner range - scanner shrunk by half therefore x16 decelleration is closer to the normal game experience in terms of relating to objects within scanner range.
• I did try making systems even bigger (some time ago @ x6.6 rather than x3.3) but that added little to the experience and made it too easy to overshoot the station when torus-ing in. x3.3 makes for a better experience IMO.
• The greater witchpoint to planet distance is closer to the original elite game but encounters are much more common in Oolite. I've had more fun from my limited playing time by doubling the width of the spacelane (signposted up-thread). This is closer to the original elite in two respects: 1, less encounters (and therefore less time spent in mass-lock); 2, less obvious that there is a 'space lane'. Not for everyone of course but may appeal to some.

[Redspear]

I must post code updates for this soon...

I've got it working in 1.83 and it's the version I play (unless testing certain oxps).

OXP compatibility issues:

• Whether shrunk or not, all imported ships need to have their speeds halved
  All imported 'laser' weapons need to have their ranges halved

Otherwise, it works great (IMO) but I confess to just playing with it in 1.83 rather than testing it to destruction.