world.Export persist is broken

Page: 1 2
Oct 24 2016, 3:43 pm
Lummox JR resolved issue with message:
The persist value in world.Export() had been disabled since version 487, but it has been reenabled now. Several issues with incorrect results from server-to-server Export() calls have been identified and fixed.
Oct 24 2016, 3:48 pm
it really is the best day on earth.
Oct 26 2016, 5:49 pm
In response to Somepotato
Somepotato wrote:
> Hello! Received @ (2.045); Delta: 0.082; time since accept: 0.059
> Hello! Received @ (2.108); Delta: 0.063; time since accept: 0.026
> Hello! Received @ (2.18); Delta: 0.072; time since accept: 0.044
> Hello! Received @ (2.235); Delta: 0.055; time since accept: 0.025
> Hello! Received @ (2.299); Delta: 0.064; time since accept: 0.028
> Hello! Received @ (2.352); Delta: 0.053; time since accept: 0.025
> Hello! Received @ (2.416); Delta: 0.064; time since accept: 0.025
> Hello! Received @ (2.469); Delta: 0.053; time since accept: 0.024
> Hello! Received @ (2.528); Delta: 0.059; time since accept: 0.029
> Hello! Received @ (2.609); Delta: 0.081; time since accept: 0.039
> Hello! Received @ (2.675); Delta: 0.066; time since accept: 0.027
> Hello! Received @ (2.733); Delta: 0.058; time since accept: 0.031
> Hello! Received @ (2.801); Delta: 0.068; time since accept: 0.031
> Hello! Received @ (2.885); Delta: 0.084; time since accept: 0.034
> Hello! Received @ (2.948); Delta: 0.063; time since accept: 0.028
> Hello! Received @ (3.003); Delta: 0.055; time since accept: 0.025
> Hello! Received @ (3.073); Delta: 0.07; time since accept: 0.026
> Hello! Received @ (3.131); Delta: 0.058; time since accept: 0.03
> Hello! Received @ (3.181); Delta: 0.05; time since accept: 0.025
> Hello! Received @ (3.262); Delta: 0.081; time since accept: 0.046
> Hello! Received @ (3.314); Delta: 0.052; time since accept: 0.023
> Hello! Received @ (3.361); Delta: 0.047; time since accept: 0.025
> Hello! Received @ (3.404); Delta: 0.043; time since accept: 0.021
> Hello! Received @ (3.455); Delta: 0.051; time since accept: 0.024
> Hello! Received @ (3.516); Delta: 0.061; time since accept: 0.031
> Hello! Received @ (3.57); Delta: 0.054; time since accept: 0.025
> Hello! Received @ (3.626); Delta: 0.056; time since accept: 0.028
> Hello! Received @ (3.683); Delta: 0.057; time since accept: 0.029
> Hello! Received @ (3.737); Delta: 0.054; time since accept: 0.022
>


