ID:260597
 
It's been a while, I see alot of cool features being added in version 421. Maybe it's finally time for better control of "time" on BYOND? C++ and Java allow you to manage things down to the milliseconds, Byond uses tenths (supposedly it was made for muds not action based games). I'm hoping maybe we can get something a little better if not that much atleast slightly better (hundreds?) ; (.

I'm aware of world tick which lets you speed the whole world up, but that causes lag and I'm not trying to run a world procedure, I'm just trying to speed things up for individual mobs or objects.

There's all these games where they just increase strength. But these days developers are trying to incorporate different methods of progress. Take the speed of the swordsman for example.

The new sword user swings at this rate = Image Hosted by ImageShack.us More experienced user = Image Hosted by ImageShack.us
I'm making this request to give the players the full swordsmanship experience and also for the benefit of future game developers that run into this common Byond limit.
I totally agree with this suggestions. Being able to put things into milliseconds would totally make our icons look smoother.
Because BYOND works discretely in the tick-based system, world.tick_lag is your only option for increasing animation speed. Any separation between client animation speed and server update speed would be a total paradigm shift in BYOND and more or less impossible. =)

There is a plan to convert the existing "frames" setting of the icon editor into multiples of 1/10 seconds instead of multiples of ticks. Then fractional delays could be used in tandem with faster tick_lag settings. However, this would require the client end to be smart about discarding and/or reusing frames in order to conform to the tick_lag animation speed.
full support, it seems to me that it should be more feasible to break the tick 1/10 limit on just graphics for now anyway, and i know it would be a great thing for everybody.

I'm with you. I've wanted a feature like this for a while because some animations don't look that great at the current delay we have available between frames.
In response to Jtgibson
Jtgibson wrote:
Because BYOND works discretely in the tick-based system, world.tick_lag is your only option for increasing animation speed. Any separation between client animation speed and server update speed would be a total paradigm shift in BYOND and more or less impossible. =)

Well, that's not really true. We currently sync the client to the lesser of the tick_lag and 100ms, but we could easily adjust the latter to a lesser number if such movies are playing. It might be kind of inefficient since we blit the whole map each time, but I'm sure we could eek out a factor of 3-4 at least without much trouble.

That said, we're getting this 420+ series and a few website things stable before moving onto new features. I like the suggestion though.
In response to Tom
Tom wrote:
Well, that's not really true. We currently sync the client to the lesser of the tick_lag and 100ms, but we could easily adjust the latter to a lesser number if such movies are playing. It might be kind of inefficient since we blit the whole map each time, but I'm sure we could eek out a factor of 3-4 at least without much trouble.

That said, we're getting this 420+ series and a few website things stable before moving onto new features. I like the suggestion though.

Sounds like awesomeness! If it does turn out well it should be beneficial to an overwhelmingly wide variety of games.
In response to Hulio-G
Well thats great news to my ears. Ive been wanting this for awhile.
In response to Tom
Tom wrote:
Well, that's not really true. We currently sync the client to the lesser of the tick_lag and 100ms, but we could easily adjust the latter to a lesser number if such movies are playing. It might be kind of inefficient since we blit the whole map each time, but I'm sure we could eek out a factor of 3-4 at least without much trouble.

That said, we're getting this 420+ series and a few website things stable before moving onto new features. I like the suggestion though.

After careful observation over several posts, a 1 on 1 chat with Data (and wondering after a week if I should still bother since this is old). It's clear to me people didn't understand my post the way it was meant to be understood. I was suggesting more then just animation quickening, I was asking for a greater difference then 1/10 second timing.

How odd would it be a sword user leveled up and they just looked like they swung faster rather then actually swinging faster? Or if a runner increased his speed statistics and only looked like he ran faster rather then actually moving at a faster rate?
In response to Hulio-G
world.tick_lag is the only means to accomplish faster internal timing.
In response to Jtgibson
Jtgibson wrote:
world.tick_lag is the only means to accomplish faster internal timing.

Everybody knows this, I seriously don't know why thats suggested in every thread where people are trying to increase faster internal timing for single individuals, thats not supported and thats why I'm in "byond features".

Post [link] Post [link] Post [link] - Just from this week
Post [link] Post [link] Post [link] Post [link] Post [link]- Others
Post [link] - He's not really on the request side but I like this post. It's also interesting to learn this has been spoken about before I was even on Byond.

So basically what you've been trying to tell me is that this is possible by playing around with world.tick_lag with the default timer being set to ticks of 1/10th seconds, which can be set slower but can't be set faster (what I'm requesting). But apparently, you're also trying to imply that even if my suggestion was implemented we could only use half of what they made because they'd be increased lag on the server. Reason being the server has to be faster due to the architecture of Byond games and that all communication goes through the server.

Which would be________ Server_______Structure.
/ | \
Client Client Client

Seems you've been trying to hint to me over and over that my request is impossible and that I've hit a Byond limit so If I want to do be able to do this I should go elsewhere.

I'm thinking though, (I'll let my ideas be heard for the sake of a stronger engine for all of us in the future) would it be reasonible to suggest something that would require tampering with byonds architecture? Say a build on to the current client <- -> server structure but allowing the client to process things? I'm unaware if anyone has ever requested client side processing before.
In response to Hulio-G
I'm saying that increasing the tick rate for "single individuals" is nonsense, because the server has to tick as fast as the fastest person. It'd be impossible for the server to react to a client if the client is going faster than it.

If you want to make people faster, make the server tick at the fastest rate and give everyone else delays.

However, I don't understand why everyone thinks world.tick_lag can't be set faster. It absolutely can. However, it can only do as much as the server's bandwidth can handle, which is effectively limited by the number of players connected.

var/const/FRAMES_PER_SECOND = 60
world/tick_lag = 10 / FRAMES_PER_SECOND


The server now cycles at a rate of 60 frames per second. That's six times faster than normal.

(If you want to sleep for a number of frames, just sleep(world.tick_lag * frames) instead of sleep(deciseconds).)


The ultimate answer, of course, is that if you want high precision, action, and speed, BYOND just isn't what you're looking for. BYOND is designed for adventure-style roleplaying games, board games, and strategy games; it's less effective at making shooters, action games, and action RPGs, though it can do it if the designer is conscientious of the limits of a computer.


I think the rule of BYOND is:

* Smooth, pixel-precise graphics
* Deep gameplay
* Fast gameplay
* Fun gameplay

Pick two.
In response to Hulio-G
Gaku made a whole library of it I believe, and yes many have, even myself ^^
In response to Jtgibson
Jtgibson wrote:
However, it can only do as much as the server's bandwidth can handle, which is effectively limited by the number of players connected.

And server bandwidth doesn't appear to be much -- I tried testing this on a machine with a rather fast internet connection and a game which had world.tick_lag set to 0.25 or such. The game was programmed to use MouseEntered() to artificially turn the direction of the players' icon based on angle. It still lagged and did not work smoothly, even though the server would've been more than capable of handling it.
In response to Android Data
Very nice usage of the mouse procs for testing purposes there. =P They're known to be less than smooth normally, so it doesn't mean much by itself. And you've used an icon operation too. >_>