Oolite Bulletins

Day wrote: ↑Tue Mar 31, 2020 1:42 pm

Testing the basic build out now. Will likely need some tweaks before I can present it but scaling around the mk 3 makes things so much easier...

Re: ship rescaling, it occurs to me that if I just rescale freighters and stations then there'd be no need to play with laser ranges (smaller fighters requiring smaller laser ranges else they become near indistinguishable).

I'll perhaps cover that with an oxp option, one that folks can try out in combination with either of the two builds already mentioned.

... And another way (albeit less oxp friendly) to test the second proposed build would be to scale around the scanner itself. More hassle but no known reason why it wouldn't work.

Just curious, by how much are you scaling things? I played with scaling freighters and stations a while ago and found that 2.5 (I think) worked well for the stations, Boas, and the Anaconda while 2 worked for the Python.

Looking forward to seeing the product!

Well, previously and relative to the mk 3, it was...

• planets & stars x 6.6
• space lane x 12
• stations and freigters x 2
• fighters x 0.66

I did have a version where ship scalings were more specific but once you shrink anything then you need to start thinking about doing the same with laser ranges.

Re the Anaconda, I rather like the idea that its size is defined by the docking bay (just as some container ships today are defined by particular waterways) and so it is likely that it will always match the station (besides, the 750 TC was almost certainly a typo...)

I think that scaling the ships and the station really makes the whole thing 'pop' and it seems I'm not the only one (scroll up to see the pics). I think the Boa was canonically smaller than the Python but could ship more cargo due to being a much younger model.

Ships aren't really on the menu just yet however - I'm focussing on making a recognisable version first (in terms of combat and docking).

Thanks for your interest

I think I've solved the scanner problem

In a nutshell:

• Scanner at 50% resulted in no docking ships at the main stations. Not great...
• Just tried scanner at 66% which but oonly docking ships were vipers. Better but still an issue...
• One code tweak later, I arrived at Isinor station to be immediately queued behind an Anaconda and a Boa Cruiser. Glorious

So, in theory I now have a lot more freedom to tweak things and none of the previous test environments are (as yet) off the menu.

To explain a little more my thoughts on the scanner...

The scanner in Oolite is a bit odd: it's both too small to show things that are visible with the human eye; and at the same time it's so big that masslocks and escape attempts can be very dull affairs. So in a very peculiar way, one could argue that it's just about the right size to act as a compromise between the two extremes.

Shrinking it however, enables me to do two things. Firstly, I could also shrink the ships - wouldn't want a proportionally bigger scanner or else I'd be caught between having massocks and escapes take much longer or combats being much harder (if I didn't also reduce the speeds). Secondly, it let's me explore what gameplay might be like if I could shrink it a little, proportionally to ship sizes. Maybe the mass-lock/escape compromise isn't quite optimal and if I can tweak the scanner independantly of the ships then all the better.

So what of the visual aspects? The scanner is already short ranged in that regard isn't it?
Not for everyone perhaps but I'm using it as an ID scanner rather than a purely orientational device.
It's a tweak to a tweak that another_commander posted previously. I'll likely post images later.

So hear was my first station arrival after the successful code adjustment.

Please note that the only thing that has been rescaled, that you can actually see, in these pictures is the scanner.




Note that I'm third in the queue (so not just a freak incident of one ship making it to the station) and also that the scanner is a little different.
The differnt line markings are a consequnce of it being smaller but the names showing up are a personal preference I learned abot here.

What I have since experimented with is reducing the name length eg. Nav Buoy rather than Navigation Buoy, in an effort to reduce clutter. Note how if it were Coriolis rather than Coriolis Station (the station being indicated by the green lollipop marker) then it wouldn't interfere with the Anaconda in this instance.




Anaconda is just about to dock with Boa lining up. You can see the clutter that can happen when entities are close to each other but the shorter the names the less of a problem this is.

Names are drawn from shipdata.plist however, so whilst Sidewinder Scout Ship might reasonably be reduced to Sidewinder, S-winder wouldn't look so good in a shipyard (although that particular ship isn't usually for sale...) and as for GalCop Viper Interceptor...




Anyway, back to the docking. So after those two docked I had to wait for a ship to launch as well.




