Scripting requests

[Wildeblood]

Personally I'd be opposed to making the galactic jump arbitrary. The jump-one-galaxy-forward-only rule seems to me as one of the core rules that define what Elite/Oolite is, similar to the 7LY rule. Changing it would create a different game.

No, Commander McLane, changing it would create the possibility of a different game. That's not the same thing. No-one could force you to participate.

[Kaks]

About arbitrary galaxy jumps, it's been vetoed before, because it would make what's supposed to be exceptional & a one way ticket to the unknown something a lot more commonplace, and - well - mundane, which would incidentally remove the rationale for starting with a clean slate after a galaxy jump.

I'm aware that this Oolite feature does disagree with Criminal Record OXP, nevertheless there are no plans to change the base game in this respect.
Do not despair, however: there are some - as yet unconfirmed - rumours about plans to introduce new OXP galaxies in a distant, distant future version of Oolite. Arbitrary galaxy jumps and/or changes to the way bounty is calculated might be re-evaluated then!

[Cody]

as yet unconfirmed - rumours about plans to introduce new OXP galaxies in a distant, distant future version of Oolite. Arbitrary galaxy jumps and/or changes to the way bounty is calculated might be re-evaluated then!

<looks-up, intrigued... decides not to ask any questions... yet>

[Commander McLane]

Personally I'd be opposed to making the galactic jump arbitrary. The jump-one-galaxy-forward-only rule seems to me as one of the core rules that define what Elite/Oolite is, similar to the 7LY rule. Changing it would create a different game.

No, Commander McLane, changing it would create the possibility of a different game. That's not the same thing. No-one could force you to participate.

In essence that's the same thing. The people who want a different game are free to write one. They are even free to base their different game on every line of code that's in Oolite already. But the game we're discussing (and hopefully improving) here is Oolite. Thus every feature request has to be judged on whether it would improve Oolite, while letting it remain Oolite, and not turn it into something else.

It's also not true that no-one could force me to participate. Of course I would be forced to participate in such a deep change. Because while as a player I have the chance to not install an OXP that would use a different galactic jump layout (insofar there's a grain of truth in your statement), as an OXP scripter I don't have that chance. A deep change to the Oolite engine (and for me changing the galactic jump mechanism is a deep change) would affect my OXPs as well. I have written a mission OXP that relies heavily on the Oolite axiom that intergalactic travel is a one-way-up thing. Changing this axiom would deeply change that OXP, considerably lessening the playing experience. Thus, while my personal game wouldn't necessarily be affected, my work for the comOonity would.

That's why one has to be careful where changes to the Oolite axioms are concerned. Every OXP in existence so far has been created for the existing set of axioms. Changing the set has the potential to invalidate all the work that has been put into the tweaks within the set. And my position is that this shouldn't be done lightly and without careful consideration.

I trust in the development team (of which I am no member) to do these careful considerations. As a player and OXP writer I am voicing my opinion as well, which is in itself of no more value—and no more binding to the development team—than anybody else's opinion. All opinions will be considered by the team, even skeptical opinions.

EDIT: due to RealLife™ circumstances this post is only submitted about one-and-a-half hours after it was written, therefore there is already a statement from the midst of the development team. I'm still submitting my reasoning, even though the answer from the team is already there.

[SandJ]

I've been trying to imagine being able to jump arbitrarily between the 8 galaxies and its impact on the Ooniverse.

The gap between the galaxies would just be an inconvenience and it would strike the player as "you can tell it's an old 8 bit game, they can't handle more than 256 systems at once". The added restriction that the wormholes (or whatever) are one way is somehow necessary to validate and hide the design weakness.

If one can move between them back and forth, visualising the experience suggests either:
a) the 8 galaxies are actually stacked one above the other and the galactic hyperdrive is a vertical movement within the same galaxy;
or
b) the 8 should be placed side by side and mapped as one big galaxy, like in Frontier.

Code: Select all

+------+------+------+------+
|      +      +      +      +
+------+------+------+------+
|      +      +      +      +
+------+------+------+------+

I can't see how you can have jumping about without breaking the galactic hyperdrive and the 8 galaxy concept, unless you add another bit of handwavium. For example, the "any destination galactic hyperdrive" might actually be a "galactic hub diverter". That is, the 8 'wormholes' (or whatever they are) all pass through a central point as they cross and this device allows the pilot to divert from one wormhole path to another, thereby changing to a different destination galaxy. Something like this: image.

But it really would have to be a very rare and expensive and unusual piece of kit rather than a run-of-the-mill device.

