"Never attacks player" = "never hurts anyone"?

Those of you who have played/tried ARPIA2 will know that there is what we call "the Escort Bug", a bug that causes all your mission-based escorts received from Arpia to be, well, cannon fodder. How so? They attack, yep, but they don't do any damage to enemies.
Now It is rather strange, isn't it?
Stranger yet is that I found it to be caused by the "Never attacks player" flag of the gövt resource.

So I guess this is yet another bug that developers should be made aware of, because it is sometimes useful to use that flag until you realise exactly what it causes.
I, for one, checked that flag in the Arpia gövt resource recently, because I felt it would be better if the player be attacked by them (I still remember those "Arpia Fleet" missions of Arpia1 when you failed a mission and got faced with a bunch of Arpian warships).

And while I'm at it, I'd better also repeat what I encountered in the Spaceball missions: the "isn't hurt by/immune to player's shots" gövt flag does not apply to beams, and therefore works less well than the similar düde flag, but the düde flag causes Nova to freeze if you board the ship, while the gövt flag doesn't. Basically, if you want an immune government, you have to either give all its ships a crew of 0 (make duplicates of the shďp resources?) and use the düde flag, or you have to settle for the gövt flag.

@pace, on Jan 4 2007, 01:34 PM, said in ARPIA2 discoveries: gövts, another quirk/bug:

Those of you who have played/tried ARPIA2 will know that there is what we call "the Escort Bug", a bug that causes all your mission-based escorts received from Arpia to be, well, cannon fodder. How so? They attack, yep, but they don't do any damage to enemies.
Now… It is rather strange, isn't it?
Stranger yet is that I found it to be caused by the "Never attacks player" flag of the gövt resource.

Are you saying that all ships belonging to a govt with the "Never attacks player" flag set fail to cause damage to enemies?

If so, I can't reproduce that bug - I've just switched the flag on for a government which has otherwise been behaving fine, and noticed no changes to its ships' behaviour towards their enemies. (And my shots pass through them.)

Can we narrow down the exact cause of the bug you've spotted?

This post has been edited by pac : 04 January 2007 - 09:18 AM

Sorry, I meant to say that mďsn-based escorts of that government don't work as they should.

@pace, on Jan 4 2007, 03:21 PM, said in ARPIA2 discoveries: gövts, another quirk/bug:

Sorry, I meant to say that mďsn-based escorts of that government don't work as they should.

Okay, the ships in my test were from a misn too. Are yours using the Aux field or the main one (mine are main)?

Edit: Right, I think I've managed to isolate what I take to be the same bug. It takes effect not based on the govt 'Never attacks player' flag (that seems to work fine), but on the 'Protect player' behaviour, set in the misn resource.

However, with this behaviour set, it's not that the ship doesn't fail to attack at all; it just fights much much less effectively (not engaging until targeted or in primary range). (It may be that with Nova/ARPIA weapons this amounted to not attacking at all.)

Doing some more testing …

Update: As those of you more familiar with the Nova engine must know, setting the 'Protect player' behaviour for a misn ship causes that ship to become the player's escort. To get normal (aggressive!) behaviour, the player needs to order the ships to attack using the usual escort commands. (Of course, the fact that he has these temporary escorts may not be evident to the player.)

Or have I not found the same problem here?

I haven't been able to reproduce this behaviour where a ship attacks but fails to do damage (although the ships have seemed weaker: I have a theory, let me have another go …)

Aha! Got it! It doesn't apply to all weapons! So far: beams (not turreted) do damage, but projectile turrets pass through the enemy! I'll narrow this down a bit further … Freeflight rockets also pass through … And guided: just beams seem to do damage (not going to check every last type).

Right! Making real progress now! Being a mission escort alone (having 'Protect player' behaviour switched on) isn't enough to trigger this behaviour. Being from a government with the 'Never attacks player' flag switched on isn't enough by itself either. It only takes effect (please test to confirm this for yourselves!) when both 'Protect player' and 'Never attacks player' are switched on for the same ship(s).

So, the exact warning should be: if you wish to grant mission escorts to the player, do not give them a govt which has the 'Never attacks player' flag set. Just use a duplicate govt without that flag, and things should be fine (no escort will/can attack the player anyway).

