Oolite Bulletins

There was some discussion a couple of years ago about implementing a witchpace cloud analyzer similar to the one in Fronteer.

The discussion has been removed from the forum, but you can see it in the google cache here http://64.233.183.104/search?q=cache:lx ... =clnk&cd=4

Does anyone know if there is an oxp with this in? I would quite like it, as it adds to the atmosphere of the game.

If you follow a ship through its wormhole then it will be there at the other end. So I guess it would be possible to have a device show the destination (as Oolite "knows" where he has gone), but I think that would have to be hard-coded rather than OXPable.

However, it wouldn't really be that useful in Oolite. In FFE the only way to follow was by making a jump yourself. In Oolite you can just piggyback the ship by flying into its exit cloud.

Yes, it all seems possible, and "Oo" created a patch back in 2004 (or 5, I cant remember which of the posts I was looking at) which did add this to the hud.

The problem is that the code has changed a lot since then, and I dont think it makes sense to try and use the patch.

I was wondering if this had made it into an oxp and had been lost in the mists of time since then.

LittleBear wrote:

If you follow a ship through its wormhole then it will be there at the other end. So I guess it would be possible to have a device show the destination (as Oolite "knows" where he has gone), but I think that would have to be hard-coded rather than OXPable.

However, it wouldn't really be that useful in Oolite. In FFE the only way to follow was by making a jump yourself. In Oolite you can just piggyback the ship by flying into its exit cloud.

I'd like to be able to analyze the clouds for the simple reason that if the wormhole goes where I was headed anyway, it's a free jump at no fuel cost (hey, nothing to be snubbed at when that system is an anarchy at 6.8 LY )

Yeah, I've thought that too... although if it was possible I can see myself ending up like some sort of annoying little dog, sniffing around the rumps of departing ships: "snf snf snf nope, not going my way... snf snf snf nope... snf snf snf nope... snf snf snf aha!" It wouldn't be terribly dignified.

...and could be easily mistaken with a spaceship courtship ritual...

Wouldn't go down too well in some of the most refined systems...

I like the idea, for the same reason. Sometimes I could spare my own fuel if I know that another guys is travelling my way. And as in the entity-dump (P, then 0) all wormholes are listed with their destination (like "wormhole entity to xyz"), the engine definitively already has the relevant information.

But I also guess it would have to be hardcoded.

Commander McLane wrote:

I like the idea, for the same reason. Sometimes I could spare my own fuel if I know that another guys is travelling my way. And as in the entity-dump (P, then 0) all wormholes are listed with their destination (like "wormhole entity to xyz"), the engine definitively already has the relevant information.

But I also guess it would have to be hardcoded.

I suppose that the up side of a piece of equipment like this would be that you could use non-Witchspace capable ships (like the Krait, Mamba or Sidewinder) without recourse to the illicit_unlock.oxp adding a Witchspace drive.

Captain Hesperus

i would like the feel of this, if it could be oxp'ed or hardcoded.

I've hacked away and put together something which works.

It does change targetting a bit though. Currently you can only target ships.

With this code-change, you can also target wormholes. This -may- break OXPs which use the players' primary target and assume that it's always a ship. It certainly required a few more changes to the code than I was expecting to identify all the areas which simply assumed the primary target was a ship. The problem is that Wormholes derive directly from Entity rather than ShipEntity which is what most things you can see on the screen derive from.

Without the new equipment "Wormhole Analyzer" the targetter only shows 'Wormhole' as the ID, with it installed it also shows the Wormholes' destination.

The alternative would be to have a key which, if pressed, analyses the wormhole currently in the cross-hairs and does nothing if there's no wormhole in the cross-hairs.

What do people think? And how expensive should the analyzer be?

The wormhole analyzer is a piece of equipment I would like to see in the game, but there are catches in correctly implementing it.

The issue that has to be addressed is that without a WA the player can know a wormhole's destination only by entering it. At this point the previous universe is destroyed and the new one is generated. So far so good. The main difference with a WA is that if I know the destination of the wormhole and a ship enters it, I already know where said ship goes. So, I would expect to find the exact same ship in the destination system and if I take a "time shortcut" to destination (i.e. making two short jumps instead of a long one), I would expect to arrive at the destination before the ship I am following. As far as I am aware the code atm does not take into account the time required for the trip when it is generating ships that passed the wormhole and just adds the ships at population time when the player has entered the wormhole himself.

If it can be coded in a way that following ships and arriving ahead of them, if needed, can work correctly, then I would not mind at all having the gadget in.

The hyperspace cloud analyzer from FFE was 1575 (reference: http://www.hooplah.com/encounters/equip.htm )

I certainly dont think it should be hundreds of thousands, somewhere around 2000-5000 would seem right to me as far as cost goes.

another_commander wrote:

If it can be coded in a way that following ships and arriving ahead of them, if needed, can work correctly, then I would not mind at all having the gadget in.

We could track all ships entering a scanned wormhole (we only care about the ones that are scanned, I guess), and record them in a log (the save file I guess), together with the destination, and arrival time, then when entering a system, we check for any expected arivals at that system, and start a timer, when the timer expires we create the ship. We additionally remove any references to any systems that have already passed.

Sounds possible, but some work.

Currently, if you enter a wormhole generated by another ship you enter the same system and the system generator puts any ships which were in the wormhole into the system.

So I'm guessing all ships take the same amount of time irrespective of size.

So to implement shortcutting, we would need to maintain a list of wormholes which were scanned by the player (we can safely ignore all others) which does NOT get destroyed when a player jumps out of a system. Then if the player is in, or enters, a system around the end-time of these wormholes they would need to eject the ships which were in them.

If the player enters a system a fair while after a wormhole ends (suitable time interval to be determined) we ignore it as well as we can assume that the ship(s) either got destroyed or moved on to another system in the meantime.

Hmm.. shouldn't be too hard - add the wormhole list to the PlayerEntity.

OTOH, do we really need to get this precise? At the moment other things in the Ooniverse aren't all that 'correct' either - for example the RandomHits - essentially the target ship hangs around in the target system until the player gets there.

Just seems to me that the game will have to do a fair bit of extra processing every frame to check for incoming ships for a situation which will hardly every arise. And I doubt there'd be many situations when a shortcutting player will end up in the target system even close to the ETA of the wormhole-ships.

Cmdr James wrote:

If it can be coded in a way that following ships and arriving ahead of them, if needed, can work correctly, then I would not mind at all having the gadget in.

We could track all ships entering a scanned wormhole [/quote]

*g* same thoughts! I just took too long to write my post..

And I hadn't thought of the requirement to save either..

All up I'd reiterate that it seems an awful lot of work for a situation which I don't think would arise very often.