Split: Re-scaling experiment

[another_commander]

Is there any chance this can be added to the all-new 1.86 release?

Added no, but if someone brings the Rescaling fork up to sync with 1.86 and make a binary out of it, then it should be possible, I guess.

[Redspear]

I'd love to keep all the new changes... plus the Rescaling thing - that would be the bomb

if someone brings the Rescaling fork up to sync with 1.86 and make a binary out of it, then it should be possible, I guess.

I think I might know how to solve the one obvious issue that remains with the recaled game: namely, a rarity of inbound, docking ships.
It's probably going to be at the cost of the modified station to planet distance though. A shame but hardly a major loss.

If it works as expected then you can expect an update relatively soon, if not then I'll need to allocate a good deal more time to the matter.

[Diziet Sma]

I think I might know how to solve the one obvious issue that remains with the recaled game: namely, a rarity of inbound, docking ships.
It's probably going to be at the cost of the modified station to planet distance though. A shame but hardly a major loss.

So you think it may be due to something other than the extra distance inbound traffic has to cover to reach the planet? Interesting...

[Redspear]

So you think it may be due to something other than the extra distance inbound traffic has to cover to reach the planet? Interesting...

Maybe...

As I understand it, traffic is generated at random points along the lane. When we had no launching traffic it wasn't due to a lack or excess of traffic being generated but rather it seems to have been the case that the lane wasn't matching the expected distance to find the station.

In other words (for anyone less familiar with this project than Dizzy...) a longer lane needn't be a major problem as the game expects that to be a variable; however, a modified planet to station distance is something it expects to exists as a known constant, a constant that I have since changed...

All well and good in theory of course but it's not much more than a guess at this stage

[Diziet Sma]

rather it seems to have been the case that the lane wasn't matching the expected distance to find the station.
...
a longer lane needn't be a major problem as the game expects that to be a variable; however, a modified planet to station distance is something it expects to exists as a known constant, a constant that I have since changed...

Hmm.. shouldn't be too hard to track down the code that makes use of that constant, then.. in theory, at least.. I'm guessing that perhaps those other routines are making use of their own local copy of the "magic number" constant.. because if they used the changed one, they should be able to handle things correctly.

[Redspear]

I'd agree that the theory is sound but when the number you're looking for is '2' then it does show up rather a lot...
Planet radius references show up rather less of course but there's a lot of unlabelled stuff in the source, speaking from the point of view of a beginner at least.

On altering the constant...
I changed the orbit of the station from 2 times the planet's radius to 1.5 times (x1 would mean the station was on the planet's surface). Given that planet's are 3.3 times bigger than normal, then...
3.3 / 2 = 1.65 greater distance than in the standard game.
Ship speeds are halved however, meaning it takes 3.3 times as long to travel from surface to station.

Having recently travelled to the surface in the standard game, the station looms not only large in the sky but enormously so. Were it to be 3.3 times smaller then that might be a nice compromise between seeming small and yet remaining clearly visible.

Lots to do but I'll get around to it soon I expect.

[Sailsman63]

Just like to add my 0.02 Cr:

Love this. I'd love to see core scripting access extended to the point that the rescale can be done as a simple OXP.

Some of the new enhancements from 1.86 look enticing, especially the upgraded planetary textures. However, the rescale enhances immersion enough for me to stick with the DizzyBuild for the time being...

[Diziet Sma]

Love this. I'd love to see core scripting access extended to the point that the rescale can be done as a simple OXP.

Maybe one day, something like that might be possible.. but first, we need to finish ironing out the wrinkles.. after that, hopefully it can incorporated into core in such a way that a simple switch can be set to enable it.

Some of the new enhancements from 1.86 look enticing, especially the upgraded planetary textures. However, the rescale enhances immersion enough for me to stick with the DizzyBuild for the time being...

Damn.. guess I'll need to get busy on a new build for 1.86 then!

[Redspear]

Just like to add my 0.02 Cr:

