Split: Re-scaling experiment

[Redspear]

Oh well, good news re the blips.

On my computer it's a LOT more than x5 but, as you suggest, it's not for everyone.

There's a trade off between realism and practicality with regards to sun distance: too near and it looks a bit silly; too far and fuel scooping starts to become a PITA. The changes to how the torus drive works (i.e. in the standard game since the start of this thread) make longer distances more bearable but the conflict remains IMHO.

[Cody]

On my computer it's a LOT more than x5...

I've experimented with much higher modifiers too, but that was before the improvements to the torus drive. I've been using 5x in deployment/trunk builds, so I'll try that with this build and see how it looks, then play with the numbers!

[Redspear]

Assuming that neither increasing planet size, nor planet to witchpoint distance, affect planet to sun distance...

Increasing the distance modifier by 3.3 (planet increase size) + 2 (planet - witchpoint distance multiplier) = 6.6 times should both make it very similar in experience to the standard game and yet also make the sun appear twice as far away as normal.

Therefore, if familiar with a x5 sun distance modifier then a multiplier of x33 (6.6*5) should give a similar gameplay experience to what you're used to but with superior realism in this regard.

...or at least I think it will.

[Svengali]

First impression is really good (and no jerky blips here), but as you say suns will need more work.

I'll try to fight some of the smaller vessels in the next run to see if it gets harder to hit them. What I've already noticed is that most of the time you don't come close enough to enjoy Griffs fine work.

[Cody]

At orbital distances, I think planet textures such as Povray may struggle a little, both in performance and appearance.

[Redspear]

What I've already noticed is that most of the time you don't come close enough to enjoy Griffs fine work.

That's why the turret ranges were at 0.33 up thread (most of this was done in 2014, so I'm trying to remember what I was thinking at that time...)

Originally the most severe ship reduction was at 0.33 times and so weapon ranges were reduced by the same amount. So ships at a third of the size fighting you at a third of the range look just as close. For other reasons however, I wanted the scanner at half size and so whilst a third of the laser range over a half sized scanner makes for an interesting scenario IMO, it also probably deviates a little too much from the standard game.

The smallest ships should appear 0.33 x 2 = 0.66 times as big when fighting at long range.
The standard is the cobra mk III et.al at 0.5 x2 = 1 times as big.
Whilst the freighters and transporter/shuttles should be 1 x 2 = 2 times as big.

We could reduce the more extreme shrinkage range e.g. in this version I think the Asp mk II is scaled at 0.4 and so would appear (0.4 x 2 = ) 0.8 times as big as before, perhaps that would be a preferable result. 0.365 has also been used in there (0.365 x 2 = 0.73) for a few ships to e.g. mamba, so see which ships seem too far away and which are fine.

Of course, the differing scales affect combat but I think a fighter should be much harder to target than a freighter.

If you don't care for ship rescaling then adjust them all to model_scale_factor 0.5 and then the only big change will be how easy it is to dock.

At orbital distances, I think planet textures such as Povray may struggle a little, both in performance and appearance.

Possibly. I did have them installed in the early days of my testing and I thought they stood up fairly well unless using planetfall. Being an oxp, I'm afraid I might not have considered it very important at the time...

I do have some images of getting very close to various planet textures from a year or so ago. I'll see if I can dig them up.

Edited to correct maths typo...

[Fritz]

Hm. I must admit that I've neglected Oolite a little bit in the past two months (because of real-life issues), but I really have to try it! I fear that there will be problems with "torus synchronization" in the "Escort Contracts" and "Synchronized Torus" OXPs, because torus speed and minimum and maximum distance for synchronization is hard-coded.

[Redspear]

Thinking about it some more, the approach I took in the old version (2014) re laser ranges at x 0.33 is probably better, if a little unusual for oolite....

Firstly, even the smallest ships can then appear as big as before in combat. Some of the others will appear slightly (or significantly in some cases) bigger. We often don't see that much of the ships that we're fighting in the standard game as it is, so making them come closer needn't be a bad thing.

Secondly, there's a pleasing (if not normally present in oolite) dynamic with regards to the scanner range. 0.33 * 2 = 0.66 or 2/3 of the scanner for laser combat. So the first third (approx) is for dogfighting, the second third for sniping and the last for closing/evading. Missiles then become the only weapons that can reach the edges of the scanner - a weapon group that could arguably benefit from a new advantage.

