Oolite Bulletins

1. Waypoints saved to game-save
2. Waypoints retained for more than one system - say, the last 5 systems where waypoints were set?

Diziet Sma wrote:

Nice! Very much what I was describing in our discussion about this at the Lion.

Feature requests:

1. Waypoints saved to game-save
2. Waypoints retained for more than one system - say, the last 5 systems where waypoints were set?

Neelix wrote:

That said though, I just had another thought. I can imagine that in many cases you wouldn't care if a waypoint was retained. There are things you might want to mark the position of that would no longer be there after the next system population. In those cases there would be no point in keeping the waypoints anyway. Perhaps however a way to mark specific waypoints to be saved might be the way to go, then keep those saved waypoints until a Galactic HyperDrive is used?
( I have a couple of ideas on how that would be accomplished too.)

Diziet Sma wrote:

Neelix wrote:

That said though, I just had another thought. I can imagine that in many cases you wouldn't care if a waypoint was retained. There are things you might want to mark the position of that would no longer be there after the next system population. In those cases there would be no point in keeping the waypoints anyway. Perhaps however a way to mark specific waypoints to be saved might be the way to go, then keep those saved waypoints until a Galactic HyperDrive is used?
( I have a couple of ideas on how that would be accomplished too.)

I see two sides to that..

The first is that many more objects are now persistent across game-saves than used to be the case, so there is less need for temporary waypoints than before.. the second is that if you're going to keep all the waypoints made until a GalJump is made, you could be looking at up to 1280 waypoints to be saved.

And past a certain point, nobody is gonna remember any more what a given waypoint in a particular system is for.. even 5 systems is probably pushing it..

Neelix wrote:

A technical query: is there any way to access a variable associated with an equipment script from a world script, or would I need to do everything via the world script to begin with, and just use the equipment script to process the triggers? (currently there is no world script in the OXP, and while it wouldn't be difficult to reorganise it I wonder if it's actually needed)

spara wrote:

A great oxp. Try to keep the use as simple as possible. The current add with n and remove with b is very usable. Not sure about naming them, that sounds complicated. Unless you manage to make it simple, of course .

Here's a simple idea for multisystem persistance. Allow max five waypoints per system and a stack of lets say 20 waypoints per galaxy. Keep the waypoints persistent over jumps and when the overall total of 20 waypoints has been reached, remove the oldest one automatically.

cim wrote:

If the world script has a reference to the equipment script, then it can access variables within the equipment script. The only way it can get that reference, though, is for the equipment script to give it to it - there's no list of equipment scripts as there is for world scripts.

I tend to find it's easier - if your equipment needs a world script at all - to put everything into the world script.

Neelix wrote:

I'm thinking that the naming process would be done through the interfaces screen once you get back to a station, and would actually remove the waypoint from the temporary stack. (so in addition to any persistent waypoints set you would also still get the five temporary ones) I see no need to complicate the primary operation of the system while in flight.

Neelix wrote:

*nods* I'll probably end up doing that, but in the interest of my ongoing education in scripting, how would I make and use such a reference?

worldScripts["my-world-script"].$referenceToEquipmentScript = this;

cim wrote:

Neelix wrote:

*nods* I'll probably end up doing that, but in the interest of my ongoing education in scripting, how would I make and use such a reference?

From the equipment script, do

Code: Select all

worldScripts["my-world-script"].$referenceToEquipmentScript = this;

Equipment scripts are processed and executed after world scripts (because sometimes you need the world and condition scripts loaded to determine whether equipment can be fitted at all), so you should be able to put that outside your trigger definitions so it's evaluated on script load rather than when you first activate the equipment.

spara wrote:

Naming interface sounds like a good solution.

Here's another idea to ponder: Could b have two functions? When first pressed on a selected waypoint, it will make that one permanent. The second press will make it disappear. That would neatly handle making permanent waypoints in-flight. BeaconLabel should then contain some hint about persistence.