(Of course, this may well be exactly what you meant in the first place, but it wasn't clear to me, at least. Thanks for the testing work-out. :))

This post has been edited by pac : 04 January 2007 - 12:12 PM

@pac, on Jan 4 2007, 04:56 PM, said in ARPIA2 discoveries: gövts, another quirk/bug:

So, the exact warning should be: if you wish to grant mission escorts to the player, do not give them a govt which has the 'Never attacks player' flag set. Just use a duplicate govt without that flag, and things should be fine (no escort will/can attack the player anyway).
(Of course, this may well be exactly what you meant in the first place, but it wasn't clear to me, at least. Thanks for the testing work-out. :))

Aye, that's what I meant

So this unfortunate Arpia escort behavior can be fixed by simply unchecking a gövt box in Mission Computer? If so I'll get right on it in my version of Arpia 2.

@lord-rama, on Jan 6 2007, 04:29 AM, said in ARPIA2 discoveries: gövts, another quirk/bug:

So this unfortunate Arpia escort behavior can be fixed by simply unchecking a gövt box in Mission Computer? If so I'll get right on it in my version of Arpia 2.

I think that would work fine.

The more total fix would be to make a copy of the Arpia govt, and switch the 'Never attacks player' flag off for it. Then, for every misn which calls up Arpia ships as escorts, switch the dude referenced to a new dude, identical to the original one, but given the Arpia copy govt rather than the 'real' govt.

Then you should find that Arpia ships you meet wandering around in the normal course of events won't attack you (they have the original 'Never attacks player' flag set) but will still hurt enemies, and those you meet in missions won't either (they're assigned as escorts) but will still hurt enemies.

Actually, I've been thinking about trying to get some positive use out of this 'feature' by using it to make things look as though two ships are 'practising' fighting each other (so being unable to hurt each other would be desirable). However, I don't think it's doable like this, as the ships have to be assigned as player escorts to get the behaviour, and player escorts won't attack one another.

This can be the next challenge though: can you find a purpose that turns this bug into a useful feature?

This post has been edited by pac : 06 January 2007 - 06:52 AM

What happens if you (auto-)abort the two missions giving you two different escorts of two different gövts that are at war with each other?
Worth a try, I reckon. It could perhaps work.

I have a to-do list as long as my arm, but the idea of having ships 'in testing' appearing to spar against each other is in my head now. I'll see if I can find some way of doing it eventually!

What about just giving them weapons with ProxSafeties of 32767?

I thought it was 32676 in Nova....

Anyway, since that's covered, what could be another possible use for this?

What if, in your storyline, you wanted to guarantee that the escorts you're assigned were destroyed when you went to kill the mission's Ship Goal ship?

...And 32767 would make sense if the variable used to hold that value were a "short integer".

@orcaloverbri9, on Jan 7 2007, 03:19 AM, said in ARPIA2 discoveries: gövts, another quirk/bug:

What about just giving them weapons with ProxSafeties of 32767?

As I understood it by the documentation (haven't tested this yet), ProxSafety only sets a time during which the ProxRadius won't be tested. It doesn't stop a direct hit.

@pac, on Jan 7 2007, 07:45 AM, said in ARPIA2 discoveries: gövts, another quirk/bug:

As I understood it by the documentation (haven't tested this yet), ProxSafety only sets a time during which the ProxRadius won't be tested. It doesn't stop a direct hit.

But that's how it detects a direct hit. Once it's ProxRadius pixels away from a ship, it detonates. If it never tests for this, it won't notice a direct hit.

Of course, I could be wrong. Testing...

Yep, stops direct hits too. Remember, the Bible says exactly what it does.

@orcaloverbri9, on Jan 7 2007, 03:40 PM, said in ARPIA2 discoveries: gövts, another quirk/bug:

Yep, stops direct hits too. Remember, the Bible says exactly what it does.

Hehe, if only that was always true. But you're quite right in this case (I've tested too now). I thought I'd seen a different behaviour, but I must have imagined it. This would certainly be a way to get the effect I was thinking of then - thanks!

@orcaloverbri9, on Jan 8 2007, 04:40 AM, said in ARPIA2 discoveries: gövts, another quirk/bug:

But that's how it detects a direct hit. Once it's ProxRadius pixels away from a ship, it detonates. If it never tests for this, it won't notice a direct hit.

ProxSafety may prevent direct hits also but this is not how it detects a direct hit. ProxRadius works only from the center of the sprite but a direct hit can be on any opaque point in the sprite. This pretty much makes ProxRadius useless but I imagine calculating it from every point in the sprite would be complicated and processor-intensive.

This post has been edited by Guy : 07 January 2007 - 05:23 PM

Okay, I may have made a (small) breakthrough in improving AI fleet behaviour (in relation to the MaxOdds field). At first, I thought I'd found a disastrous problem that was going to cause me nightmares, but I may in fact have come up with a way to get desirable behaviour (!). (This is a little related to this topic, a little related to the one we were talking about in the Nova forum, and a little related to things which came up in the AotC thread, but I ended up posting it here.)

The original problem went something like this:

• Missions are set up so that the initial system is filled with warships (Council warships, but that's not important). These warships are neither allied with nor hostile to my ship (which is at the centre of the system)
• A further mission is set up so that a Xenophobic fleet jumps into the system. This fleet is smaller - the Council fleet exceeds its MaxOdds ratio.

What happens? The entire Xeno fleet targets me! There are any number of Council ships that are closer than me, but they ignore them (except for the Xeno ship that the Council ships target - that one's in trouble). Why aren't they just running away? Well, it's the same problem we had before with the MaxOdds field (which came up in the AotC thread). This is (roughly) the Xeno AI's decision-making process:

• I've arrived in a system. I hate everything that's not allied to me. What's the nearest thing to me that I hate?
• Aha! A Council ship! (I hate them.) Are there other Council ships here ? Hmm, it seems there are. Too many for my MaxOdds value, in fact! I'm not going to attack them
• Instead of attacking them, I shall not run away though. Instead, I will continue with my default behaviour. Before I get to looking to see if there's a port I want to dock at here (there isn't, in fact, because I hate the owners of this port!), there are some Merchant ships here! But wait, the Merchant govt is allied with the Council! Therefore, they count as part of the Council fleet, so I can't attack them either.
• But there is one other ship here. This ship isn't allied with anyone. (It's my ship!) Let's all attack that! (I'm sure that Council fleet will leave us in peace to do it )

Thus we find ourselves watching the unedifying sight of four ships getting blown to pieces while trying to get to me, ignoring the huge unfriendly fleet that's attacking them (until they actually get hit/targeted, that is - and then it's too late).

The very same thing would happen in default Nova should a Pirate fleet jump into a system with a Federation (for example) fleet which exceeded its MaxOdds. The Pirates won't dare attack the Feds, but they will go for the player (and the Feds will pick them off).

But there is a solution! If I change the inherent AI of my ship to be that of the Council (or any ally of the Council), the Xeno fleet will count me as being part of that govt's fleet too (for the purposes of MaxOdds). This means they won't attack me either, because (the AI now realises) attacking me would require engaging a superior fleet. At last we get the desired fleet behaviour: the Xeno fleet now has an, 'Oh, @Ł$%' reaction, and tries to hyper straight back out again (typically, half of them make it, fyi).

So, it's possible that this may also improve (to an extent) the behaviour of the alien fleet in ARPIA2. More generally, anyone would be advised to set this up to ensure sane behaviour from Xeno fleets with MaxOdds settings (and, as pirates should generally not be fight-to-the-death types, most Xeno governments should ideally have MaxOdds settings).

What you need to do is set an inherent (combat) AI for every ship in the game that the player can get. Where it used to be '-1', it can be set to some 'Trader' govt: one which no one hates except govts which are Xeno anyway, and which everyone else of significance can be allied to without causing problems. You could create a new govt just for the purpose, in fact.

Once you've done this, make sure the friendly (eg, Arpia) fleet is allied to that govt (which most unaffiliated ships should be given), and the Xeno fleet should either run away (because MaxOdds are exceeded) or fight everything equally (if they're not).

In summary: the solution to (some forms of) bad behaviour by AI Xeno ships is to set govt class alliances as broadly as possible - and have them affect the player ship too.

(One final note: going back to the original example, let's say I'm flying a ship with a different inherent (combat) AI - one that belongs to an enemy of the Council. Now I'm not part of the Council fleet again, so the Xeno fleet will come after me. This, however, becomes a moot point, since the Council fleet now also hates me, and I'll be dead before I can notice the odd AI behaviour. :))

