Join us at the Oolite Anniversary Party -- London, 7th July 2024, 1pm
More details in this thread.

Split: Re-scaling experiment

General discussion for players of Oolite.

Moderators: winston, another_commander

User avatar
Diziet Sma
---- E L I T E ----
---- E L I T E ----
Posts: 6311
Joined: Mon Apr 06, 2009 12:20 pm
Location: Aboard the Pitviper S.E. "Blackwidow"

Re: Split: Re-scaling experiment

Post by Diziet Sma »

pleiadian wrote: Fri Apr 07, 2017 7:57 am
Diziet Sma wrote: Thu Apr 06, 2017 11:59 pm
For those wanting to test, who can't build their own from source, here's an executable and rescale OXP bundle, incorporating Redspear's latest fix for the traffic problem:

https://www.dropbox.com/s/9597zpe87kvhw ... 3.zip?dl=0

Note that, as always, you'll need to have an up-to-date copy of the latest trunk already installed, and you just swap out the executable, and install the included OXP, if you haven't already done so.
Is the fix incorportated in this repo?

https://github.com/Garryck/oolite-rescaling-experiment

Yes, it is.. that's where I got the updated code for the build I just released.
Most games have some sort of paddling-pool-and-water-wings beginning to ease you in: Oolite takes the rather more Darwinian approach of heaving you straight into the ocean, often with a brick or two in your pockets for luck. ~ Disembodied
Astrobe
---- E L I T E ----
---- E L I T E ----
Posts: 609
Joined: Sun Jul 21, 2013 12:26 pm

Re: Split: Re-scaling experiment

Post by Astrobe »

I did the benchmark I talked about earlier.
The detailed protocol is:
- stock 1.85, no OXPs
- use the easier start, buy injectors
- jump to Bemaera, head straight to the planet or the station as soon as you can see it.
- no attempts to escape masslocks
- if engaged by pirates, flee with injectors only when they start to land hits.
- time is measured from system entry to completed docking
- Note down only ships that appear on the scanner

In one or two occasions I had to break free from a masslock with injectors because I was going to be masslocked up to the station.

Results:

Run 1: 10 minutes. 1 ship at WP, 3 groups of ships + 2x1 pirates en route, 1 pirate near station, 1 viper at station. Total 8 encounters
Run 2: 14 minutes. 2x1 ships at WP, 1 ship on lane, a group of 3 ships going back to WP, 1 pirate near station, 1 viper + 1 ship at station + 1 departure (worm). Total 7 encounters, was second in queue.
Run 3: 14 minutes. 2 ships at WP, 1 large group of pirates on lane + 2-3 neutral ships, 1 group of 5 pirates, 1 group of 4 pirates, 1 ship near station, 2 ships + 1 viper at station. Queued, saw a group of 3 ships leaving. Total 8 encounters
Run 4: 12 minutes. 4 pirates at WP, 1 ship warped in at WP, 2x1 ship en route, 1 ship near planet, 2 ships + 1 viper at station. Was third in queue. Total 8 encounters
Run 5: 8 minutes. 1 ship at WP, 1 ship en route then a group of 7 pirates, 2 vipers at station going to WP, 1 viper at station, a group of 3 departing. Total 6 encouters
User avatar
Redspear
---- E L I T E ----
---- E L I T E ----
Posts: 2657
Joined: Thu Jun 20, 2013 10:22 pm
Location: On the moon Thought, orbiting the planet Ignorance.

Re: Split: Re-scaling experiment

Post by Redspear »

Just to be clear, encounter rates are still expected to be low for the meantime although a fix has been identified.

The fix that HAS been implemented is simply to increase station traffic so that waiting in the aegis for several minutes doesn't make it seem deserted.

Having said that, all testing is appreciated and results will be added to my testing data, so thank you Astrobe.
User avatar
hoqllnq
Commodore
Commodore
Posts: 154
Joined: Sun Jan 08, 2006 7:32 pm

Re: Split: Re-scaling experiment

Post by hoqllnq »

Would it be possible to quickly simulate a few hours of run time for a 'fresh' system before dropping the player into it? (Maybe cutting some corners since nobody is observing anyway.) That way, each system is automatically populated appropriately according to its launch/dock/jump-in/out rate.
User avatar
Redspear
---- E L I T E ----
---- E L I T E ----
Posts: 2657
Joined: Thu Jun 20, 2013 10:22 pm
Location: On the moon Thought, orbiting the planet Ignorance.

Re: Split: Re-scaling experiment

Post by Redspear »

