Repeated Jumps

[serger]

I think jump shock for drives is a good thing regardless of NRP jump loops problem!

[Steve Walmsley (OP)]

I think jump shock for drives is a good thing regardless of NRP jump loops problem!

This wouldn't be jump shock for drives because it is to prevent use of a stabilised jump point. The technobabble would have to cover the idea that a ship can't transit twice within a very short time.

[cdrtwohy]

Call it translation sickness or something that effects the organics and maybe that the jump drive has to recharge before its used again and ships translating through stabilized points destabilize it for a time maybe say something like the sqr of the mass in seconds?


Edit math time

Something like

T(destab) = mass^2/(640000000000) Or some other P value ( FYI using this means 4 million tons destabs for about 25 seconds)

[Droll]

What is the logic for the NPR jumping back and forth through the same JP? Perhaps fixing that loophole will resolve this issue.

There are two mutually hostile non-combat NPR fleets on the same jump point. They both try to escape the other by transiting the jump point, at which point they find themselves in the exact same situation - repeat ad nauseam.

Unless jump shock was identical for both fleets, one would transit before the other and break the cycle.

I agree that in this particular case, adding a random jump shock will break the cycle. Although in the cases mentioned by others, jump shock doesn't really fix the real issue.

Maybe for the NPR, instead of making decisions using "if A then do B" logic, some randomness can be added into the decision-making, like "if A then x% do B, y% do C, ...". The list of options and the weight of each option can be determined by say the race's properties, or the battlefield conditions (such as friend-foe force ratio, or known intel about the ships insight). This way, the NPRs will not always make the same decision in the same situation. In this particular example, if one NPR knows the other NPR's ships are non-combat, it may decide no need to escape, or the NPR with a 'larger' fleet may decide not to escape.

You could also instead of randomness maybe use fleet initiative? Idk if initiative works differently in a non-player context. But if the multiple fleets can decide to transit through JPs within the same increment, the one with better initiative goes first and then the other relevant fleets re-evaluate before making their move. If initiative is the same then you can pick randomly between the highest initiatives.

So in Steve's situation, NPR 1 and 2 can both transit, NPR 1 has better reaction so it goes through the JP. NPR 2 realizes that the fleet it is fleeing from is no longer there and decides not to jump. This does effectively add a "JP transition" phase to turn processing.

[TheTalkingMeowth]

Call it translation sickness or something that effects the organics and maybe that the jump drive has to recharge before its used again and ships translating through stabilized points destabilize it for a time maybe say something like the sqr of the mass in seconds?


Edit math time

Something like

T(destab) = mass^2/(640000000000) Or some other P value ( FYI using this means 4 million tons destabs for about 25 seconds)

Now THAT could be interesting. Honorverse had a mechanic where large mass transits of a wormhole meant no one could use the wormhole for a while afterwards.

[cdrtwohy]

Call it translation sickness or something that effects the organics and maybe that the jump drive has to recharge before its used again and ships translating through stabilized points destabilize it for a time maybe say something like the sqr of the mass in seconds?


Edit math time

Something like

T(destab) = mass^2/(640000000000) Or some other P value ( FYI using this means 4 million tons destabs for about 25 seconds)

Now THAT could be interesting. Honorverse had a mechanic where large mass transits of a wormhole meant no one could use the wormhole for a while afterwards.

That equation is the Honorverse equation lol thats where i got the idea

[Garfunkel]

Yes, to jump delay after jump because it would be a good addition for both player and the AI that nobody can make multiple instant (5-sec) jumps. And it should affect all ships, from fighters to death stars.

[Bremen]

In VB Aurora this is how it worked; I actually hadn't realized that wasn't the case in C#.

I'd say go for it, and maybe add some additional restriction to keep it from happening with LPs as well, which to my knowledge don't cause jump shock but could end up in the same situation (two hostile non-combat fleets trying to escape each other).

[Density]

I think jump shock for drives is a good thing regardless of NRP jump loops problem!

Everything I've seen says jump shock already affects jump drives. Unless I've missed a change to them somewhere.
http://aurora2.pentarch.org/index.php?topic=8495.msg113856#msg113856

