LOCK-ON target

[ikonomov]

I just discovered that there is a LOCK-ON target when the mouse is held down, and I would really appreciate any help whatsoever to find a way to disable it, if people simply must have it in their games. Maybe it is something that is needed for consoles, so I will not press the issue wasting anybody's time here into a longer than needed discussion. Still, I'm reporting it here rather than in Discussions because I think it needs more attention and I believe should be addressed. To reproduce this behavior:

1. hold down mouse button to start attacking
2. as soon as the first attack is made move the cursor away from the target, but keep the button held down

Expected behavior: At this point the character should stop attacking and move to where the pointer is held down, but instead the target has been LOCKED ON and the cursor position is ignored until the button is released or the target is dead, at which point the character stops all actions.

In vanilla multiple attacks don't happen when the mouse button is held down. Many of us used a program that simply did repeated mouse clicks when the button was held down. I believe this is a meaningful improvement without changing the essence of the gameplay mechanic in the game. The new behavior in DevX is in my opinion simply too different than what the original game has, as part of its unique gameplay. I believe it is something that is worth preserving and the new LOCK-on behavior is going too far into changing this mechanic. If too many people disapprove and like this feature, if anybody knows how please help me and post a PR with a possible solution. I cannot find where this happens in the code, or how to change it.

Also there is this PR that is related to this issue. It interrupts the attack after the target is dead. I like this behavior, but I believe that once the target is dead the player shouldn't make an extra swing, but respect the action of the held down button and either move to the tile where the held down cursor is pointing to, or move to another target if the cursor is on another target.

In the very least, if this whole LOCK-on feature is something that can be included as a Toggle, I believe that it should be and needs to be.

[AJenbo]

This is intended behavior, the behavior you describe is a limitation of an external program that isn't able to track the state of the game or the intent of the player. To have the behavior you are describing you can simply keep using such and application as it will release the mouse and there by avoid the target lock on.

[ikonomov]

This changes the gameplay mechanic of the game completely. With a rogue, you can lock-on to a target, then while the button is held down move the cursor to the next target. When the first target dies, simply click the button again and switch to the next one. In vanilla, when the first target dies, you need to reposition the cursor quickly and precisely to move on to the next target. It is an integral part of the challenge and the lock-on feature changes the dynamics of the gameplay. This is a very significant change and one that I hope we can all agree we should have an option to configure in the settings. If there is a setting for this, I think there should be 3 different modes of operation:

1. Auto-clicker disabled, same as vanilla.
2. Auto-clicker enabled, when the button is held down on top of a target it essentially does multiple clicks at some interval. No interruption when the target dies, the character should start walking towards the spot where the cursor is being held down when there is no attack target.
3. Lock-on feature enabled. Same as it is currently.

[AJenbo]

Yes I know how it works, that is intentional. There are already multiple options for not using it:

1. Don't hold down the button
2. Use an auto-clicker

So there isn't really a need for making an option for this.

[ikonomov]

As you say. If only I could figure out how in track.cpp the repeated clicker works... I just need to tell it to repeat the mouse clicks when attacking only while the cursor is on the target.

[kphoenix137]

As a long time diablo 1 player, I enjoy saving both the wear and tear on my mouse and helping reduce the risk of carpal tunnel. The mechanic has been enjoyable as well for me.

[ikonomov]

I was able to disable the repeated attacks simply by removing these lines from track.cpp (line 62-69), so at least I can get vanilla behavior. I would really like to find out how I can modify the code so that the repeated clicking behavior can be retained, but it'll only function when the button is held down while the cursor is on top of the target. Any help would be greatly aprecited.

	case MouseActionType::AttackMonsterTarget:
		if (pcursmonst != -1)
			NetSendCmdParam1(true, rangedAttack ? CMD_RATTACKID : CMD_ATTACKID, pcursmonst);
		break;
	case MouseActionType::AttackPlayerTarget:
		if (pcursplr != -1 && !gbFriendlyMode)
			NetSendCmdParam1(true, rangedAttack ? CMD_RATTACKPID : CMD_ATTACKPID, pcursplr);
		break;

[ikonomov]

FluffyQuack was gracious enough to provide a perfect solution for which I'm infinitely grateful.

[DakkJaniels]

Another solution might be to figure out what monster you are on (similar to the code starting at L406 of cursor.cpp ) and see if the monster you get is the same as the pcursmonst you had previously. You could even have it retain the pcursmonst so if you happen to highlight it again, it starts attacking again.