Oolite Bulletins

Yep, no problems at all in 1.76 with the spooky station scenarios. All nice and doable already, and not subject to change in the foreseeable future!

However:

SandJ wrote:

Just as today, if I'm driving down the motorway and the motorway services are closed by fire / power cut / strike / a crash on the sliproad / whatever I would NOT expect my in-car GPS to determine it's because that Granada Services has gone into administration AND that the next services don't do the coffee I like AND that I should instead go up the M666 for a Cooffee-U-Like. All I expect is to be told of any alternative and leave it to the superior intellect - the human - to handle exceptions. The Compass is an aid.

Yep! In 1.76 the compass does exactly what you don't expect, though... ( and badly: it shows you roughly the way to the Cooffee-U-Like from close to where the services used to be, but the closer you get to the C-U-L the less chance you have to find the d*mned place - actually, this bit is pretty close to real life! )

If it is such a regular occurrence for main space stations go Poof! and disappear, then the Ooniverse has a bigger worry than what shape the beacon's icon is.

Agreed!

As a player, if the main station is missing, I expect it to be a VERY odd occurrence and for weird stuff to happen, not for everything to handle it like an everyday occurrence as that would be very odd.

Also agreed! However, in 1.76, we immediately get the newly 'promoted' hoopy casino/thargoid carrier/mega-pirate/whatever offering all the services available at the main station with 0 apparent disruption, while at the same time carrying on with its previous script - carrying on as if nothing at all had happened, which kind of doubly ignores disruption, in a disruptive way!



The quickest solution to 'cure' the compass & behavioural anomalies would be to stop 'promoting' stations, as McLane mentioned a few times already. Explosive main stations being such an exceptional occurrence, it shouldn't really inconvenience anybody much, and would underscore how exceptional the thing is.

We're not in a hurry to make that decision, though, and I'm hoping there's a couple of other options that can be explored before a decision is made!

In this instance I'm actually going to have to agree with Wildeblood here. Since the main station just doesn't go poof then it stands to reason that an oxp would be behind it, and if it were then it stands to reason that the result of the station going poof would be tested before the oxp was released.

If someday I wanted to create a giant floating city station a few thousand units over a tech 15 planet and get rid of the main station and have the floating city station be the main station, well then how would I do it? From what I understand it can be done today. What is being proposed would eliminate that possibility, correct?

Stop fixing things that aren't broken. This is just an attempt to plug a loophole that an oxp could exploit that someone doesn't like. Why? It's just an oxp and doesn't affect the core game anyway now does it?

What's the real agenda here? Shouldn't the developers first focus be how to make the core game better followed by acting on requests for ways to increase oxp capability?

And while on the subject of Wildeblood having some secret oxp in the works, what if he does? Perhaps forget about that for a second and think that maybe there might be dozens of people with private builds(oxps) that have a slightly different ooniverse using this loophole. Maybe a few years from now some of them might be available as a universe changing oxp that we can try out and it took that long for all the bugs and balance to be worked out. There's something for you to think about.

And please leave the main station's navigation beacon alone. The triangle is fine. I don't want a diamond! I really like the triangle!!!

CommonSenseOTB wrote:

In this instance I'm actually going to have to agree with Wildeblood here. Since the main station just doesn't go poof then it stands to reason that an oxp would be behind it, and if it were then it stands to reason that the result of the station going poof would be tested before the oxp was released.

Well, the OXPs (and native mission) that I know of that get rid of the main station also get rid of every other dockable in the system. "Promotion" of other stations seems to be an inconvenience to them. So automatic unavoidable promotion of an arbitrary station does not appear to be what everyone wants.

Obviously there are other applications - which may be taking shape in private, or just floating round in people's heads, as you say - where promotion of a station is correct. So the ideal would be to find something that works for both cases.

CommonSenseOTB wrote:

If someday I wanted to create a giant floating city station a few thousand units over a tech 15 planet and get rid of the main station and have the floating city station be the main station, well then how would I do it? From what I understand it can be done today. What is being proposed would eliminate that possibility, correct?

No, not at all. The easiest way to do that now is to set the main station role in system.info (either by script or by planetinfo.plist, the latter being the more robust approach if you can do it that way) to be the giant city station (and then move it to the correct location in your this.startUp/this.shipWillExitWitchspace, if you want it in lower orbit than standard). Then you don't have an "original" main station to remove in the first place, which is much simpler. This would be unchanged if auto-promotion was stopped.

