Project

General

Profile

Bug #3691

Enemies do not initiate combat with player followers on sight

Added by R. D. 11 months ago. Updated 11 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
AI
Target version:
Start date:
12/23/2016
% Done:

100%

Reproducibility:
Always
Operating system:
Windows
Severity:
Normal

Description

Enemies should initiate combat with player followers on sight like in vanilla.

Associated revisions

Revision 588442b6 (diff)
Added by R. D. 11 months ago

Make enemies start combat with player followers

Recreates vanilla behavior of enemies starting combat with player
followers and escorters. (Fixes #3691)

History

#1 Updated by R. D. 11 months ago

  • Status changed from New to In Progress

#2 Updated by Jeffrey Haines 11 months ago

You shouldn't confirm your own bugs because you want others to validate the issue.

But I also see this issue good catch :)

#3 Updated by Jeffrey Haines 11 months ago

verify*

#4 Updated by R. D. 11 months ago

Well, yes, receiving a second person verifying is ideal, but in this case I could clearly see and reproduce the issue, and I already pretty much knew what the cause was, so it didn't seem necessary to me to wait to work on it. I've seen some other bugs here that never had anyone come by and confirm them, maybe because they were posted by Jannik Heller and everyone just trusted him that they were true. If that is to be the process here, or is and I just missed it, I'll abide by it though.

#5 Updated by Miroslav Remák 11 months ago

There's no such rule. If a dev reports a bug with the intention of fixing it, it would be wasteful to wait for somebody else to confirm it, considering our PRs go through review.

#6 Updated by R. D. 11 months ago

  • Status changed from In Progress to Rejected

I made this its own bug, but actually its the essentially the same thing as #3690, it's the root cause. I'll consolidate it in there and write an explanatory comment.

#7 Updated by Jeffrey Haines 11 months ago

  • Status changed from Rejected to In Progress

In terms of best practice for preventing regressions, bugs should be confirmed (verification) then PRs reviewed (validation). For example, the voice clipping bug on the Mac was a failure in the review process at the time of validation (PR review). Letting others verify the problem and the fix is a good step to take and isn't a waste of time.

Example: If someone has a Linux specific issue and other Linux developers confirm his very time consuming fix works for them, but Windows and Mac users haven't had the same opportunity to verify the fix. That's a mistake in the process.

Just shedding light on a very common issue in industry from my experience as a PM.

#8 Updated by Jeffrey Haines 11 months ago

  • Status changed from In Progress to Rejected

Sorry mistake on my part.

#9 Updated by Jeffrey Haines 11 months ago

Just want to correct what I said and mention the Mac voice clipping could have been a failure to verify a fix.

#10 Updated by R. D. 11 months ago

I think it depends on the bug as well. For a relatively simple game mechanic bug like this, where I pretty much knew what was causing it and could reliably reproduce it and it shouldn't differ between systems, I think sending it through the PR process is probably good enough. That sound issue on the Mac, though, as I gather from casually following the discussion, is a more elusive thing that I don't think has been pinned down yet, and verification and feedback from multiple people seems more valuable there.

If we want to have a more in-depth discussion the forums is probably the place for it, though.

#11 Updated by R. D. 11 months ago

  • Status changed from Rejected to In Progress

Reopening for the reason stated in #3690.

#12 Updated by R. D. 11 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100

#13 Updated by scrawl . 11 months ago

  • Target version set to openmw-0.42

Also available in: Atom PDF