Oolite Bulletins

Will try it. I wanted to reintroduce multiple lasers in my game, but in split mode instead of multiply mode. I'll be on the receiving end only for now because I'm currently riding a Moray Medical.

On the subject of small fighters, the Sidewinder right now is a giant PITA as soon as it has a decent AI. I can't dogfight them (even in a Moray): too small, too fast, too hard to get them in the reticule. They kill your patience more than your ship.

Astrobe wrote:

On the subject of small fighters, the Sidewinder right now is a giant PITA as soon as it has a decent AI. I can't dogfight them (even in a Moray): too small, too fast, too hard to get them in the reticule. They kill your patience more than your ship.

Can't say I've encountered such a problem thus far and I have killed a few; perhaps I need to try the more dangerous systems.

Sidewinders are one of the few ships faster than the mk III however, so with decent AI they should be a handful.
Currently they're at 0.33 scale factor but that could potentially go as high as 0.5 without causing major problems. That would be proportionall the same as in the standard game however, so 0.4 might be a better compromise.

When I first looked at the oolite profile for the sidewinder what really struck me was the 3 energy banks - the mk III only has 4, so 2 seemed more appropriate for a fighter (and would be a better 'solution' to this problem in my opinion). I mentioned this as a possible adjustment just prior to the release of version 1 of this thing (I might post a link to it later...)

Thanks for your experience.

Quick update:

Launching ships should be appearing as normal or slightly more often, docking ships however are rarer.

Have occasionally observed likely traders (a python twice and a boa) looking 'lost' just outside the aegis.
They would stop, zig-zag or change heading when unexpected.

Given that the aegis is smaller, the ship AI may be expecting to find it at the old distance, and when not finding it then acting confused instead of approaching the station to dock. Dockings are occasionally observed however so it does seem rather strange.

Perhaps a hardcoded number or two are in one of the checks somewhere. I'll investigate...

Additional:

Re the lane length paramaters that were recently changed back to 3 from 1.1...

A value of 3 places them at two planet radii from the planets surface, in the standard game that places the station equidistant between the end of the lane (of generated trafic) and the planet surface.

The equivelant value for the rescaling experiment would be 2, however that leaves the ships with much further to travel in terms of actual distance. The station is positioned at 1.5 but is also angled away from the main lane. Reducing the value significantly lower than 1.65 appears to remove station traffic almost entirely (but at 1.65 launching traffic is common).

Redspear wrote: ↑Thu Apr 27, 2017 12:42 am

Have occasionally observed likely traders (a python twice and a boa) looking 'lost' just outside the aegis.
They would stop, zig-zag or change heading when unexpected.

Given that the aegis is smaller, the ship AI may be expecting to find it at the old distance, and when not finding it then acting confused instead of approaching the station to dock. Dockings are occasionally observed however so it does seem rather strange.

Perhaps a hardcoded number or two are in one of the checks somewhere. I'll investigate...

Additional:

Re the lane length paramaters that were recently changed back to 3 from 1.1...

A value of 3 places them at two planet radii from the planets surface, in the standard game that places the station equidistant between the end of the lane (of generated trafic) and the planet surface.

The equivelant value for the rescaling experiment would be 2, however that leaves the ships with much further to travel in terms of actual distance. The station is positioned at 1.5 but is also angled away from the main lane. Reducing the value significantly lower than 1.65 appears to remove station traffic almost entirely (but at 1.65 launching traffic is common).

Hmmm.. that does sound like maybe there are a couple of 'magic numbers' messing us up.. hopefully they're not too hard to track down.

What I found so far:

"ShipEntityAI.m"
Line 1933ff, function setPlanetPatrolCoordinates, there are a number of hardcoded distances.
Line 1200, function getWitchspaceEntryCoordinates, another hardcoded distance (10000)
Line 2211, function setDestinationToDockingAbort, another hardcoded distance (8000)

"DockEntity.m",
Line 307ff, function dockingInstructionsForShip, more hardcoded distances (10000, 1000, 5000, etc) which might need tweaking.

phkb wrote:

What I found so far:

