Oolite Bulletins

Posted: **Wed Jan 01, 2014 11:38 am**

Redspear wrote:
Is mass-lock from ships purely triggered by their appearance on your scanner?

Yes. There is rather a lot of player status check that only happens if the relevant HUD dial is drawn - I just recently fixed up a bug where the player's aegis status wouldn't be updated if the compass wasn't drawn (as opposed to drawn at 0.0 alpha) - and similarly there's a bunch of code in HeadUpDisplay.m which forces scanner checks if no scanner is drawn. The code for updating alert status and masslocks should really be in PlayerEntity.m as part of the update routine, with the scanner dial just reading a "nearby entity" list.

Redspear wrote:
If so, it might be beneficial for me to increase that a bit (not necessarily by as much as 3.3) in order to approach current encounter rates.

Possibly, yes, though it would make masslocks more annoying, and change the extreme-range dynamic of the military laser (not necessarily for the worse).

However, the populator in 1.79 already adapts system population numbers to the spacelane length (because it's simulating an average arrival rate, so a longer spacelane requires more ships in transit). It might be easier to match the encounter numbers by making the spacelanes wider - update the LANE_WIDTH constant at the top of Universe.m - that will spread out the larger linear number of ships across a wider cross section. Probably multiplying it by sqrt(3.3) is correct, so ~93000.

Posted: **Wed Jan 01, 2014 3:58 pm**

cim wrote:
Redspear wrote:
Is mass-lock from ships purely triggered by their appearance on your scanner?
Yes. There is rather a lot of player status check that only happens if the relevant HUD dial is drawn - I just recently fixed up a bug where the player's aegis status wouldn't be updated if the compass wasn't drawn (as opposed to drawn at 0.0 alpha) - and similarly there's a bunch of code in HeadUpDisplay.m which forces scanner checks if no scanner is drawn. The code for updating alert status and masslocks should really be in PlayerEntity.m as part of the update routine, with the scanner dial just reading a "nearby entity" list..

Good. I can work with that

Agreed. PlayerEntity is where I'd have looked for it in my ignorance.

cim wrote:
However, the populator in 1.79 already adapts system population numbers to the spacelane length (because it's simulating an average arrival rate, so a longer spacelane requires more ships in transit). It might be easier to match the encounter numbers by making the spacelanes wider - update the LANE_WIDTH constant at the top of Universe.m - that will spread out the larger linear number of ships across a wider cross section. Probably multiplying it by sqrt(3.3) is correct, so ~93000.

Ah, so in 1.79 it's more a case of my having to consider the greater entity count rather than a lack of encounters if I'm increasing planet size?

In that case it's probably easier to leave the scanner alone for now (and maybe the lane width too until there's been some initial testing, although I do like the idea of wider lanes).

As always cim, thanks for all the tips and signposting

Redspear wrote:
I used to wonder if the torus speed could change depending on say your distance from the witch-point?
If the further you got from the witch-point the faster it went then longer distances might be navigable.
If the gradient of change was a gradual one then it might appear subtle in game.
There might also be a more realistic effect of planets appearing small for a long time and then more abrubtly starting to get bigger as you begin to get close to them (I explained that quite badly but I hope it makes sense).
The decelleration on the torus would have to be very strong in that situation I suspect.
Anyway, that's for another time perhaps...

The above idea perhaps makes more sense if torus speed were to decrease as the player got further from the witch point.
It could then work to simulate greater distances rather than to cross them.
In either case, I don't know how to do it yet, so it ain't happening for the forseeable

Posted: **Wed Jan 01, 2014 4:10 pm**

Redspear wrote:
Ah, so in 1.79 it's more a case of my having to consider the greater entity count rather than a lack of encounters if I'm increasing planet size?

Both, irritatingly.

If you make the planets X times bigger, that makes the spacelane X times longer. But it also makes it X times wider, in terms of where the player might be, if you assume they start from the witchpoint and head to some point on the planet's surface (or - with an ASC - potentially a bit to the side of the planet's surface). Similar calculations for the W-S and especially S-P lanes.

So the volume encompassed by the spacelane is X-cubed bigger. You want about the same number of encounters as before, though, so you only need X-squared more ships. The populator, however, only adds X times more ships because it only considers the length.

