Page 34 of 54
Re: Split: Re-scaling experiment
Posted: Thu Apr 06, 2017 6:10 am
by 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.
Re: Split: Re-scaling experiment
Posted: Thu Apr 06, 2017 7:39 am
by 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.
Re: Split: Re-scaling experiment
Posted: Thu Apr 06, 2017 9:00 am
by Disembodied
Redspear wrote: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!
Re: Split: Re-scaling experiment
Posted: Thu Apr 06, 2017 11:13 am
by 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.
Re: Split: Re-scaling experiment
Posted: Thu Apr 06, 2017 12:37 pm
by Disembodied
Redspear wrote: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.
Re: Split: Re-scaling experiment
Posted: Thu Apr 06, 2017 5:01 pm
by 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...
Re: Split: Re-scaling experiment
Posted: Thu Apr 06, 2017 5:20 pm
by Disembodied
Redspear wrote: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!
Re: Split: Re-scaling experiment
Posted: Thu Apr 06, 2017 8:45 pm
by Redspear
Disembodied wrote:
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
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.
pleiadian wrote: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);
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);
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.
Re: Split: Re-scaling experiment
Posted: Thu Apr 06, 2017 11:06 pm
by Diziet Sma
Disembodied wrote: ↑Thu Apr 06, 2017 9:00 am
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 wrote: ↑Thu Apr 06, 2017 5:20 pm
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 wrote:
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 wrote:
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!
Re: Split: Re-scaling experiment
Posted: Thu Apr 06, 2017 11:24 pm
by Redspear
Diziet Sma wrote:
I too have had that hope.. since this project first began, in fact.
Supporter in chief, no less
Diziet Sma wrote:
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
Diziet Sma wrote:
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
Re: Split: Re-scaling experiment
Posted: Thu Apr 06, 2017 11:26 pm
by Diziet Sma
Redspear wrote: ↑Thu Apr 06, 2017 11:24 pm
I think I just GitHubbed
Fingers crossed I didn't break anything
Seems to have gone through just fine.
Re: Split: Re-scaling experiment
Posted: Thu Apr 06, 2017 11:59 pm
by 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.
Re: Split: Re-scaling experiment
Posted: Fri Apr 07, 2017 7:52 am
by Redspear
Diziet Sma wrote:
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...
Re: Split: Re-scaling experiment
Posted: Fri Apr 07, 2017 7:57 am
by pleiadian
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
Re: Split: Re-scaling experiment
Posted: Fri Apr 07, 2017 8:15 am
by 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).