Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?
You are not logged in.
Pages: 1
If you don't know, there's a small wait inbetween placing blocks.
Bots have to Thread.Sleep(5); and wait five milliseconds before placing another block, and this is pretty helpful for preventing bot block spam and trollers trolling too much.
However, I'd like it do be disabled!
In the world options, there'd be a checkbox "Disable Block Wait". By default, this is enabled. If you uncheck it, bots no longer have to Thread.Sleep(0);, and blocks are placed instantly.
Protocol Changes:
At '38' in 'init', there'd be a boolean: InstantBlocks.
There would be "instantblock", send parameters:
"instantblock"
0 - boolean, enable instant blocks is true, disable instant blocks is false
Recieve message would be the same
"instantblock"
0 - boolean, enable instant blocks is true, disable instant blocks is false
In world db objects:
"instantblocks" true or false
1 woot = 1 supporter
This would make bots able to place blocks significantly faster, as well as benefits to the player, and it is toggle-able, so that you can choose whether or not it is on.
Offline
huh the block limit is that high? last time i heard it was 96/s
btw i thought it was there to prevent some major issue or something. if its not, support
suddenly random sig change
Offline
Although this would be good, the main reason is that if there was no delay, then bots would basically be DOSing the servers, and that isnt a very good thing... (I think this is the main reason the delay was added in the first place)
Also, if you want a bot to place blocks faster, use a queue and timers instead of Thread.Sleep() because the latter isnt very accurate, and ends up as about 15+ ms per block usually, which could be improved by about 30+% if you have a good connection.
If you cant be bothered to impliment this, then I've done it in my ConnectedWorld library (a plugin for WorldSaver), Im probably going to upload the source too some time, if you dont want a whole library
Edit:
huh the block limit is that high? last time i heard it was 96/s
It is 100 messages per second I think, read that^ for an explanation for why this is the case for what Ninja is doing
Offline
huh the block limit is that high? last time i heard it was 96/s
btw i thought it was there to prevent some major issue or something. if its not, support
5 milliseconds,
1000 / 5 = 200
200 bps
Although this would be good, the main reason is that if there was no delay, then bots would basically be DOSing the servers
The servers are paid for, so they can handle quite a bit of messages. Plus, think back to when there was 1000 players, how many "m" was being sent, how many blocks were being placed, all those rooms!
Also, if you want a bot to place blocks faster, use a queue and timers instead of Thread.Sleep() because the latter isnt very accurate, and ends up as about 15+ ms per block usually, which could be improved by about 30+% if you have a good connection.
That's very insteresting, I'd like to read/see more about that.
Offline
That's very insteresting, I'd like to read/see more about that.
Here is a quick test to show you what im talking about:
using System;
using System.Threading;
namespace SleepTest
{
class Program
{
static void Main(string[] args)
{
{ // Control
long oneSecond = DateTime.Now.Ticks + TimeSpan.TicksPerSecond;
int loops = 0;
while (DateTime.Now.Ticks < oneSecond)
{
loops++;
}
Console.WriteLine("Control: " + loops);
}
while (true)
{
Console.Write("\nDelay: ");
int delay;
if(!int.TryParse(Console.ReadLine(), out delay)) break;
Console.WriteLine("Target: " + (1000 / delay));
{ // Sleep test
long oneSecond = DateTime.Now.Ticks + TimeSpan.TicksPerSecond;
int loops = 0;
while (DateTime.Now.Ticks < oneSecond)
{
Thread.Sleep(delay);
loops++;
}
Console.WriteLine("Sleep test: " + loops);
Console.WriteLine("Actual sleep: " + (1000 / loops));
}
}
}
}
}
And the output:
Control: 1316387 (This shows that the loop executes very fast without the sleep, so the speed of the rest of the code doesnt significantly affect the results)
Delay: 5
Target: 200
Sleep test: 69
Actual sleep: 14
Delay: 10
Target: 100
Sleep test: 65
Actual sleep: 15
Delay: 20
Target: 50
Sleep test: 36
Actual sleep: 27
Delay: 50
Target: 20
Sleep test: 18
Actual sleep: 55
Delay: 100
Target: 10
Sleep test: 10
Actual sleep: 100
Offline
Spam blocks fast enough and you'll crash the world. There's a good reason why an artificial limit was introduced.
Use multiple bots if you need to draw faster.
One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.
Offline
Spam blocks fast enough and you'll crash the world. There's a good reason why an artificial limit was introduced.
Use multiple bots if you need to draw faster.
ok lets just lower the limit then
5 in 5ms sound good?
suddenly random sig change
Offline
many questions to address
The servers are paid for, so they can handle quite a bit of messages. Plus, think back to when there was 1000 players, how many "m" was being sent, how many blocks were being placed, all those rooms!
well the idea of zero-delay is basically saying "let's compare this potentially infinite rate of blocks to this otherwise previously limited rate of blocks" which doesn't really make sense. It's an oversimplification, but I want to argue that creating a system with "but old parameters worked well, why can't our new situation be ramped up" is nonsense because we still ideally want to be able to do that previous throughput. If we use your logic, then we're liable to hit some ceiling.
Spam blocks fast enough and you'll crash the world. There's a good reason why an artificial limit was introduced.
but what's the underlying cause?
Use multiple bots if you need to draw faster.
so the cause is somehow not related to ... the connection? But yet, the fact that it's one connection? That says something about architecture if you feel multiple bots is a solution (as opposed to saying "ninja, your idea is entirely unnecessary because we don't need to go that fast" -- instead you say "yes you're on to something, use multiple bots)
ok lets just lower the limit then
5 in 5ms sound good?
you're relenting so quickly. But again, who are we to blindly make decisions as to what the limits should be without knowing why they exist?
and finally, what if we look at this another angle?
remember this gem? -- yeah, sure, block spam is a bummer. But if whatever reason we have delays is message-related and not block-information-processing related, then we could just neatly lump it together yeah?
Offline
Offline
Pages: 1
[ Started around 1711697246.8837 - Generated in 0.052 seconds, 12 queries executed - Memory usage: 1.59 MiB (Peak: 1.77 MiB) ]