Laser ranges at 0.33 was the version I tested the most in 2014 (as did anyone who tried the previous version of this experiment with it's oxp companion) and I certainly found it fun, so that's probably something that should be tried again.

I fear that there will be problems with "torus synchronization" in the "Escort Contracts" and "Synchronized Torus" OXPs, because torus speed and minimum and maximum distance for synchronization is hard-coded.

Not sure exactly how those oxps calculate speeds - if they simply match pkayer speed (even under torus) then there shouldn't be a problem should there?

[phkb]

OK, one deleted post later...

I'm having a problem with Smugglers and the Rescaling package. Smugglers' is causing the game to crash completely, but with no error notification anywhere as far as I can see. I've tracked the issue back to the "this.updateGeneralCommodityDefinition" routine in "smugglers_illegalmarket.js" file.

The first few lines of my debug process should be enough to point to the error. Here's what I put in:

Code: Select all

this.updateGeneralCommodityDefinition = function(goodDefinition, station, systemID) {

	var si = worldScripts.Smugglers_Illegal;
	log(this.name, "got here");
	log(this.name, "goodDefinition " + goodDefinition);
	log(this,name, "station " + (station == null ? "null!" : station));
	log(this.name, "systemID " + systemID);

In the "latest.log" file I find this:

15:28:58.210 [Smugglers_IllegalMarket]: got here
15:28:58.210 [Smugglers_IllegalMarket]: goodDefinition [object Object]

and then nothing. The routine gets to the station line, and then bombs - no more output, Oolite vanishes from the taskbar. I haven't event got to the spinning Cobra yet. All I've seen is the Oolite logo.

So I'm assuming the "station" being passed into this routine is causing problems, although I have no idea how. Obviously this doesn't happen in 1.82, or in the default 1.83. I'd appreciate any pointers as to what's going on.

[Redspear]

Hmm... I'm also struggling to think why.

The only thing that I recall doing to the stations is moving them proportionally closer to the planet.
If the station is set too close to the planet then it cannot appear. Unless it is being destroyed/buried and then defaulting to a new/old position then I can't see a potential issue.

It's possible that there is some relic in there from another source tinkering that I didn't undo but I didn't see it when I checked the code on github. Furthermore I don't recall ever doing anything to station markets in the source (oxp yes, but not source).

Wild stab in the dark: check tradegoods.plist for anything unusual as I might have mixed that up with an oxp version of the file. I don't think that would have gotten past a_c's work on github though...

[another_commander]

The bug with the Smugglers crashing was in the core and should be fixed in the latest commit (both master and rescale branch).

[Cody]

I took this build for a parcel run last night, and it seems to make evading/outrunning WP assassins considerably easier.
That's down to the half-size scanner range, I guess - slowly-pulling-ahead stern chases become much shorter.

I am seeing a performance hit when looking at some Povray textures from station distances, btw.

[Disembodied]

I took this build for a parcel run last night, and it seems to make evading/outrunning WP assassins considerably easier.
That's down to the half-size scanner range, I guess - slowly-pulling-ahead stern chases become much shorter.

Would that be fixable by altering the starting formation of WP assassins? E.g. by placing a blocking assassin a little bit further down the WP-planet axis?

[Day]

Would it be possible to have a linux version?

(I understand it could need too much work at this stage.)

[Redspear]

I took this build for a parcel run last night, and it seems to make evading/outrunning WP assassins considerably easier.
That's down to the half-size scanner range, I guess - slowly-pulling-ahead stern chases become much shorter.

Scanner is at half-size but then ships are at half speed... Two possibilities off the top of my head: 1- oxp player ship without having speeds halved; 2 - assassins being positioned a set distance from the WP beacon and so being closer to the scanner edge (I havent investigated how this is done in the source yet).

I am seeing a performance hit when looking at some Povray textures from station distances, btw.

Thanks for all the reports Cody. How bad is it? Minor or severe?

@ Disembodied: That does sound like a good strategy for an assassin. Unless I'm missing something in my understanding however, that shouldn't be necessary in order to achieve comparable results to the standard game... Good to have options though Thanks.

@Day: Isn't Dizzy a linux guy? He was always supportive of this thing and would be up to the job. I might PM him and try to be nice