Love this. I'd love to see core scripting access extended to the point that the rescale can be done as a simple OXP.

Some of the new enhancements from 1.86 look enticing, especially the upgraded planetary textures. However, the rescale enhances immersion enough for me to stick with the DizzyBuild for the time being...

Thanks Sailsman63, glad you're enjoying it

Updating this for 1.86 (with a possible station traffic fix) is on a very long to-do list that I have been creating for myself.
I'd like to say soon but... we'll see.

[Redspear]

Okayyyyy...

Started building for 1.86, step by step in an effort to find at which point docking ships become so rare.

Good news is that it's not at the system rescaling stage (two quick tests both yielded docking ships) meaning that it's likely either the sytem rearrangement or ship rescaling stage, both of which have much more room for manoeuvre.

Found a few lines in ShipEntity.m that lead me to believe it might be a consequence of the smaller scanner, in which case it should be easy to fix by simply increeasing the range of the search for nearby stations. More testing needed but a good start.

[Redspear]

Confirmed, it's a consequence of a smaller scanner.

Editing this line in ShipEntity.m helps

Code: Select all

if (sd2 < SCANNER_MAX_RANGE2 * 4.0f) // double scanner range	

By increasing this value I've seen docking ships become uncommon rather than exremely rare.
For example, in a handful of tests I twice saw two ships dock in a row, I'd never seen that before with this branch despite many, many tests.

There are a few other instances of SCANNER_MAX_RANGE and SCANNER_MAX_RANGE2 in ShipEntity.m and at least one more of them appears to be having an effect. The trick now appears to be to find the right combination of values to give the desired effect.

[Redspear]

Found a setting in ShipEntity.h which raised a smile:

Code: Select all

#define PIRATES_PREFER_PLAYER			YES

Explains a lot

[Diziet Sma]

Confirmed, it's a consequence of a smaller scanner.

Editing this line in ShipEntity.m helps

Code: Select all

if (sd2 < SCANNER_MAX_RANGE2 * 4.0f) // double scanner range	

By increasing this value I've seen docking ships become uncommon rather than exremely rare.
For example, in a handful of tests I twice saw two ships dock in a row, I'd never seen that before with this branch despite many, many tests.

There are a few other instances of SCANNER_MAX_RANGE and SCANNER_MAX_RANGE2 in ShipEntity.m and at least one more of them appears to be having an effect. The trick now appears to be to find the right combination of values to give the desired effect.

Sounds promising! It does beg the question, though, of just how/why changing the scanner range has this (presumably unintended) side-effect?

Hopefully, one of the devs who has a handle on how the populator mechanics work can chime in..

[Redspear]

It does beg the question, though, of just how/why changing the scanner range has this (presumably unintended) side-effect?

I think I may have it: some distance checks are simply made with scanner radius (or its square) as a unit.
They hold true with rescaling the planets and the system being rearranged but don't like it when you shrink the scanner to 1/3 (unsurprisingly perhaps).

So it should be a simple matter of just multiplying by three (or the same to the square root before squaring again), right?
Well, given the multiple occurrances and uses of the scanner range unit, it's proving to be a little more complicated.

So I may still be stabbing around in the dark but at least I now appear to be holding the correct end of the knife

[Redspear]

The plot thickens...

ShipEntityAI.m
DockEntity.m
ShipEntity.m

All have instances of 10km as desired range for a ship from its target.
Trouble is, a 1/3 range scanner only extends to 8.5km (approx).

10 km is less than half of the standard scanner's range (25.6km) and so presents no problem in the standard game.
Shrink the scanner sufficiently however and suddenly a ship's targets won't show up on its scanners anymore. They would on a half range scanner (as used in earlier versions of the experiment), which may be why a lack of docking ships wasn't observed earlier.

So if I reduce 10km to 3.33km then I may not even need to mess about with the SCANNER_MAX_RANGE2 values...

There are probably more instances or issues for me to track down. I do appear to be on the right track however, so I suppose we will see where it leads.