Oolite Bulletins

Posted: **Mon Apr 03, 2017 10:49 pm**

Now that lane width is proportional to the scanner (unlike version 1) then the major factor in encounter rate becomes lane length.
Length is roughly twice as long so proportion of scanner to lane width should be roughly halved:

Adjust the space-lane
Universe.m line

Code: Select all

#define LANE_WIDTH		(4.0 * SCANNER_MAX_RANGE)

In normal game it is twice scanner radius, so that should be right (scanner occupies a quarter of the lane width rather than a half).

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)

Therefore:

Code: Select all

#define LANE_WIDTH		(3.0 * SCANNER_MAX_RANGE)

Another tweak:

Double (approx.) planet distance from witchpoint as it is currently:
Universe.m line

Code: Select all

planet_zpos *= [planetDict oo_floatForKey:@"planet_distance_multiplier" defaultValue:5.0];

Here's the original line with it's predecessor:

Code: Select all

double planet_zpos = [planetDict oo_floatForKey:@"planet_distance" defaultValue:500000];
planet_zpos *= [planetDict oo_floatForKey:@"planet_distance_multiplier" defaultValue:1.0];

If the default value is not proprtional to the size of the planet then the multiplier should really be 6.6 (planet size 3.3 times bigger doubled for greater proportional distance from witchpoint.

So,

Code: Select all

planet_zpos *= [planetDict oo_floatForKey:@"planet_distance_multiplier" defaultValue:6.6];

is probably closer to the defaul game in terms of number of encounters.

Looks like I have my might have my first git hub tweaks to do (gulp)...

pleiadian wrote:
As a matter of fact I didn't find any huge asteroids yet, but I attribute that to me not knowing how to scan for asteroid fields That means, I don't know how to find them yet.

What I've done is made asteroid fields a little more common. What I probably should have done is instead make them a little larger. Same number of entities but in larger clusters for a more cinematic effect without being more common. With more room to play with, asteroid 'fields' (a generous descriptor) could certainly be a little larger.

Not sure which variable this would be but oolite-populator.js would probably be the place to look.

pleiadian wrote:
Anyways, as for the Hyperdrive - I must say it's quite fun to zoom around a system with about 300 km per second. I'd say the planets "zoom" by as they should be. I can hyperdrive toward a station and only in a relatively short distance to the station I mass-lock into the aegis. This is quite fun I have to say and much more realistic. When not hypercruising, I'm still at normal speed of 320m/s with a Cobra Mark II-X. This is really cool, and it looks stable enough for me to be used for normal game play.

Really glad you're having fun with it

Any observation, good or bad, please feel free to share.

Posted: **Tue Apr 04, 2017 12:49 am**

One thing I noticed when I had the chance to play with it was that planet rotation speeds seem a little high, and now that they're bigger it's quite noticeable. This isn't a big deal but I just thought I'd mention it.

Posted: **Tue Apr 04, 2017 4:17 am**

Apropos to all the discussions of encounter frequency, etc, is another observation I was hoping to test further, before reporting on.. but recent demands on my time have prevented me from doing the in-depth testing I was hoping to.. and I'm not sure when I'll have time, so I'll just throw this out here now.

Hopefully, somebody else can check my observations.

I spent three hours just loitering outside Erlaza (G1) station.. Erlaza has 4 reasonably decent neighbouring systems.. so, it's not particularly busy, but not especially quiet, either. In that whole time, not counting a small wing of Vipers, there were only 5 ships launched from the station.. one of which was an escort for another ship. The other 3 ships were all in-system Shuttles and Transporters. There were NO arrivals.

Far from the more usual situation in Oolite, of having major traffic jams build up in a system over the course of time, the system felt utterly empty. The sense of loneliness was almost palpable. The usual feeling of being in a vibrant, busy system was entirely absent.

I've been pondering this apparent lack of station traffic. I suspect there are two distinct factors at work here.

Firstly, on the subject of arrivals. We all know the way NPC traders just tootle along much of the time, at rather less than full speed. It's as if they're in no hurry to reach the station at all. Combine this with the longer spacelane, and it may now literally take hours for inbound ships to get to the station. Perhaps this is behind the complete lack of arriving ships I experienced.

Secondly, departures.. this one has me more puzzled, but I may have come across a clue.

In some recent reading, I was checking out the wiki page for

Station Dock Control. In part, it states:

Previously, the standard populator would randomly launch ships of various types, but some of that randomness was mitigated by some balancing functions. That is, if there was more than a certain number of ships with a particular role, no more of that role would be created. What that did was prevent a system from having more than 3 heavy hunter groups, or 4 medium pirate freighter groups. If there are 3 or more heavy hunter groups, the populator wouldn't create anything.

This got me thinking..

Now, whilst I know that ships exiting the Station will quickly witchjump out of the system, what about those that are outbound in the spacelane? Do they fly all the way to the Witchpoint Beacon before jumping out? Because if so, all roles may be fully populated, and the populator may be waiting for ships to depart, before creating new ships with those same roles. But since it may take hours for outbound ships to depart, in the meantime, the result is that almost no ships are leaving the station, except for traffic down to the planet's surface, which is a much shorter trip, meaning that, relatively quickly (albeit still more slowly than before), the populator gets a chance to remove the ship on "arrival" at its destination, thereby allowing a new one to launch.

It also occurs to me that, given the reduced number of encounters we're seeing, NPC traders are somewhat less likely to encounter NPC pirates. This would mean a reduction in the NPC death-toll as well, which would also help to reduce the number of NPC ships being spawned by the populator.

Thoughts on all the above points would be welcome, and I'd also like to request that all testers spend a few hours just loitering -sitting stationary- outside a Station, taking notes, to try and get a clearer picture of Station traffic frequency and intervals. Things seem to be a LOT quieter than they are in stock Oolite, to the point of feeling lonely, and that doesn't strike me as a good thing.

Posted: **Tue Apr 04, 2017 6:57 am**

Some very useful feedback emerging here, so thank you all.

phkb wrote:
One thing I noticed when I had the chance to play with it was that planet rotation speeds seem a little high, and now that they're bigger it's quite noticeable. This isn't a big deal but I just thought I'd mention it.

That's a good point and (happily) a very easy fix

Diziet Sma wrote:
I spent three hours just loitering outside Erlaza (G1) station.. Erlaza has 4 reasonably decent neighbouring systems.. so, it's not particularly busy, but not especially quiet, either. In that whole time, not counting a small wing of Vipers, there were only 5 ships launched from the station.. one of which was an escort for another ship. The other 3 ships were all in-system Shuttles and Transporters. There were NO arrivals.

Far from the more usual situation in Oolite, of having major traffic jams build up in a system over the course of time, the system felt utterly empty. The sense of loneliness was almost palpable. The usual feeling of being in a vibrant, busy system was entirely absent.

I've been pondering this apparent lack of station traffic. I suspect there are two distinct factors at work here.

...

Things seem to be a LOT quieter than they are in stock Oolite, to the point of feeling lonely, and that doesn't strike me as a good thing.

A third factor is the reduced ship speeds, so ships are effectively travelling 6.6 times as far at half the speed, therefore taking over 12 times as long to travel to the station.

The good news is that half of the spacelane's length is purely cosmetic and so there's tweaking potemtial there.

In testing I have encountered non-player interactions and combats numerous times so if not as common as before then they certainly aren't absent.

I could try to tweak the populator/AI to avoid so many ships trawling the full distance to the witch point (if the situation is as Dizzy imagines) but perhaps better is another idea...

Non-player ships have a cruise speed that they tootle along at: 80% of max speed. If there were an AI check for player presence and red alert then, in the absence of both, cruise speed could be = 1,200% of max speed. You would then have a simulated torus drive which we couldn't have before partly because there wasn't enough room. Their speed relative to player torus (which is increased for rescaling) would still be slow and so encounters distributed along the lane would still be common.

Needs work but there may be potential there.

EDIT: It could look really nice if non-player ships (NPS?) travelling towards you exhibited a brief 'glide' to their normal speed as if slowing from torus. Check for player could be 3 times larger than scanner range (no further in terms of actual difference than for the default game) if the new 'cruise effect' was something that was to be more subtle in terms of visibility.

Posted: **Tue Apr 04, 2017 8:19 am**

Redspear wrote: ↑Tue Apr 04, 2017 6:57 am
A third factor is the reduced ship speeds, so ships are effectively travelling 6.6 times as far at half the speed, therefore taking over 12 times as long to travel to the station.
...
Non-player ships have a cruise speed that they tootle along at: 80% of max speed.

Well, that was an assumed but unstated portion of my first factor, incorporated into the statement; "it may now literally take hours for inbound ships to get to the station"

Redspear wrote: ↑Tue Apr 04, 2017 6:57 am
If there were an AI check for player presence and red alert then, in the absence of both, cruise speed could be = 1,200% of max speed. You would then have a simulated torus drive which we couldn't have before partly because there wasn't enough room. Their speed relative to player torus (which is increased for rescaling) would still be slow and so encounters distributed along the lane would still be common.

Needs work but there may be potential there.

EDIT: It could look really nice if non-player ships (NPS?) travelling towards you exhibited a brief 'glide' to their normal speed as if slowing from torus. Check for player could be 3 times larger than scanner range (no further in terms of actual difference than for the default game) if the new 'cruise effect' was something that was to be more subtle in terms of visibility.

This sounds VERY promising.. but first, we need the feedback from more 'loitering tests'. (Yes, I know loitering-based testing is extremely boring.. sorry, but it can't be helped. It helps to set your ship up off to the side of the Station, positioned so your view is aimed just outside the Station docking port. You then activate your ID scanner.. that way, any time a ship goes in or out of the dock, you'll be alerted about it.. which will allow you to also read a book or something while you wait.)

I'm also very interested in the thoughts and opinions of the devs in this regard.. their insights into populator and traffic behaviours might be able to shed some light on things.

Posted: **Tue Apr 04, 2017 10:20 am**

Diziet Sma wrote:
Well, that was an assumed but unstated portion of my first factor, incorporated into the statement; "it may now literally take hours for inbound ships to get to the station"

Sorry

Just establishing the relevant numbers in order to calculate the (avoiding a certain word) size of the issue.

I'm almost certain I've been in cues behind incoming traffic before but given the maths above it would be no surprise if some sort of tweak could be advantageous. A more casual way to test might simply be to record traffic on arrival at the station (make sure docking protocol is 'on'). Did you have to wait to dock? If so was it for outgoing or incoming traffic? Again, if so then what was your cue position? Not as detailed as Dizzy's tests but fairly easy for anyone to do whilst still playing the game.

Posted: **Tue Apr 04, 2017 4:56 pm**

What I can say is:
- I am rarely queued when I request docking clearance, because there are usually no ship around
- When I launch, I usually see one or two ships, but I haven't seen traffic jams
- When I arrive in a system, I've not yet seen combats in the distance

OTOH just today I've been masslocked a bunch of times in a system. It looks like there's some threshold effect. One possible cause is that it may be easier than we think to be "off-lane".

Navigation MFD usually reports ETA from WP to Station in the range of several hours for a Moray, so the test Diziet suggests probably requires a TAF.

I've also noticed that the number of entities reported by 'F' has jumped to almost 1000 versus 100 with the stock game. I'm not sure if it's relevant or related. My FPS is still at the 60 FPS ceiling.

Posted: **Tue Apr 04, 2017 6:07 pm**

Thanks Astrobe.

Longer lane should create more entities as I understand it so lane width can be used to balance that ( I may need to revisit my maths above with a clearer head...)

I'll get back to this later.

Posted: **Tue Apr 04, 2017 10:22 pm**

Astrobe wrote: ↑Tue Apr 04, 2017 4:56 pm
OTOH just today I've been masslocked a bunch of times in a system. It looks like there's some threshold effect. One possible cause is that it may be easier than we think to be "off-lane".

The player ship currently has 5 (I quoted 6.6 earlier but that is not in the current code) times as far to travel down a lane that is (0.33 *2) 0.66 times as wide as before at half speed. 0.66 / 0.5 = 1.32 so lane is proportionally wider (relative to travel time during combat/encounters) but also much longer.

The chance to leave the lane over the course of an encountyer is therfore reduced (takes 132% travel time to clear lane)
Were there to be a gradual drift of the player leaving the lane (~~questionable given unpredictable heading and distances during combat~~ EDIT: actually that does make sense as once deviated from center then likelihood to for a random direction to return towards the centre is reduced) then there could be a cumulative likelihood. If 100% lane length (standard game) / 100% distance to leave lane (standard game) = 1, then 660% / 132% = 5 times as likely to clear the lane.

However, a stabilising factor here is the compass. If the player typically targets the planet/station during torus travel then they are continually drawn back to the lane. Just before the compass switches from planet to station there may be a bit of a 'dead zone' where encounters are less likely but generally speaking, with greater travel distance any 'leaving of the lane' becomes likely less significant as the compass draws the player back to the lane. This assumes of course that the player either uses the compass or heads directly towards the planet.

If the encouter adjustment I suggested before were to be applied:

Code: Select all

#define LANE_WIDTH		(3.0 * SCANNER_MAX_RANGE)

Then (0.33 *1.5) / 0.5 = 0.99 or approximately standard lane width to travel time.

I suspect lane drift isn't too bad under normal circumstances but calculating it accurately is more problematic.
Encounter rate however could do with an adjustment (the line above perhaps) and inbound traffic may need to be more visible around the station.

I'm drawn back to the idea of doing something with cruise speed. Cruise speed in absence of other ships and cruise speed in presence of others (simulating a sort of mass-lock period to allow pirates, police etc. to catch them when moving to max speed). I think I might know how to create the property, I just need to work out how to implement the check. Might need to adjust shipEntity.h shipEntity.m and some of the AIs.

There are some possible cheats around the issue but I think I'd like to avoid those for now.

Posted: **Tue Apr 04, 2017 11:52 pm**

Astrobe wrote: ↑Tue Apr 04, 2017 4:56 pm
Navigation MFD usually reports ETA from WP to Station in the range of several hours for a Moray, so the test Diziet suggests probably requires a TAF.

If you download the v3.02 executable I made, or build your own as a release snapshot ("make -fMakefile release-snapshot"), the TAF will be available to use.

Posted: **Wed Apr 05, 2017 9:34 am**

Another game environment for me to test:

Code: Select all

#define LANE_WIDTH		(2.5 * SCANNER_MAX_RANGE)

Code: Select all

planet_zpos *= [planetDict oo_floatForKey:@"planet_distance_multiplier" defaultValue:4.95];

If I'm calculating planet distance correctly (beginning to wonder as 5.0 was always a 'fudge' value...) then 4.95 (very close to the 5 currently being used) would be proportionally one and a half times further from the planet than in the standard game. It looks further than that to me...

Perhaps I should be tweaking this line instead:

Code: Select all

double planet_zpos = [planetDict oo_floatForKey:@"planet_distance" defaultValue:500000];

Anyway, if we assume a lane one and a half times as long then we still have some cosmetic benefits on system entry (wider 'overview' of system than in standard game) and then if lane is 2.5 times scanner distance:

(2.5*2.5)/1.5 = 4.166
Which is only fractionally less encounter-wise than than the default game's:
(2*2)/1 = 4
The four representing 1 in 4 of lane encounters crossing the player's path, so a smaller number means more encounters.

I've got some computer time coming up so I'll have a play with the values and report back.

Posted: **Wed Apr 05, 2017 6:52 pm**

OK, some initial tests have yielded promising results.

To summarise:

It appears my maths re distances was sound
Adjustments to lane length and width can increase the encounter rate significantly
Bringing in the planet it made sense to adjust the sun distance which made the corona visible on system entry again
Greater encounter rates slows player progression relative to NPS and a shorter lane allows them to progress relatively further in shorter time
Despite the above NPS still couldn't make it to the station in time to stop the player getting to the front of the queue
Torus drive remains to be readjusted to the shorter distance but more is likely to be required to simulate a busy station

So, Astrobe's point re encounter rates has been addressed (although I must confess that a compromuise value would likely be more to my personal preference).

Dizzy's point re station traffic however, although mathematically improved significantly, remains an issue.

Pictures and code tweaks to follow, perhaps after I adjust the torus drive...

Posted: **Wed Apr 05, 2017 8:29 pm**

I've been playing the Rescale edit for two days now, and implemented the above changes as well... it's the like the stations are completely void of traffic. Maybe a Galcop ship here and there, but nothing else. I waited about 10 minutes at an Anarchy TL 2 station - nothing happened, no ship whatsoever.

That needs some tweaking. For the moment I'll switch back to vanilla 1.85 with shaders only.

Posted: **Wed Apr 05, 2017 10:08 pm**

I think I might have a solution. I haven't checked the code yet but in theory this would be a very simple fix - much easier than the cruise speed idea.

What's the most efficient way to populate a 'non-player-centric' galaxy?
As long as it is for a single player game then it is only to generate traffic within the same system as the player.
Wormholes can still be followed but once they are gone there is no longer a need to record the traffic that passed through...

~~Battery dying... more to follow...~~

...unless that traffic included the player.

To simulate traffic having arrived at various times prior to the player doing so, traffic is spawned at various points along the lanes. If this is done well then there can be a near constant stream of traffic both arriving at and leaving from the station.

So, what is going wrong?

If you've tried the experiment then you may have noticed that station bound traffic is rarely the reason for mass-lock once you start to get close to the planet or the station.
Entity count has gone up so it shouldn't be a lack of traffic.
Rather what appears to be happening is that traffic isn't being spawned along the entire lane.

Given that 'position 0' in the system is the witch-point then unless the spawn distance is adjusted station bound traffic is delayed - there would then be a large gap on the space-lane carousel.

If I understand correctly, lane length has one variable in the standard game: planet size.
If that is the case then it can be easy to see how any increase to proportional lane length (as is the case for the rescaling experiment).
Even if the lane is 'only' increased by another 25% then that is a huge distance (and therefore time delay) for NPS which are restricted by there lack of torus drive.

The solution?

I have yet to find the code but if the above is correct then it should be a relatively simple matter of increasing the range of random distances from the witch point to match the new length of the lane.
The populator is expecting a lane length of x * planet size
For the rescaling experiment it needs to be x * planet size * cosmetic increase to lane length.

I could be wrong of course

as the above is nearly all theoretical at present.
A quick test would be to remove the cosmetic adjustmment to lane length (and rebalance the torus drive and lane width) and see if station traffic normalises.

I'll let you know...

Posted: **Thu Apr 06, 2017 12:57 am**

Shrinking the lane does indeed result in increased station traffic but that all seemed to be outgoing traffic.
Is it possible that these adjustments could be a mis-step (the 1.1 values used to be 3)?

Universe.m

Code: Select all

result = OORandomPositionInCylinder(kZeroHPVector,SCANNER_MAX_RANGE,[planet position],[planet radius]*1.1,LANE_WIDTH);

Universe.m

Code: Select all

result = OORandomPositionInCylinder([planet position],[planet radius]*1.1,[sun position],[sun radius]*3,LANE_WIDTH);

Random position in the cylinder (or lane) sounds very much like what I was concerned with and yet they have been reduced here to compensate for (perhaps rather than to account for) increased planet size.

Possibilities:

The 1.1 values could be switched back to 3.0
They could instead be increased to 9.9 (if larger planet = proportionally longer lane)
They could be increased to 2.2 or 6.0 or 19.8 (approx doubling if using full cosmetic adjustment to lane length)

Traffic is also spawned near to the station aegis but not nuch of that seems to be headed to the station for whatever reason.

Oolite Bulletins

Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment