I, along with many others, have tried to tweak the standard to create a much smoother movement system. We all know that the predefined Move() doesn't always react the way we want it to. We have all experienced the delay while pressing and releasing macros, and while moving a mob, witnessed the sliding effect and difficulty changing directions.
So, with a little testing of the obvious, when a macro is held down, it calls the macros procedure (assuming the macro calls one of course) once every tenth of a second. Thats all well and fine and is also common knowledge, but what some don't know is that it takes approximately 1/2 second to react to the macro being held down, and also about 1/2 second delay after the macro is released.
When a macro is initially held down the procedure is called only 5 times in the first second, and every second after, it is called 10 times. Also, when the macro is released the macro is still called 5 times after. That bit of delay on both sides greatly effects the results we are looking for. Even if you cut down the times a procedure is called when a macro is held down to twice, or once every 1/2 second, it still isnt as responsive as I would have hoped for, and if we are talking about a mob moving around, for most games thats pretty slow.
So how can we go about fixing this? Is there anyway as programmers that we can fix this? My guess is probably not. I'm wondering if it could be simplified to BYOND needs a quicker response time to key strokes, or if its a pause while deciding whether the user is holding a key down or just tapping it. Either way, it's been a hurdle us "Dream Makers" have dealt with since I joined this community and im sure far before that.
What are your thoughts on the topic? Do you believe this is something we could see fixed in the near future?
ID:152119
 Jan 23 2008, 7:31 am
|
|
Something like that is possible, but it will still have a delay greater than or equal to the time it takes a packet to travel from the client to the server. Basically, on KeyDown of one of the movement macros, you set a boolean variable which says whether or not the user is moving. You continue to move the character, by use of a loop, until the variable is reset by KeyUp. I don't think this is a very good design model because to be accurate, you have to loop one every frame, but I think it's EXCELLENT for games with delay movement.
Now, I've heard that BYOND has KeyDown/KeyUp functions, but I don't know how to use them. You can use a library called Keystate by Loduwijk to simulate KeyUp/KeyDown. It utilizes javascript, so the client will be required to have javascript enabled in IE. | |
That Keystate library is obsolete. The keyup/down functions are in the interface, under macros, where you can change them to trigger only once (keydown), on release (keyup), or repeatedly (default).
| |
I addressed this issue the other day in this post. It works when used right but it glitches up when you mash the keys around really fast. The whole point of the snippet is to bypass the repeat lag by just instantly sending you off in a direction instead of queuing up the key repeatedly.
If you want to measure how long someone is holding a key then you'll have to start a clock when a key is pressed and then end the clock when it is released. You might have to make independent stop() procs for each key though. Feel free to change or add to it. | |
SuperAntx wrote:
If you want to measure how long someone is holding a key then you'll have to start a clock when a key is pressed and then end the clock when it is released. You might have to make independent stop() procs for each key though. Nope! All you have to do is store the world.time when the keydown proc was called in a variable. Whenever you want to see how long the key has been held down, compare that variable against the current world.time. | |
I think the whole macro system is pretty much [insert word Foomer doesn't use]'d up.
At this point I typically resort to non-repeating movement macros. You can't go wrong if the player has to tap the key every time they want to move. Just don't make huge distances for them to cross unless there's a more convenient way to do it. Besides which, I did a quick test and BYOND doesn't always catch the key-up macro, which pretty much ruins any hope of a customized hold-key-down-to-move setup. | |
You might consider this little snippet I did up. It was primarily-intended for single-player games, and it's not instantaneously responsive to input, but it allows somewhat better detection of what's actually going on with the user and their key states.
[link] I should probably cross-post that into the Snippets DB. | |
Foomer wrote:
Besides which, I did a quick test and BYOND doesn't always catch the key-up macro, which pretty much ruins any hope of a customized hold-key-down-to-move setup. Usually the failure to catch a key-up signal is a symptom of the keyboard hardware itself. Most keyboards I've seen, but particularly Microsoft and Logitech keyboards, support only 3 simultaneous keys. There's a reason for it, of course: because keys all have binary IDs, if you hold down a couple of keys simultaneously it's possible that two keys, with their binary signals spliced together, will add up to some completely different key. The keyboard attempts to prevent this from happening. | |
BYOND should catch a key-up as long as the key-down macro didn't use the Repeat flag. However as Spuzzum noted, keyboard hardware can get in the way as well.
Lummox JR | |
Tell me about it. Why the hell does Move() (and the procedures it calls) have to loop through the contents of a turf TWICE? That's just inefficient. Enter() should simply return an object to be bumped into, or 0 to allow movement. Exit() would of course be changed to be the same. Of course, that'd never happen, because it's break backwards compatibility. Oh well.
This is the result of lag. Nothing you can do about that.
This is a result of your keyboard settings (repeat rate and repeat delay, specifically) and lag. The first has nothing to do with BYOND at all.
The way you deal with lag is that you design your game to not be so dependent on lag.
Near? Nope.