Ideally I think you'd multiply the populator arrival rates all by X, and then also multiply LANE_WIDTH by X. The catch with that is that it does lead to X times more ships per hour leaving or reaching their destinations, so ideally in that scenario you also have X times as many stations in the system to receive and deploy ships. (That's probably a good thing in itself, though not easy to achieve while the main station retains its numerous "special status" properties in the current implementation)

Posted: **Wed Jan 01, 2014 4:25 pm**

Redspear wrote:
Norby wrote:
Ships: I think the scale_ship = yes can be a metadata in ship oxps to flag it is designed to human scale and the core can rescale with the rescaleBy method. For backward compatibility the missing flag mean the oolite ship scale. In the main branch the core can scale up human sized ships, an other (scaled?) branch can scale down all other ships so both can use all ships after some possible bugfixes.
Like it, that should make Paradox happy

I think he knows it already, I repeated his idea to confirm the benefits.

Redspear wrote:
if once we get past, say 10 times bigger, will the benefit be significant?

The sense of short lanes partially comes from the large planet view either from Withchpoint or Sun, so 10x is better but not real. The game engine can give as real sense as real the data what we use, so 100x can give more realistic increasing of planets during approach.

Redspear wrote:
the torus speed could change depending on say your distance from the witch-point?

In my idea the max.speed of torus depends on your distance from the nearest planetary mass. It can be smooth and fast also with a good curve what I will find during my test.

Redspear wrote:
see if we can get 3.3 to work and then if we can do that there will probably be some more adjusting to do to get it to work better, and perhaps closer (gameplay wise) to the current Oolite.
e.g. If we have to increase scanner range even a little then that could change the start of every encounter with other ships.

Changed scanner range can cause problems, especially in OXPs, so I suggest to test the 3.3x case with the original scanner. Try change as little as possible which is easier to accept and if we change all things with the same multiplier then we can not get the feeling of longer space lanes. I am sure you will find the correct populator multipliers with cim's excellent support.

Redspear wrote:
Thanks again for your interest and support

Thinking on the game is another game what I can play far from the keyboard also.

Posted: **Wed Jan 01, 2014 11:08 pm**

cim wrote:
If you make the planets X times bigger, that makes the spacelane X times longer. But it also makes it X times wider...

I'd missed the 'wider' part previously. Makes sense I suppose...

cim wrote:
The populator, however, only adds X times more ships because it only considers the length.

I suppose that make sense too with the current set up, otherwise populations would show little variation by system.

cim wrote:
Ideally I think you'd multiply the populator arrival rates all by X, and then also multiply LANE_WIDTH by X. The catch with that is that it does lead to X times more ships per hour leaving or reaching their destinations, so ideally in that scenario you also have X times as many stations in the system to receive and deploy ships. (That's probably a good thing in itself, though not easy to achieve while the main station retains its numerous "special status" properties in the current implementation)

Sounds good but I suspect I need to get something basically functional first. I may well get back to that though...

Norby wrote:
Redspear wrote:
Like it, that should make Paradox happy
I think he knows it already, I repeated his idea to confirm the benefits.

Yes but your 'missing flag' idea makes it a little more tidy

Norby wrote:
The sense of short lanes partially comes from the large planet view either from Withchpoint or Sun, so 10x is better but not real. The game engine can give as real sense as real the data what we use, so 100x can give more realistic increasing of planets during approach.

Ah, so you're taking about increasing lane size by a different factor than planet size, right?
Sorry, I misunderstood...

Norby wrote:
In my idea the max.speed of torus depends on your distance from the nearest planetary mass. It can be smooth and fast also with a good curve what I will find during my test.

If it can switch between reference points then that could work well. If that can't be done easily then I'd suggest the witch point.

Norby wrote:
I am sure you will find the correct populator multipliers with cim's excellent support.

