Oolite Bulletins

For information and discussion about Oolite.
It is currently Wed Aug 23, 2017 7:34 pm

All times are UTC




Post new topic  Reply to topic  [ 539 posts ]  Go to page Previous 132 33 34 35 36 Next
Author Message
PostPosted: Fri Apr 07, 2017 8:48 am 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Mon Apr 06, 2009 12:20 pm
Posts: 6178
Location: Aboard the Pitviper S.E. "Blackwidow"
Quote:
Quote:
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


Top
   
PostPosted: Fri Apr 07, 2017 12:59 pm 
Offline
---- E L I T E ----
---- E L I T E ----

Joined: Sun Jul 21, 2013 12:26 pm
Posts: 442
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


Top
   
PostPosted: Fri Apr 07, 2017 3:36 pm 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Thu Jun 20, 2013 10:22 pm
Posts: 1065
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.

_________________
"With our thoughts, we make the world" :-)


Top
   
PostPosted: Fri Apr 07, 2017 3:48 pm 
Offline
Dangerous
Dangerous
User avatar

Joined: Sun Jan 08, 2006 7:32 pm
Posts: 103
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.


Top
   
PostPosted: Fri Apr 07, 2017 4:17 pm 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Thu Jun 20, 2013 10:22 pm
Posts: 1065
Quote:
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.

_________________
"With our thoughts, we make the world" :-)


Top
   
PostPosted: Fri Apr 07, 2017 5:22 pm 
Offline
---- E L I T E ----
---- E L I T E ----

Joined: Sun Jul 21, 2013 12:26 pm
Posts: 442
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.


Top
   
PostPosted: Fri Apr 07, 2017 8:09 pm 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Thu Jun 20, 2013 10:22 pm
Posts: 1065
Quote:
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):
Quote:
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.

Quote:
- 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.

Quote:
I've played a bit with the latest version and the improvement is indeed noticeable.
That's good to hear. Thank you.

_________________
"With our thoughts, we make the world" :-)


Top
   
PostPosted: Sun Apr 09, 2017 1:39 am 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Thu Jun 20, 2013 10:22 pm
Posts: 1065
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.

_________________
"With our thoughts, we make the world" :-)


Top
   
PostPosted: Sun Apr 09, 2017 9:22 am 
Offline
---- E L I T E ----
---- E L I T E ----

Joined: Sun Jul 21, 2013 12:26 pm
Posts: 442
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:
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:
Quote:
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.


Top
   
PostPosted: Sun Apr 09, 2017 9:36 am 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Thu Jun 20, 2013 10:22 pm
Posts: 1065
Quote:
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...

_________________
"With our thoughts, we make the world" :-)


Top
   
PostPosted: Sun Apr 09, 2017 7:08 pm 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Thu Jun 20, 2013 10:22 pm
Posts: 1065
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).

_________________
"With our thoughts, we make the world" :-)


Top
   
PostPosted: Mon Apr 10, 2017 1:58 am 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Mon Apr 06, 2009 12:20 pm
Posts: 6178
Location: Aboard the Pitviper S.E. "Blackwidow"
Quote:
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


Top
   
PostPosted: Mon Apr 10, 2017 8:37 am 
Offline
---- E L I T E ----
---- E L I T E ----

Joined: Sun Jul 21, 2013 12:26 pm
Posts: 442
Sorry, I forgot I was running with sun_distance_multiplier=15 instead of 6.6. The logs I've posted earlier are wrong.


Top
   
PostPosted: Mon Apr 10, 2017 5:28 pm 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Thu Jun 20, 2013 10:22 pm
Posts: 1065
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).

_________________
"With our thoughts, we make the world" :-)


Top
   
PostPosted: Wed Apr 12, 2017 4:55 pm 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Thu Jun 20, 2013 10:22 pm
Posts: 1065
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.

_________________
"With our thoughts, we make the world" :-)


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 539 posts ]  Go to page Previous 132 33 34 35 36 Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
cron
Powered by phpBB® Forum Software © phpBB Limited