So while the specific case here (NPRs transitting a stabilized JP) is the most likely to cause a slow down from NPR behavior, it's not the only case of ships being able to jump while affected by shock. Bouncing back and forth can be done via jump tender (since the tender itself isn't transitting, the drive isn't suffering shock). Technically, ships could squad jump with one jump ship, then join up with another jump ship waiting on the other side that isn't affected by shock and squad jump back; but if you can set this up, there's not really a practical reason to do so.

Overall, I agree that shock preventing ships from jumping would be an improvement, even if it doesn't completely fix the problem.

The important thing I want to know is, does the failure of an NPR fleet to jump cause an interrupt for the player (in the same way that a player fleet jump failure does)? If it does, we'd be trading an infinite set of 5-sec interrupts for 2-3 minutes of 5-sec interrupts. (Still an improvement, but not ideal.)

Edit: Migi just incidentally reminded me that transit failure will interrupt at the next sub-pulse, not the next 5-sec increment.

[Migi]

I'm running a test campaign and I have encountered the issue where an NPR is jumping a ship back and forth through the same stabilised jump point, causing a long series of small increments. I am considering the best option to prevent this behaviour and welcome any suggestions. For example, should jump shock prevent a ship from jumping again until it wears off?

I am confused.

In my experience, when my ships transit a jump point using a normal jump and try to transit back straight away, they can't jump back and I get an interrupt event. The event is "Transit Failure" "no available jump drive capable etc."
This occurs even if the sub-pulse would be much larger than any possible jump shock.
To stop it happening you need to put in an order delay of about 180 seconds (roughly jump shock time), which inevitably I forget to do.

