Aurora 4x
C# Aurora => C# Mechanics => Topic started by: Steve Walmsley on December 08, 2021, 11:47:59 AM
-
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?
-
That seems like an appropriate solution. The only issue that springs to mind would be in making it really, really hard to probe defended jump points. But that might not be a bad thing.
-
That seems like an appropriate solution. The only issue that springs to mind would be in making it really, really hard to probe defended jump points. But that might not be a bad thing.
honestly that might be a good thing :) i second Meowth's suggestion Steve
-
The idea of jump shock preventing jumps I think is a good idea on its own but I am uncertain how that would solve the issue at hand.
This just sounds like instead of 5s increments you will be stuck at 1-2min increments forever.
Why would the AI opt to repeatedly transit through the same JP connection is what I would want to know.
-
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?
What is the logic for the NPR jumping back and forth through the same JP? Perhaps fixing that loophole will resolve this issue? Adding a jump shock will likely just change the behavior from '5-s hell' to 'a-few-minute hell'.
I recall someone also reported a similar issue caused by a geo survey ship with the 'survey unsurveyed system' standing order, jumping back and forth between 2 partially surveyed systems, where the remaining bodies are more than 10bkm from the JP (so the standing order won't add such bodies to the order list automatically). This situation should also be fixed better by fixing the underlying reason causing the situation.
-
Maybe have it only cause jump shock jump drive interrupt on hulls above FAC class? So you can still peek a boo with a Fighter/FAC as a player?
-
Um... It does not prevent it now..? Like, you jump in the new system, suffer jump shock, then you have a bad feeling about this, order to jump back, you do, and thus you've evaded like several hundreds of AMMs and ASMs and a bunch of other stuff?
Then... what does jump shock even do now?
-
Maybe have it only cause jump shock jump drive interrupt on hulls above FAC class? So you can still peek a boo with a Fighter/FAC as a player?
NPRs use FACs too though. Especially the Swarm.
-
Um... It does not prevent it now..? Like, you jump in the new system, suffer jump shock, then you have a bad feeling about this, order to jump back, you do, and thus you've evaded like several hundreds of AMMs and ASMs and a bunch of other stuff?
Then... what does jump shock even do now?
Disables Active Sensors if I remember correctly, so you can't fight for a long time if you don't Squadron Jump
-
For example, should jump shock prevent a ship from jumping again until it wears off?
Yes. I will echo other sentiment that ideally the poor AI logic that causes these things to happen would be corrected, but even so there is no good reason for the NPR ships to have this cheap way of rendering JP defenses impotent.
Why would the AI opt to repeatedly transit through the same JP connection is what I would want to know.
What is the logic for the NPR jumping back and forth through the same JP? Perhaps fixing that loophole will resolve this issue? Adding a jump shock will likely just change the behavior from '5-s hell' to 'a-few-minute hell'.
What I can gather is that there are a lot of reasons. One example from recent practice: NPRs do consume fuel, but their ships are still able to move when out of fuel and the NPR is coded to send such ships to the nearest refueling location. This can cause a behavior loop where the NPR will jump into a system because it is on the way to a fuel depot (in this case the NPR home system), however they will then immediately jump back out because the system has a very high threat rating - because I have occupied the system and blown up a lot of their ships. Notably, they will jump out even if they did not actually detect any of my ships in-system.
Based on this it seems like the NPR should be checking the danger rating of a system before they jump into it, not after. I think this would solve a large amount of the problems that currently occur.
-
For example, should jump shock prevent a ship from jumping again until it wears off?
Yes. I will echo other sentiment that ideally the poor AI logic that causes these things to happen would be corrected, but even so there is no good reason for the NPR ships to have this cheap way of rendering JP defenses impotent.
Why would the AI opt to repeatedly transit through the same JP connection is what I would want to know.
What is the logic for the NPR jumping back and forth through the same JP? Perhaps fixing that loophole will resolve this issue? Adding a jump shock will likely just change the behavior from '5-s hell' to 'a-few-minute hell'.
What I can gather is that there are a lot of reasons. One example from recent practice: NPRs do consume fuel, but their ships are still able to move when out of fuel and the NPR is coded to send such ships to the nearest refueling location. This can cause a behavior loop where the NPR will jump into a system because it is on the way to a fuel depot (in this case the NPR home system), however they will then immediately jump back out because the system has a very high threat rating - because I have occupied the system and blown up a lot of their ships. Notably, they will jump out even if they did not actually detect any of my ships in-system.
Based on this it seems like the NPR should be checking the danger rating of a system before they jump into it, not after. I think this would solve a large amount of the problems that currently occur.
In the specific example you gave I would argue that the NPR should just ignore threat rating. This could result in tactically unsound movements but I would consider that the consequences of an NPR running out of fuel and not necessarily bad design.
However in the more general sense your suggestion of checking threat before not after is still good if not already implemented.
Edit: Your comment regarding JP defenses becoming impotent has me confused. Surely jump shock preventing ships from immediately jumping out would do the opposite? You effectively force yourself to take 1-2 mins of weapons fire instead of 5s when you jump in on a defended JP.
-
Edit: Your comment regarding JP defenses becoming impotent has me confused. Surely jump shock preventing ships from immediately jumping out would do the opposite? You effectively force yourself to take 1-2 mins of weapons fire instead of 5s when you jump in on a defended JP.
To clarify, I mean player JP defenses against NPRs, as the NPRs jumping out at a 5s increment makes it impossible to actually fire on them. Strategically I suppose the job is still done, but it's extremely frustrating and annoying to not be able to shoot things, with ships designed to shoot things, in a game about shooting things.
-
Disables Active Sensors if I remember correctly, so you can't fight for a long time if you don't Squadron Jump
Ah, so passives still stay.
I suppose jump shock should do more than that. Leaving the ships sitting ducks.
Although, if the jump point is stabilised... Although wait - unstabilised jump point does not allow any kind of movement through it? While stabilised - jump shock if non-squadron jump, normal transit if squadron jump?
-
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.
-
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.
-
I think jump shock for drives is a good thing regardless of NRP jump loops problem!
-
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.
-
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)
-
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.
-
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.
-
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 :)
-
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.
-
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).
-
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.
-
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.
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
They do inflict shock. The distinction is that currently shock doesn't prevent jumping, but it does disable jump engines.
-
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.
They do inflict shock. The distinction is that currently shock doesn't prevent jumping, but it does disable jump engines.
Right so the ships cannot squadron jump but would still be able to do a standard transit. With the change, now standard transit is also being blocked by the shock.
-
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.
Stable jump points have always inflicted shock. However, you don't need a jump drive to transit them. So the NPRs were under jump shock and couldn't use a jump drive, but they could transit anyway. Now that the jump shock applies to the ship and not the jump engine for transit purposes, it changes the dynamic.
-
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.
They do inflict shock. The distinction is that currently shock doesn't prevent jumping, but it does disable jump engines.
Right so the ships cannot squadron jump but would still be able to do a standard transit. With the change, now standard transit is also being blocked by the shock.
Technically, a fleet that standard transits with a jump engine in the fleet that tries to standard transit before the shock wears off is also blocked.
The cases where fleets can currently standard transit while suffering jump shock is when using a stabilized JP, or there is a jump tender parked at either side of the JP (the tender isn't jumping, so the engine isn't affected by the shock).
-
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.
Because if the enemy is armed and you are not, you are a lot safer on the other side of a jump point than heading in-system, especially as you are probably slower. The ship would be wreckage long before reaching a population or friendly fleet if it stayed in range of the enemy force. The NPRs assess the best option to reach safety as quickly as possible. The idea here is for the NPRs to behave in a way that gives them the best chance to survive, not the one that creates the fewest interrupts for a player. I just need to deal with any repetitive situations caused by the need for self-preservation.
-
I have been one of the parties in a repeating jump situation. I was defending a jump point, and a hostile NPR would repeatedly jump in and out of the system. My 30k ton laser stations sitting right on the JP could do nothing, because they would jump back out on the next increment. I think we can fix this by making auto-fire happen after motion, detection, and targeting. This way my laser stations would still get to shoot, which would increase the threat rating in the NPR's perception, or kill their ships. Either way, the repeated jumps can't happen indefinitely.
-
I have been one of the parties in a repeating jump situation. I was defending a jump point, and a hostile NPR would repeatedly jump in and out of the system. My 30k ton laser stations sitting right on the JP could do nothing, because they would jump back out on the next increment. I think we can fix this by making auto-fire happen after motion, detection, and targeting. This way my laser stations would still get to shoot, which would increase the threat rating in the NPR's perception, or kill their ships. Either way, the repeated jumps can't happen indefinitely.
I had this exact problem as well, ships would jump through, see my forces, jump back, and then repeat that again and again. Glad to see Steve is adding in a blocking system so that ships cannot transition and retreat freely, even through a stable point.
Edit: indeed I meant 'cannot', rather than 'can'.
-
You mean can't because that's the change here.
-
Another solution would be to add a minimum reaction time to sensor detection based on crew training, leader abilities, and/or other factors that would serve to prevent both fleets from taking action at exactly the same time. I like the idea of using initiative as well.
At any rate, perhaps we should update http://aurora2.pentarch.org/index.php?topic=8495.msg113856#msg113856. It should mention stabilized jump points at least.
-
I have been one of the parties in a repeating jump situation. I was defending a jump point, and a hostile NPR would repeatedly jump in and out of the system. My 30k ton laser stations sitting right on the JP could do nothing because they would jump back out on the next increment. I think we can fix this by making auto-fire happen after motion, detection, and targeting. This way my laser stations would still get to shoot, which would increase the threat rating in the NPR's perception, or kill their ships. Either way, the repeated jumps can't happen indefinitely.
You can acquire targets for your BFC the first time they jump in and order to open fire the next increment. That way the next time they jump in you have your guns hot.
Modification to that tactic that worked for me in the past is that I have my fleet on the enemy side of the JP. When hostile ships are detected I'm getting my targets for BFC. Then my fleet is jumping back to my side of the JP a few minutes before aliens do. Sometimes more when missiles are involved.
Then I have just a few increments with open fire order active (I know enemy ships speed and distance so I have an estimate of when to expect them) and my ships are reporting that they cannot fire. Until the enemy fleet jumps in.
Once this led to the surrender of the enemy fleet.
What really bothers me is that when my ships are transiting JP where the enemy is on the other side. They are shooting the same increment the transit occurred. Maybe Fire at will could help here? Or new order "Fire at anything that transit"?
-
Yes, the NPRs have a mechanics advantage during jump point attacks. The AI makes fire decisions after movement so they can fire on ships who transit in the same increment. The player has to manually assign firing so he can't fire until the following increment. The fairest thing would be some equivalent form of auto-fire for players, which would trigger a 'fire-at-will' attack against ships that transited in the same increment.
-
Yes, the NPRs have a mechanics advantage during jump point attacks. The AI makes fire decisions after movement so they can fire on ships who transit in the same increment. The player has to manually assign firing so he can't fire until the following increment. The fairest thing would be some equivalent form of auto-fire for players, which would trigger a 'fire-at-will' attack against ships that transited in the same increment.
I don't care about AI advantages - it really needs advantages to make a story interesting! - yet it's often a pain to remember which different rules are for NRP, and so you can make stupid mistake that ruins entire good story if you have no fresh save.
So I'd like so see the thing you have suggested: this way we'll just have no need to remember the special rule.
-
Yes, the NPRs have a mechanics advantage during jump point attacks. The AI makes fire decisions after movement so they can fire on ships who transit in the same increment. The player has to manually assign firing so he can't fire until the following increment. The fairest thing would be some equivalent form of auto-fire for players, which would trigger a 'fire-at-will' attack against ships that transited in the same increment.
If an NPR fleet chases another fleet across a jump point, can the chasing fleet shoot immediately? Does it make a difference if the JP is stabilised?
-
At any rate, perhaps we should update http://aurora2.pentarch.org/index.php?topic=8495.msg113856#msg113856. It should mention stabilized jump points at least.
Why? There are no special rules to how jump shock works for when a transit is done via stabilized JPs as opposed to any other method.
If an NPR fleet chases another fleet across a jump point, can the chasing fleet shoot immediately? Does it make a difference if the JP is stabilised?
No, the chasing fleet would suffer jump shock from transitting. No, there are no special rules for jump shock when a transit is done via stabilized JPs.
The only things that affect how jump shock works is:
1. If it is a squad transit or a standard transit. Shock is shorter for squad transits, but can only be done by a jump-capable fleet using it's own jump engine.
2. NPRs suffer shock for only half as long.
I think the confusion comes in because we notice transit failures when a jump engine is suffering shock, and notice unwanted NPR behavior when they rapidly use stabilized JPs. This isn't happening because of stabilized JPs (if NPRs used jump tenders instead of stabilizing every JP they know about, we'd be seeing the same behavior). This isn't happening because the NPRs have special rules about what is affected by shock (the player can do the same things the NPRs are doing, we are just unlikely to do so except as a test).
The confusion comes from conflating: A. a fleet transiting using its own jump engine, with B. a fleet being able to transit. Currently, the former is affected by jump shock, and the latter isn't. But once a player is led to believe that there's some special rules to jump shock when it's an NPR and/or a stabilized JP, they of course are going to want to know all the things those special rules affect. But there aren't any special rules about this.
-
It seems the jump shock is already decided upon, and I guess it is kind of ok, though I hope it does actually also solve the specific issue about not just turning the 5sec intervals into 2 minutes or something when those AI ships realize they should return once more to the JP after the shock is cleared. (I guess that would only result in loop if their speed is identical though)
I liked Iceranger's (http://aurora2.pentarch.org/index.php?topic=12859.msg157674#msg157674) idea more still, since it would solve a number of AI issues at once and also create some curiosity towards their behavior.(..which then can be RP interpreted as personality, which I am always a fan of) Might be harder to realize on grand scale though.
Yes, the NPRs have a mechanics advantage during jump point attacks. The AI makes fire decisions after movement so they can fire on ships who transit in the same increment. The player has to manually assign firing so he can't fire until the following increment. The fairest thing would be some equivalent form of auto-fire for players, which would trigger a 'fire-at-will' attack against ships that transited in the same increment.
I have found myself on the receiving end of this disadvantage, and it was pretty uncomfortable, since the enemy had vastly better engines, so I could only shoot against them once before they successfully invaded my systems. Since I would have destroyed them if it was fair, and they did destroy one of my fleets when the situation was reversed, yes, I don't like that this is unnecessarily disadvantaging the player. (...and it is confusing too. Before reading it here, I always pondered if it was an error I should report, because I thought 'fire-at-will' was meant to be the state the AI used to barricade jump points. ..But it didn't work for me.)
So I vote for clearing that bump towards auto-fire equality.
-
At any rate, perhaps we should update http://aurora2.pentarch.org/index.php?topic=8495.msg113856#msg113856. It should mention stabilized jump points at least.
Why? There are no special rules to how jump shock works for when a transit is done via stabilized JPs as opposed to any other method.
There is clearly a lot of confusion around jump shock so I don't see why some clarification about not-necessarily-intuitive scenarios would be a bad thing.
Most AARs describe jump shock affecting the crew. The wiki says it's a "sensor distortion effect" so I guess the fact that jump drives are affected changed with C#?
If you read the exact wording, the 1.0 post says that jump shock affects the ship, which leads to the following train of thought: ship is affected by jump shock, jump shock disables jump engines, therefore ship can't transit jump points.
The exception (1.13 and earlier): it can transit a stabilised jump points because those don't require jump engines to transit.
If an NPR fleet chases another fleet across a jump point, can the chasing fleet shoot immediately? Does it make a difference if the JP is stabilised?
No, the chasing fleet would suffer jump shock from transitting.
For some reason I had forgotten that Beam Fire Controls would be affected.
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.
Because if the enemy is armed and you are not, you are a lot safer on the other side of a jump point than heading in-system, especially as you are probably slower. The ship would be wreckage long before reaching a population or friendly fleet if it stayed in range of the enemy force. The NPRs assess the best option to reach safety as quickly as possible. The idea here is for the NPRs to behave in a way that gives them the best chance to survive, not the one that creates the fewest interrupts for a player. I just need to deal with any repetitive situations caused by the need for self-preservation.
So in a scenario (different to the one you had) where two fleets meet at a *stabilised* jump point, and both sides believe that Fleet S is stronger than Fleet W. Fleet S tries to engage and Fleet W tries to escape.
In 1.13 and earlier being able to transit every increment would allow Fleet W to remain out of range by keeping the jump point 'between' them forever.*
In 2.0 neither side will be able to transit every increment. Now Fleet W needs to recover from jump shock faster than Fleet S in order to keep jumping before Fleet S can shoot. Eventually, through random chance, (accelerated or slowed if there is difference in crew grade) Fleet S will recover faster and fire upon Fleet W, so continuous transiting is no longer a guarantee of safety.
Does that mean you'll change the AI so that fleets are less likely to try and shield themselves by continually jumping? Or is it moot because they will get destroyed eventually either way?
*If Fleet S is strong enough, it can split and cover both sides at the same time. On a long enough time scale one side will build and send reinforcements.
-
At any rate, perhaps we should update http://aurora2.pentarch.org/index.php?topic=8495.msg113856#msg113856. It should mention stabilized jump points at least.
Why? There are no special rules to how jump shock works for when a transit is done via stabilized JPs as opposed to any other method.
There is clearly a lot of confusion around jump shock so I don't see why some clarification about not-necessarily-intuitive scenarios would be a bad thing.
Most AARs describe jump shock affecting the crew. The wiki says it's a "sensor distortion effect" so I guess the fact that jump drives are affected changed with C#?
If you read the exact wording, the 1.0 post says that jump shock affects the ship, which leads to the following train of thought: ship is affected by jump shock, jump shock disables jump engines, therefore ship can't transit jump points.
The exception (1.13 and earlier): it can transit a stabilised jump points because those don't require jump engines to transit.
I'm not opposed to a clarification, I'm opposed to calling it an exception and to singling out stabilized JPs; players may still assume there might be more to stabilized JPs than they are being told. I would phrase it something like:
In 1.13 and earlier, ships affected by jump shock can transit jump points when a non-shocked method is available, such as a stabilized jump point or another jump engine (i.e. a jump tender).
and even that isn't perfect because it doesn't really get into the non-intuitiveness of the current rules, which boils down to: a jump engine can be disabled from shock without being used, and a jump engine can be used without suffering shock.
Anyway, yeah, another good thing about the change is that it'll be more intuitive and much easier to explain.