Hunting and Creature Behavior Suggestions

[Kryos]

This has been mentioned before, but I believe the topic deserves revisiting in a new thread.

1)  Creatures that are not moving stealthfully, especially extremely large creatures, should be visible when moving about or approach without having to 'look' for them or 'watch a direction.'  10 tons of pure anger known as a Mekillot should not be able to ninja-teleport into melee range with a:

Code Select Expand


A ruddy brown mekillot arrives from the west.

A ruddy brown mekillot claws your head, inflicting horrendous damage.

Your vision goes black.

>flee

You cannot move while asleep!


I purpose this because having worked on the code of muds before to the point of making one for my job, I believe this is an extremely low cost, high value change.

A practical implementation of this would be a string that is emoted to nearby rooms (radius, 1, 2, 3 based on size) when a creature moves, unless it is moving stealthfully.  Then you have your typical scan vs stealth contest.  This applies to PCs(who are small(1) And mounted PCs (Who are bigger(2))).  This is probably best only for outdoor areas (not the streets of cities).

2)  When a monster is going to spawn, you should get a warning.  While kneeling down and skinning that gurth you worked so hard to kill, you should not suddenly find yourself standing next to a gaj because you happen to be at its spawn location.

This, I believe, is a bit more complex to implement, but warning and a brief stall on the spawn in the room is occupied would be tremendous.

There are other, more in depth suggestions I would make, such as animal behaviors changing to make some sense (other then some being utterly dormant, seemingly brain damaged additions and others being psychotic pcp smoking berserkers killing anything that moves) but while the return is high value, the cost is also high.

[greasygemo]

I've often thought gigantic animals suddenly emerging from an adjacent room was jarring. Like.. Er I'm standing in an open grass plain. I guess I didn't notice that ginormus met walking over though because I didn't stare westward..

Even if the emote was something like, "You hear shuddering footsteps to the north" or "You see a large shape from the corner of your eye to the west". Something that alerted you to look like one might assume a ten ton lumbering animal approaching would weather you were actively looking or not.

Also, listen skill.. Why you no detect approaching figures? I can hear a muffled conversation behind a door but not the rampaging monster barreling towards me?

[Kryos]

Also, listen skill.. Why you no detect approaching figures? I can hear a muffled conversation behind a door but not the rampaging monster barreling towards me?

Agreed, but small, crisp, incremental suggestions one at a time, I think that's the ticket.

[FantasyWriter]

There are currently things that happen in game that echo into ajacent rooms (off the top of my head '>shout', certain magicky things), so it is certainly possible. I too, would like to see large creatures/mounts movements added to the list. Wagons, also.

Edited to add: And combat.

Code Select Expand

The clash of battle can be heard coming from the east.

[Maker]

I think the "spawn on top of you" solution wouldn't be so difficult to code if you implemented a spawn area rather than a spawn point.  So, instead of a mob always spawning in the same room, it could spawn randomly in, say, any room within a range of 2 rooms from the center, omitting any room occupied by a PC from the selection.

[FantasyWriter]

Or just not let animals spawn in the same room as PCs.

Or this:
Second   1: Animal spawns <ten second delay before it can do anything>
Second   1: Beast-specific echo: a wild, mangy gortok crawls sleepily out of its den.
Second 11: A wild, mangy gortok claws you in the face.

Mek: A ruddy brown mekillot trundles through the area, oblivious to your presence. (for a little while )
Carru: A something something carru wonders into sight, head down foraging through the grasses.
etc.

[Kryos]

I think the "spawn on top of you" solution wouldn't be so difficult to code if you implemented a spawn area rather than a spawn point.  So, instead of a mob always spawning in the same room, it could spawn randomly in, say, any room within a range of 2 rooms from the center, omitting any room occupied by a PC from the selection.

