Oolite Bulletins

The only actual difference between a main station and a non-main station is that you can actually save at a main station - (hmm, unless you go through save anywhere).

Within the code, there's no way of creating more than 1 main station, unless there's some major alteration to the codebase. That's already enough to 'close the door' on that possibility.
Starting with a clear, simple to understand codebase makes things simpler for any future expansion. At the moment the actual reasons for the present behaviour are a bit obscure, and IMO it's a good thing we're talking about that.

As an example, docking computers used to work in a different way depending on whether the player wanted to dock with the main station or a secondary station. Without micha taking an interest and deciding to clean up that behaviour, we'd still have the somewhat dubious pleasure of separate C & D keys for docking. Anything that makes people think 'wait, that doesn't make sense' is pretty much a legitimate concern for any developer, sometimes for 2 or more developers at once!

In any case, I'd like to remind you guys:

1) the codebase is big! If one of the devs has taken the time to look at how one part of it works, and while doing so spots a problem/inconsistency, it kind of makes sense if that same developer acts upon it before the recently acquired in-depth knowledge gets pushed out of the brain by other Oolite stuff and/or RL...

2) This whole thread is a consequence of cim kindly taking it upon himself to try and provide things people have requested to be enhanced.
I believe there's a saying: 'no good deed goes unpunished', and somethimes it looks like there is some truth in that...

I don't recall how to do docking computers with secondary stations as of v1.76
Does that change in any way when that secondary station has become the main station due to the original main station being destroyed by a script?

Chasing a dredger as the replacement main station would be nuts.
Is there even code to prevent hostile stations/carriers from becoming the main station?
Such as a nearby Thargoid carrier destroying the main station...would it become the next main station if no other stations/carriers are in-system?

Err, the point I was trying to illustrate is that there's no difference whatsoever in docking as of v1.76, thanks to micha's work.


The difference did indeed exist in previous stable releases (ie 1.65 and before), and in a lot of test releases up until fairly recently.


And both questions about 'replacement main stations' are very much valid... before your question, I didn't even think about the possibility of an OXP causing a thargoid carrier to destroy the only non-thargoid station in a system. Unless other devs already thought of that possibility, I very strongly suspect there's nothing to stop one of them from becoming the new 'save station'..

Switeck wrote:

Is there even code to prevent hostile stations/carriers from becoming the main station?
Such as a nearby Thargoid carrier destroying the main station...would it become the next main station if no other stations/carriers are in-system?

Oh, is that why the Thargoids built the Thargoid Carrier? How very clever of them. That's just the sort of evil thinking humans apply: find an exception and exploit it.

SandJ wrote:

Switeck wrote:

Is there even code to prevent hostile stations/carriers from becoming the main station?
Such as a nearby Thargoid carrier destroying the main station...would it become the next main station if no other stations/carriers are in-system?

Oh, is that why the Thargoids built the Thargoid Carrier?

Yes, of course!

And to answer Switeck's question: there is no code to prevent anything from becoming the main station. I once had accidentally the isCarrier-flag assigned to a ship that didn't even have a docking bay (c&p-error). On removing the main station this ordinary ship became the replacement main station.

One reason more to do away with the replacing completely.

Kaks wrote:

The only actual difference between a main station and a non-main station is that you can actually save at a main station - (hmm, unless you go through save anywhere).

There are a few others, too, I think:
- export penalty checks are only applied at the main station
- non-main stations will give docking clearance to Fugitives
- cargo/passenger contracts are only fulfilled at the main station
- cargo/passenger contracts can only be picked up at the main station
- lots of OXP mission screens only run at the main station
- can you buy new ships outside the main station?
- some AIs (core and OXP) use the main station as a waypoint.
- probably some OXPs which use system.mainStation or station.isMainStation in various ways unconnected to the above.

Having a (non-nova) system be without an intentional main station long-term would be very messy in the current set-up, I think. That it's currently possible to do that anyway by messing with planetinfo data doesn't mean it's particularly well supported. Perhaps we should be looking at ways to do away with some of those dependencies - a "has_contract_market" flag in shipdata, for instance? - so that OXP writers can destroy the main station without breaking all sorts of things.

Given that short-term replacement of the main station is neither guaranteed to work nor do anything remotely sensible if it does "work" as things stand, it does make sense to stop doing it, I think.

Switeck wrote:

Such as a nearby Thargoid carrier destroying the main station...would it become the next main station if no other stations/carriers are in-system?

