Oolite Bulletins

Just wanted to tell you all that I used the wormhole scanner for the first time. Came across a wormhole in front of a station, targeted it, and it turns out that it leads to a system 6.8LY away.

Made two shorter jumps and arrived in the target system hours before the ETA of my scanned wormhole. So I spend the next couple of hours finding out how far away I could get from the sun in order to make it look like one of the background stars (turns out a good three hours of straight J-flight don't yet do the trick ), before I have to turn around and get back to the witchpoint.

I arrive in time to spend the last half hour lurking and watching interesting ships come and go. And then, very much at the ETA, a Dark Wheel Cobra III pops out of a blue sphere. The target inspector shows that it has exactly 0.2LY of fuel in its tanks, so I figure that must be my man!

Blew him up, of course, before he could orientate himself.

Very nice new feature!

(Oh, and the time acceleration came in handy, too.)

Keeping track of the ships that have entered scanned wormholes and making sure that they appear in the system they are travelling to at the correct time was the reason why it took a few months of Micha's time to implement.

Also, you can save your game and exit it, then continue at a later time and all scanned wormholes will still be tracked and your DW Cobra will still appear when you expect it to, if you are already there waiting for it.

So, all that's left now is for you to start working on the first ever Oolite ambush missions pack, that will put the Wormhole Scanner to good use. How about that, eh?

Just like the contract killings in Frontier

another_commander wrote:

So, all that's left now is for you to start working on the first ever Oolite ambush missions pack, that will put the Wormhole Scanner to good use. How about that, eh?

Good idea, although I think there is one necessary feature still missing: The ability to set the destination to an NPC witchjump via script. As it is, NPCs jump randomly into one of the neighbouring systems, therefore there is no guarantee that the player will be able to "overtake" his mark, because there may be no system in-between.

That's one of the reasons why I requested more JS-control over the whole witchjump-business some time ago. That would start with a JS-method that returns all systems in reach, and also require a method that could transfer a specific system to the NPC's AI, and of course a modified performHyperspaceExit in the AI itself. Alternatively a JS-method that circumvents the AI and performs a jump to a given system directly in the script.

Oh, and by the way: an ambush mission could always be scripted, and doesn't need the wormhole scanner anyway. Just send the player to a target system, and create his mark with an ordinary addShip after a while. (Of course, using the wormhole scanner gives a nice touch to it. )

I must say I did not expect anybody to actually try to ambush any wormholed ships... at least I guess this validates all the 'extra' work

When I started it I just wanted a way to save fuel...

PS. *g* 'months of Micha's time' thanks for the kind words, but, well, to be honest, most of that was trying to get to grips with debugging Obj-C and fixing that 'one' crash bug. Actual real implementation work was in the order of days, perhaps a week or so at most.

I propose an experiment.
Some NPCs carry more than 7.0LY of fuel, so the experiment is to see how far those overfuelled ships can jump.

Jump limits are supposed to be hardcoded at 7LY, and for the player ship that's certainly true. But if NPCs break that limit, then the scanner could expose a potential bug.

Cmdr Wyvern wrote:

I propose an experiment.
Some NPCs carry more than 7.0LY of fuel, so the experiment is to see how far those overfuelled ships can jump.

Jump limits are supposed to be hardcoded at 7LY, and for the player ship that's certainly true. But if NPCs break that limit, then the scanner could expose a potential bug.

I believe you will find that there is no bug there. The code specifically checks for nearby systems that are less than or equal to 7.0LY distant from the current ship position, independently of the fuel being carried. If no such systems are found, the AI receives a "WITCHSPACE_UNAVAILABLE" message and reacts according to that.

Commander McLane wrote:

another_commander wrote:

So, all that's left now is for you to start working on the first ever Oolite ambush missions pack, that will put the Wormhole Scanner to good use. How about that, eh?

Good idea, although I think there is one necessary feature still missing: The ability to set the destination to an NPC witchjump via script. As it is, NPCs jump randomly into one of the neighbouring systems, therefore there is no guarantee that the player will be able to "overtake" his mark, because there may be no system in-between.

That's one of the reasons why I requested more JS-control over the whole witchjump-business some time ago. That would start with a JS-method that returns all systems in reach, and also require a method that could transfer a specific system to the NPC's AI, and of course a modified performHyperspaceExit in the AI itself. Alternatively a JS-method that circumvents the AI and performs a jump to a given system directly in the script.

Oh, and by the way: an ambush mission could always be scripted, and doesn't need the wormhole scanner anyway. Just send the player to a target system, and create his mark with an ordinary addShip after a while. (Of course, using the wormhole scanner gives a nice touch to it. )

I second that it is just the feature i was looking for in my next mission oxp. At the moment if you want the player to follow a target through their wormhole you can't specify the system computer ship is witching to.

The target inspector shows that it has exactly 0.2LY of fuel in its tanks, so I figure that must be my man!

What's this target inspector?

wackyman465 wrote:

The target inspector shows that it has exactly 0.2LY of fuel in its tanks, so I figure that must be my man!

What's this target inspector?

The inspector is a development tool for examining ships during play. Its part of Debug.oxp but only available on the mac.

hmmm is this debug.oxp available on the wiki my friend?

Commander McLane wrote:

I spend the next couple of hours finding out how far away I could get from the sun in order to make it look like one of the background stars

inadvertently I set the speed of a ship to 8350 instead of 350

the vessel exploded on launch: it took a while to work out why!! but eventually I removed the "8" and all was well

but then I wondered what is the upper limit????????? so am experimenting with a kestrel, and have got up to 7500 (7.5C) which generates some appropriate relativistic effects, doesn't explode on launch, and renders suns into semi distant stars quite quickly, I imagine. I've been testing the speed of this ship flying between a couple of gas giants, which come up on the screen like suns during skimming for fuel -- but this speed is completely useless for actual game play, of course. It is possible that when the sun becomes too distant it simply goes out, like a distant station..

later edit: yes, sun goes out (gas giants still visible on my moniter)