View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0006654 | Valley 1 | Bug - AVWW Multiplayer | Mar 16, 2012 1:54 am | Mar 25, 2012 12:30 pm | |
| Reporter | MaxAstro | Assigned To | keith.lamothe | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 0.905 | ||||
| Fixed in Version | 0.913 | ||||
| Summary | 0006654: Skelebot Guards Invinicibilty Issues | ||||
| Description | A couple things. Firstly, a general annoyance: A skelebot guard at the edge of a raised area with a ceiling only as high as the guard is tall is almost impossible to kill. This is especially notable in the intro mission. Once he sets in place, his knockback makes him pretty much unassailable and the low ceiling prevents you from going around. Especially frustrating when you can set a platform right in front of him and shoot him and he doesn't die; I had to literally continually walk into him and take damage to hurt him. On to the actual bug: When a skelebot guard decides which PC is its "target", that PC is the one it uses to decide when to go invincible. So if I am on the same level as the guard but the other player is well above him, he will go invincible - at one point he went invincible but continued chasing me! This can also happen if the guards take up the dreaded "tower of death" attack formation - one guard stacked on top of the other. The guard on top will stay invincible but can be "carried" around by the guard he is standing on. Almost awesome enough that it should be an intentional behavior, but horribly deadly. I also feel the guards really REALLY should not be able to keep attacking and stay invincible. At the very least they should lose invincibility for a duration after they attack. Oh! Almost forgot. In the intro mission, there is a room with a red slime blocking a veeeery long tunnel to the right. Traditionally this tunnel is full of an army of skelebots. For us, however, the skelebots spawned all directly on top of eachother in the far right of the hall, stuck in place and hilariously easy to kill. | ||||
| Tags | No tags attached. | ||||
| Internal Weight | Fix Before Major Release | ||||
|
|
Also when a guard approaches one of those vertical ladder shafts that are common in maze and evil rooms it will cover half of the shaft while standing invincibly. If you're lucky with the room layout you can bait him away from there and just RACE to the shaft, hoping you get through before he closes it again but there's no guarantee that the room will allow this. They should probably have a delay to changing into the guard stance as well, kinda silly that they go invincible for a moment when you jump over them. |
|
|
You should probably log separate issues in separate reports. It lets the developers mark each item separately as fixed, in progress, considering, etc. I agree that skelebot guards should temporarily drop invincibility while attacking. |
|
|
As see this as one overarcing issue, namely as currently implemented the skelebot invincibility mechanic is frankly stupid; I feel the mechanic as a whole needs to be changed, hence the single issue. Don't get me wrong - I like the idea that skelebots can sit down and do this whole "you shall not pass" thing. I just think some serious limiters need to be put in on when and where they can do that. Not being able to shoot them while airborne (or while they've knocked you into the air because of their attacks) is frustrating. But I did consider splitting it into several issues each to address the individual points; I decided it would be kinda like spamming the Mantis list, though. :) |
|
|
* Skelebot Guards no longer go invincible when there is not enough room above them for you to jump over them, or when they are in midair. |
|
|
If you wind up seeing any skelebot guards running while invincible in MP, let me know -- that's the only potential remaining bug that should be here as of 0.907, I think. |
|
|
I've managed to reproduce the "running while invincible" skelebot guard by jumping over him. When you're right above him, he'll stop running and turn invincible. When I'm past him, he'll charge after me while remaining invincible. |
|
|
In mp? |
|
|
Yeah, that was in MP. |
|
|
Okay, I think I know what that is. Most likely that is also a problem for player invincibility in MP, so I'll have to do something that fixes both. |
|
|
Thanks! Keith got this one: * MP: fixed a bug where skelebots were not properly losing their invincibility when they moved because they were trying to use logic that only works (in MP) for player entities. |
|
|
In the latest version, in single player, none of the skelebot guards are going invicible at all. They still walk up to an edge and cross their arms, but no lightning and they still take full damage. |
|
|
This happens in buildings for me. The skeletons that were outside turned invincible correctly. |
|
|
The one thing that springs to mind is the headroom. They'll only become invincible now (since last version, I think, or the one before) if there's enough room above them for you to jump, to prevent them from becoming concrete blocks. |
|
|
Ah right! That's it. Maybe they should run away in that situation? |
|
|
* Skelebot Guards are now Skelebot Grunts, and no longer have that "become-invincible" behavior. While that was fun in theory, it was not terribly fun in practice. |
|
|
Yea, the thing with invincibility mechanics is that any sort of bug or oversight with them can easily completely break battles where the mechanic comes into play. As such, IMO, as a good maintainability principle, invincibility mechanics should be handed out conservatively and judiciously. Giving them to a basic, "near bottom tier" enemy type is most certainly not being conservative with it. |
|
|
Yep. I imagine some boss modifiers will add that functionality back in for some advanced bosses, but it needs to be done conservatively and much later in the game than the intro mission, as you say. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Mar 16, 2012 1:54 am | MaxAstro | New Issue | |
| Mar 16, 2012 1:08 pm | KDR_11k | Note Added: 0020905 | |
| Mar 16, 2012 2:19 pm | khadgar | Note Added: 0020911 | |
| Mar 16, 2012 2:22 pm | tigersfan | Internal Weight | => Fix Before Major Release |
| Mar 16, 2012 2:22 pm | tigersfan | Assigned To | => keith.lamothe |
| Mar 16, 2012 2:22 pm | tigersfan | Status | new => assigned |
| Mar 16, 2012 2:26 pm | MaxAstro | Note Added: 0020913 | |
| Mar 17, 2012 11:39 am | Chris_McElligottPark | Note Added: 0020941 | |
| Mar 17, 2012 11:48 am | Chris_McElligottPark | Note Added: 0020942 | |
| Mar 17, 2012 11:48 am | Chris_McElligottPark | Assigned To | keith.lamothe => Chris_McElligottPark |
| Mar 17, 2012 11:48 am | Chris_McElligottPark | Status | assigned => feedback |
| Mar 18, 2012 3:39 am | Toll | Note Added: 0020965 | |
| Mar 18, 2012 9:06 am | Chris_McElligottPark | Note Added: 0020969 | |
| Mar 18, 2012 3:01 pm | Toll | Note Added: 0020990 | |
| Mar 18, 2012 3:19 pm | Chris_McElligottPark | Note Added: 0020991 | |
| Mar 22, 2012 5:05 pm | Chris_McElligottPark | Note Added: 0021171 | |
| Mar 22, 2012 5:05 pm | Chris_McElligottPark | Status | feedback => resolved |
| Mar 22, 2012 5:05 pm | Chris_McElligottPark | Fixed in Version | => 0.913 |
| Mar 22, 2012 5:05 pm | Chris_McElligottPark | Resolution | open => fixed |
| Mar 22, 2012 5:05 pm | Chris_McElligottPark | Assigned To | Chris_McElligottPark => keith.lamothe |
| Mar 24, 2012 12:50 pm | Penumbra | Note Added: 0021228 | |
| Mar 24, 2012 2:45 pm | Penumbra | Note Added: 0021233 | |
| Mar 24, 2012 2:51 pm | Toll | Note Added: 0021234 | |
| Mar 24, 2012 2:55 pm | Penumbra | Note Added: 0021235 | |
| Mar 25, 2012 12:11 pm | Chris_McElligottPark | Note Added: 0021310 | |
| Mar 25, 2012 12:29 pm | TechSY730 | Note Added: 0021312 | |
| Mar 25, 2012 12:30 pm | TechSY730 | Note Edited: 0021312 | |
| Mar 25, 2012 12:30 pm | Chris_McElligottPark | Note Added: 0021313 |