Doing it by removing the existing main station would work, just about, unless something else with isCarrier happened to be closer to the planet at the time, which depends on factors beyond your control. Of course, you could just do until your station finally won, but that wouldn't be friendly to other OXPs, especially if your replacement was something designed to be a long way from the planet (even in your example with the station really close to the planet, what happens if someone uses SaveAnywhere while docked at a PlanetFall station?)

If you were looking to write an OXP where "main station" status was visibly handed-over while the player was about...
"Urgent notice to all pilots! Diso Coriolis 1 has been overrun by trumbles. Do not dock there! Inbound traffic, please divert to Diso Coriolis 3"
... then the current scripting situation doesn't really support that either - you'd have to remove main stations in sequence until Coriolis 3 got main station status, and then put most of the ones you'd removed back again. Depending on what internal scripting those stations had, that might again not work well with other OXPs, would certainly mess up any nearby AIs trying to dock when you did the remove+replace, would mysteriously auto-launch the player if they were docked with one at the time, and probably some other stuff I've forgotten...

So in that case I'd be expecting to see a request for a system.setMainStation(station) function, or similar, to let the promotion be under the OXPer's full control - and perhaps delayed - rather than the engine doing it instantly to its own favourite station. (Someone who really liked the current way of doing things could of course call that function on the station that Oolite currently would pick anyway, when they remove the old main station)

We could then have a discussion over whether you should be allowed to call that function if there already was a main station. I can see a case for either position, there - one of my idea-stage OXPs would say "yes", but I think "no" is neater in other respects and makes behaviour more predictable for OXPs which don't go around changing main stations (i.e. most of them). "no" of course implies disabling auto-promotion, which might be another argument for/against it.

Actually, having wrote that as an example, would that be a way forward that works for both sides? Disable auto-promotion, but let OXP writers optionally choose a station to be promoted when they remove the old one?

CommonSenseOTB wrote:

What's the real agenda here?

For me? Chat about how main stations work, now that the topic's come up, and see if there's a better way of doing things than the current approach. I have no particular opinion on how it should work in future - the current approach doesn't seem entirely satisfactory in some areas but nor is there anything that obviously needs urgent change. It doesn't particularly interfere with the things I'm actually working on in the code (mostly scripting requests from various sources, at the moment).

cim wrote:

So in that case I'd be expecting to see a request for a system.setMainStation(station) function...

Oddly enough, that is exactly what I am here to suggest.

cim wrote:

We could then have a discussion over whether you should be allowed to call that function if there already was a main station.

The answer is yes. If the answer were no, it would just force script writers to explode stations unnecessarily. No need for any more discussion.

Hi! For my part, I do find the concept: "don't fix it, don't fix it, you must have a hidden agenda for wanting to fix bugs!" frankly baffling.
Gentlepeople, it does not compute!


@Wildeblood: There you go, was it so difficult?


Good, system.setMainStation(myStation) would remove the 'need' to automatically promote another in-system station. Mind you:

- we'll still need to fix the compass behaviour so that a main station set some distance away from the planet doesn't cause compass problems.
- since a huge amount of code is based on the concept of there being at most 1 main station, setting a new mainStation will have to 'demote' the previous one.


Last but not least: the nav beacon shape on the compass: so far we've had some people saying "please change the triangle, it's confusing", a few saying "naah, it's not really confusing", and one person saying "leave that triangle alone!". Sounds like it's time for a poll!

Kaks wrote:

Sounds like it's time for a poll!

Yay! I like a good poll!

Your wish is my command! Can't guarantee the goodness of the poll, though!

It's an option for the future, but keeping track of which station is the main station for which entity I reckon is going to require a lot of code auditing... something for 1.79/1.80 perhaps!

cim wrote:

We could then have a discussion over whether you should be allowed to call that function if there already was a main station.

The answer is yes. If the answer were no, it would just force script writers to explode stations unnecessarily. No need for any more discussion.[/quote]
True. I was missing the obvious there...

