Do something about .configure delay. Give developers full control over it, make it function better on its own, add options for it in the pager, remove it completely, or some other crazy plan never before dreamed of by the craziest of all crazy dreamers.
As far as I can tell, its just a client sided version of tick_lag, which does nothing but forcibly degrade the gameplay experience in an imaginary attempt to ease poorly handled lag. I've had it increase on me because I was downloading a file, and then never return to normal until I re-logged on the game, and it can't even be manually restored in games with control_freak. I also hear it can be used for abuse in games by setting it insanely high, though I'm not sure if I've ever had issues with that. At absolute least, a detailed description of its supposed functionality would be nice.
ID:105326
Dec 4 2010, 7:15 pm
|
|||||||||
Redundant
| |||||||||
Maximus_Alex2003 wrote:
I made this suggestion in SuperAntx's Feature Request a while ago. You can macro it with any case that isn't EXACTLY '.configure delay #', if you change it to '.configure Delay #', '.CoNfiGure delay #', etc., then it works. Bug? Intended? I dunno. |
Just wanted to bump this, as well as provide an interesting find of mine:
Calling: winset(src.client, null, "command= .CONFIGURE DELAY [counter]") (1) The current network-delay. (2) Whether client-sound is on or off. (3) The last accessed file-url. (4) Whether client-graphics-rendering is on or off. Why are we allowed to do this, but just can't simply GET a value of network-delay and then actually make it useful by being able to force-call .configure delay #. |
The most you can really do right now is set it in a macro as .CONFIGURE DELAY #
http://www.byond.com/members/ DreamMakers?command=view_tracker_issue&tracker_issue=2318