And using the galactive hyperdrive to lose ones criminal status would come to an end as it would be viable to chase people to another galaxy and then fly back home for tea, or for GalCop to regularly communicate with other galaxies' criminal record offices.

[cim]

ship.setBeacon(code) is made available in r4840. Using the empty string will clear an existing beacon.

Following a coding suggestion from Kaks, this is now accomplished by the much simpler method of making ship.beaconCode read-write.

[Wildeblood]

------------------------------------------------------------------------
r4855 | cim | 2012-04-15 22:19:23 +0300 | 4 lines

- Take out ship.setBeacon in favour of making ship.beaconCode writable.
- Prevent writing of mainStation beacon.
- Change way that station beacon is handled with ASC - rather than having the compass point at the buoy, just make the main station beacon visible anywhere in the system.

------------------------------------------------------------------------

Which "main station beacon" is this referring to? The N in COMPASS_MODE_BEACONS, or the one in COMPASS_MODE_STATION?

[cim]

Which "main station beacon" is this referring to? The N in COMPASS_MODE_BEACONS, or the one in COMPASS_MODE_STATION?

COMPASS_MODE_STATION: visible on ASC from anywhere in system, not just close to planet
N in COMPASS_MODE_BEACONS: removed from core shipdata (obviously can be re-added by OXPs)

It seemed slightly odd to have two different beacons pointing almost but not quite at the same object, one of which wasn't always visible on the ASC and one of which was...

Because the main station has the uneditable COMPASS_MODE_STATION beacon, editing of its COMPASS_MODE_BEACONS potential beacon is disallowed to avoid the same object having two beacons (less of a problem for the planet or sun, of course)

[Eric Walch]

Which "main station beacon" is this referring to? The N in COMPASS_MODE_BEACONS, or the one in COMPASS_MODE_STATION?

i think something goes wrong. With oxps installed, it still looks okay and i can find the buoy, but when removing all oxps, I can't lock on the buoy anymore. And this buoy is the guide to the dock of the station.

[cim]

Which "main station beacon" is this referring to? The N in COMPASS_MODE_BEACONS, or the one in COMPASS_MODE_STATION?

i think something goes wrong. With oxps installed, it still looks okay and i can find the buoy, but when removing all oxps, I can't lock on the buoy anymore. And this buoy is the guide to the dock of the station.

You should however be able to get the square station beacon from anywhere in the system, which gets you to the same basic vicinity of the station, at which point the docking buoy is visible on the scanner anyway. The N beacon for the buoy itself shouldn't be necessary then (though the change does take a little getting used to, as the station's long-range beacon is now before the sun rather than after it)

[Wildeblood]

Oh, well, it's an excuse for some piccies. Goodbye N beacon...



Hello square beacon...



