AI Tracking And Firing Through Solid Cover

[odonovan1]

Twice in two nights, my avatar was under fire by AI emplacements, so I ducked him down behind cover. Both times, I had him behind fortified positions, the ones with the logs for walls and roofs, sandbags, and tank traps. I kept him prone BEHIND (not inside) the positions, behind thick layers of logs, sandbags, and earth, where bullets could not possibly get him.

Both times, I moved him back and forth a couple feet, crawling prone behind the cover, where the AI couldn't possibly see him. Whenever I did, the AI started firing to the same side I went to. Both nights, after doing this a few times to test my theory, all of a sudden my avatar was hit. I got to watch the tracers coming completely THROUGH the fortification and the mounds of dirt, coming out of the solid construction as if by magic. This should be IMPOSSIBLE.

The AI being able to track targets when not in line of sight and its ability to hit targets through solid cover both need to be fixed. Either time, I could have had my avatar pop a smoke grenade and try to get out from under fire, but when the out of LoS tracking first started I wanted to make sure this wasn't an isolated incident.

Thanks!

-Irish

Edited July 1, 2015 by odonovan1

[vmanstein]

AI will track and kill you through smoke with no problem, don't bother wasting smoke grenades on it.

[odonovan1]

AI will track and kill you through smoke with no problem' date=' don't bother wasting smoke grenades on it.[/quote']

Well then, that's another facet of the same problem. I can see them firing blindly into the smoke, but specifically tracking an avatar through the smoke is another example of the out of LoS bug.

Fix, please!

-Irish

[DOC]

It's not a bug. AI doesn't see smoke, it doesn't know how. The engine the game is built on can't do that. LOS is not an aspect of player co-ordinate data. in 1999 (when the game engine was built) that was just not doable as part of the design.

Now, wanting that to be changed is fine. I'd agree with that. But it's not a bug, that's all I'm saying.

Edited July 2, 2015 by DOC

[odonovan1]

It's not a bug. AI doesn't see smoke, it doesn't know how. The engine the game is built on can't do that. LOS is not an aspect of player co-ordinate data. in 1999 (when the game engine was built) that was just not doable as part of the design.

Now, wanting that to be changed is fine. I'd agree with that. But it's not a bug, that's all I'm saying.

Well then, the other part of it is still a bug. Being able to track avatars through solid objects, when there is no LoS, then shoot through the solid objects to kill them; that's a bug...probably two bugs, actually.

-Irish

[DOC]

I think you misunderstand. A bug is a feature or aspect of the program that is broken ie: not operating as designed.

The lack of LOS tracking (more correctly the obfuscation of LOS tracking when something is blocking LOS) does not exist as a feature, it is not a part of the game engines design. There is no code to do this so it isn't bugged, as you think, so fixing it isn't a matter of fixing a bug.

One would have to redesign the game engine so that such a feature could be included where at present, it doesn't even exist. So that your expectations can deal with the reality of such a task, or to align your desires with a reasonable lack of frustration over it (which is how I would live my life, so that I am not frustrated, but that's a choice we as individuals have to make for ourselves) it is important to understand what is a "fix" (which suggests small difficulty in that pursuit) is, and what a new feature that has to be created and incorporated into an existing (and very complex) design is. This represents an enormous difficulty.

LOS obfuscation that includes variable reactions to things the game engine can't even see (as part of the existing code it is all built on) is a far bigger project than fixing a bug is. Enormously so. A bug suggests a feature that does exist isn't working correctly.

Lack of LOS obfuscation is not a bug. I was hoping you would understand the difference so that what you desire (and I would desire it to) can be incorporated into a more realistic expectation. I would find that a much better way to look at it than the reverse.

It may prove to be not helpful to you. It is to me, because it means I can use it to not be frustrated over things that if I thought they were simple, I might become frustrated over when they didn't get any attention.

[odonovan1]

I think you misunderstand. A bug is a feature or aspect of the program that is broken ie: not operating as designed.

Thank you, Mr. Rogers. I'm so glad to be in your neighborhood. Can you treat me any MORE like an idiot? I assure you, I'm well aware of what a bug is.

The lack of LOS tracking (more correctly the obfuscation of LOS tracking when something is blocking LOS) does not exist as a feature, it is not a part of the game engines design. There is no code to do this so it isn't bugged, as you think, so fixing it isn't a matter of fixing a bug.

What you originally said was that smoke didn't block the AI's LoS, which I put down to the smoke being a temporary effect and not part of the landscape geometry of the game. This game was developed over 10 years after the first generation of first person shooters. I'm surprised there isn't at least some rudimentary LoS for the AI guns.

One would have to redesign the game engine so that such a feature could be included where at present, it doesn't even exist.

A version of it does exist, by necessity. Otherwise, the game would be played on a flat grassy plain with no buildings or landscape. Intervening geometry IS recognized by the game. A version of the same code which causes players' bullets to be stopped by cover could be used to cause the AI not to fire.

