Update 5/19/2007

[Vitoc]

Added movement delays and a command "stacking" system to compensate for any other commands that have a delay.

It will probably need a little work, but it appears to be functional.

[DeathCow]

Ew...movement delays.....I guess I wont be taking anymore 2000 room jogs.  Now how will I crash TCA's comp?

[The Crazy Animal]

Ew...movement delays.....I guess I wont be taking anymore 2000 room jogs.  Now how will I crash TCA's comp?

na that was just securecrt having trouble swallowing.

[DeathCow]

hawt

[Faceless thing]

These delays  I dont think they are working right im none and im moving like im heavy

[Ian]

phew, I thought it was just me!

[Vitoc]

Sorry, I turned them down a bit this morning.  Now the minimum delay is .5 seconds.

Just a note, the movement delays don't just change at 66% like in Major MUD; we're using a sliding scale.  For every 1% of enc you get a 20 ms penalty (might lower that to 10 or 15, we'll see).  So currently the max penalty at 100% would be 2.5 seconds (.5 + (20 * 100)).

People running around at none/light should have some sort of movement advantage over people at medium or near heavy.  It didn't make sense that people with 65% enc were running around as fast as people at 0%.

[Sam the Banana]

Sorry, I turned them down a bit this morning.  Now the minimum delay is .5 seconds.

Just a note, the movement delays don't just change at 66% like in Major MUD; we're using a sliding scale.  For every 1% of enc you get a 20 ms penalty (might lower that to 10 or 15, we'll see).  So currently the max penalty at 100% would be 2.5 seconds (.5 + (20 * 100)).

People running around at none/light should have some sort of movement advantage over people at medium or near heavy.  It didn't make sense that people with 65% enc were running around as fast as people at 0%.

That is totally awesome.

[DeathCow]

Well fine, I suppose if vitoc updates I should as well.  I was going to upate last night, but I wasnt exspecting the coding changes vitoc made with normal type rgen, so I decided it would be best if I scanned over all the room to make sure we wouldnt have giant beasts rgening all over the place. 

That being said I go about 200 rooms in when I realized I wasnt going to be able to stand scanning 20k rooms last night.  So I'll try to get an update for today. Not that I actually know what I've changed in the database since the last update, but I'm sure I've changed something.  Can you find it? :P

[Vitoc]

Cool, let me know when you have a file for me dc.

Back on the topic of movement delays, I'm thinking about making it so parties can only move as fast as their slowest party member.  I know that's a big change over mmud, but it makes sense, doesn't it?  If someone typically takes 2.5 seconds to move from one room to another, how are they all of a sudden going to be moving faster just because they're following someone?

[DeathCow]

I don't think I'll be working on it anymore today, so I'll go ahead and compile 053107Update.mdb

[Faceless thing]

i know i havent been on in while but  i styill think i am moving slow for being none with one party member and med with 2 others

[Vitoc]

i know i havent been on in while but  i styill think i am moving slow for being none with one party member and med with 2 others

The minimum delay is 1 second, and that's at 0% enc.  For every 1% of enc, you get a 20ms movement delay penalty.

None ends at 16% I think?  With our current system if you were 15%, that'd be 1.3 seconds.  I guess it does seem a bit extreme when you realize in Major MUD you don't see any change in delay until 66%.  I could move the minimum delay to anywhere from .5-.75 seconds, so at the upper limits of no enc, you'd see would be about a second.  Or perhaps if someone is none, don't add any penalty, and only start adding the 20ms per 1% enc movement delay penalty at light enc?  What do you guys think?

[The Crazy Animal]

Moving the start point of enc delay penalty will make the curve harsher.

What about using a secondary penalty curve based on the encumbrance percent that would set the percentage of the calculated penalty to use. So at 100% enc you'd use 100% of the calculated penalty value but at 0% enc you'd use 0 percent of the penalty. I know it sounds like an odd way to do it but it would cause the actual graphed range of the penalty to develop slower. Rather then just compress its effects down between two closer points.

[Vitoc]

Moving the start point of enc delay penalty will make the curve harsher.

What about using a secondary penalty curve based on the encumbrance percent that would set the percentage of the calculated penalty to use. So at 100% enc you'd use 100% of the calculated penalty value but at 0% enc you'd use 0 percent of the penalty. I know it sounds like an odd way to do it but it would cause the actual graphed range of the penalty to develop slower. Rather then just compress its effects down between two closer points.

Either I'm not understanding what you mean or that makes no sense at all.

Code Select Expand

Current way:
% enc   delay in seconds
0 1
10 1.2
50 2.0
100 3.0

If we moved the min delay to .5
0 0.5
10 0.7
50 1.5
100 2.5

If we don't enforce penalty for "none" but keep current 1 sec min delay
Method 1: (starting at 16% you get .02 second delay penalty for every % of enc)
0 1.0
10 1.0
16 1.32
50 2.0
100 3.0

Method 1: (starting at 16% you get .02 second delay penalty for every % of enc *over 15*)
0 1.0
10 1.0
16 1.02
50 1.7
100 2.7
Ugh... thought code handles tabs but apparently not.  Anyway, I think you can make sense of that.  Can you show how your idea differs from any of these options, hopefully with an example like I've provided?