[mjn.mixael]

I actually disagree that it messes with balance. In the example of the mission I was playing, it took me much longer to find the next useful hostile target after everytime I killed a hostile ship. That precious time allowed those craft to do a noticeable amount more damage to the ship I was protecting than before.

[karajorma]

Ah, in that case we should use the retail version for that reason too.

[Mastadon]

Since a majority of the voters want option 2, I have gone ahead and created a patch that removes the code that attempts to auto-target ships that are attacking you first.

[attachment deleted by a ninja]

[mjn.mixael]

Yes that works like I expected. 'H' targets nearest hostile. 'R' targets nearest attcking hostile. 'Auto Target' targets nearest hostile.

[Sushi]

Patch looks good to me.

[CommanderDJ]

approval++;

[Mastadon]

Shouldn't that be ++approval;

 

[CommanderDJ]

Shouldn't that be ++approval;

 

Shouldn't that have been a question?

Seriously though, no one's ever really explained the difference to me. Is there a meaningful change in speed or something?

[Sushi]

Patch committed in r/8848. Thanks, Mastadon!

[Iss Mneur]

Seriously though, no one's ever really explained the difference to me. Is there a meaningful change in speed or something?

In theory a prefix operator is faster because no data was copied (if you recall, a postfix operator returns the current value and does the increment afterwords).

In practice, a compiler will catch that sort of thing even at the lowest optimization levels, especially when the postfix operator is called in a void context (ie. its not going to assign the return value to anything, this is one reason why a copy constructor or an assignment operator should not change data just copy it).

[Mastadon]

Shouldn't that be ++approval;

 

Shouldn't that have been a question?

Seriously though, no one's ever really explained the difference to me. Is there a meaningful change in speed or something?

Like Iss Mneur said, the big logical difference in the prefix verses postfix increment operators is in what gets returned by the operator. With the prefix increment and decrement operators, the variable is incremented / decremented first and the resulting value of the variable is returned by the operator. In contrast, the postfix increment and decrement operators return the current value of the variable first, then increment the value of the variable.

In terms of performance, I've also herd that the prefix variants can be faster than their postfix counterparts, but in practice I have had a hard time proving that claim.

[Tomo]

There is a difference in the speed of assembly, however there's no difference in the speed of the C/C++ because all modern* compilers will optimise any difference out.

As Mastadon said, there is a difference in result though:

Code: [Select]

x = 0;
y = ++x;

x = 0;
z = x++;
After this snippet, y != z. Surprise!

I use the prefix version of increment almost exclusively.
It's primarily a style thing - if I'm using the result, I never want the value from before the increment because if I did, I'd assign it on a separate line for improved readability.

- Equally, the above snippet is fairly bad form because it may not be immediately clear what happens.

* Last decade, if not longer. You're not going to be using a compiler that doesn't.

[Goober5000]

With all the discussion on what the hostiles are actually doing, I don't think anyone paid attention to the other thing Mastadon suggested, the bit where the target key could ignore the Aten with a destroyed weapon system.  Because that actually has a direct bearing on this bug in Mantis.  Mastadon, have you added any filtering functionality where ships with no functioning guns or turrets are not targeted?

[Mastadon]

I'm not sure if I have added additional filtering functionality to the effect that ships w/ no functioning guns or turrets are not targeted. If I have time, I'll take a look tomorrow...maybe late today if I have the time.


EDIT: Darn, looks like my time just got eaten up through Friday with work and church. I'll see if I can get to this Friday.

[Swifty]

Question about this patch. Did this patch completely remove the ability of Target Closest Attacker to target closest hostiles if there are no present attackers?

Perhaps this patch made Target Closest Attacker now work as advertised but I feel that was done at expense of the command's original functionality which was still pretty useful.

If possible, does anyone mind if I also re-add the capability for this command to target closest hostile if there are no attackers present? I mean, if you don't have any present attackers, the command doesn't really do anything now. Might as well fill the gap.

[mjn.mixael]

I would prefer that fix, actually.

[Mastadon]

Question about this patch. Did this patch completely remove the ability of Target Closest Attacker to target closest hostiles if there are no present attackers?

Perhaps this patch made Target Closest Attacker now work as advertised but I feel that was done at expense of the command's original functionality which was still pretty useful.

If possible, does anyone mind if I also re-add the capability for this command to target closest hostile if there are no attackers present? I mean, if you don't have any present attackers, the command doesn't really do anything now. Might as well fill the gap.

Actually, the target closest attacker doing nothing is a feature if nobody's actually attacking you because it tells you that nobody's attacking you. If we have the target closest attacker feature then target the next closest hostile if nobody is attacking you, you have no way of knowing whether or not the hostile targeted is either attacking you or just another potential victim.

[Swifty]

But the hollow attacker arrow that goes around the reticle should be information enough. I don't see why it doing nothing when you have no attackers is a feature when closest hostile can be context dependent. I'm trying to make a compromise here between original retail functionality and the current new functionality.

[Iss Mneur]

What is wrong with using the "Target Hostile" key when you are not being attacked?

[Swifty]

Because you're cycling through hostiles. That key doesn't immediately give you the closest hostile exclusively. You could already be in the middle of the list of enemy targets cycled. What's wrong with a fallback behavior that emulates the original retail functionality?