I really need to get a proper test environment set up soon. The talk has been very useful (cim's been great) but I'd better get back to the source soon and let other interested parties give it a try and invite some criticism... yours too I hope

Posted: **Sat Jan 11, 2014 4:20 pm**

Sorry for the delay (for anyone interested) but I have at least been able to do a little more work on this...

So I tried sizing the planets up by a factor of 3.3 to create larger systems.
I then adjusted the torus drive to take a similar amount of time to travel the spacelanes as before.
To compensate for the greater drift distance when dropping out of torus speeds, I also sharpened the decelleration.

Here's the result of a very quick (and rather slap-dash) test:

Launched at Lave and hyperspaced to Leesti (corporate state) with no cargo on board. Followed the compass to the planet and then the main station. I didn't make particular efforts to stick to the lane and on a few occasions headed a little sideways to escape masslocks quicker.

Without having made any adjustments to the lane, the populator or to the scanner, I was masslocked several times en route.

I encountered:

1 Boa Cruiser
2 Pythons (seperately, although one overlapped with Boa Cruiser)
1 Anaconda
2 Boas (seperately again)
3 Asteroid clusters (distinct from each other)

I saw in the distance (by chance rather than scanning):

1 Laser fight
1 Patrol of Vipers (or Ship + Escorts, I didn't investigate)

Time to get to the planet seemed similar to before (as expected) but as cim reported previously, the masslock of the planet was quite restrictive in terms of heading directly to the station at that scale. The station however, was satisfyingly dwarfed by the planet.

Not bad and basically playable but I expect sunskimming and planetfall would be a total PITA, so to change the mass-lock radius... I haven't worked it out yet

... Can anyone tell me where this is set please?

I also had some trouble implementing the 'rescaleBy' function for the stations (must be doing something wrong) but that's much less of an issue at present...

The torus adjustments worked as hoped but the first time I set them I accidentally slowed the decelleration rather then sharpening it (so it was a bit like turning on a really old tv: for the first few seconds there was no noticeable response and it was easy to be lured into pressing it several times waiting for something to happen

); luckilly that was a simple fix. The current setting (as I have it) is a bit sharp compared to the original but I like it and, crucially, it is a simple matter to adjust it.

So it needs plenty more testing but what do you think of that encounter rate?

Posted: **Sat Jan 11, 2014 4:31 pm**

Redspear wrote:
Not bad and basically playable but I expect sunskimming and planetfall would be a total PITA, so to change the mass-lock radius... I haven't worked it out yet ... Can anyone tell me where this is set please?

In HeadUpDisplay.m

Code: Select all

- (BOOL) checkEntityForMassLock:(Entity *)ent withScanClass:(int)scanClass
{
  ...
			double factor = ([stellar isSun]) ? 2.0 : 4.0;

The square root of factor is the number of radii from the centre you have to be before a masslock from a planet or sun - note that it's already closer in for stars. (Or as you'll see, within 25k of the surface)

If you've sized the planets up by 3.3, dividing the factors by 3.3 squared (or 10 is probably close enough) should give the same distance from the surface for masslocks.

Posted: **Sat Jan 11, 2014 4:34 pm**

cim wrote:
In HeadUpDisplay.m

Brilliant!

Thanks again cim.

Posted: **Sun Jan 12, 2014 5:00 am**

Redspear wrote:
Without having made any adjustments to the lane, the populator or to the scanner, I was masslocked several times en route.

I encountered:

1 Boa Cruiser
2 Pythons (seperately, although one overlapped with Boa Cruiser)
1 Anaconda
2 Boas (seperately again)
3 Asteroid clusters (distinct from each other)
I saw in the distance (by chance rather than scanning):

1 Laser fight
1 Patrol of Vipers (or Ship + Escorts, I didn't investigate)
...

what do you think of that encounter rate?

I'd say it seems pretty typical of standard play..

You're off to a promising start..

Posted: **Tue Jan 14, 2014 7:17 pm**

Diziet Sma wrote:
I'd say it seems pretty typical of standard play..

You're off to a promising start..

Thanks DS

Well, I've since edited those mass-lock radii and headed to the planet surface on Lave and gone sun-skimming at Leesti

Ignore the 'atmospheric entry' bit, it's a relic of fiddling with Wildeblood's altimeter, but the distance is relevant here.
So, I'm close to the surface of Lave (not one of the bigger planets) and it's starting to flatten out nicely.

A good deal closer now and using that nearby planet to illustrate the peak in the surface.

Very close now and pancake like flatness is evident.

Same altitude, different view. Note the slight peak just to the left of the sun: one of Lave's edges, illustrating that it is a polygon.
Is it realistic? Not really but in my mind detail is missing rather than glaringly 'wrong'. To me at least, this will make planetfall look much better.

I went sunskimming too (forgot to take 'photos'

) and can confirm that it worked. There was an interesting graphical quirk that I quite liked (I'll try it again and get a picture when I can) but I'm not sure how much it was a product of the rescaling and how much it was to do with the new suns. I just about escaped in time (no heat shielding) but I will need to do some more tinkering with the torus drive to introduce a little more skill into the process...

Posted: **Wed Jan 15, 2014 2:33 am**

Redspear wrote:
Thanks DS

Just "Dizzy" will do.. no need to be formal..

Redspear wrote:
Well, I've since edited those mass-lock radii and headed to the planet surface on Lave and gone sun-skimming at Leesti

I went sunskimming too (forgot to take 'photos' ) and can confirm that it worked. There was an interesting graphical quirk that I quite liked (I'll try it again and get a picture when I can) but I'm not sure how much it was a product of the rescaling and how much it was to do with the new suns. I just about escaped in time (no heat shielding) but I will need to do some more tinkering with the torus drive to introduce a little more skill into the process...

You might find the Numeric HUD handy here.. the 1% precision of the digital altimeter, plus the fact that the altimeter reads out to a full diameter (2 x planetary/solar radius, or 200%, in other words) may be helpful in your tinkering. I find it most informative when sunskimming. For instance, I know that the scoops will always activate the moment my altitude falls below 15% of the stellar radius.. it takes the guesswork out of fuel-scooping..

(although if Wildeblood's Altimeter works for the sun as well, that might be even more useful.. despite which, I think there's a lot to be said for the way the Numeric HUDs altimeter displays in units of Percentage of Planetary Radius.. that way there's less need to take the size of the sun/planet into account..)

Posted: **Wed Jan 15, 2014 9:34 am**

I love the way this experiment is going...

Posted: **Wed Jan 15, 2014 11:44 pm**

Diziet Sma wrote:
Just "Dizzy" will do.. no need to be formal..

Got it!

Diziet Sma wrote:
You might find the Numeric HUD handy here.. the 1% precision of the digital altimeter, plus the fact that the altimeter reads out to a full diameter (2 x planetary/solar radius, or 200%, in other words) may be helpful in your tinkering. I find it most informative when sunskimming. For instance, I know that the scoops will always activate the moment my altitude falls below 15% of the stellar radius.. it takes the guesswork out of fuel-scooping..

That sounds well worth looking into. Thanks!

Zireael wrote:
I love the way this experiment is going...

Thank you

It's nice to know there are at least a few others out there who think this is worthwhile

So I went sunskiming again (without numeric HUD), at Diso this time. Here's what happened...

Standard looking approach...

Mass lock and full fuel scooping occurred almost instantaneously at this altitude (need to sharpen that torus decelleration). I'd tried it previously with an empty tank and got the same result.

Note the compass, I'm now facing away from the sun; such is the glare of the corona.

If you look carefully, you might just be able to make out a planet immediately to the left of the laser sights and another a little further to the right.

A little further out now (compare altitude gauge) and using external views to make things a little more obvious (perhaps you can make out the engine glares of the ship, just above the HUD).

Made it with just a little room to spare

Well, it works. I quite like the disorientating effect of feeling like the sun was everywhere you headed (took me a few moments the first time) as heading into a star probably would be a bit on the disorientating side; plus the glare of the corona adds to the feeling of it being massive. The standard compass was a big help but I could also see those planets if I hadn't thought of that.

What I missed was the dilemma between scooping just a little more and getting out safely. Sharpening the torus drive further should help to remedy that.

Oh, had my first combat too. A Thargoid... It didn't last long

Posted: **Thu Jan 16, 2014 12:48 am**

Redspear wrote:
Well, it works. I quite like the disorientating effect of feeling like the sun was everywhere you headed (took me a few moments the first time) as heading into a star probably would be a bit on the disorientating side; plus the glare of the corona adds to the feeling of it being massive. The standard compass was a big help but I could also see those planets if I hadn't thought of that.

Agreed.. that was most impressive.. and to my mind, pretty realistic. Anyone that close to a star should be totally immersed in the glare. Nice to see that your changes made that happen.

Posted: **Thu Jan 16, 2014 7:49 am**

The position of the glare effect is related to the corona edge position, which is proportional to two factors: the corona_flare value for the system, and the square of the radius of the sun. Perhaps there needs to be a little adjustment in 1.79 to make it less subtle (if you go deeper than necessary for sunskimming, you can try it out, though)

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