A python has just launched showing that when two entities are close enough it hardly matters how long their names are (a quick roll of the player ship wil reveal them in many instances however). So with both launching and docking ships at the station, I think I can carry on testing with this new scanner

I'm personally justifying the scanner as being the ship's ID range rather than the ship's detection range. Given that the regular scanner has less range than the player's eyesight (in game rather than the scanner's supposed 25km ) then I don't think that's so bad.

The names are just something I'm having fun with, I'm not expecting them to go in the standard build (of the rescaling project).

Well those docking ships certainly weren't a fluke - I got stuck at 21st in a docking queue

I can't recall that ever happening to me before, in any version of the game, so I may need to look into that.

Masslocking for planets and stars needs a little more tweaking but it's workable in its current form. Only a couple of tests so far but worryingly no encountes on WP-planet or WP-star. May need to find similar fix to the one for the WP-planet (re docking arrivals) but I've had the scanner be smaller before without this problem.

Perhaps most likely is that I've made the station too easy to find in relation to the star, so ships are all heading there instead. Further investigation required I think...

As an aside, although related to the scanner:
With no oxps operating, you really find out which ones you miss. Apart from some of the cosmetics and stations, I think my Power to Engines oxp might be the one I miss the most from a gameplay perspective as it 'solves' the speed issues (inherent in the standard Oolite) for nearly every playable ship.

The smaller scanner I'm working with right now helps with that but problems remain against faster ships and so it doesn't really solve anything, it just makes it less annoying. Last time I worked with the rescaling (over a year ago) I hadn't yet made the PtE oxp, so if I now believe there's a workable solution with the old scanner then do I really want to keep this new one?...

The scanner at 66% is just a little bigger than beam laser range, which reduces the military laser's advantage (sniping) and also the time spent closing/escaping a target. It also makes station approach a little more breakneck if the planetary masslock radius is set right (and it's fun ). Briefly tempted to hardcode the power to engines solution (weapons offline = max speed boost when not using injectors) but that's not really what the experiment is about...

Re: reduced scanner

Pros:

• Reduced time spent in masslocks
• Reduced time spent escaping slower aggressor
• Lining up to the station aegis becomes a fun skill
• Edge of scanner marks range at which station blocks a hyperspace jump
• Less room for sniping, so more dogfighting

If the first two can be addressed by oxp then perhaps the third one can too. There's an is_massLockable (or similar) property that could be disabled within the station aegis but that would have to be (de)activated prior to the masslock occurring.

The fourth one is very nice but hardly essential (less useful with player experience) and the last one is a bit of a mixed bag depending on where one might wish to go with laser ranges and combat balance.


Cons:

• Masslocking aggressors likely have less distance to cover in order to attack
• Non-player ship behavioural quirks that may or may not be easy to solve
• Less room for imaginative uses of space

Again the first could be a boon or a curse depending on where combat goes. The second one however, is either a non-issue or potentially quite serious; the main concern at the moment being how much work it would be to make it into the former.

With regards to the third on the list, I think it's true that the big scanner has (literally) more room for manouver with regards to combat in particular. The scanner marks the extent of the arena in which the player interacts with other entities that aren't stars, moons or planets. Reducing this may not be wise in that it limits other possibilities. The current thing it would limit is the usefulness of the military laser's long range (not necessarily a bad thing) but then it also means that Thargoids could attack you from off scanner (could be good but probably not...)

Masslock and escaping can be a considerable PITA but if they're easily resolved by oxp (I'll tweak mine so that pythons are viable - if you really want to fly an anaconda then what do you expect? ) then that's already the main benefit of a smaller scanner gone.

Any ideas on how to achieve this via oxp however,

There's an is_massLockable (or similar) property that could be disabled within the station aegis but that would have to be (de)activated prior to the masslock occurring.

would be gratefully received.

Redspear wrote: ↑Thu Apr 02, 2020 9:45 pm

'solves' the speed issues (inherent in the standard Oolite)

I think a good solution could be an automatic time manipulation in the boring situations.

The TAF is not available in end-user builds so i am thinking on an other solution, which basically multiply the maxspeed and turn rates of all moving objects, and also the game clock speed (by addSeconds). It could be auto-activated at the high end of speed bar, turn off by reducing speed a bit and instant off in red alert.

Anyway, your project is still interesting.

Norby wrote: ↑Fri Apr 03, 2020 6:53 pm

