Page 1 of 1

Hyperspace blocking after countdown

Posted: Sat Sep 20, 2008 9:59 pm
by Micha
Anybody else find this a little bit vexing that the block message only appears after the countdown is finished?

I've made the following trivial hack by copying the following code-block from PlayerEntity.m:peformWitchspaceCountDownUpdates into PlayerEntityControls.m:pollFlightControls at line 954 in order to get the blocked message when I press the Hyperspace key:

Code: Select all

					ShipEntity* blocker = [UNIVERSE entityForUniversalID:[self checkShipsInVicinityForWitchJumpExit]];
					if (blocker)
					{
						[UNIVERSE clearPreviousMessage];
						[UNIVERSE addMessage:[NSString stringWithFormat:DESC(@"witch-blocked-by-@"), [blocker name]] forCount: 4.5];
						[self playWitchjumpBlocked];
						[self doScriptEvent:@"playerJumpFailed" withArgument:@"blocked"];
						jumpOK = NO;
					}

Note that the original code is unchanged as it's possible to start the countdown but then enter a situation during the countdown when the hyperspace could fail.

Thoughts?

Posted: Sat Sep 20, 2008 10:42 pm
by JohnnyBoy
Is the decision to block/allow a witchspace jump based on the position of the ship at the time that 'h' is pressed or does it calculate where the ship will be 15 seconds after 'h' is pressed?

Posted: Sat Sep 20, 2008 11:13 pm
by Micha
It does so at the present position - it's impossible to predict where the ship will be since the player can adjust the velocity during the countdown. One could always optimistically assume that the velocity will remain constant and base the prediction off that since another check is made after the countdown and just before the actual jump anyway - so it will still fail if the player hasn't made it outside the block range due to manouvering.

I realise some people want to time their jump so that they initiate within a block range but are outside the range by the time the countdown finishes.

But I personally prefer it to block if I initiate it within the block range. In fact I'm even considering changing the station block range so that you have to be outside the stations' aegis range. After all, you hyperspace -into- a system at a fair distance away, why do that when you can hyperspace out right next to the station? Might as well make the incoming witchspace point near the station then as well.. or, along the lines I'm thinking, force outgoing traffic further away as well. Perhaps not quite as far as the Witchspace Buoy, but at least a little distance out.

Posted: Mon Sep 29, 2008 9:29 am
by Commander McLane
I am one of those people who are engaging their hyperdrive as soon as possible and just calculate that they will be outside the blocking range when the countdown is finished.

Therefore I would not vote for a change here. I find it good as it is. And the occasional "too close to station"-message after the countdown is just the justified punishment for me being too fast with hitting the H-key. 8)

Posted: Sat Oct 04, 2008 1:48 am
by nijineko
i can see advantages and disadvantages. on the con side, that's one more piece of info to process in the middle of a hectic dogfight. on the plus side, when things are slow, it'd be great to know you're not out of the limit yet.

Posted: Sat Oct 04, 2008 7:25 am
by Micha
You'd only process this if the player actually hits the hyperspace key - and if you're at the stage where you have to hyperspace out of a fight it's probably too late for that anyway (assuming you've even got enough fuel to do so!) And in that event I'd want to know ASAP whether or not I can actually hyperspace!

I'll see about adding in the optimistic prediction of where you're going to be in 15 seconds and basing the hyperspace countdown off that.

I was also thinking of starting up a wiki page sometime with all my personal patches to Oolite (once I clean them up a bit), and people can decide for themselves whether or not they want to put them into their game. Sorta like the OXP page but for code-patches which aren't slated for trunk inclusion.

Posted: Wed Oct 08, 2008 5:19 am
by Dr Beeb
I fired up BBC Classic expecting to take notes on how far away from the station, planet you had to be, what happened if you turned around and headed toward the Space Station etc. and .... nothing.

There appear to be no restrictions when/where you can engage the witchdrive and for it to work. Came as a surprise to me, are others in a position to check? When did a drive-abort enter the game - maybe around the Archimedes version? (Except, of course, you get the 'Docked' message if you hit the H-key while still inside the station :wink: )

This also ties in with a post recently discussing falling into other peoples' wormwholes by mistake when you are coming in for a manual docking in Oolite. I am sure I have also seen Pythons etc in Oolite leave the station and disappear into their wormhole BEFORE they got as far as the navigation beacon; whereas I am usually forced to get at least that far away from the station. If the player has to get a certain distance away, then so should the other ships. :evil:

Introducing the drive abort may sound realistic but should be done to introduce fun, not frustration. ie let ships witch-space whenever they want, but if you go through, say, Dark Wheel's space-traffic control lanes/Babylon 5-like jump gates then maybe there should be a reward, like less game time elapsed re contract runs, or some extra fuel left over for your injectors once you arrive in the new system. :D

Posted: Wed Oct 08, 2008 5:57 am
by Thargoid
Dr Beeb wrote:
This also ties in with a post recently discussing falling into other peoples' wormwholes by mistake when you are coming in for a manual docking in Oolite. I am sure I have also seen Pythons etc in Oolite leave the station and disappear into their wormhole BEFORE they got as far as the navigation beacon; whereas I am usually forced to get at least that far away from the station. If the player has to get a certain distance away, then so should the other ships. :evil:
Happened to me just yesterday. I'm final-testing a new little script, which involves a lot of buzzing around the station aegis plus trips between the docking bay and the buoy.

Launched behind a Cobra variant en-route to the buoy, slowed to a slow approach to "persuade" it out of the flight line, then I get a (quite pretty) blue effect on my screen, my screen freezes for a little while (accompanied by the normal HD thrash) and suddenly I ain't in Kansas any more Toto :roll: And I was no more than half-way from the station when it happened.

All rather annoying, when it was docking I was testing, so had to fly to the station in Leesti (where I ended up) in a literally brand new Jameson. Thank heavens for JS console and awardEquipment to give me fuel injectors :twisted:

PS I can remember that the 'speccy version certainly didn't have mass lock, as there used to be the old trick of setting a jump and then docking. The countdown would end during the tube effect, and you'd end up docked at the station in your destination system. Used to be a handy little cheat for saving time.

Posted: Wed Oct 08, 2008 2:17 pm
by Micha
AFAIK the witchspace-lock is an Oolite feature; certainly never saw it in any ports/remakes of Elite.

However, it sortof makes sense from a consistent universe point of view - you Witchspace in at a fair distance from the planet/station - so why not be forced to Witchspace back out once you're a safe distance away again?

The explanation could be that a hyperjump releases a burst of hard radiation which is dangerous within a certain distance, hence the requirement to have Witchspace entry/exit a certain minimum distance away from planets.

As far as the NPCs jumping into Witchspace near the Station is concerned, I believe that was a bug. This has possibly already fixed in 1.72 - at least, I haven't seen it happen in quite a while.

Posted: Thu Oct 09, 2008 8:09 am
by Commander McLane
Micha wrote:
As far as the NPCs jumping into Witchspace near the Station is concerned, I believe that was a bug. This has possibly already fixed in 1.72 - at least, I haven't seen it happen in quite a while.
Yes, that is a known and fixed bug.