hoqllnq wrote:
Would it be possible to quickly simulate a few hours of run time for a 'fresh' system before dropping the player into it? (Maybe cutting some corners since nobody is observing anyway.) That way, each system is automatically populated appropriately according to its launch/dock/jump-in/out rate.
Not a bad idea but could increase system loading times significantly.

If my own ideas don't work out then I may look into that one further. Thanks.
Astrobe
---- E L I T E ----
---- E L I T E ----
Posts: 609
Joined: Sun Jul 21, 2013 12:26 pm

Re: Split: Re-scaling experiment

Post by Astrobe »

The default populator (Resource/scripts/oolite-populator.js) takes a lot of factors in consideration, including the nearby systems. Also, ships are spawn at almost random positions within the lanes, which is more or less the same as simulating the prior activity of the system. The script is well commented and quite readable.

Some things depend on the system dimensions (basically the edges of the witchpoint-sun-planet triangle). From what I understand, the intention is to have a constant "traffic density" for systems that may vary in shape. That would explain the observed increase in the number of entities. However, since the algorithm considers three lanes, the rescaling may have thrown some of its computations off (there are "magic numbers" here and there).

In my opinion, one might want to partially revisit it:

- populating the witchpoint-sun and planet-sun lanes is probably a lost cause. I don't see any traffic there in the stock game, probably because it's even more easy to be far off the lane than with the main lane (or maybe it's just because some OXPs I use make it extremely easy?). Only ad hoc and dynamic populators like Deep Space Pirates can do a good and efficient job there (and even work when you add planets). Then we could reallocate the traffic of the "auxiliary" lanes to the main lane.

- I would consider making the lane length a fixed quantity. "Scale" as the word suggests is a relationship between two objects. One is typically a "unit", the other is the subject. Archeologist and mineralogists sometimes photograph artifacts with a coin next to them to show the scale of the subject. In Space, we have a similar problem of observing objects whose distance and size is unknown, like planets. Making the distance a constant would give a better impression of the relative size of planets, which contributes in restoring the sense of scale.

Since Cim is the author of the default populator, one should certainly wait for his opinion on this.

I've played a bit with the latest version and the improvement is indeed noticeable.
User avatar
Redspear
---- E L I T E ----
---- E L I T E ----
Posts: 2657
Joined: Thu Jun 20, 2013 10:22 pm
Location: On the moon Thought, orbiting the planet Ignorance.

Re: Split: Re-scaling experiment

Post by Redspear »

Astrobe wrote:
Some things depend on the system dimensions (basically the edges of the witchpoint-sun-planet triangle). From what I understand, the intention is to have a constant "traffic density" for systems that may vary in shape. That would explain the observed increase in the number of entities. However, since the algorithm considers three lanes, the rescaling may have thrown some of its computations off (there are "magic numbers" here and there).

In my opinion, one might want to partially revisit it:
From version 1 I've known that a longer lane equates to more traffic (entities) but it's only recently that I've realised the extent to which I had overcompensated.

Double the lane for double the traffic, so double the lane width (thinning out the traffic) to balance this. However, in doing so I had made a very basic mathematical mistake.
Lane length is one dimensional, lane width however is not, it is 2 dimensional (there is no 'lane height' only a lane width applied to two dimensions).

Thus (up thread a bit):
Redspear wrote:
Width is not the same as area of course...
  • 2x2 (twice scanner radius) = 4 /1 (lane length) = 1:4 encounter ratio (standard game)
  • 4x4 = 16 /2 = 1:8 encounter ratio (rescaled game)
  • 3x3 = 9 /2 = 1:4.5 encounter ratio (proposed adjustment for rescaled game)
The lane is I understand a cylinder rather than cuboid and so area = π r2, rather than just r2 (mistaken for length), but with r being the only variable I believe the point is moot. [couple of edits in that last sentence to clear up the explanation]
Thus a new value for lane width should probably be more like 2.825 than 3 (or the 4 that we currently have).

I've made the change on my own computer and encounter rates seem to be up. Your recent data will make a nice comparison for me to test against.

As for "magic numbers" I think you're right: I'll need to take another look.

Astrobe wrote:
- I would consider making the lane length a fixed quantity. "Scale" as the word suggests is a relationship between two objects. One is typically a "unit", the other is the subject. Archeologist and mineralogists sometimes photograph artifacts with a coin next to them to show the scale of the subject. In Space, we have a similar problem of observing objects whose distance and size is unknown, like planets. Making the distance a constant would give a better impression of the relative size of planets, which contributes in restoring the sense of scale.

Since Cim is the author of the default populator, one should certainly wait for his opinion on this.
Good point and it is something I've wondered about before (I think others have flagged it up too) but I also like that some systems just take longer to travel through than others (by virtue of distance rather than other factors).

Sun distance is also proportional to planet size I believe but perhaps that needn't be the case. At present I think the clearest way to tell how big the planet is is to check the apparent size of the sun upon system entry (without checking f6 or f7 of course). This however at least make proportions look different upon entry.

This is non-urgent stuff of course and very much in the cosmetic category as I see it.

Astrobe wrote:
I've played a bit with the latest version and the improvement is indeed noticeable.
That's good to hear. Thank you.
User avatar
Redspear
---- E L I T E ----
---- E L I T E ----
Posts: 2657
Joined: Thu Jun 20, 2013 10:22 pm
Location: On the moon Thought, orbiting the planet Ignorance.

Re: Split: Re-scaling experiment

Post by Redspear »

Some testing re station traffic...

Tried the default game for comparisom (admittedly v1.82).
10 mins outside station upon first arrival, recording launches and dockings:

Zaonce: 2 vipers launched, mk3 docked, moray med docked
Lave: nothing
Leesti: mk3, boa and moray med, all docked

So from having less traffic we may now even have more. Variation can be such however that there are still very quiet spells.
Far less docking traffic however both numerically and proportionally.

I've been playing with the aegis and planet orbit settings and the good news is that I've witnessed my first docking ship: a python. That's a pretty slow ship so my space-lane to station fears may be unfounded.

oolite-populator.js would appear to confirm that the station aegis is where docking traffic is generated and so it looks like playing around with the relevant properties in Universe.m could yield good results.

The 'cosmetic' adjustment of moving the station proportionally closer to the planet may be causing the issue but it looks like I should be able to make the adjustments for this to work.
Astrobe
---- E L I T E ----
---- E L I T E ----
Posts: 609
Joined: Sun Jul 21, 2013 12:26 pm

Re: Split: Re-scaling experiment

Post by Astrobe »

I turned on the logging for the populator yesterday. This is on 1.85-RSE with some OXPs. I've snipped the less relevant information in order to keep it as short as possible:

Code: Select all

15:54:44.722 [universe.populate.information]: G1: Onusorle
15:54:44.722 [universe.populate.information]: Hub count: 9 (3)
15:54:44.723 [universe.populate.repopulate]: Incoming chance: traderFreighters = 0.033438909943741026
15:54:44.723 [universe.populate.repopulate]: Incoming chance: traderCouriers = 0.0034244674143664045
15:54:44.723 [universe.populate.repopulate]: Incoming chance: traderSmugglers = 0.0025552431107986667
15:54:44.723 [universe.populate.repopulate]: Incoming chance: pirateLightPacks = 0
15:54:44.723 [universe.populate.repopulate]: Incoming chance: pirateMediumPacks = 0
15:54:44.723 [universe.populate.repopulate]: Incoming chance: pirateHeavyPacks = 0
15:54:44.723 [universe.populate.repopulate]: Incoming chance: hunterMediumPacksReturn = 0
15:54:44.723 [universe.populate.repopulate]: Incoming chance: hunterHeavyPacksReturn = 0
15:54:44.723 [universe.populate.repopulate]: Incoming chance: hunterMediumPacks = 0
15:54:44.723 [universe.populate.repopulate]: Incoming chance: hunterHeavyPacks = 0.016666666666666666
15:54:44.723 [universe.populate.repopulate]: Incoming chance: thargoidScouts = 0.0003968253968253968
15:54:44.723 [universe.populate.repopulate]: Incoming chance: thargoidStrikes = 0
15:54:44.723 [universe.populate.repopulate]: Outgoing chance: traderFreighters = 0.033438909943741026
15:54:44.723 [universe.populate.repopulate]: Outgoing chance: traderCouriers = 0.0024691358024691358
15:54:44.723 [universe.populate.repopulate]: Outgoing chance: traderSmugglers = 0.0002743484224965706
15:54:44.723 [universe.populate.repopulate]: Outgoing chance: pirateAegisRaiders = 0
15:54:44.723 [universe.populate.repopulate]: Outgoing chance: pirateIndependents = 0.0433604825157967
15:54:44.723 [universe.populate.repopulate]: Outgoing chance: pirateLightPacks = 0.013333333333333332
15:54:44.724 [universe.populate.repopulate]: Outgoing chance: pirateMediumPacks = 0.004166666666666667
15:54:44.724 [universe.populate.repopulate]: Outgoing chance: pirateHeavyPacks = 0.0006944444444444445
15:54:44.724 [universe.populate.repopulate]: Outgoing chance: hunterLightPacks = 0.007619047619047619
15:54:44.724 [universe.populate.repopulate]: Outgoing chance: hunterMediumPacks = 0
15:54:44.724 [universe.populate.repopulate]: Outgoing chance: hunterHeavyPacks = 0
15:54:44.724 [universe.populate.repopulate]: Outgoing chance: policePacks = 0
15:54:44.724 [universe.populate.repopulate]: Outgoing chance: policeInterceptors = 0
15:54:44.724 [universe.populate.repopulate]: Outgoing chance: assassins = 0.004184505987407757
15:54:44.724 [universe.populate.information]: Routes: 4042200 , 17183369.50884472 , 20246924.77905331
15:54:44.725 [universe.populate.information]: Freighters: 24
15:54:44.725 [universe.populate.information]: Freighters (D): 2
15:54:44.725 [universe.populate.information]: Couriers (1): 2
15:54:44.725 [universe.populate.information]: Couriers (3): 9
15:54:44.725 [universe.populate.information]: Smugglers: 2
15:54:44.725 [universe.populate.information]: Hunters (1): 3
15:54:44.725 [universe.populate.information]: Hunters (T): 5
15:54:44.725 [universe.populate.information]: HuntersM (1): 0
15:54:44.725 [universe.populate.information]: HuntersM (3): 0
15:54:44.725 [universe.populate.information]: HuntersH (1): 6
15:54:44.725 [universe.populate.information]: HuntersH (3): 15
15:54:44.725 [universe.populate.information]: Pirates (1): 30
15:54:44.725 [universe.populate.information]: Pirates (2): 10
15:54:44.725 [universe.populate.information]: Pirates (3): 15
15:54:44.725 [universe.populate.information]: Pirates (L1): 1
15:54:44.725 [universe.populate.information]: Pirates (LT): 1
15:54:44.725 [universe.populate.information]: Pirates (LR): 0
15:54:44.725 [universe.populate.information]: Pirates (M1): 1
15:54:44.725 [universe.populate.information]: Pirates (MT): 0
15:54:44.725 [universe.populate.information]: Pirates (MR): 0
15:54:44.726 [universe.populate.information]: Pirates (H1): 0
15:54:44.726 [universe.populate.information]: Pirates (HT): 0
15:54:44.726 [universe.populate.information]: Pirates (HR): 0
15:54:44.726 [universe.populate.information]: Assassins (WP): 1
15:54:44.726 [universe.populate.information]: Police (1): 0
15:54:44.726 [universe.populate.information]: Police (T): 0
15:54:44.726 [universe.populate.information]: Police (I1): 0
15:54:44.726 [universe.populate.information]: Police (IW): 0
15:54:44.726 [universe.populate.information]: Thargoid (SC): 0
15:54:44.726 [universe.populate.information]: Thargoid (ST): 0
I have three more if you're interested.

I was slightly wrong about the traffic there being "useless" because I saw a pair of hunters (or so I guess) launch and head to the sun, a nice feature. This is actually the making of the REpopulator though:
The system repopulator function will be called approximately every twenty seconds, and can be used to replace ships that have been destroyed. Generally such replacements should enter the system in a believable way - exiting witchspace near the witchpoint, by being launched from an appropriate station or the planet, or by some similar method. It is important for smooth gameplay that this function runs very quickly. If calculations are needed, run as many as possible in the populator function to save the result.
I still see less combat between NPCs in the distance, so a hypothesis is that less ships are destroyed due to a lower ship density, and so the repopulator spawns ships less often?
Considered that the repopulator spawns ships at WP and at station, maybe the lane cylinder can be shorter on both ends so we can make it wider to compensate for the smaller scanner and to take into consideration that players naturally deviate from the lane line?

I think altering OORandomPositionInCylinder in Core/HPVector.m could give us what we want and optimize things. My intuitive understanding of this function is that it takes a random position along the cylinder's axis, then use it as a center of a sphere in which is picked a random position. It has to try again if the result is outside of the cylinder (might happen near both ends of the cylinder); or rather, it retries if the result is "too close" from one or the other end.

We could remove the last part to obtain a position within an approximate ellipsoid (a cylinder with spherical ends). Judging from a quick grep, it seems that the function is only used by the populator.

Or we could make it so that the function sees it as a line of "bubbles". it would actually help with decreasing the actual volume and increase the traffic density without having to spawn more ships. But I think I've seen that idea before.

I can try to implement that if you think it may be part of the solution.
User avatar
Redspear
---- E L I T E ----
---- E L I T E ----
Posts: 2657
Joined: Thu Jun 20, 2013 10:22 pm
Location: On the moon Thought, orbiting the planet Ignorance.

Re: Split: Re-scaling experiment

Post by Redspear »

Astrobe wrote:
I still see less combat between NPCs in the distance, so a hypothesis is that less ships are destroyed due to a lower ship density, and so the repopulator spawns ships less often?
Considered that the repopulator spawns ships at WP and at station, maybe the lane cylinder can be shorter on both ends so we can make it wider to compensate for the smaller scanner and to take into consideration that players naturally deviate from the lane line?
I'm actually seeing ship spawn more often (certainly at the station).
Lack of ship interaction is likely due to lane width: wider dispersal of traffic = less encounters (both with and between NPS) = less chance of inter-NPS combat.

Before considering other balancing tweaks it's probably better that I implement this one. Likely within next 12 hours...
User avatar
Redspear
---- E L I T E ----
---- E L I T E ----
Posts: 2657
Joined: Thu Jun 20, 2013 10:22 pm
Location: On the moon Thought, orbiting the planet Ignorance.

Re: Split: Re-scaling experiment

Post by Redspear »

Fix for encounter rates has been added to Github (now calculted by area for closer experience to default game).

Currently working on a fix for docking traders and appear to be on the right trail (they do appear occasionally).
User avatar
Diziet Sma
---- E L I T E ----
---- E L I T E ----
Posts: 6311
Joined: Mon Apr 06, 2009 12:20 pm
Location: Aboard the Pitviper S.E. "Blackwidow"

Re: Split: Re-scaling experiment

Post by Diziet Sma »

Redspear wrote: Sun Apr 09, 2017 7:08 pm
Fix for encounter rates has been added to Github (now calculted by area for closer experience to default game).
For those who can't build their own, here's a Win64 build based on the above fix.
https://www.dropbox.com/s/70tppzktmigk2 ... 4.zip?dl=0
Most games have some sort of paddling-pool-and-water-wings beginning to ease you in: Oolite takes the rather more Darwinian approach of heaving you straight into the ocean, often with a brick or two in your pockets for luck. ~ Disembodied
Astrobe
---- E L I T E ----
---- E L I T E ----
Posts: 609
Joined: Sun Jul 21, 2013 12:26 pm

Re: Split: Re-scaling experiment

Post by Astrobe »

Sorry, I forgot I was running with sun_distance_multiplier=15 instead of 6.6. The logs I've posted earlier are wrong.
User avatar
Redspear
---- E L I T E ----
---- E L I T E ----
Posts: 2657
Joined: Thu Jun 20, 2013 10:22 pm
Location: On the moon Thought, orbiting the planet Ignorance.

Re: Split: Re-scaling experiment

Post by Redspear »

Thanks Dizzy.

No worries Astrobe.
I'll be looking again at sun distance modifier but actually considering reducing it. The corona effect is quite nice and it's a shame when it can't be seen at all unless you're headed that way (as is the case in some systems with larger planets).
User avatar
Redspear
---- E L I T E ----
---- E L I T E ----
Posts: 2657
Joined: Thu Jun 20, 2013 10:22 pm
Location: On the moon Thought, orbiting the planet Ignorance.

Re: Split: Re-scaling experiment

Post by Redspear »

Something I haven't explored yet is multiple laser mountings. The rescaling experiment could add new potential to this feature.

If we thing of the Krait, with it's two prongs on either side, then mounting lasers on these features looks great but gives the pilot a hard time hitting anything. That's not really surprising however when you consider that the Krait is wider than some of the largest ships in the game (including the Anaconda).

Rescale it to 0.4 however and (in theory) it should be far more successful. With some fighters being scaled to as little as 0.33 there's good potential for them to use multiple laser mounts successfully against larger ships.

Lore has it that the Krait was superceeded by the Mamba - perhaps it just couldn't compete with the newer, smaller, single laser mount fighters that were to follow (such as the Mamba and Sidewinder). Against an Anaconda however it could potentially pack a more powerful punch depending upon how multiple laser mounts were to work.

So, on fighters multiple laser mounts could now work very well in many instances but on the largest ships they would likely be more problematic than ever. To me, that sounds like a trade-off worth making. The Krait could be reimagined as an anti-freighter specialst, vulnerable to smaller fighters which it would struggle to hit.

EDIT: Multiple mounts on freighters might make more sense on the sides rather than fore and aft. Like a broadside from the age of sail: more chances to hit and less dependant on manouvering; also reduce a fighter's 'hiding places' when attacking a freighter.
Post Reply