I have always assumed that my experience was WAI (except that the message was slightly wrong and I don't remember ever reporting it), is that not the case and should I post it in the bugs thread? Or are you saying that this doesn't apply to NPRs and you are considering expanding it?

There are two mutually hostile non-combat NPR fleets on the same jump point. They both try to escape the other by transiting the jump point, at which point they find themselves in the exact same situation - repeat ad nauseam.

Unless jump shock was identical for both fleets, one would transit before the other and break the cycle.

For this specific example, at some point the NPRs should realise that the ships are non-combat and they can safely ignore each other.

Alternatively you could simply put in some logic that tracks how many jumps the fleet has attempted in the past 30 seconds, and if it reaches 6 (ie it has tried to jump every increment) then give it a 33% chance of waiting 1 increment and a 33% chance of waiting 2 increments before choosing the next action. That is likely to break the deadlock because they are unlikely to choose the same delay time, and if they do the situation will cycle back and try to resolve again.

[Density]

In my experience, when my ships transit a jump point using a normal jump and try to transit back straight away, they can't jump back and I get an interrupt event. The event is "Transit Failure" "no available jump drive capable etc."
This occurs even if the sub-pulse would be much larger than any possible jump shock.
To stop it happening you need to put in an order delay of about 180 seconds (roughly jump shock time), which inevitably I forget to do.

I have always assumed that my experience was WAI (except that the message was slightly wrong and I don't remember ever reporting it), is that not the case and should I post it in the bugs thread? Or are you saying that this doesn't apply to NPRs and you are considering expanding it?

If this is occuring for a fleet that includes a jump engine that is going through a JP that is not stabilized and there is no jump tender on either side, then it is WAI for the jump engine to fail to jump. If this isn't the case, then we're in bug territory.

A stabilized jump point doesn't have a jump engine that suffers shock. So I've been assuming the interrupts Steve encountered wasn't transit failures but NPRs repeatedly getting hostile contacts.

[Steve Walmsley (OP)]

I'm running a test campaign and I have encountered the issue where an NPR is jumping a ship back and forth through the same stabilised jump point, causing a long series of small increments. I am considering the best option to prevent this behaviour and welcome any suggestions. For example, should jump shock prevent a ship from jumping again until it wears off?

I am confused.

In my experience, when my ships transit a jump point using a normal jump and try to transit back straight away, they can't jump back and I get an interrupt event. The event is "Transit Failure" "no available jump drive capable etc."
This occurs even if the sub-pulse would be much larger than any possible jump shock.
To stop it happening you need to put in an order delay of about 180 seconds (roughly jump shock time), which inevitably I forget to do.

I have always assumed that my experience was WAI (except that the message was slightly wrong and I don't remember ever reporting it), is that not the case and should I post it in the bugs thread? Or are you saying that this doesn't apply to NPRs and you are considering expanding it?

These NPR fleets aren't using jump engines - its a stabilised jump point.

There are two mutually hostile non-combat NPR fleets on the same jump point. They both try to escape the other by transiting the jump point, at which point they find themselves in the exact same situation - repeat ad nauseam.

Unless jump shock was identical for both fleets, one would transit before the other and break the cycle.

For this specific example, at some point the NPRs should realise that the ships are non-combat and they can safely ignore each other.

Alternatively you could simply put in some logic that tracks how many jumps the fleet has attempted in the past 30 seconds, and if it reaches 6 (ie it has tried to jump every increment) then give it a 33% chance of waiting 1 increment and a 33% chance of waiting 2 increments before choosing the next action. That is likely to break the deadlock because they are unlikely to choose the same delay time, and if they do the situation will cycle back and try to resolve again.

They are non-combat fleets but they include combat ships (salvage ship plus escorts for example) so both sides are correct to attempt escape. Also, it wouldn't make logical sense for an NPR to deliberately delay escaping a threat.

[Steve Walmsley (OP)]

As there seems to be a broad consensus on the idea of jump shock, I have updated the code accordingly.

http://aurora2.pentarch.org/index.php?topic=12523.msg157641#msg157641

[Migi]

I hope the change fixes the problem.

These NPR fleets aren't using jump engines - its a stabilised jump point.

I had no idea they worked differently so I learned something today.

There are two mutually hostile non-combat NPR fleets on the same jump point. They both try to escape the other by transiting the jump point, at which point they find themselves in the exact same situation - repeat ad nauseam.

Unless jump shock was identical for both fleets, one would transit before the other and break the cycle.

For this specific example, at some point the NPRs should realise that the ships are non-combat and they can safely ignore each other.

Alternatively you could simply put in some logic that tracks how many jumps the fleet has attempted in the past 30 seconds, and if it reaches 6 (ie it has tried to jump every increment) then give it a 33% chance of waiting 1 increment and a 33% chance of waiting 2 increments before choosing the next action. That is likely to break the deadlock because they are unlikely to choose the same delay time, and if they do the situation will cycle back and try to resolve again.

They are non-combat fleets but they include combat ships (salvage ship plus escorts for example) so both sides are correct to attempt escape.

Also, it wouldn't make logical sense for an NPR to deliberately delay escaping a threat.

The fact that the fleets include combat ships does make it less clear cut.
But if they keep jumping away from each other it seems reasonable for one side or another to realise that neither side wants to engage and change behaviour. If one side wanted to engage, they would stay and try to lock weapons, and follow next increment to regain targets. By jumping at the same time they are trying to escape.
I think it would make sense for a commander, realising that neither side wants to engage, would be willing to retreat in a way that temporarily takes the fleet closer to the enemy.
Alternatively you could justify it as a small realism sacrifice for squashing an annoying gameplay outcome.

Maybe a different question to ask is why one both sides don't try to retreat in-system?
Rather than trying to flee to an adjacent system, why don't they attempt to link up with a friendly fleet or flee towards a core system?
As long as the path to a friendly fleet or core system is in a direction for both sides, it will cause them to break contact.

[nuclearslurpee]

As far as fluff goes, I always thought jump drives held the wormhole open (otherwise stationary jump tenders don't work) and the "shock" was an effect of the wormhole travel itself. A stabilized jump point would be the same, the wormhole is held open but going through it still inflicts the shock effect.

I didn't know until this thread that stable jump points don't inflict jump shock, I thought it was a weird NPR thing to account for weak AI logic. This change makes much more sense to me fluff-wise - and of course mechanically.