Oolite Bulletins

another_commander wrote: ↑Sun Mar 26, 2017 4:57 pm

I have updated Dizzy's github fork with the changes required for the rescaling, as per Redspear's latest instructions. You can build from the fork's repository and test it: https://github.com/Garryck/oolite-rescaling-experiment

Thanks, a_c.. that was on my to-do list for this morning.

I've compiled the rescaling code for 64bit Windows machines..

If anyone already has an up-to-date installation of trunk, you can swap the executable in, in place of the regular trunk executable, and install the 1.3 version of the rescaling OXP (link below), to test out the build yourself.

Note that if you have built from source yourself, you DO NOT need the OXP. The OXP is only to supply copies of 4 resource files (3 plists and a JS script) that have been altered from a normal build. If you've built from source, you already have the correct versions of those files in your build.

Rescale executable:
https://www.dropbox.com/s/slwa1zsd1gybw ... e.exe?dl=0

Rescale OXP:
https://www.dropbox.com/s/uj2dt2v3xndta ... p.zip?dl=0



If anyone needs a 32bit version of the executable, just ask..

Well..

It looks like the display-lollipop range setting is going to need some tweaking. I started a fresh Jameson, and took a trip to Zaonce, and found I was regularly getting mass-locked with nothing showing on the scanner.

Turns out ships and other objects would only appear on-scanner at around 2/3 - 3/4 of maximum scanner range, and would disappear from the scanner when about 2/3 - 3/4 of the way back out to the edge. I would then remain mass-locked until about when they should have disappeared off the scanner.

Edit:
It looks like works a lot better for me.. which is kinda what I'd have expected, given that the original value was 256, and the scanner range has been halved. Objects are now appearing and disappearing right at the scanner edge, as they should.

Ok, I can see what has gone wrong here...

First of all the fix:

The value of 85.33 was actually correct, it is the two scanner size lines above that are wrong.
The scanner in this version is supposed to be at 33%, not 50%, as explanied up thread.

So scanner max range should be 8533.0
scanner max range2 should be 72812089.0

Now the explanation:

I still had an old version of entity.h as a tab on notepad++ and I simply copied the version 2 numbers by mistake.
I realised this had happened with some other values and was able to fix them but those two slipped through the net.

The scanner is supposed to be one third of its original size in order for this version to work properly.

Apologies for the confusion.

another_commander has updated the scanner ranges on GitHub.

Here's a 64bit Windows build with the correct scanner ranges applied. There's also a copy of the rescaling OXP bundled with it.

https://www.dropbox.com/s/z99t8dndrkmel ... 1.zip?dl=0

Thanks again to Dizzy and another_commander.

another_commander wrote:

Redspear, github seems like a monster when you get started but it's really only a few actions that you need to learn and perform.

In this regard so many things in life are similar that I'm almost certain you are right.

another_commander wrote:

Once you start working with it you'll wonder why you hadn't done it this way from the very start.

Looking more and more like prophesy by the second

It turns out that by reducing all ship speeds by 50%, the speeds displayed in the F4 Ship Library were being under-reported.. eg, the Cobra III is "Very Slow" and the Viper Interceptor only "Average"!








I've reduced the values in OOShipLibraryDescriptions.m by 50%, in lines 49, 53, 57 & 61 to put things back the way they should be.

Good spot Dizzy!

I didn't realise that those values were calculated.

Viper Interceptor as 'average' is quite amusing

V3.02 Win64 build, with Ship Library fix applied, bundled with the Rescale OXP, download link:

https://www.dropbox.com/s/teo9ia9phdesh ... 2.zip?dl=0

Having spent the evening playing around with an iron-arsed Cobby, my main impression was that encounters seemed a bit less frequent than in a stock game.. but random numbers being what they are, this probably needs more testing before reaching a conclusion.

Does Traffic Redistributor help with this?

Redspear wrote: ↑Sat Mar 18, 2017 7:22 pm

Having made the traffic redistributed oxp it combines very nicely with the reduced scanner I've been testing recently. Furthermore, one of my early reservations concerning a reduced scanner has proved to be more of a boon than a curse (at least to me).