Thanks phkb.
Without checking, I knew of the ShipEntityAI.m ones but not those in DockEntity.m, so I must check those out.

Can it be this simple...

Lane is 3.3 (planet size increase) * 2 (proportional planet distance increase) = 6.6 times longer.
Aegis is 0.33 (scanner size reduction) times bigger.

Therefore Lane is 6.6 / 0.33 = approx 20 times longer in relation to the aegis than before (and is being travelled at half speed).

If approx 10% of traders are generated around the aegis (according to my early and crude understanding of oolite-populator.js) then this might expain the now rather busy launch queues we are seeing at the stations compared to the default game (at least since I stopped the wp-planet lane overlapping it - which doesn't happen in the default game either).

If the aegis is now approx 20 times smaller (proportionally) then that could significantly skew traffic generation in the system... and also explain why the one adjustment that has resulted in sightings of docking traders has been to the aegis population bubble.

It's currently 3 times smaller whilst everything else around it is 3.3 times bigger, so it is potentially much more isolated than before. Luclily, it appears to be defined seperately in terms of its gameplay size and its populator volume.

So there's potentially 2 complementary adjustments here:

• Universe.m - Aegis bubble size (with planet radius influence)
• oolite-populator.js - proportion of traffic generated around aegis

After some tinkering, I'll report back.

This branch has been quiet for a while...

I can understand that you have better things to do or are burnt out. Could you inform us on the current state of the branch so that we can maybe try to work on solutions (I'm actually afraid to make that offer). Also, what is the current opinion of the project team about a merge with the main branch?

I don't know that I have enough experience to speak for the rest of the dev team, but I think it might be slightly premature to consider a complete merge with the main branch. There would be a lot of flow on effects, particularly for OXP's, that would need to be considered. In my opinion it would be beneficial to work out how to make the changes switchable, like the alternate planet textures, so that it's easier for more players to test the changes.

phkb wrote: ↑Tue Jun 13, 2017 9:51 pm

I don't know that I have enough experience to speak for the rest of the dev team, but I think it might be slightly premature to consider a complete merge with the main branch. There would be a lot of flow on effects, particularly for OXP's, that would need to be considered. In my opinion it would be beneficial to work out how to make the changes switchable, like the alternate planet textures, so that it's easier for more players to test the changes.

Agree fully. I think that this effort is a really worthy one, but I don't think it is ready to be included just yet. As phkb states, the switchability between this and the normal build should be considered, but to do that the RE's changes have to be first well defined and stabilized. It might also be beneficial if the final stable changes didn't go in as one gigantic commit, but in stages.

Astrobe wrote:

This branch has been quiet for a while...

Yes, sorry about that

Astrobe wrote:

I can understand that you have better things to do or are burnt out. Could you inform us on the current state of the branch so that we can maybe try to work on solutions (I'm actually afraid to make that offer).

Just very busy... I did do quite a bit of trawling in the source code (before I became distracted) and found some interesting things that all looked like they really should be tweaked but didn't seem to make much difference.

We have docking ships but they are far, far outweighed by launching ones (which are more frequent than in the standard game). Lane perameters are significant but may not be the only issue. If remember I was about to look into entity counts as a possible factor (longer lanes = more traffic therefore less restrictive entity cap required?). AI was another candidate for ships approaching the station and a worthy test would probably be to return the station to it's original orbit and see if that made any difference.

I do this stuff whenever I have some free time and am in the mood (like most of us, right?) but by the time I get some free time again some other (unrelated) idea has often popped into my head and is amusing me; worse, I can't always remember where I was up to or why I did things in a particular way A bit 'slap-dash' I know but it's just for fun and I'm no programmer. Anyway, enough excuses, all interest in this little project is very much appreciated, so sincere thanks

phkb wrote:

I think it might be slightly premature to consider a complete merge with the main branch.

There is, at the very least, one issue (likely with some overlap into other issues) that needs resolving first (i.e. traffic irregularities). A good deal of that stuff is cosmetic rather than essential (to rescaling that is) but it would be nice to keep some of it. I have observed some oddities but they seem to be quite rare and I'm not sure that anything is broken (or at least I haven't found it yet )

Having spent far too long watching ships launch from the station however I am really confident that increasing the size range amongst ships is a big improvement - watching an Anaconda launch really looks impressive now , as does a viper patrol or escort pack. I might tweak some of the intermediate ships a bit but in both principle and practice I'm really happy with it.

another_commander wrote:

I don't think it is ready to be included just yet.

Agreed and I'm going to be busy again for a while
It's always the last 25% or so ...

I've been experimenting with this along with my full complement of OXPs.

Here's what I've found:


Perception of scale

The standard game was bugging me with with how tiny the planets are and even worse the stars and claustrophobic feel to the star systems. The lack of range in ship sizes didn't help at all, either. With the original Elite, when I played it back in the 80's on my Electron it didn't really matter, there wasn't the detail and visual immersiveness, which meant far more went on in the imagination than on the screen, which was just as well given the specs of the computer and tape loading times! Docking with Coriolis stations was a challenging part of the game, with the only player ship being the Cobra mk3 it made sense to scale the slot to the player ship. This isn't relevant to Oolite since the player buy other ships, and even start with something else, like a large freighter, it becomes a challenge to dock when it should be.

I've created an OXP containing a shipdata-overrides.plist for scaling and speed/thrust adjusting just about every ship in every OXP, and the impression is a vast improvement. I was able to rescale the Imperial Star Destroyer model to the official dimensions and it still looked big! The bigger planet and stations helps too, along with the star and system size, but I can't help but feel it could/should have gone even further. Yes, that would mean a change in the populator along the lines of the bubble allocator suggested previously will be necessary or else every ship/group would be too isolated even if the numbers were increased, which at least without multi-threading I can't see as being viable.


Incompatibilities

I've hacked a number of OXPs to make them work with rescaling, including ShipVersion and EscortDeck, but many are going to need to be modified. I'm going to take a look at EscortContracts OXP since it doesn't seem to be placing the Escort Mother anywhere near the station, while Gallery OXP places the Witchpoint Exhibition at the main space station!

Carriers OXP needs to be reworked a bit. I left the carrier ships at original size without rescaling so they would still be able to carry Anacondas. This though means that currently carrying ships that have been shrunk looks all wrong, where the models do no even contact the carrier itself!

With all but the biggest ships so much smaller, since it's proportional to volume, the mass falls at a ^3 to the rescaling factor. This highlights the need IMHO to vary the density of various ships to allow certain classes to conceivably carry the standard and upgrade equipment they need. For example, heavy fighters, particularly those with man energy banks would be expected to be heavy, with a higher density than say a transport shuttle or indeed a light fighter. Without this the various OXPs that attempt to balance the game according to ship mass and class (including ShipVersion and ShipConfiguration) will be quite unfair. I'm considering adding a density entry where it makes sense to me in the shipdata-overrides.plist.

Outside of OXPs I think there needs to be a modification to the Docking Computers code, it gets quite confused and mostly ends up going backwards and forwards!

I don't think a heuristic approach to scaling models at load time is workable since it really does need to be considered on a ship by ship basis, taking into account the apparent intention of the ship designer with respect to human scale texture details port holes/windows/hatches etc, "official dimensions" with imported ships such as the Star Destroyer above, or other clues that couldn't be captured by an automated approach.

I wonder if it wouldn't be worthwhilie to either make the Rescaling Experiment version have an incompatible version number or better yet have compatibility flags of some kind, so only supported OXPs which know about the Rescaling Experiment load (perhaps with a whitelist for ships etc) and a flag that can be tested by OXP scripts to determine whether they should use different values.

I'll tidy up the shipdata-overrides.plist and put the OXP up on my github for anybody who wants to try it, and/or add any ships I've missed or scaled inappropriately. I'm not sure what to do with my modified OXPs, I'm concerned about violating the license clauses some authors have used regarding compatibility and derivative works, perhaps it's okay to put them up too if they're clearly indicated, I don't know.

This project is yet another time quite impressive in what work it generates !

Bravo!

Is there any chance this can be added to the all-new 1.86 release? I'd love to keep all the new changes... plus the Rescaling thing - that would be the bomb