Hello! Received @ (46.134); Delta: 0.037999999999997; time since accept: 0.102
Hello! Received @ (46.158); Delta: 0.024000000000001; time since accept: 0.126
Hello! Received @ (46.183); Delta: 0.024999999999999; time since accept: 0.151
Hello! Received @ (46.209); Delta: 0.026000000000003; time since accept: 0.177
Hello! Received @ (46.243); Delta: 0.033999999999999; time since accept: 0.211
Hello! Received @ (46.278); Delta: 0.034999999999997; time since accept: 0.246
Hello! Received @ (46.311); Delta: 0.033000000000001; time since accept: 0.279
Hello! Received @ (46.345); Delta: 0.033999999999999; time since accept: 0.313
Hello! Received @ (46.373); Delta: 0.027999999999999; time since accept: 0.34099999999999
Hello! Received @ (46.399); Delta: 0.026000000000003; time since accept: 0.367
Hello! Received @ (46.424); Delta: 0.024999999999999; time since accept: 0.392
Hello! Received @ (46.448); Delta: 0.024000000000001; time since accept: 0.416
Hello! Received @ (46.502); Delta: 0.054000000000002; time since accept: 0.47
Hello! Received @ (46.531); Delta: 0.028999999999996; time since accept: 0.499
Hello! Received @ (46.56); Delta: 0.029000000000003; time since accept: 0.528
Hello! Received @ (46.598); Delta: 0.037999999999997; time since accept: 0.566
Hello! Received @ (46.627); Delta: 0.029000000000003; time since accept: 0.595
Hello! Received @ (46.833); Delta: 0.206; time since accept: 0.80099999999999
Hello! Received @ (46.888); Delta: 0.055; time since accept: 0.85599999999999
Hello! Received @ (46.934); Delta: 0.044999999999995; time since accept: 0.90199999999999
Hello! Received @ (47.048); Delta: 0.114; time since accept: 1.016
Hello! Received @ (47.086); Delta: 0.037999999999997; time since accept: 1.054
Hello! Received @ (47.113); Delta: 0.027000000000001; time since accept: 1.081
Hello! Received @ (47.162); Delta: 0.048999999999999; time since accept: 1.13
Hello! Received @ (47.214); Delta: 0.052; time since accept: 1.182
Hello! Received @ (47.301); Delta: 0.087000000000003; time since accept: 1.269
Hello! Received @ (47.32); Delta: 0.018999999999998; time since accept: 1.288
Hello! Received @ (47.348); Delta: 0.027999999999999; time since accept: 1.316
Hello! Received @ (47.382); Delta: 0.033999999999999; time since accept: 1.35


Delta is the time between messages -- its actually decently quicker. Good job Lummox!
Oct 26 2016, 11:18 pm
One thing I need to mention here: Although the way messages are sent has vastly improved, world.Export() will still send, receive, send, receive, etc. if it has requests stacked up. There was simply no other good way to handle it in the short term. In the longer term, I'd like to improve that so it can send a bunch of stuff at once, as long as it doesn't end up creating a spam problem.
Oct 27 2016, 3:53 am
In response to Lummox JR
Lummox JR wrote:
One thing I need to mention here: Although the way messages are sent has vastly improved, world.Export() will still send, receive, send, receive, etc. if it has requests stacked up. There was simply no other good way to handle it in the short term. In the longer term, I'd like to improve that so it can send a bunch of stuff at once, as long as it doesn't end up creating a spam problem.

It might not be a bad idea to buffer data or allow for firing and forgetting with a parameter on Export. I don't see how you could sanely queue up requests given that its blocking and whatnot in not softcode anyway so I think for now its fine.
Oct 27 2016, 8:23 am
In response to Somepotato
Queuing can happen if you spawn off a request, like I did quite a bit in testing. Also if multiple procs did an Export(), like B sending while A was still waiting for its response, it'd work the same way.

This queuing however does not wait for the proc tick, so that's a good thing at least. As soon as a response is received, the socket calls TransmisionReturn() which pushes the sleeping proc back onto the list to activate on the next tick, and then sends out the next request to the remote server. So in theory with a fast connection you could get a lot of back-and-forth on a single tick, if a lot of things were queued up.
Oct 27 2016, 10:27 am
In response to Lummox JR
Lummox JR wrote:
Queuing can happen if you spawn off a request, like I did quite a bit in testing. Also if multiple procs did an Export(), like B sending while A was still waiting for its response, it'd work the same way.

This queuing however does not wait for the proc tick, so that's a good thing at least. As soon as a response is received, the socket calls TransmissionReturn() which pushes the sleeping proc back onto the list to activate on the next tick, and then sends out the next request to the remote server. So in theory with a fast connection you could get a lot of back-and-forth on a single tick, if a lot of things were queued up.

Alright that'll make using it a little smarter implementation wise.
One downside though is that it'll hang procs for a very long time if the server doesn't return or it can't connect to the server. This behavior should probably be changed.
Page: 1 2