Split: Re-scaling experiment

[Astrobe]

In a way, I think that a lower encounter rate is not as bad as a higher encounter rate, because it can be fixed adjusted with a custom populator.

The difficult question is, what should it be in the default game? Is the encounter rate considered the "right" one or does it need to be adjusted like the scales?

Or put it in another way: how long in average should it take to travel from witchpoint to station when one includes encounters, docking queue times, and Torus time (<=> masslock time)? 5 minutes or 20 minutes?

This time matters in three ways:
- it is the game time unit, in the sense that it is the answer to questions like "Do I have the time to make another trip before my appointment?"
- it sets the credits/hours rate. This is the trade/economy aspect of the game,
- it sets the number of events/combats per game time unit. This is the combat aspect of the game.

Furthermore, this has implications on other destinations (additional stations placed by OXPs for the most part). My approach is to tune things (e.g. Deep Space Pirates for encounters) so that the timings are roughly the same as on the main lane (YMMV because some destinations may be more or less advantageous than the main station).

If we want to be conservative about these aspects, I think we need to benchmark the default game. Something like start with the easy start (I believe we should take injectors in consideration because they are almost mandatory), go to Bemaera and note down how much time it takes to reach the station (docking included, fights not included) and how many encounters happened.

[Redspear]

Some good points there Astrobe.

I think, for the meantime at least, that creating the same (or very similar) encounter rate is probably a good idea.

If it can be replicated successfully (as appears to have been achieved in my latest tests) then it remains independent of, rather than a casualty of, rescaling.

[Disembodied]

I think, for the meantime at least, that creating the same (or very similar) encounter rate is probably a good idea.

Probably best to get a quick fix now, but it might be helpful if any fix could contain the possibility for future variety. A long, empty lane, and a near-deserted aegis with little or no station traffic, could be Good Things in certain circumstances, e.g. in a backwater system at the far end of a lonely offshoot.

Is there already a variable to determine how populous a system should be? If not, could it be calculated in some way, e.g. how many other systems are within (say) 2 jumps? If we could have systems categorised as backwater; quiet; average; busy; hectic (or even just quiet, average, and busy) it would help make different systems feel different. Again, assuming that something like this doesn't already exist!

[Redspear]

Encounter rate fix has been tested successfully I'm just waiting on its compatbility with any station traffic fix that I can hopefully implement soon.

Re population variance among systems, there may be ways to do that whilst still respecting the default time : credits ratio.
For example: Suppose the 'mainly' economies were less well populated. You csn make less money trading there so less traders come, so less pirates come, do less hunters come etc. You could then have a safer option for players in their early careers, moving on to the other economies once they are a little more established.

[Disembodied]

Re population variance among systems, there may be ways to do that whilst still respecting the default time : credits ratio.
For example: Suppose the 'mainly' economies were less well populated. You csn make less money trading there so less traders come, so less pirates come, do less hunters come etc. You could then have a safer option for players in their early careers, moving on to the other economies once they are a little more established.

The problem there though is that could reduce traffic in some "hub" systems: planets with "mainly" economies might not receive much volume of trade themselves, but they could still be stopping points on major trade routes. Counting the number of systems within 2 jumps - if this is practical - would give a better indicator of expected traffic volume, I think.

[Redspear]

The other problem being that I don't know how programme that yet
'Hub' systems is a good point though.

Main job here is to rescale with minimal undesirable side-effects. Other stuff (whilst very interesting to me) should be equally applicable to the standard game (unless requiring some element of the rescaling itself), although to be fair there's quite a large grey area...

[Disembodied]

Main job here is to rescale with minimal undesirable side-effects. Other stuff (whilst very interesting to me) should be equally applicable to the standard game (unless requiring some element of the rescaling itself), although to be fair there's quite a large grey area...

Yes, this is just detail … although to be honest I have a hope that your rescale project might end up becoming the standard game!

[Redspear]

Yes, this is just detail … although to be honest I have a hope that your rescale project might end up becoming the standard game!

Thank you... although 30 odd pages ago that kind of talk would've required a hard-hat

Meanwhile, good news! It looks like I have greatly improved the station traffic problem

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.

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.

Well I've just spent (approx) 10 minutes at Leesti station and withnessed (after a quick code tweak ) the following number of launches:

• 2 Cobra Mk IIIs
• 1 Gecko
• 1 Mamba
• 4 Kraits
• 1 Asp Mk II
• 1 Transporter
• 3 Viper Interceptors
• 2 Adders
• 2 Sidewinders