Could flag the mob as invis when it spawns in a room with a pc, make it inactive, send the emote, wait 5 seconds then uninvis and make it active.  Could send it off in a random direction a few rooms away.  Could simply have it to wait to spawn till the pc leaves, etc.  One of the beauties of coding, at least for me, is finding creative solutions.  But speculation is also moot without having the source or knowing the source (I don't know DIKU well did socketmud and then original work). 

Many options, but we leave that to the talents of Morgenes and Tiernan.

[Maso]

Ohhh, this would be awesome. I like the spawn echos...

And for meks and mets getting close....something as simple as 'the ground shakes around you' would be helpful, especially for those awkward diagonal moments.

[Lizzie]

Some of the frustration, I think, is because Armageddon code doesn't include diagonal directions. So if I'm standing...

here.

And I'm moving south...

I have no way of knowing that there is a mekillot immediately to the west of that southward room I'm about to move. It's only ONE room away from ME...to the southwest. But I can't tell it's there because "southwest" isn't a valid coded directional in the game. There is only a grid of north/south/east/west/up/down.

Since the diagonals aren't, and since trying to add them at this point would probably be a huge mess...

Adding an echo whenever a non-PC mob that is a) visible b) aggro c) within a 2-room radius *on the grid* is present...

would be helpful.

An additional echo when there's combat would be great too, but it's not nearly as common as running into an aggro mob simply because you weren't able to look southwest.