At 1/3 standard scanner size it is quite easy to overshoot the station when using the torus drive. At first I saw this as a problem and undesirable. Having played with it for a while now however it is starting to feel like gameplay.

Steering your torus propelled ship towards a station that is now very much dwarfed by the planet it orbits has become, dare I say it, fun. Thrilling, no, it is hardly the planetary landing sequence in 'Aliens' but once I stopped expecting the compass to remain perfectly aligned the entire time then it actually became quite fun; like a much more forgiving version of docking.

Absolutely! I very much enjoyed the new style station approaches when playing.. much more fun than in a stock game, IMO. Particularly once one has the ASC installed.

Redspear wrote: ↑Sat Mar 18, 2017 7:22 pm

remaining things for testing include ... mining with the new asteroids.

If there's anything else someone thinks really needs testing (where my tinkerings are likely to have an effect) then please let me know. Thanks

Is there anything other than asteroid mining that needs testing, that you can think of?

I'll be having a go at the Rescale build tonight and will let you know about my findings.

Re encounter rates: adjusting the lane width was the way I used to balance this but right now I can't recall the maths required to make it comparable to the standard game; once I'm back at the PC it should be a simple matter.

Disembodied wrote:

I very much enjoyed the new style station approaches when playing.. much more fun than in a stock game, IMO.

So it's not just me then And to think it was only a last minute decision to abandon the 1/3 range scanner for version 1 of the experiment.

Hard to think what else might need testing right now. A couple of non-player things: sun-skimming and planet-station shuttle journeys.


Thanks pleiadian, I look forward to reading your thoughts.

Diziet Sma wrote: ↑Tue Mar 28, 2017 11:49 am

Having spent the evening playing around with an iron-arsed Cobby, my main impression was that encounters seemed a bit less frequent than in a stock game...

Does Traffic Redistributor help with this?

What traffic redistributer (a seperate oxp) does is to skew the encounter rates to make the slower traders more common in an effort to reduce the ocurrance of the longest mass-locks.

Three major determnants in terms of mass-lock duration are

• Heading of mass-locking ships relative to the player
• Speed Difference between player and mass-locking ship (with a large difference in the player's favour being the most desirable)
• Scanner Range with a larger reach taking longer to clear

So whilst traffic redistributer addresses speed difference factor, rescaling addresses scanner range (33% reach at half speed taking 66% normal duration to clear).

As long as lane width has been adjusted to suit scanner size (and lane length which has been roughly doubled) then encounter rates should remain much the same. With the reduced scanner non-hostile encounters will be taking less time however.

It is true that prior to the two mass-lock 'solutions' listed above I was favouring a reduced encounter rate so some relic of that preference may still be lingering.

The real question of course is what sort of encounter rate would be the most fun?

Lol, I have four slightly different copies of Oolite now:

- vanilla 1.84
- vanilla trunk 1.85
- locally built and hacked 1.85
- locally built rescaling experiment branch

Astrobe wrote: ↑Wed Mar 29, 2017 5:09 pm

Lol, I have four slightly different copies of Oolite now:

- vanilla 1.84
- vanilla trunk 1.85
- locally built and hacked 1.85
- locally built rescaling experiment branch

Welcome to the club.

Explanation:
AddOns: Standard OXP folder
AddOnsDebugOnly: Only Debug.oxp here, helps with quick testing core game only
Debug Console: Debug Console files and executable
old: Earlier versions of Oolite, going as back as 1.62 alpha
oogit: Contains
. - Standard repositroy dev checkout - this is where commits are coming from
. - A general play-with-and-experiment-till-you-break-it read-only checkout (just so that I can't accidentally commit anything from here)
. - RescalingXP checkout
oolite.app: Latest trunk, play at own risk in here
oolite180.app: v1.80, for quick testing whether a reported bug was in that version or not
oolite182.app: v1.82, for quick testing whether a reported bug was in that version or not
oolite184.app: v1.84, for quick testing whether a reported bug was in that version or not

Some of these folders contain their own sub-AddOns folders, just to make things more interesting.
Madness.
Sorry for the off-topic.