Still Getting Hit By Held Mobs

[Ringlord]

I ran my weekly loot runs for cash of the giant caves with my guild leader last night and we still took hits from boulders or the club of the giant that was currently being held and the fire giants would also cast fireball at us on occasion as well.

I think it was happening less than it used to, but I have to say nope they did not get the problem fixed yet Oh well as long as there is progress.

[Qzipoun]

Are you surprised?

They indeed do it less often, but still do.

A guildy brought up an interesting point, they clearly have the coding done right for trips and commands. The enemy just lies on the ground and does not attack. So why not apply the same coding to being held/stoned with very minor changes to animation (so they're not on the floor ) and add the auto-crit.

[Mad_Bombardier]

A guildy brought up an interesting point, they clearly have the coding done right for trips and commands. The enemy just lies on the ground and does not attack. So why not apply the same coding to being held/stoned with very minor changes to animation (so they're not on the floor ) and add the auto-crit.

Nope. Just this week, there were screenshots in another thread of a guy making rolls versus trip while facing a tripped/prone worg.

[Palmetto]

I think it was happening less than it used to, but I have to say nope they did not get the problem fixed yet Oh well as long as there is progress.

The theme of half-ass fixes to bugs is nothing new to this game.

Remember when they finally fixed SC?

Why on earth would anyone expect anything different?

[Jomee]

Nope commanded/tripped mobs still slide around the floor, also held ones hit on occasion.

[Missing_Minds]

saw a kobold get held yesterday ins smuggler's warehouse.. and then it took off like a bolt. I mean it was as if it went "yark! I'm held.... fleeeeeee!!!!" because it took off, blue chains and all.

Running the orchard 2 nights ago saw one of the rats get flesh to stoned.... and it was still running. I mean we had this moving statue chasing us. That happened not just once, but many times.

I mean how bloody hard is it to add a canPreformAnyAction check before the mob actually does anything?

[jjflanigan]

Alright...having worked on smaller games and lots of other programs before...this one boggles my mind how it can't be fixed. Assuming you have a class for the MOBs and that class has event handlers for moving, attacking, etc. Just check the state of the mob and, if it's in one of the "halt" states...don't fire off the events for moving and attacking. Should be simple If/Then/Else. Even taking it out to the level of complexity I'm sure the new AI system added...you should still be able to break out of the AI functions for movement and attacking if the MOB has a halting effect on it (or just don't make the call to the functions).

Hire me turbine, I promise to help fix a lot of these bugs, a new set of eyes can only help in debugging huge code projects.

[Talcyndl]

Alright...having worked on smaller games and lots of other programs before...this one boggles my mind how it can't be fixed. Assuming you have a class for the MOBs and that class has event handlers for moving, attacking, etc. Just check the state of the mob and, if it's in one of the "halt" states...don't fire off the events for moving and attacking. Should be simple If/Then/Else. Even taking it out to the level of complexity I'm sure the new AI system added...you should still be able to break out of the AI functions for movement and attacking if the MOB has a halting effect on it (or just don't make the call to the functions).

Hire me turbine, I promise to help fix a lot of these bugs, a new set of eyes can only help in debugging huge code projects.

I would assume (yeah, I know) that the difficulty lies in syncing things given network latency.

[Missing_Minds]

I would assume (yeah, I know) that the difficulty lies in syncing things given network latency.

No, in this case JJ is right. The state of the mob is what is in question. Then again we don't even know if the mobs are running through states or not. network latency would only effect initial slides when the mob is held, not the continuing actions.

JJ, if you really want to help them, you know where to toss your resume at. That link has been posted before.

[MTG]

I was farming tangle root last night and i didn't free the render and he was runnig around the room.

[Missing_Minds]

I was farming tangle root last night and i didn't free the render and he was runnig around the room.

Ok, now that is funny.

[jjflanigan]

No, in this case JJ is right. The state of the mob is what is in question. Then again we don't even know if the mobs are running through states or not. network latency would only effect initial slides when the mob is held, not the continuing actions.

JJ, if you really want to help them, you know where to toss your resume at. That link has been posted before.

Roight. Since we receive the visual element of the mob being in a "halt state" (held, tripped etc) even when another player causes the effect, we know that the state update is traveling between the source client, to the server and then down to the other clients in range. It's just not getting handled properly for some reason.

And I've been very seriously considering applying for one of the development positions out there, I just am loathe to move at this exact moment.

[captain1z]

A held giant incaped my wizzy after I hit him with a scorching ray he began to throw rocks at me. im squishy

[Talcyndl]

No, in this case JJ is right. The state of the mob is what is in question. Then again we don't even know if the mobs are running through states or not. network latency would only effect initial slides when the mob is held, not the continuing actions.

Unless the "continuing actions" also include attacks. My experience has been that they only do it for a certain period after being held. It's not a continuous thing. And that seems consistent with it being related to network latency issues.

That's a particular problem for DDO because of its "real time" combat. I'm sure there are a lot of fudges to permit real time combat even with significant network latency.

[parvo]

Alright...having worked on smaller games and lots of other programs before...this one boggles my mind how it can't be fixed. Assuming you have a class for the MOBs and that class has event handlers for moving, attacking, etc. Just check the state of the mob and, if it's in one of the "halt" states...don't fire off the events for moving and attacking. Should be simple If/Then/Else. Even taking it out to the level of complexity I'm sure the new AI system added...you should still be able to break out of the AI functions for movement and attacking if the MOB has a halting effect on it (or just don't make the call to the functions).

Hire me turbine, I promise to help fix a lot of these bugs, a new set of eyes can only help in debugging huge code projects.

I think it has something to do with lag. Anything you do at range seems to be problematic.

[Pentastic]

I was really looking forward to this fix as there have been many times that as you solo the initial quests on your wizard, sorcerer, cleric or bard the held, hypno, commanded, etc. creatures still knock the snot out of you. At that low level I just shrug my shoulders, as the xp debt is nothing at all. When you get to the higher level quests and holding a monster or two for your fighters to tank or greater commanding a mob can make the difference sometimes between a cure mod spell and a heal spell or even in the rare occasion a wipe (talking mana points here). I have soloed in the giant hold tor area and the new necroplis area (yawn nothing new) and nothing ticks me off more than a held creature putting me under (after unsuccesful other instant death spells being cast) it is as if that creature is going to get you no matter what (usually after a few succesful named loot/chest runs). Happened before Mod 5 happened after Mod 5. I can not speak definatively to the relative decrease as I have not done this with the same regularity but the fact that it still occurs means that it should not be "checked off the spreadsheet" of outstanding issues - an attempted fix is not the same as fixed.

[Missing_Minds]

Roight. Since we receive the visual element of the mob being in a "halt state" (held, tripped etc) even when another player causes the effect, we know that the state update is traveling between the source client, to the server and then down to the other clients in range. It's just not getting handled properly for some reason.

And I've been very seriously considering applying for one of the development positions out there, I just am loathe to move at this exact moment.

*snaps fingers* you know, I bet I know what it is. mobs have a que that contains the actions they are going to do. For some reason the "hold" state as it were, does not stop the "read que/next action in que" function, so mob is still attacking. The que should really be emptied and not filled again till after "hold" state is removed. "death" should not allow it to become filled either. I don't want mobs getting last breath death shots in.

I mean we can diplomacy a mob, and the mob will still attack for 2 to 4 more times before going away. The que is obviuosly not emptying correctly.

[Riggs]

The difference seems to be much like the difference between Inturrupts and Instant spells in MtG.

Enemy casts a lightning bolt at you for 3 damage, which would kill you say. You tap a mana and cast a lightning bolt back. Both are instants, and so get resolved in order of casting, but they do not prevent other instants. So lightning bolt A goes off, player B drops to 0 life, then lightning bolt B goes off, doing 3 damage to player A. Then everything is added up and player B dies.

If player B casts an Inturrupt instead like Counterspell, the previous spell instead is prevented from going off. Counterspell 'jumps the queue' as it were.

DDO needs Intrrupt actions -as it is clear (I also have been hit with spells/atatcks post mod5 from monsters that should be unable to ), as someone above said - the queue still keeps going even after something is incap/held/tripped/dead. Much the same as when your madly clicking to kill something - and suddenly want to change weapons or block. Stopping attacks and hitting block or swapping weapons doesnt take effect until your own queue is cleared, which usually takes 2 attacks more when when you stop clicking.

Blocking should be an inturrupt, as it is now pretty slow. Taking out a monster by any means should be preventing it from killing you.

It is not lag as jj said when you SEE the effect take place, but monster keeps attacking. If you SEE the effect, then it means it has reached the server.

[Beherit_Baphomar]

My favourite one was a giant in the Tor sliding around stoned...that was funny....

[jjflanigan]

Enemy casts a lightning bolt at you for 3 damage, which would kill you say. You tap a mana and cast a lightning bolt back. Both are instants, and so get resolved in order of casting, but they do not prevent other instants. So lightning bolt A goes off, player B drops to 0 life, then lightning bolt B goes off, doing 3 damage to player A. Then everything is added up and player B dies.

Totally off topic, but I thought MtG used the "stack" so it was LiFo (Player A would die first)?

It's quite possible that it is related to actions being "queued" for MOBs, however that only works to a certain extent since they would obviously have the logic in place to "jump the queue" since if you are fighting toe-to-toe and step backward, the MOB will stop it's attack long enough to come towards you again. If they can do JIT queue changes for the MOB actions, one would think they could just as easily flush the queue so the mob stops moving / fighting immediately once the server parses the "halt" action.