(edited to add yes I know there's also in/out, but in/out aren't part of the grid so I didn't include them)

[Kalai]

Listen echoes terrify me and I am all for more of them.

[Synthesis]

You know, I don't recall anyone ever proposing this particular solution for the problem.  It's always been some variation on diagonal looking.  I like it.

[Maso]

Listen echoes terrify me and I am all for more of them.

Totally!

Code Select Expand



You hear the slow crackle of snapping twigs and branches.

> runrunrunrunrun



[Dalmeth]

It seems to me the greater problem lies in the difference between the mob's ability to detect and act on a nearby PC and the PC's ability to do the same.

You could just add a delay between the time between when a mob detects a PC and the moment in moves.

You can say you should be able to see a big, bad monster in an adjacent room, but then it should be able to see you, too.  So you don't really solve much.  This is just part of the game.  However, if a reasonably equipped PC has no time to respond to the entrance of a massive, charging monster, then you just give the player more reaction time.

[Synthesis]

You -do- have some time to react.

A long time ago, mobs didn't have any movement delay at all, and they would attack you within milliseconds of entering the room.  Nowadays, their time-to-attack is determined by their movement speed*, so you -can- outrun them, if you're faster.

Of course, it seems like time-to-react might be too brief, since mobs have instant reaction time, no net lag, and no delay for typing speed.  That can't be more than a few hundred milliseconds in total, though.  My guess is that the vast majority of people getting pwned by mekillots and bahamets these days are getting pwned because their PC is slow on foot or riding a slow mount, or are delayed due to issuing a command like forage or scan.  In my past experience, a mekillot will catch a beetle** (the most common southern mount) within 2 rooms if you don't switch it to running, so you have to be very careful to make 'run' your first command.  If you spam directions before changing speed, you'll get caught.

That being said, I'm still in favor of the idea proposed by the OP.  If we were to fix the problem with reaction time, I'd suggest treating the first aggro-move into the PC's room different than subsequent aggro-moves.  That is, make the first movement delay substantially longer, but leave movement delays during the chase phase the same (pegged purely to movement speed).  There's clearly some sort of "mob memory" flag, since tracking animals remember you, so I imagine a similar code construct would apply, just alter the behavior resulting from the flag.

*However, if an aggro mob is following another mob, the follower does not suffer from movement delay, and can still attack you instantly.  I'm sure many people have bugrepped this, but it remains a substantially annoying bug, especially in the context of certain bugs.

**Movement speed may vary between beetle types...I haven't really quantified it.

[Kryos]

I would hope what I'm proposing is part of what is slowly incremented up in giving a big change to the 'feel' of outdoor life.  Being able to see gigantic killing machines headed your way from a bit of a distance and not getting an ankheg spawned on your head with no warning/emote  is just a 'quality of life' change that I believe will be of benefit to most who spend time outdoors in Arm.  Its frustrating, instead of 'dangerous'.  In the end, I hope outdoor life is a bit more . . . interesting.

I would love it eventually, if different critters had different behavior patterns depending on the time of year (mating season, birthing season, a sluggish season, and so on), how hungry they are (over hunting gurth leads to swarms of pants wielding raptor attacks, news at eleven), if archery was updated to feel more like 'hunting' was just that (shoot it in the neck and sure, it'll run for a while, but then it'll bleed out.  You've probably scared all the other small game away, but . . . oh god was that a tembo I just saw?) and most importantly, if predators and prey behaved a bit more like their intended types (say 'clever girl' really would have a point because a bunch of lumber-axe wielding raptors ARE flanking you as you chase the open one).

I just think it has to be kept to very small, quick implementations.  Suggesting big projects from the player side has an extremely low % of success(based on my observation), and they may be working on cooler business that is high return as well.

You -do- have some time to react.

A long time ago, mobs didn't have any movement delay at all, and they would attack you within milliseconds of entering the room.  Nowadays, their time-to-attack is determined by their movement speed*, so you -can- outrun them, if you're faster.

I think generally, yes.  However, I have lost a PC within the last year due to something extremely large arriving in my room and instantly head shotting me into a bad place.  And I do mean before the time I could pop a flee alias. 

Having things move at different speeds well, that is really something someone should learn about ig.  But animals and people moving at different speeds really does make cat and mouse more interesting . . .

P.S.  Gith ( you know what I mean) are just frustrating too.  Its not 'harsh' when it feels like more of a slap in the face(see ARMrage).

[Dalmeth]

You -do- have some time to react.

I think a large part of the ongoing complaint is that some of the largest, reel-locking creatures are actually quite fast, and many of the common animals are not fast enough to outrun them.  I'm not concerned with sharing that bit of IC info, because it's something that should be plastered somewhere easily accessed and often read : that there are some riding animals that will get you killed.  Couple that with the sometimes serious delay between entering a command and the MUD responding, people do have cause for complaint.

Thing is, making the delay longer between detection and action or adding a special echo for diagonally located nasties essentially increases response time.  Given how spammy the game can already get, I'm less inclined for more lines of text.  It's pretty simple.

[musashi]

Large animals are supposed to run fast. That's why in RL you can't outrun an elephant. Big legs. Covers ground quickly.

Size and movement rate going together makes fine sense to me. What we lack I think is a size modifier to actually hit stuff when you're huge and its small. You can easily outrun a mouse in a straight line race IRL. But for anyone who has ever tried to catch one with their hands ... those little buggers can dodge, duck, dip, dive, and dodge.

But once you get ahold of them one time, they aren't going anywhere. I think mekillots and bahamets function similarly.

[Kismetic]

Musashi has a point, though, the big animals do behave correctly.  However, I'm in total agreement that you'd see that walking house come your way.  Be cool if we could get this code change.

[musashi]

It's kinda the same reason dwarves can't outrun half-giants.

[Maso]

If we're using RL animal behaviours as examples for Arm animal behaviours...then it should also be considered that herbivores (for example carru) or other creatures that would not consider humanoids good eats would not be territorial against humanoids (e.g. not aggressively moving into rooms with PC's) and only become aggressive if someone moves into a room with them, and should be content with scaring someone off not chasing them and killing them.

[Schrodingers Cat]

I've always wondered if riding empty handed increased my riding speed.  I guess I'll have to find out IC.

[Kryos]

Indeed, I'm not advocating changing the fact they are hella dangerous to most people.  Just that you should see your death coming. 

In fact, it would be really cool if a hungry <killing machine> decided that you were lunch, it would chase you as long as it could, in turn, see/sense you, better then the 1 room situation that now exists.  It would make outdoorsmany type hunting skills much more valued, or the ability to run away fast.

[Dalmeth]

Large animals are supposed to run fast. That's why in RL you can't outrun an elephant. Big legs. Covers ground quickly.

Size and movement rate going together makes fine sense to me. What we lack I think is a size modifier to actually hit stuff when you're huge and its small. You can easily outrun a mouse in a straight line race IRL. But for anyone who has ever tried to catch one with their hands ... those little buggers can dodge, duck, dip, dive, and dodge.

But once you get ahold of them one time, they aren't going anywhere. I think mekillots and bahamets function similarly.

Hmm?  Didn't actually say to slow down the animal, just make it take longer to act after detecting a PC.  That is, after all, why a large animal finds it hard to catch a smaller one : they need to build more momentum.

[musashi]

The post movement delay is the metric by which "speed of travel" is determined IG.

So yeah, that's what you're asking for.

[hyzhenhok]

The post movement delay is the metric by which "speed of travel" is determined IG.

So yeah, that's what you're asking for.

No, the suggestion is to delay the NPC's reaction upon first detecting a PC. Not to delay it every time it moves into a new room during the chase.

[RogueGunslinger]

The post movement delay is the metric by which "speed of travel" is determined IG.

So yeah, that's what you're asking for.

No, the suggestion is to delay the NPC's reaction upon first detecting a PC. Not to delay it every time it moves into a new room during the chase.

I honestly don't think this is needed.

[musashi]

Ah, I misunderstood. I guess I'd be ok with that, I suppose, but only if it could somehow be coded in such a fashion that it's only the first movement the critter takes that has a pre-command delay.

Because if the mekillot sees you, waits a second or two, then runs in but you run out ... it's got post-command delay and pre-command delay again. And I think that would make it too easy to run away.

[Dalmeth]

Ah, I misunderstood. I guess I'd be ok with that, I suppose, but only if it could somehow be coded in such a fashion that it's only the first movement the critter takes that has a pre-command delay.

Because if the mekillot sees you, waits a second or two, then runs in but you run out ... it's got post-command delay and pre-command delay again. And I think that would make it too easy to run away.

I think you got confused between Synthesis's argument and mine, where he spoke of a greater movement delay on the first move, and I just wish for a more regular delay before movement on spotting something it should be aggressive to.

I tend to favor my method, because it allows for outright stupidity, where a person simply may not look north and see the mekillot.  As much as people say that you should be able to hear a giant beasty coming, the truth is people get distracted.  Some minimal level of awareness should be required.

I honestly don't think this is needed.

Perhaps a significant change isn't needed, but at the very least, we need to make the delay before an aggressive creature moves regular.  Last I checked, it could vary from a few seconds to almost instantly, and even using a macro to run can get you killed.

Movement speed is the only thing that will save you from some beasties that will kill you for doing nothing better than salting or hunting rittikki.  It isn't a matter of entering their territory or something else you could avoid, it's a matter of a random number generator not rolling against you.

Not to say there isn't a way you can be immune to all this, but it does require a particular style of play.  I'm open to allowing still further styles of play.

[Nyr]

Perhaps a significant change isn't needed, but at the very least, we need to make the delay before an aggressive creature moves regular.  Last I checked, it could vary from a few seconds to almost instantly, and even using a macro to run can get you killed.

This sounded familiar--I knew we'd covered this before, and I knew that I'd tested this and also responded to it before.

If you have specific evidence (with timestamps) that shows a mob entering a room and attacking within a half second, please submit a request with your time-stamped log.

All NPCs should have a delay before they can attack after moving, same as PCs.  If they don't, it's a bug and needs to be addressed.  But we don't have anything other than anecdotal evidence of this occurring.

I tested an NPC going through a series of scripted movement commands to attack a non-aggressive NPC a few rooms away.  I then switched out of the NPC and went to the room and waited to watch.

It eventually got to the room.

It did go through the same movement lag before attacking.

I tested an NPC group as well.

Three similar NPCs, all in the same room, were set up to follow one of these NPCs.  I named it Spanky.  One of the followers I named Bill.  I switched into Spanky and ran through movement commands to a non-aggressive NPC a few rooms away.  I switched out of Spanky and into Bill.  As soon as our group got to the target room, I hit "Kill target."  I had to wait.

Yeah, so far, nothing I'm finding does an instant attack with no movement lag.

Now working on nearby room aggro attack testing with multiple NPCs. 

Yes, it happens quickly. 

No, it is not instantaneous, and is (in fact) exactly comparable to the exact scenarios I described earlier.  It seems faster because you are going apeshit (appropriately) over reading the roomspam of things entering the room.

They all work the same, yes. Text-based games may transmit quickly over the interwebs (comparatively speaking, w/r/t graphical games), but we are talking about a matter of only a handful of seconds.  

Nyr ... test it with kryl ...  

Groups of kryl ... *shivers as the nightmares return*

Was just about to send in a request with this. Lost more than one PC... I will send it still.

I checked out a special attack that is set on a particular NPC that folks may be worried about with this change.   That special attack also will not fire off if the NPC is in a wait state (such as waiting from movement lag).  Note that there is not movement lag inside the room itself, so if (for instance) npcs are breaking off from a "pack" npc due to, say, another script...that is not considered "movement."

I don't mean carru by any of this testing, though.  That's intentional.

I can't really get more specific than this.

Yes, kryl are included in the "they all work the same way."

Gah, I keep skimming through my brain and coming up with more to say.

Yes, kryl are included in the "they all work the same way."

Well, there is one group of kryl set to follow a, "leader," so they may be a subtle modification that was overlooked with previous changes.

I checked them too

No, it is not instantaneous, and is (in fact) exactly comparable to the exact scenarios I described earlier.  It seems faster because you are going apeshit (appropriately) over reading the roomspam of things entering the room.

I'm not so sure about that....

I do recall having an AI agility character get beetle'd after loading my command queue down with "n n n n n n n n n n n n n n n n".

Was one of those situations where I was merrily riding northward, wild beetle pops in from the east, attacks, knocks me off my mount, I flee and then spam north and it caught up to me after a couple of rooms and eated mai character.

Though... This was sometime last year, or maybe even the year before, and it may have been caused by lag more than anything.

or it was running and you weren't (or your mount is slow as poop)

or it was running and you weren't (or your mount is slow as poop)

To be fair, yes, PCs are faster than most animals that could kill them instantly.  However, only a handful of mounts, which most PCs use, are as fast or faster than the player, and those mounts tend to be expensive or rare.

Though it is worth noting that one of the fastest mounts is also one of the most common.

Right.  That doesn't point to there being a problem with NPCs not having movement delay prior to attacking, though.  So far, I've yet to duplicate a single scenario mentioned, after multiple tests.  I will continue to try and find one, but so far people are reporting that this is intermittent, only happened once or twice with them, etc.--yet all scenarios are different, with different NPCs, NPC groups, and programs involved.  Even with that accounted for in testing, I am still unable to duplicate, which leads me to point towards connections, movement delay on the part of the PC, and player perception.  Even I was affected by the last bit during testing.  I had to use a timer to be sure that the delay was comparable; I was sure that I'd found something but it was approximately the same amount of delay.

[Synthesis]

Either something's wrong with your test that's giving you bad results, or the wait state on certain grouping mobs is near-zero.

[Nyr]

Either something's wrong with your test that's giving you bad results, or the wait state on certain grouping mobs is near-zero.

I don't see your results in the request queue with a time-stamped log, and I tested every single suggestion people had, so I'm going to go out on a limb and assume that the anecdotal evidence in your case does not trump the data.  We will need more direction than "I've got a feeling this is wrong."  Please submit a request and let us know what we have not looked at.

[musashi]

Oh yeah ...

Well ... well ... you're a neener.

[Maso]

I lost my 'Nyr'd' image. 

[Akaramu]

I lost my 'Nyr'd' image. 

Noes 

It shall be mourned.

[Nyr]

I lost my 'Nyr'd' image.  

just curious, but if I go back through your posts and find it, is it too meta for me to

[Synthesis]

I don't know what exactly the problem is with reproducing this issue from the staff side.  It reminds me of the first-round NPC double-attack bug that was ruled "not a bug" because supposedly PCs have the same chance of it occurring in their favor, but everyone knows this just ain't so.  I'd go and test it again to make sure to myself that it's still happening, but unfortunately I'm not in a position to be able to do that.

[Maso]

Too late, you did it anyway.

[Nyr]

I don't know what exactly the problem is with reproducing this issue from the staff side.  It reminds me of the first-round NPC double-attack bug that was ruled "not a bug" because supposedly PCs have the same chance of it occurring in their favor, but everyone knows this just ain't so.  I'd go and test it again to make sure to myself that it's still happening, but unfortunately I'm not in a position to be able to do that.

I'll take a look at this issue once more.

As for the main idea presented by this thread, I'm not really sure that's an "easy" code change.  Easy to discuss, sure...but ease of implementation should be left to our fantastic coding staff.

[Maso]

In the meantime, just have Storytellers watch all roaming PC's and send room echoes whenever something is within the range that should technically be visible but isn't.

[Nyr]

I don't know what exactly the problem is with reproducing this issue from the staff side.

Without getting into a lot of detail, it really is exactly what Morgenes and I were saying over and over:

We needed more data.  

I grabbed the results we had from our last testing sessions (about a year ago) and went back into testing, throwing things out there to try and make something stick.  Long story short, there was another script involved that was creating this problem, and this one required other variables in play to make it function (or malfunction).  Thanks to Morgenes, it has been fixed.

[Euphoric Nightmare]

opps...resolved

[Dalmeth]

Either something's wrong with your test that's giving you bad results, or the wait state on certain grouping mobs is near-zero.

I'm inclined to agree, but it's not with specific mobs.  It seems more like the move is a scheduled action, and sometimes, it's so quick after a pers0n enters the room, that you spend a whole second just realizing it happened.

It's not a regular thing, but the time in which a mob reacts to an entering PC is variable.

[Nyr]

Ok, so the issue we actually found isn't the issue we actually found?

[musashi]

Exactly. But not at all.

[Dalmeth]

Ok, so the issue we actually found isn't the issue we actually found?

No.  To say that sometimes aggressive NPCs attack instantly or that the response time to a particular NPC is variable is largely saying the same thing.

[Nyr]

Ok, so the issue we actually found isn't the issue we actually found?

No.  To say that sometimes aggressive NPCs attack instantly or that the response time to a particular NPC is variable is largely saying the same thing.

We're not saying that, though.  In fact, we've found that aggressive NPCs do not (and should not) attack instantly.  We found a bug in a script that allowed this to occur with a particular NPC type.  We fixed it.

[Maso]

The room echoes would still be cool though. More just for...coolness. And atmosphere. Worrying about a split second here are there and attack delays is for nerds. 

[evilcabbage]

I've experienced this double-attack bug, on the receiving end. It is not nice at all. I have yet to perform the double-attack, unless I'm wielding two weapons! So would I get a quadruple attack if the bug kicked in my favor?

[Nyr]

I've experienced this double-attack bug, on the receiving end. It is not nice at all. I have yet to perform the double-attack, unless I'm wielding two weapons! So would I get a quadruple attack if the bug kicked in my favor?

[Kryos]

My poor thread.

But as to the discussion at hand.  Nyr, in the case mentioned, at least as I've experienced it in limited fashion, you need to have two "aggro mobs" i.e., a player and some type of NPC that would be attacked by the 2nd NPC (the insta attacker) fighting.  The insta attacker moves into a bordering room.  Following its script, it then moves into the room with the fight and swings with nearly no delay.

In my case, this happened with the no-delay beast being a bahamet, if that's useful.  That being said, as advised, if I find myself believing this situation could arise again, I'll log it and use time stamping to give additional information.

On the other hand, any chance of seeing horrible death machines coming?

[Morgenes]

Ok now assisting is something we haven't looked at. Good point. I'll look at that ASAP

[Dalmeth]

We're not saying that, though.  In fact, we've found that aggressive NPCs do not (and should not) attack instantly.  We found a bug in a script that allowed this to occur with a particular NPC type.  We fixed it.

This is a separate issue.  Let me put it this way :

Code Select Expand


> e

Next Room [NSEW]
Blah, blah blah.  Blah-blah, blah blah blah blah.  Blah, blah blah.  Blah-blah, blah blah blah blah.  Blah, blah blah.  Blah-blah, blah blah blah blah.
Blah, blah blah.  Blah-blah, blah blah blah blah.  Blah, blah blah.  Blah-blah, blah blah blah blah.  Blah, blah blah.  Blah-blah, blah blah blah blah.
Blah, blah blah.  Blah-blah, blah blah blah blah.  Blah, blah blah.  Blah-blah, blah blah blah blah.  Blah, blah blah.  Blah-blah, blah blah blah blah.
A giant, ruddy-skinned mekillot has arrived from the north.

> l n

> l s

You look the north :
Nada.
PLAYER THINKS : Holy Shitmonkeys on a stick!
> l e

You look to the south :
Nada
> run

You look east :
Nada

> w

You start running.

> w

A giant, ruddy-skinned mekillot attacks you.
A giant, ruddy-skinned mekillot bites you, doing horrendous damage.
You reel from the blow.

> w

You are in combat and cannot escape, type FLEE.
You are in combat and cannot escape, type FLEE.

>

You are in combat and cannot escape, type FLEE.


This is not always the way it happens.  Sometimes, the NPC will stay in its own room for a full second before entering, and there's the problem.

There are times where doing the cautious thing and looking both ways when you enter a room can cost you precious reaction time you need to escape.  Looking both ways or just looking at that line that snuck onto the bottom of the room text can cost you the time you need to flee.

So the reaction time given to a player is variable, and a mere handful of commands can be the difference between life or death.  It's depressing that doing the smart thing, being as aware as the code can let you be, can get you killed based on chance.   I said let's make sure the NPC stays in the room long enough to be seen.  Synthesis said let's make sure the NPC's first move gives them reasonable time to escape on a decent mount.

Either way, I think this is something that could be improved.

[Maso]

Isn't the biggest problem not realistically being able to stay a safe distance from said creatures in the first place, because they are hiding in those awkward diagonal rooms. Most people wouldn't be within a stones throw of a 'met out of choice, and yet end up getting tangled up in them because they simply didn't know they were there. And scouting out the diagonals simply puts you in the same danger because you can't see the diagonals...off those diagonally placed rooms...If that makes sense.

[MeTekillot]

The way movement seems to work is there's a 'build-up' time after entering a room to where you're allowed to move to the next room. The thing with this is that if you're in a room long enough, you can move in any direction instantly. Why not alter that game-wide to where it's the same amount of time to move from room to room, but the build-up time stops about half-way and only continues upon input of a movement command?

With queued movements there'd be no difference, is what I'm saying. I know very little about code, so I don't even know if this would be viable or even possible.

[MeTekillot]

And as a separate idea and thus a separate post, would it be possible to give mekillots and bahamets a sort of room-desc thing that broadcasts a certain number of rooms from them so that you see "You see a large shape very far/far/nearby to the southeast."

[Dalmeth]

Isn't the biggest problem not realistically being able to stay a safe distance from said creatures in the first place, because they are hiding in those awkward diagonal rooms. Most people wouldn't be within a stones throw of a 'met out of choice, and yet end up getting tangled up in them because they simply didn't know they were there. And scouting out the diagonals simply puts you in the same danger because you can't see the diagonals...off those diagonally placed rooms...If that makes sense.

This is where your language can trip you up.  How is that mekillot or bahamet hiding?  Besides, when you see it, why can't it see you?  Why won't it chase you down from a diagonal room the exact same way it would from an adjacent room?

So, running away is the method by which you, "keep your distance."  We just assume that getting attacked is what happens when you don't keep your distance.

Remember, this is a game, and it's important that you don't make your  rules to simulate real life (no rule can), but make sure they generate consistent statistics.  This is all an abstraction, so you can't translate your experience in-game directly to a real life situation.

My problem is the reaction time available to a player is not consistent, and at times, suspiciously beyond the threshold where a player on an average connection can be expected to respond.  Let's just forget about those people with bad connections.  That's just depressing.

[Morgenes]

Per my earlier post, from my desk check of the code, NPCs assisting each other should be subject to the same wait conditions on movement as simple aggression.

[Kryos]

Thanks for checking up on that, its appreciated.

It indeed felt devlishly fast, but, time is subject to perspective and perhaps I flinched before trying to flee and thusly was obliterated.  Maybe the bad has a lot more agility then would be expected from a outside perspective.  Stuff happens.