Unknown error. How to check lua errors on dedicated server.

[Primo]

Hello. Today i got dedicated server, but i can't normal play.
I suppose that the problem in lua script, but i can't check errors in game.
This problem only on dedicated server.

And panorama has a real lags.
For example in test version i create a repeat timer (schedule) in 0.005sec, and he don't has lags, but on dedicated server game(client) has a real lags.

And in console writes this:

[SteamNetSockets] \src\steamnetworkingsockets\clientlib\../steamnetworking_statsutils.h (710) : Assertion Failed: relay ack was pended for 45012033 usec, cannot pack delay properly! usecNow=b65f8f8, timestamp=8b724b7, usecThen=8b724b7

[aveyo]

Timers are inherently dangerous and should not be used without consideration.
A 5ms timer can wreck havoc when it ignores networking (that's limited to 30 updates per second).
Set a reasonable timer. But why are you not using the built-in think functions and events instead?
There are people knowing this stuff better, try posting here: http://dev.dota2.com/showthread.php?t=284507

The network message should be unrelated (it's spewed for all dota users).

[Primo]

Now I'm interested in fix problems with lua scripts. Because panorama lags are most likely related to the lua script.

[aveyo]

You can't run debugging on the remote Valve servers.

But you could simulate a network load on your dev machine. Try:
host_limitlocal 1; // Apply cl_cmdrate and cl_updaterate to loopback connection [0]
net_fakejitter 50; // Jitter fakelag packet time
net_fakelag 20; // Lag all incoming network data (including loopback) by this many milliseconds.
net_fakeloss 3; //Simulate packet loss as a percentage (negative means drop 1/n packets)
net_fakeloss_recv -2; //Simulate recieved packet loss as a percentage (negative means drop 1/n packets)
net_force_steamdatagram 0; // Force newer datagram protocol [0]
net_queued_packet_thread 1; // Use a high priority thread instead of sending queued packets each frame. [1]

Still think there should be no timers used in lua but instead make use of events and triggers (think functions) - that's "server-side".
If you must, then use panorama-defined timers - that's "client-side" hence it won't degrade that much when networked.

[Primo]

I talk about timers in panorama (javascript).
Like this:

function SimpleFunction(){
...
$.Schedule(....)
...
}
SimpleFunction();

And thanks for cvars.

[aveyo]

You've complained about lua in your first post, so that's why I assumed it was non-native lua timers.

Just avoid really small delays and/or try setting just one short timer globally that would check/run/set different stuff or chain-load larger timers.
I'm not sure anyone can help without providing actual code.

[Primo]

Problem not with timer. Problem with lua script, and i want check error log, but can't do it on dedicated server.

[Primo]

Problem has been fixed. It related in the fact that the player_connect_full event did not work on dedicated server.

[DoctorGester]

But why are you not using the built-in think functions and events instead?

You've complained about lua in your first post, so that's why I assumed it was non-native lua timers.

That's funny, how do you think those "non-native" timers would work even? Magic? They are built using a native think function. And they are obviously also limited to 30 updates per seconds just like any lua code in dota ever.

[aveyo]

That's funny, how do you think those "non-native" timers would work even? Magic? They are built using a native think function. And they are obviously also limited to 30 updates per seconds just like any lua code in dota ever.

What's funny about that? At that time the guy did not post any code snippet, and for all I know, he could have used gaben knows what baked coroutines / client-side hackery / SetContextThink directly / custom timers.lua from barebones.

Magic?

And it was actually unrelated to lua performance, since OP used panorama javascript timers and controlled them with the wrong events - probably his whole initiation code fired on "gamenewmap" was on a loop instead of finishing on "player_connect_full".