So that your expectations can deal with the reality of such a task, or to align your desires with a reasonable lack of frustration over it (which is how I would live my life, so that I am not frustrated, but that's a choice we as individuals have to make for ourselves) it is important to understand what is a "fix" (which suggests small difficulty in that pursuit) is, and what a new feature that has to be created and incorporated into an existing (and very complex) design is. This represents an enormous difficulty.

Wow... Sermonizing AND talking down to me at the same time. Thanks.

LOS obfuscation that includes variable reactions to things the game engine can't even see (as part of the existing code it is all built on) is a far bigger project than fixing a bug is. Enormously so.

Variable reactions? Object blocks bullet path (aka LoS), the bullet doesn't kill the avatar. The AI doesn't track or fire. Nothing blocking LoS, the AI tracks and fires. That's not a variable reaction to me. That's an if/then statement...one line of code with a binary switch.

A bug suggests a feature that does exist isn't working correctly.

I think we've covered that already.

Lack of LOS obfuscation is not a bug. I was hoping you would understand the difference so that what you desire (and I would desire it to) can be incorporated into a more realistic expectation. I would find that a much better way to look at it than the reverse.

This is the third time. The horse is dead.

It may prove to be not helpful to you. It is to me, because it means I can use it to not be frustrated over things that if I thought they were simple, I might become frustrated over when they didn't get any attention.

What may be helpful to me is not being lectured unnecessarily, and talked AT like I'm a child. I'm almost 60 years old and even my father never talked to me that way. Take the hint.

-Irish

[DOC]

You might want to think about the fact that AI doesn't (actually can't as it exists in this game engine) turn itself off just because there is something in a LOS that it doesn't have, because the code does not have a way to employ LOS for AI. It tracks a player by his co-ordinates, it can't see anything really. The AI fires at objects for the simple reason that they are in the path of the bullet, the AI is shooting as if the object is not there because it cannot see it at all.

A version of it does exist, by necessity. Otherwise, the game would be played on a flat grassy plain with no buildings or landscape. Intervening geometry IS recognized by the game. A version of the same code which causes players' bullets to be stopped by cover could be used to cause the AI not to fire.

Game geometry (objects placed in the world) cannot affect AI "vision" but it can stop a bullet because vision isn't required to perform that function. Additionally, that the world is not flat has nothing to do with buildings or objects placed on the terrain. The base (terrain) they sit on exists with no objects at all, all objects are added by hand after the terrain is shaped and do not in any way influence the AI, or the flatness of the world. The game world is not procedurally generated.

Object blocks bullet path (aka LoS), the bullet doesn't kill the avatar.

This is not correct in terms of how it was written in the game engine. The bullet is blocked by the object because the art of the object model is bullet proof as an attribute of that artwork. LOS is not employed at all. It doesn't exist as an attribute to employ. There is a bullet path, but the AI uses the same ballistics code as player guns do and that path is determined by those ballistics, there is no LOS since the AI fires at where the player co-ordinates are and doesn't see anything between it's muzzle and the target. The direction of the bullet is determined solely by the arc and elevation of the gun, and it follows a digital GPS type of code to point the gun as it doesn't have any LOS. It could employ LOS but I was trying to demonstrate why that's a pretty big job to change since you'd be adding a bunch of inter-related functions that have no existing code hooks and have no (current) knowledge of the others existance.

Being able to track avatars through solid objects, when there is no LoS, then shoot through the solid objects to kill them; that's a bug...probably two bugs, actually.

Definition time again. It's not a bug that it can track you "through an object". AI tracks you because it has your digital co-ordinates, it can't see what is between you and itself (LOS) BY DESIGN so that's not actually a bug. Secondly, AI cannot shoot you through a solid wall, or a berm. The tracer might render though such things at times (due to refresh rate and render cycles) but it can't hit you. World objects like walls and such (including berms) are bullet proof.

I can see where the existing feature might "be turned off" and stop shooting if the bullets collide with an object (wall, building, etc..) since it can detect bullet collisions within the ballistics feedback it sends when bullets are tracked. Making it stop "knowing you're there" is not as likely. The simple GPS style of detection is always on. It isn't sophisticated. It could be made anew I guess and be a lot more complicated but I just don't think I'd expect that to be in the current scope of work. I could be wrong. Maybe they'll think the game engine needs exactly that kind of work.

I was BTW, never saying that what you seek as a feature is impossible. It's probably so big though, that to expect it, would be a very long wait. Maybe forever.

I would consider that good information myself. Unless you already knew it, but your posts suggest you did not. I was just shedding some light on that for you. Perhaps it is because you don't wish to accept what I am telling you in the spirit it was provided, that makes it seem I am talking down to you. I figured you didn't already know how the game world was created, and thus how it exists, so I thought I'd help you out with that.

Edited July 5, 2015 by DOC

[denizzftp]

odonovan1, DOC means well, he just can be a bit... rough around the edges .

[DOC]

I'm not your fairy god mother, I speak direct ... I can't fluff you they don't pay me enough