i am thinking on an other solution

Exactly: there's more than one way to do it (i.e. solve the speed issue) and so if it can be done by oxp then maybe no need to be hardcoded - players can chose the one they like

Norby wrote: ↑Fri Apr 03, 2020 6:53 pm

Anyway, your project is still interesting.

Good to know! Things are pretty quiet round here these days


Meanwhile, pics...

One of the (very) few advantages to being placed 21st in the docking queue is that you get to observe other ships on docking approach.

I must apologise for the low lighting here, it's related to sun distance multiplier (which makes perfect sense of course). I'm experimenting with ambient light to resolve the issue.

The thing to notice however is that the station and some of the ships have been doubled in size (nothing has been shrunk).
Easiest way to record them was as a shadow against the station, so if you look for that then they should be clear enough to make the point.

Cobra Mk III:




Python:




Anaconda:




Gecko:




Viper:




Cobra Mk I:




Moray:




Asp Mk II:




I think you get the idea...

No need to reduce laser ranges, no need to reduce the scanner (although it is reduced in these images), all it needs is a bigger system so that we have enough room for the expansion without things looking silly.

Stations and some ships x2 (python, boas, anaconda, transporter, shuttle)
Planets and stars x 6.6
Spacelane x12
Station distance from planet x 3.3

Looking good. If you are using trunk, can you please check whether the resizing of planets breaks the atmosphere shaders in any way or not? Do the atmospheres still look OK in Extra Detail both from nearby and afar?

another_commander wrote: ↑Sat Apr 04, 2020 7:44 am

If you are using trunk,

Downloaded recently using the easy install method for pc, so that would be a 'yes' I'm guessing?

another_commander wrote: ↑Sat Apr 04, 2020 7:44 am

breaks the atmosphere shaders in any way or not?

I'm not seeing the atmosphere effect you posted in the Progress thread in January...
Would I be correct in thinking that OOStandaloneAtmosphereGenerator (.h & .m) might be good places to investigate?

Have been playing with ATMOSPHERE_DEPTH in OOStellarBody.h but tried returning it to the old value but to no avail.

Redspear wrote: ↑Sat Apr 04, 2020 2:54 pm

I'm not seeing the atmosphere effect you posted in the Progress thread in January...
Would I be correct in thinking that OOStandaloneAtmosphereGenerator (.h & .m) might be good places to investigate?

I don't think so, but maybe the atmosphere shaders would be. Do you get any shader errors in your log?

Also, can you please post a screenshot while approaching Lave, at a distance just about before the sky starts turning blue?

No errors reported in the log.





I realise that the atmosphere is very low here. I hadn't returned ATMOSPHERE_DEPTH to its rescaled value.


Other news:

Both lack of traffic on the other lanes and crowding at the station are not scanner related.
Former has traffic but not much (as long as it has some I suppose).
Latter seems to happen at Isinor but not Tionisle, and even then only when I go sunskimming first.

Need to compare it to the situation on the core game. Main suspect for any rescale specific problem at the moment would be the jump drive. As well as increasing the minimum value, this time I tried increasing the maximum value too. Maybe some systems just need a little longer to settle; so if I'm Tourusing down almost empty lanes at record speed then maybe they don't get that time...

Masslocking of planets and suns is nearly there. No problems with it, just trying to find an optimal value.
Increasing the ambient light levels has helped a lot and should make combat a little more visually appealing (and possibly a little easier too).

Slowed rotation on planets and stations and finally shrunk something, the thargon: for a scoopable item it's huge! Consequences are likely to be that they are much harder to target (but who really targets them anyway?)

If your screens are at Extra Detail, then there is a problem with the atmosphere shader,as in, it does not generate an atmosphere. Rescaling the ATMOSPHERE_DEPTH might help, but it is not guaranteed. You may have to tinker with the formula that calculates cosThreshold in the atmosphere fragment shader too,

Sorry, I wasn't clear.

I've already tried it with ATMOSPHERE_DEPTH ajusted to scale, just not in those pics. Appropriate depth gives a full, light blue, starless sky but not the hue to the planets edge that they should do from a distance since January.
Yes, screens are at extra detail setting.

Pardon my ignorance but where is the atmosphere fragment shader please?
Quick search for cosThreshold in each of the files that I found with 'shader' in the title came up blank.