Worse, given that it's probably relatively close to the main station it just destroyed, it has pretty high odds of becoming the main station even if there are other dockables in the system. (Wasn't "Thargoid-infiltrated main station" the plot of one of the built-in missions in one of the original Elites?)

cim wrote:

Switeck wrote:

Such as a nearby Thargoid carrier destroying the main station...would it become the next main station if no other stations/carriers are in-system?

Worse, given that it's probably relatively close to the main station it just destroyed, it has pretty high odds of becoming the main station even if there are other dockables in the system. (Wasn't "Thargoid-infiltrated main station" the plot of one of the built-in missions in one of the original Elites?)

Before everybody gets worked-up too much about Thargoid Carriers destroying main stations, I'd like to point out two things:

1. No Thargoid Carrier (or its plasma accelerators) can ever destroy a main station, because main stations are indestructible by any kind of weapon. They'd need to be explicitly removed or destroyed by script, and the Thargoid Carrier script very clearly and deliberately doesn't do that.
2. There is a reason why Thargoid Carriers are explicitly programed to only attack the secondary station that is farthest away from the main station, and the plasma accelerators are forced to keep on track against their original target, and not go astray against the main station. Because main stations cannot be destroyed by the attack anyway, it would look silly if they got attacked and vent plasma forever, that's why precautions are taken in the OXP to prevent this from happening as much as possible. And if the player commits himself to the cause, the fight won't get close enough to the main station.

The guy who wrote the Thargoid Carrier script has actually invested some thoughts into what he was doing before and while he was doing it. Just sayin'.

cim wrote:

Given that short-term replacement of the main station is neither guaranteed to work nor do anything remotely sensible if it does "work" as things stand...

Says who? How is it "not guaranteed to work"? How can it do something "not remotely sensible"? Why are people suddenly so concerned about an obscure part of the game most script writers never use and most players never experience?

Ok, there's more than just 1 difference between main & secondary stations, though quite a few of them can be worked around via scripts, like in save anywhere!

Even more reasons for sorting out that part of the code!

Before I forget, and while I'm on the subject of sorting stuff out, making stations market prices available during flight is against an essential Galcop law, so please do not expect any changes in that direction...

Wildeblood, the reason most script writers never use it & most players never experience this part of the game, and the reason it's fairly obscure, is exactly because it - not being that sensible to begin with - hasn't got much in the way of scripting possibilities.

