Two wonderfull time related suggestions

[Psp The Blocklander]

A. A 0.0 timescale, Host only.
B. A freeze everyone but yourself mod. RTB Togglable for Host, SA, Admin, And everyone.


Okay descriptions. 0.0 Timescale, Freezes time, And is hostonly. Simple as /timescale 0.0

B. Simple, Freezes everything, But yourself. Everything INCLUDING projectiles. And if possible brick physics. This is a nice thing to have when someones about to snipe you.

[Ad Bot]

[Kalphiter]

V Predictions: People yelling at me that torque can't do this, Blah Blah Blah.V

If it's impossible then it won't happen, you idiot. Screaming louder won't make it suddenly possible.

[Psp The Blocklander]

If it's impossible then it won't happen, you idiot. Screaming louder won't make it suddenly possible.

Who ever said it was not possible?

[Kalphiter]

Who ever said it was not possible?

It's impossible.

[Psp The Blocklander]

It's impossible.

Bring much happiness in the world?

Explain to me why its impossible.

[Uristqwerty]

Timescale affects *everything*. Setting it to 0 would probably freeze the game (including the ability to turn it off, more likely than not) and/or crash the game from division by zero.

Furthermore, it is a global change, there is no way, without an engine change, that an individual could have a different timescale, and even if you could set individual objects to have a timescale multiplier, how many objects are there per player? 10? 20? What about the scripts, where there are timescale-affected schedule()s with no object associated to them? How would you multiply the length of only those related to selected objects? And then you get into the crazy world of trying to synchronize differing timescales between clients, and it starts to look like the easiest method would be to invent atime machine in *real life* because without a whole team of 10-20 people working for years on that one single feature, it won't happen. Ever.

[Kalphiter]

Timescale affects *everything*. Setting it to 0 would probably freeze the game (including the ability to turn it off, more likely than not) and/or crash the game from division by zero.

Furthermore, it is a global change, there is no way, without an engine change, that an individual could have a different timescale, and even if you could set individual objects to have a timescale multiplier, how many objects are there per player? 10? 20? What about the scripts, where there are timescale-affected schedule()s with no object associated to them? How would you multiply the length of only those related to selected objects? And then you get into the crazy world of trying to synchronize differing timescales between clients, and it starts to look like the easiest method would be to invent atime machine in *real life* because without a whole team of 10-20 people working for years on that one single feature, it won't happen. Ever.

Learn what you're talking about before you speak.

[Uristqwerty]

I happen to know that the timescale is a global setting, it affects schedules in the scripts, it is implemented in the engine, and I also happen to know the meaning of exageration. You seem to have missed that last point. Oh, and in older versions of Blockland, you could adjust a client timescale independantly of the server's. Every few frames, the client would return to where the server determined they would be, but it still could be changed independantly. Furthermore, I recall working with scripts that adjusted the timescale, and had to write code to compensate for the effects of it on schedules. Finally, it could not be implemented anywhere *except* in the engine, as it affects player physics seamlessly, a feat that cannot be truely accomplished elsewhere.

[Treynolds416]

And then there's also the fact that this is amazingly abusable.