Now what would be useful is two distinct categories of beacon. Square icons on any stationary beacon, and triangles on moving beacons. (And a multi-shift gal-drive if you've got some spare time, thanks. )

Edit: Or, even better, square icons on moving targets. You can make a cool gun sight with that station beacon , but it's only good for shooting at the station.

[Commander McLane]

Which "main station beacon" is this referring to? The N in COMPASS_MODE_BEACONS, or the one in COMPASS_MODE_STATION?

i think something goes wrong. With oxps installed, it still looks okay and i can find the buoy, but when removing all oxps, I can't lock on the buoy anymore. And this buoy is the guide to the dock of the station.

You should however be able to get the square station beacon from anywhere in the system,

As far as I understand you just removed the 'N' beacon code from the game completely and put a system-wide code on the main station instead. Am I understanding this correctly?

If yes, may I ask why this change was made? Is it the result of a discussion in the development team of which we normal forum denizens are not aware?

It seems like a rather arbitrary change of something which was part of Oolite since station beacons were introduced (which was a long time ago). What are the reasons for this change? Which problem is addressed with it? And why is it that nobody brought up the fact that there was a problem before the change was made?

Or is there something being "fixed" which wasn't broken in the first place?

Also, it doesn't seem clear to me what happens without the advanced compass being installed. Up to now the compass is pointing to the planet until reaching a certain proximity, after which the compass points to the station. Is that still the case after the change? Or will the compass always point to the station and disregard the planet altogether? Here we are dealing with an Elite legacy (which is not the case with an installed advanced compass, because there were no beacons in Elite), which implies that a change (and thereby deviation from Elite) has to pass a higher hurdle of justifying. The advocates of change would have to argue that the situation in Elite was in fact somewhat broken (like in case of the energy bomb), thus justifying a fix. But again, I don't recall any arguing or any discussion at all.

Please excuse this rather inquisitorily looking post, but I'm just puzzled that something gets changed which (in my view) wasn't broken, without bringing up the need for a change before jumping right in and doing it. I sincerely hope that there was a discussion on the developer back channel, if regrettably not on the boards. Because on the face of it it looks a little like the new guy in the team, unaware of the usual procedures, went a little overboard with implementing a personal pet idea, which I feel isn't in the spirit of the comOonity as we have come to know and love it.

[another_commander]

Also, it doesn't seem clear to me what happens without the advanced compass being installed. Up to now the compass is pointing to the planet until reaching a certain proximity, after which the compass points to the station. Is that still the case after the change? Or will the compass always point to the station and disregard the planet altogether? Here we are dealing with an Elite legacy (which is not the case with an installed advanced compass, because there were no beacons in Elite), which implies that a change (and thereby deviation from Elite) has to pass a higher hurdle of justifying. The advocates of change would have to argue that the situation in Elite was in fact somewhat broken (like in case of the energy bomb), thus justifying a fix. But again, I don't recall any arguing or any discussion at all.

Please excuse this rather inquisitorily looking post, but I'm just puzzled that something gets changed which (in my view) wasn't broken, without bringing up the need for a change before jumping right in and doing it. I sincerely hope that there was a discussion on the developer back channel, if regrettably not on the boards. Because on the face of it it looks a little like the new guy in the team, unaware of the usual procedures, went a little overboard with implementing a personal pet idea, which I feel isn't in the spirit of the comOonity as we have come to know and love it.

I just checked and it looks like the standard compass behaviour has not been changed. The only change I perceive is that the "N" beacon is missing when the advanced compass cycles through its modes. I am not sure whether I like the change or not. It seems to be practical and, yes, up to now the compass was essentially pointing at the same point twice when cycling, once for the station and once for its navigation beacon. It seems cleaner to point only once to the station, but I am not sure what effect it may have on existing OXPs that may rely on its current mode of usage (not that I can think of any right now). The way the compass works has been unchanged since at least v1.65 and I have to agree with Commander McLane that it is much preferrable if such gameplay changes be discussed at least internally before being committed. And that is without considering the documentation changes that will have to be applied (see readme and reference sheet) if this is accepted as the way forward. Note, I don't mean to turn the idea down, but I would be interested to hear what the community thinks about it.

Maybe starting a new topic to discuss this would be a good idea?

[cim]

Also, it doesn't seem clear to me what happens without the advanced compass being installed.

No change at all. Points to the planet if you're outside planetary aegis; points to the station inside, just as before. (At least, if it doesn't, that's bad coding rather than intentional changes)

Please excuse this rather inquisitorily looking post, but I'm just puzzled that something gets changed which (in my view) wasn't broken, without bringing up the need for a change before jumping right in and doing it. I sincerely hope that there was a discussion on the developer back channel, if regrettably not on the boards. Because on the face of it it looks a little like the new guy in the team, unaware of the usual procedures, went a little overboard with implementing a personal pet idea, which I feel isn't in the spirit of the comOonity as we have come to know and love it.

The logic behind it was:
- beacon codes are now writable by script.
- but it was then pointed out to me that this makes the long-standing bug where the station and witchpoint buoy codes can be changed even more obvious, so the other bits of the change followed from that discussion.
- so I made the main station's triangle code itself unwritable so it can only have the square code.
- I couldn't think of anything to do to prevent that problem with the witchbuoy since it's just an anonymous ship in game terms.
- This left the nav buoy ... wait, why do we have separate station and nav buoy beacons anyway, one of which shows up system-wide and one of which doesn't? Well, if we just make the station beacon visible system-wide with an ASC, then we don't need to have both of them with beacons, and the nav buoy can simply be a "dock this side" marker.

As "the new guy" I've been trying to stick to the uncontroversial bug fixes and feature requests for precisely that reason, and checking before implementation if I think there might be any controversy, and I apologise for significantly underestimating how controversial this change would be and thus not consulting widely enough on it. I'll start a new topic for it as another_commander suggests, and revert this part of the change when I get home.

[another_commander]

I'll start a new topic for it as another_commander suggests, and revert this part of the change when I get home.

cim, I would say that there is no immediate need to revert the change. Leaving it in for the moment would offer a chance for it to be reviewed by those who use nightly builds for testing and a better idea of what it is about. Plus, it might end up being a fine change after all, so I would keep it for now and only revert if it turns out that it causes problems.