As another example, before I added that possibility (in 1.71 or 1.72, can't quite remember when... ) people could create additional planets & moons, with their own textures, however, the main planet couldn't be assigned any alternative texture. Amazingly there were already a few oxps where hex pattern main planets (this was also before detailed planets was a game option) would be shown next to fully detailed moons, which at the time struck me as odd.

Weirdly enough, I don't think anybody at the time had requested a mainPlanet.setTexture() function - that was the way it was first implemented - but almost the second it became available Capt. Kev (with a bit of help from myself) developed Planet Redux to exploit that very function.

Edit: basically, the idea behind them examples is: taking the trouble of fixing stuff, even when it's considered good enough already, tends to add a bit more depth to the game, making it more fun in the long run...

Kaks wrote:

Edit: basically, the idea behind them examples is: taking the trouble of fixing stuff, even when it's considered good enough already, tends to add a bit more depth to the game, making it more fun in the long run...

You and cim have repeatedly referred to "fixing" things, but that's not what you're proposing to do. You're proposing to remove a working function from the game, just because... why? The comparison with adding the planet texturing ability is nonsensical because it's the exact opposite of the situation here. In fact, planet texturing proves my case. It's several years since you gave Oolite the ability to do this with high-quality cube-mapped textures, but it's only in the last few weeks that players have seen the benefit, thanks to submersible's efforts. Where would we be if, in the meantime, you guys had said, "Well, no one is using this planet texturing function properly, so we're taking it out again"?

Kaks wrote:

Wildeblood, the reason most script writers never use it & most players never experience this part of the game, and the reason it's fairly obscure, is exactly because it - not being that sensible to begin with - hasn't got much in the way of scripting possibilities.

I can only repeat: says who? Who are these omniscient persons who can already see all the possibilities? (Not to flog a dead horse, but are they the same people who rule out a multi-shift gal-drive because it would introduce too many possibilities that they couldn't control?)

@Wildeblood: Eh? Dear, oh dear, oh dear!

Ok, history lesson mode:

The ability of using cube maps was an indirect result of me adding the ability to texturise main planets, but was introduced by Ahruman some time after that.
The ability to retexture planets has been used by a few oxps at least ever since 1.72. (you might want to look at the oxp list to reassure yourself that it's indeed the case). Unfortunately we had some scripting changes in the meantime, but - hard to believe, I know - we've always tried to keep disruptions to existing OXPs to a minimum.

On a different subject, and the only vaguely recognisable fact in your post: submersible is the person that started the ball rolling again on shader enabled planets some time after 1.76 was released. We suspended development on those in order to deliver the MNSR within some reasonable time. As it were, reasonable got 'kind of streched' to 'about 2 years'.


And since you asked: no-one can see all possibilities, or even most. Some of us are content with seeing some possibilities some of the time. While with OXPs we do have what some people might consider a pretty flexible structure, there are some boundaries between 'generic space game' and 'Oolite'. Unfortunately you did bump against one of those boundaries.


And now, a bit of applied psychology: are you by any chance working away at some top-ultra-secret oxp that relies on the flawed way stations and/or carriers get 'promoted' to main station at the moment? Is this the reason why you sound so upset about this?

If that's the case, you might as well say that, instead of beating about the bush. If not, all I can say is 'good trolling'!
Mind you, trolling is never the answer!



Anyway, I believe the topic was something along the following lines:

'Promoting' stations, as it happens at the moment, is flawed. We're trying to figure out what would work better.
Any constructive contribution on how to improve the situation, including new scripting possibilities?

@McLane: Hmmm, " the guy ", " just sayin' "... I wonder who he's referring to...

Kaks wrote:

Anyway, I believe the topic was something along the following lines:

'Promoting' stations, as it happens at the moment, is flawed. We're trying to figure out what would work better.
Any constructive contribution on how to improve the situation, including new scripting possibilities?

As a player, I don't care for an elegant, clever solution. I want a plausible one. I don't expect main space stations to be blown up as a matter of course, so if the ship's navigation system says anything helpful, that's pretty good. "EMERGENCY: Main station location beacon missing! The next nearest docking beacon highlighted instead" is a very acceptable solution. It should then be down to the player to think:

"Oh, something odd has happened. I wonder why the main station beacon isn't working" and then go and have a look. If there is loads of laser fire and huge alien space ships floating about, I would expect the pilot to work it out for themselves. However, if everything looks normal, I would expect them to request docking clearance to see what the outcome is:

"Sorry Commander, some Jameson crashed into the beacon, come on in" or
"Sorry Commander, we're having a minor crisis. Come back later" or
"All you base are belong to us. Play music on your pencils, dog-swimmer!" or
<a suspicious silence>

and then make a decision.

If the main station isn't there, again I would expect the pilot to work that out for themselves that something unusual has happened.

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.

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.

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.

Kaks wrote:

@Wildeblood: Eh? Dear, oh dear, oh dear!

Ok, history lesson mode:

The ability of using cube maps was an indirect result of me adding the ability to texturise main planets, but was introduced by Ahruman some time after that.
The ability to retexture planets has been used by a few oxps at least ever since 1.72. (you might want to look at the oxp list to reassure yourself that it's indeed the case).

Thanks for the unnecessary "history lesson". I've tried the old texture packs, and I stand by what I wrote: until submersible came along with Povray Planets, planet texturing looked like a lost cause.

SandJ wrote:

As a player, I don't care for an elegant, clever solution. I want a plausible one. I don't expect main space stations to be blown up as a matter of course, so if the ship's navigation system says anything helpful, that's pretty good. "EMERGENCY: Main station location beacon missing! The next nearest docking beacon highlighted instead" is a very acceptable solution. It should then be down to the player to think:

"Oh, something odd has happened. I wonder why the main station beacon isn't working" and then go and have a look. If there is loads of laser fire and huge alien space ships floating about, I would expect the pilot to work it out for themselves. However, if everything looks normal, I would expect them to request docking clearance to see what the outcome is:

"Sorry Commander, some Jameson crashed into the beacon, come on in" or
"Sorry Commander, we're having a minor crisis. Come back later" or
"All you base are belong to us. Play music on your pencils, dog-swimmer!" or
<a suspicious silence>

Actually this has worked this way already for the past years. With the only difference the signal didn't went to the pilots, but directly to the headquarters of the Galactic Repair Service (GRS) and they signaled the nearest buoy repair facility to deliver a new buoy.

I doubt if any normal player ever has seen that another station became the main station so this seems more an academic problem to me. For scripters that use the console that is differently. I assume most of us have at least once typed in the console: system.mainStation.explode()

I have even a macro: :kill that explodes my current target. .... Did I say: “I never cheat” ?? That was a lie than.

Ok Wildeblood, have fun with the trolling!