So at nearly 2 ships a minute, if not exactly frantic it remains a huge improvement over pleidians report; and so massive an improvement over Dizzy's report that even this single test encourages me towards an early conclusion.

It remained the case that there were still no arrivals during that time but it still represents such an improvement that it is highly satisfactory as a 'quick fix'. And yes, I had done some waiting around at stations at various other settings but nothing anywhere near as busy as this particular change induced.

So what was it?

The culprits:

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);

These were both late changes to version 2 of the experiment but added for an expected problem rather than for a discovered one (I think...) which would explain why all of my testing for version 1 and nearly all of my testing for version 2 would have failed to discover a lack of station traffic.

The original and 'fixed' values (which I shall try to restore via github soon ):

Universe.m

Code: Select all

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

Universe.m

Code: Select all

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

Thanks to Dizzy for the find (apologies for the lost 3 hours of your life ) and to pleiadian for the confirmation.

[Diziet Sma]

Disembodied said: Probably best to get a quick fix now, but it might be helpful if any fix could contain the possibility for future variety. A long, empty lane, and a near-deserted aegis with little or no station traffic, could be Good Things in certain circumstances, e.g. in a backwater system at the far end of a lonely offshoot.

Is there already a variable to determine how populous a system should be? If not, could it be calculated in some way, e.g. how many other systems are within (say) 2 jumps? If we could have systems categorised as backwater; quiet; average; busy; hectic (or even just quiet, average, and busy) it would help make different systems feel different. Again, assuming that something like this doesn't already exist!

From observations, (as part of my bountyhunting strategy, I sometimes spend a fair amount of time loitering outside stations, waiting for a free ride to a more distant location - protracted combat with skilled opponents on empty tanks is not recommended!), I believe Oolite already does something like this.. the less systems a given system is 'linked' to, the less traffic there seems to be overall.

Disembodied said: although to be honest I have a hope that your rescale project might end up becoming the standard game!

I too have had that hope.. since this project first began, in fact.

Redspear said: It remained the case that there were still no arrivals during that time but it still represents such an improvement that it is highly satisfactory as a 'quick fix'. And yes, I had done some waiting around at stations at various other settings but nothing anywhere near as busy as this particular change induced.

This is good news.. the fix for the arrivals situation is, I believe, in your proposed "simulated Torus Drive for NPC ships". That ought to balance things out nicely.

Redspear said:
Thanks to Dizzy for the find (apologies for the lost 3 hours of your life )

No apology necessary.. as I mentioned above, occasional loitering is a normal part of my gameplay, so it's natural I'd test it.

Have fun making your first commit to the GitHub code!

[Redspear]

I too have had that hope.. since this project first began, in fact.

Supporter in chief, no less

This is good news.. the fix for the arrivals situation is, I believe, in your proposed "simulated Torus Drive for NPC ships". That ought to balance things out nicely.

I really must work out exactly how to do this...
One day I might be able to code as well/creatively/stupidly as I can can think; then I'll be dangerous

No apology necessary.. as I mentioned above, occasional loitering is a normal part of my gameplay, so it's natural I'd test it.

Have fun making your first commit to the GitHub code!

Doubly thanks.

I think I just GitHubbed
Fingers crossed I didn't break anything

[Diziet Sma]

I think I just GitHubbed
Fingers crossed I didn't break anything

Seems to have gone through just fine.

[Diziet Sma]

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.

[Redspear]

the fix for the arrivals situation is, I believe, in your proposed "simulated Torus Drive for NPC ships". That ought to balance things out nicely.

Thinking some more...

If the 'gap in the carousel' hypothesis was correct then there may be another gap that hasn't been addressed: the gap between the end of the witchpoint to planet lane and the station itself. With planets 3.3 times bigger and the station in orbit (and a proportionally tighter one as well) the increase in distance may even be greater than the usual 3.3 multiplier.

The quickest fix that presents itself to my mind would then be to change the lane to be witch-point to station - but would that be a simple matter and would there be any side-effects?

There is also the area around the station where traffic can be generated, I could experiment with increasing this area. If, as is the case with the lane, increased area leads to increased traffic then this could be exactly the area to target in order to facillitate inbound station traffic.

As usual, more pondering and tinkering to do...

[pleiadian]

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

[Redspear]

Er, I think so... The way to check would be to find those two culprit lines in Universe.m and check if the values have been returned to 3 rather than the erroneous 1.1

What won't be included however is the fix for increased lane encounters. I wanted to add one fix at a time and make sure that they are independantly stable.

So station traffic should be much busier now (with both quiet and busy spells) but lane traffic will remain fairly quiet for a little while longer (although lane width will be fairly robust).