Interesting. What happens if you are allied with the Council but there is some other non-allied ship in the system which the xenos can happily prey on?

@guy, on Jan 8 2007, 03:35 AM, said in ARPIA2 discoveries: gövts, another quirk/bug:

Interesting. What happens if you are allied with the Council but there is some other non-allied ship in the system which the xenos can happily prey on?

The same (ie, the Xenos will go after the unallied ship, and get picked off as before). This is why it's important to set up alliances as broadly as possible.

Given that you can ally traders (and other neutrals) with everyone, the main time this might happen would be if you had a 'three-way war' situation (like the Strand War, where each sides hates the other two), in which one or more of the sides are Xeno. But how likely is that to come up? (What's that? It comes up in AotC …? :blink: ) But there should still be work-arounds - and three-way battles will always become confused anyway … But in essence, this is an 'improvement' of rather than a solution to AI behaviour anyway.

This post has been edited by pac : 07 January 2007 - 10:43 PM

Another discovery during testing, but this one is more of a curiosity.

When misn ships are set to 'Hyper in after a short delay' their arrival point is set as the last 'jump point' used by the player. This is done in order to give the impression, in certain missions, that the player is being followed. (Note that if you have two - enemy - fleets both set to jump in like this, they will appear right on top of each other! (Makes it short but sweet, as a rule.))

However, there is an exception. If the pilot has never left the system he's currently in (ie, he's just started the game), then the misn ships will jump in arriving at the 'hyper limit', each group of misn ships at a different random point around the circumference of this circle (and bearing no relation to 'jump points'). In the case of opposing fleets, this makes for a different kind of battle again.

Unfortunately, I have yet to find a way to reproduce this behaviour once the pilot has left his initial system (ie, made any jumps anywhere). I tried moving the pilot through control bits, but the engine still 'remembers' the last jump point used. (I haven't tested what happens if you move system by wormhole/hypergate, however.)