Okay, now for the complications in implementing it caused by the current special properties of main stations. (These are all problems right now, but if it's an obscure event that no-one ever sees they can mostly be ignored, whereas they probably do need some sort of fixing if setMainStation is actually a supported activity)
Some of these could probably be less urgent to address if setMainStation could only be called if the player wasn't docked at either the old or new main station.

- save games only at main station
Mostly these are for the OXPer to work around to make sure that the main station is changed again (by system.info or by scripting) after the save game is reloaded, and that the player ends up inside it. Well, it might be better to remove this restriction so that the player can save anywhere without needing Save Anywhere, but that is not at all straightforward, and mostly a separate problem.

- export penalty checks are only applied at the main station
Trivial to work-around with OXPs, unless you wanted the new main station not to apply those checks, in which case still possible but potentially messy. Perhaps this could be solved by making "apply_export_penalties" or similar a shipdata property, and setting it on the core game's stations?* That would be more flexible for many things, and it could default to false.

- non-main stations will give docking clearance to Fugitives
Will look a bit silly if you give a pirate cove main station status, but otherwise probably harmless. Better handling of docks and docking has been requested elsewhere anyway, so it's not really a "main station" issue as such.

- cargo/passenger contracts are only fulfilled at the main station
- lots of OXP mission screens only run at the main station
Fine, just dock at the new one. Everything then just works, I think.

- buy new ships only at main station
- cargo/passenger contracts can only be picked up at the main station
I can see there being a real mess if setMainStation is called while the player is on the F8 F8 or the F3 F3 screen, especially with the GUI code being as arcane as it is... Nicest solution might be to allow cargo/passenger contracts/ships to be picked up at other stations designated through shipdata.plist*, and check that instead.

- F8 screen in flight shows main station market
Probably okay. Presumably the goods should stay where they are, rather than teleport to the new main station, which I think will require some minor internal tweaks before system.setMainStation can be written, but should be fine in general.

- some AIs (core and OXP) use the main station as a waypoint.
...and some of them mean it, and some of them really mean "a station near the planet". Should be safe to unpick which is which, though it might be a bit of work for OXPers, and might need some extra AI commands.

- COMPASS_TARGET_STATION expects the main station to be near the planet
Wait, we've been here before... Making it visible from anywhere in the system is the "easy" fix, but looks a bit odd with the N beacon if people haven't been messing with the main stations. If we're making it easy to non-destructively cycle main stations, we can't just say "Well, it's a calamity, and the compass being odd is probably the least of your worries right now", which is the current state of the code. Possibly it could be changed to show COMPASS_TARGET_STATION if you're no more than X% further away from the planet than the main station is? That matches current behaviour in a default system, at least once I've looked up 'X', and does something reasonably sensible with other main station locations. (Perhaps have the current distance of 3 planetary radii as a minimum, too, for ones closer to the planet than normal)

- Other stuff I haven't thought of that's tied to the main station
This is probably going to be a problem...

* Of course, changing properties in shipdata.plist causes problems with shipset OXPs which will redefine the entity back to what it was before, at least until they're updated. Is it worth doing this if - for instance - it subtly breaks the DeepSpace Ships OXP? Probably can be worked around so it's compatible both ways, but that needs to be done carefully.

Kaks wrote:

- since a huge amount of code is based on the concept of there being at most 1 main station, setting a new mainStation will have to 'demote' the previous one.

Yep. On the other hand, looking at the above list, at least some of the things that are currently attached to the main station probably shouldn't be anyway. Being able to reassign the main station in a sensible (and supported) way is good, not having to reassign it just to get a contract market at the constore is also good.

Kaks wrote:

Sounds like it's time for a poll!

Great! Diamond is in the current nightly builds for testing; have a look and decide you hate/love it after all...

Thargoid wrote:

Just to throw another "idea" onto the table.

That one's been on my list of "vaguely thought-out but not started" OXPs ever since your Kiota stations were released. I think it's possible entirely in OXP code in 1.76... [/optimist]

Kaks wrote:

- we'll still need to fix the compass behaviour so that a main station set some distance away from the planet doesn't cause compass problems.

That will be the least of our problems. When the main station has be moved, the player knows there has been a major catastrophe in the system. And the player can adapt.

But think about all the traders with pre-programed navigation computers. They still will be flying witchpointEntry -> planet -> mainStation, even when the main station is not near the planet.

And vipers will still be patrolling the old route. When traders head to the new station position they will not be protected. Lucky enough, pirates will also not know about this change.

Or, what about a script that populates the route witchpointEntry -> mainStation.

The slightly odd ACS behaviour will be the least of the trouble.

Thargoid wrote:

Just to throw another "idea" onto the table. As canonically there are supposed to be many "main stations" per system, could something like that be put into the game? Rather than just one Cori (or whatever) per system, have several spaced around the main planet orbit. On arrival into the system each ship gets assigned a main station as a "home port" whilst they are there (ie in code-terms all of the additional stations are just that, additional ones that are not main stations as far as the player ship and equipment is concerned). If that station is destroyed then the nearest of the sister stations takes on the role of the main station.

The only thing that may need to change is what "main station" refers to for NPCs, to spread the load around the station family per system perhaps. It will even have the additional advantage of spreading out the traffic on "route one" a bit wider, making things more realistic.

At first sight this looks like a great idea, however, on second sight I'm not so sure.

My main concern is the necessary increase in entity numbers per system. What about the low-end computer people?

If I understand you correctly you're not only proposing multiple GalCop stations around the planet, but also multiple corridors, thus multiple witchpoint buoys and traffic between each of the witchpoint buoys and one of the GalCop stations. Of course there should be a chance for asteroids to appear on each of the new routes, and Rock Hermits as well. Should there also be Constores potentially at each of the new witchpoints? I'd say yes, why shouldn't they? Each of the new stations would launch shuttles and traders as well, of course.

As a result the total number of entities per system gets multiplied: as a first approximation, if you multiply the number of GalCop stations by four, you can expect to multiply the total number of entities by four. If you want eight GalCop stations around the planet, you'll multiply the total entity number by eight.

Now, the actual end result will be less than eightfold, because in the beginning you also had a certain number of entities between planet and sun, and these won't be multiplied. Still, currently in my game there are usually between 80 and 120 entities in a system when it's created. With a couple of additional GalCop stations this number will easily rise to 500 or more. This will be causing a noticeable drop in frame rate on my computer. It may render Oolite unplayable on older systems. And I don't even know off the top of my head whether there is a hard upper limit for entities per system which we may get dangerously close to.

Also, and just as a side note, having multiple GalCop stations would render the complete concept of "main" stations totally moot. After all, this concept exists for the sole reason that the "realistic" multiple stations would be too much of a burden for the computer and make the game unplayable. If we had multiple GalCop stations orbiting the planet, then of course each of them would be under the same GalCop rules: no docking for fugitives, fines for launching with illegal goods. It would make absolutely no sense to have these rules only applied to a single one of a couple of stations which are meant to be totally equal according to the back story. Perhaps saving the game would still only be possible on one of the stations, but that would be pretty much the only thing that would distinguish it from the others. And if there would be reliably multiple GalCop stations around each planet, even the rationale for the save-at-the-only-reliably-existing-place-only rule would no longer exist, so there would remain only the question of technical viability, as far as the code is concerned.

Thargoid wrote:

No, still one buoy (one witchpoint). The routes would be between it and the stations, so would be close to one another, in effect making the existing route one more "triangular" and becoming broader as you approach the main planet.

There would be the same amount of entities (except for the additional stations), but they would be spread out more widely as you went toward the planet..

In some way this happened in Oolite 1.65. Ships headed to the main planet and when entering the planet aegis, they went to the nearest station. But with added stations this was seen as unwanted behaviour as traders now went to custom stations that were never intended for general docking. e.g. carriers.

Since than they go to the mainStation. Current trunk now holds a command setTargetToRandomStation. When writing that command, carriers and stations that don't allow npc traffic are explicit excluded. That command could be used to randomly select a station when arriving at the planet. Last week I updated the wiki AI page with this command.

Eric Walch wrote:

Current trunk now holds a command setTargetToRandomStation. When writing that command, carriers and stations that don't allow npc traffic are explicit excluded. That command could be used to randomly select a station when arriving at the planet. Last week I updated the wiki AI page with this command.

Could that not be applied as soon as the main station ceases to exist? So ships en route to the planet would turn around and set course immediately, rather than flying to the planet before turning around and (say) flying all the way back out to a constore or something?

The other issues regarding the temporary absence of a main station would, I think, be best dealt with by not having a backup main station. Players can't save the game in that system (in the absence of Save Anywhere) because the main station has been destroyed. Export checks don't apply in that system, because the main station has been destroyed. Other stations will allow fugitives to dock because everyone's running around like headless chickens, because the main station has been destroyed. There are no cargo/passenger contracts, because the main station has been destroyed. OXP mission screens are temporarily irrelevant, because the main station has been destroyed. Nobody is buying new ships, because the main station has been destroyed. The F8 in-flight screen is still showing main system station prices, but they're irrelevant because the main station has been destroyed. The compass is wonky because the main station has been destroyed.

In short, the main station has been destroyed. The NPCs all start flying off towards any random station (or go sunskimming and witch out, if no stations are available). All other considerations are rendered moot for the time being.

Is that not easier to do, and more "realistic"? Or is there a built-in requirement in the code for all systems to have a designated main station at all times?