[D1 v1.4a, D2 v1.2 DOS] Robot homing weapons don't track while host is dead
#1
In a Cooperative or Robo-Anarchy game, while the host is dead, Homing Missiles (and other homing weapons) fired by robots don't track the other players. This bug affects both D1 and D2. Homing weapons fired by players work normally even while the host is dead, whether fired at players or at robots.

D1 demo: no_lock.zip
Reply
#2
This is most likely (not 100% sure tho but bots any ultiplayer is a sensitive thing to begin with) an old legacy bug. But behaviour in Mulitplayer still is a problematic thing due to their AI relying on a player object (i.e. this player controls the bot so this player makes the AI for the bot). Since there are also still problems with the thief I still have to clean and improve a lot on this part of code.
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Reply
#3
(12-03-2013, 11:44 AM)zico link Wrote: This is most likely […] an old legacy bug.

Aha … Theory confirmed. (I Heart DOSBox. Smile )
Reply
#4
Yeah I feared this was the case. You know if I had screwed it up, it would probably be easier to fix. But like the Thief there is just too much missing in the code for it to work properly. I've already written a thief handler for Multiplayer but the whole control code for the bots is what actually drives the AI mad. And in a way that carries over to targeting, too. I still hope I can fix these things without rewriting a large part of the AI itself.
Depending on how it looks I'll TRY to make this behaviour a bit more streamlined. Sometimes things look "off" when compared to Singleplayer. However all things considered in most cases this is actually "intended behaviour" - at least when we see how the AI functions and how it can interact in a multiplayer (literally multiple players) environment.

So whatever happens - the bot who shot the homer was probably interacting with the player who died. This isn't necessarily the host and after death of the player (or at least it's respawn) it should be able to interact with other players and track those again. Well, at least this is how it *should* be able to function. But I'm working on assumptions here. As I said, the AI is complicated enough and as soon as you bring in the Multiplayer mechanics it becomes very .... more complicated. So I'll see it when I get there.
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Reply
#5
(12-04-2013, 11:28 AM)zico link Wrote: […] the bot who shot the homer was probably interacting with the player who died. This isn't necessarily the host […]

I actually tested that too. While the host is dead, the weapons of all robots in the mine lose their homing abilities—even robots that are across the level from the host, definitely out of the host's sight. While a client is dead, robots' homing weapons can still track other players—even if those robots were interacting with the dead client. I kinda forgot to show this in my demo … Whoops.
Reply
#6
This is really interesting. In this case it doesn't seem to be what I thought at all.
More likely a missing handler so part of the code only checks for "the blue guy who also plays alone all the time". Maybe the game developed some muscle memory in this regard. Jokes aside. At first glance this seems much easier to fix than AI ... at least I hope so.

Anyway I'll get to that bug later on. I just bought 5 mice from a store and I gotta hurry up so I can hopefully return them again later. Big Grin
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Reply
#7
(12-10-2013, 10:43 AM)zico link Wrote: […] I just bought 5 mice from a store and I gotta hurry up so I can hopefully return them again later. Big Grin

Ah, testing the legacy mouse code vs. current mouse code issue? Smile I wish I could add something useful to that discussion, but I can only see a slight acceleration difference between vanilla and Rebirth, so I couldn't say much that hasn't been said already … Anyway, thanks for looking into that.
Reply
#8
While going offtopic, but still. Yes, it's a bit difficult. I switched mice recently myself and checking in again I could also see a slight difference in numbers after Drakona raised the point. But it's more on the paper for me - only the numbers tell me there is something happening/changing between these mice. While playing I can hardly feel this but like I always say - I am a ROOKIE player.

I will later push a small change to unification which increases the base delta values. Basically what this means is that it will double the acceleration and base sensitivity so you get a decent feedback with a slow mouse (either cause it has low DPI or you set it low in your system). Currently with my budged mouse a "natural move" raises to full acceleration in less than 30ms. 33ms would be a one-frame-move in the original game running at 30FPS. As a comparison in 0.58.1 with the same mouse it takes 60 to 70ms. And all that is with middle sensitivity. So there is room above and below.

The thing is that the more you speed up acceleration, the less accurate you can aim. Best example/comparison is the Keyboard. It goes from 0 to 100 instantly but you know how pixel accurate that is. Initially I wanted to raise the base reading much more but that ended up so heavy that even when turning up/down, the pyro was quickly shivering between left and right turns since I cannot drag my mouse in a pixel-accurate line.

So this is why I switched up the base reading a little. What was full sensitivity before is now archived with middle or a notch below.

EDIT: If someone's interested, the change regarding mouse is now up in unification. I hope the actual bug reported in the topic will be committed there, too.
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)