[Release] Waypoint Here OXP

[Neelix]

==Overview==
Want to be able to find your way back to a specific location within a system without leaving behind an expensive piece of equipment that uses up a valuable missile pylon and could be damaged or scooped before you get back? The latest advances in HUD technology allow Talaxian Enterprises to offer a solution.

Waypoint here is a software upgrade for your Advanced Space Compass. It allows you to set up to five waypoints, anywhere in the system. If your HUD is configured to display waypoints these will be visible on-screen, with a range indicator.

==Usage==
To use Waypoint Here functions, you'll need to first prime it with 'Shift-N'.

To add a waypoint at your current location, press 'n'. Your position and orientation will be recorded and one of 5 ASC beacons will be assigned.

To clear a waypoint, select the waypoint you want to remove on the ASC and press 'b'.

==Details==
* Tech Level: 10
* Price 2500Cr

There are 5 available beacons, called Alpha, Bravo, Charlie, Delta and Echo. When you add a new waypoint through Waypoint Here the first available beacon will be used. The symbol on the ASC will be the first letter of the beacon name.

As with other methods of marking a specific locations the waypoints are cleared when you leave the system.
Waypoints are not currently saved, so if you save and reload the game any Waypoint Here waypoints you had set will be lost.

Being a software upgrade Waypoint Here can not itself take damage in combat. It will however stop working if the ASC is damaged.

If the waypoints do not show up on your screen you may need to adjust your HUD settings to include a drawWaypoints dial or switch to a HUD that already includes it. This dial was introduced in Oolite version 1.79 so older HUDs probably won't include it unless they have been recently updated.

==Requirements==
* This OXP needs Oolite v1.80.

==Licence/Author==

This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/4.0/.

OXP by Neelix

==Version History==
0.1 Initial Release


Available through the Expansion Pack Manager or from the Wiki: [wiki]Waypoint_Here[/wiki]
Any feedback is welcome.

- Neelix

[Diziet Sma]

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]

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?

Cheers!

Funnily enough both those features are already on my todo list, but I wanted to get the basic functionality down first.
5 systems seems a sensible limit too, I was pondering that...

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.)


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)

- Neelix

[Diziet Sma]

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 set 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]

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..

Ahh, but I was thinking of offering a way to name the waypoints you want to keep. I agree that it would make sense to limit how many waypoints can be saved, but for marking persistent features 5 for the whole galaxy/sector seems a little low.

- Neelix

[Diziet Sma]

Ah.. in that case, go for it.. naming waypoints had crossed my mind, but I thought that might be a bridge too far.

[spara]

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]

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)

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]

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.

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.

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.

*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?

[Zireael]

That's an amazing OXP, will grab it as soon as I have my own computer back.

[Diziet Sma]

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.

A neat solution.

[cim]

*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.

[Neelix]

*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.

That seems obvious in retrospect. Hind-sight as they say...
Cheers!
Now I have more studying to do, to learn how to script the next part.

- Neelix

[spara]

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.

[Neelix]

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.

Interesting idea. Will give that some thought.

Thanks.

- Neelix