Another bug report (v. 2.3.3l) I´m pretty sure it was caused by lag...
Please take a closer look at deacon1985. As a rookie he tried several times to join the race (bl1) with an untrimmed FXO, of course he was sent to spec everytime. He received an auto-kick for repeated tries.
After track changed to so4r he managed it somehow to join the race.
At 12:33:17 AIRIO sent him to spec, but he was still on grid as the race started...
Eh, yes, it looks like FE1/2 pitlane is really short, and if there's a small delay when entering pitlane (and that is very often), the exit follows less then 6 seconds later and it is seen as DT cheating. New code limits the check to BL2 only as it is probably the only track where DT cheat can be done to unfair advantage.
I guess you're right. Certaily the /spec command to send him off the track was issued (maybe you can check this in server log?), unfortunately LFS server ignored that command. It happens sporadically, especially with /restart and /end commands. For these two I added special timers checking if the command was actually carried out, repeating it several times if necessary.
Up till now I've never seen /spec command being ignored, but obviously it may happen. A solution would be to check some 5 seconds later whether the driver was really specced (or kicked, I guess /kick could be also ignored), repeating the command several times to be sure the required action is carried out. Eh...
Data offered by InSim contain no information about IPs of connections. The FULL version of Airio can listen to changes in server log files (if server directory is correctly specified in Airio config), grab IP addresses from there and assign them to connections. Currently only checking for doubled IPs (and kicking for that) is supported.
Earlier people asked me if banning by IP would be possible. Well, yes, to a certain extent and with some limitations. First, the listening mechanism is not guaranteed to always capture the correct address. I'd say it would work in 99 percents of connections, but when actions align badly it may fail.
Also many different people use one privider and are seen as using one IP. Banning by IP may hit many people that just happen to use the same provider as some stupid crasher. A possible solution would be to ban IP e.g. for just one hour, so that the crasher cannot connect back immediatelly with different username, but others are not excluded for too long.
All in all, FULL version of Airio can capture IP addresses. The usage is currently limited though due to other considerations. Still, the possibilities to display IPs and do more actions based on IPs are open, adding such things would not be too complicated.
Basically, warning say some state or condition was not expected, but it is nothing serious. In this case people disconnected without first leaving the race. This was caused by the fact they disconnection from lobby after end race was called. Airio expects that all disconnecting people have PID (player ID, yes) equal to zero. This was not the case, that's why the warning. I did a small update in Airio code, replacing /clear command carries out on race end by !sall, spectating all people. Some testing would be necessary though to see it is OK...
Strange in your output is this line:
09.09.12 12:10:45 #1 This command needs a parameter
It would be good to see what LFS command it was and then see why it had no parameter (see server log, optionally turn on server logging to capture all / commands into Airio log for easier debugging). My guess is this was /track= command. Note that there's no message about track being loaded in your output. People waited for some 30 seconds, nothing happened, and they disconnected.
This means a character code was not found in internal LFS <-> Unicode conversion tables. You may ignore these warnings. In time I want to fully support conversion of LFS character codes to Unicode and back (!), including Asian charsets, but it is a tricky matter...
Ah, right, sorry. It seems I was doing some experiments with pitlane and forgot to activate back one parameter chance in the test version you're using. Thanks a lot for spotting this!
Drivers stayed in pits, it was just airio who give the message
The bad thing is this /spec counts...so drivers will be kicked sooner or later, we use MaxSpectatings=4
I think it was correct. A driver pitted, remained in pits. Yet Airio specced him like he was still on track, which was not correct. The driver would see only a little change, Join button would turn to OK. (And if midrace join is disabled, he would not be able to join.) I hope I corrected this behavior now.
Something weird seems to be happening. Racers are reporting if they win the race or place in the top couple they get spectated during restart countdown or directly after they finish. I have not seen it but its coming from a few more racers now. Here is a log of a time it happened. Look at Joku123
As for spectating on next race start (if you use reversed grid, it could be the last winner that is spectated), it is connected with "limit overcome" feature. 12th on grid is spectated if there are 13 or more connections. If then 2 or 3 cars join at approximately the same moment, then it is possible to have 13 or even 14 cars on track even in demo. A little bug in 2.3.3 caused the spectate to always happen, regardless of LimitOvercome setting. It is corrected now for some time.
The idling check always runs only during race. I cannot believe someone was spectated for idling after race, I see no way that could happen (but I can be blind of course). Very rarely someone could be spectated during race while he is driving. This is mostly the case when for some (unknown to me) reason the server does not see the driver moving. His arrow is not moving in the little map, his car stays in pits in Remote, yet the driver says he was moving, leaving pits. But no one can se him, not even Airio, so he gets spectated after a while. This is very exceptional condition, but I can't do anything about it.
First, when having some people in the NDR server, when the combo was on an autocross, it would spectate drivers for idling on track, even though they were clearly moving. Has this been brought up to you before or is this due to the fact that there are no pth files ? It gets annoying to get the warning when you're quite clearly to the human eye moving on track.
Second, I was attempting to set our track roation to do timed races, but I was thinking it was something like SO1|-15 for 15 minutes, but that didn't work. What is the correct format for that ?
same problem here when setting up a rotation on AU1. would not perform rotation, and when i typred !tr, would not even show the next track in the rotation........
Heh, no doubt that looks very stupid, sorry! If I remember correctly there was this idling bug on tracks with 0 nodes (such as AU1 or BL3) in a very early release of 2.3.3, but I think the compile available now already solves it. If you can, please try downloading 2.3.3 again and see if the problem is still there. Also I plan to release 2.3.4 today, so maybe you can wait a few hours and get the latest... Also there's always the option to disable idling check (in SRV, CheckIdling).
The format of track rotation is track|cars|time, you can omit time (laps) or also cars, but not just cars. So the entry track|time is not recognized, try putting also cars in the middle, then it should work...
I can wait till 2.3.4 comes out and gets up on 500servers. I did a clean reinstall of 2.3.3 on there late last night, so all the old crap I had was gone, but I can live with a temporary fix I have (max time between splits, crude, but should work until overnight).
And dangnabbit, fix the documentation then ! Funnily though, even with just track and laps, it IS still rotating, even though it apparent'y shouldn't.
Ah, yes, I'd like to, but I'm short of manpower...
Eh, nothing serious, just limad levels printed for test purposes, sorry, I forgot to remove one command. It is now corrected in the latest FULL version...
But well... just to give you some more work I had some brainstorming yesterday...
To prepare an event it would be handy to be able to turn on/off the RName lock bye time - just as it works with the "normal" lock too. So I could prepare the event settings a day before and activate them automatically - or could this be done bye a scheduled command?
Using and LFS-Admin Slot would require the admin pass. Couldn´t this be done by Airio too? Checking new connecting guest if they are a at a decent limad level, and if there are no more slots left then the guest would be kicked for "server is full"
Ok, and there is one question I have - had not time to test it yet:
If I lock the server by the RName, are limads able to drive too, or are only RName listed guys are allowed? (Limad is set to "allow join") If I lock a currently running server by RName, will currently racing but not listed guys be speced or does Airio only check if someone wants to join the race?
Well, I have no experience with such systems, so I'm not sure what advantage they could present...
The "improper DT" is in version 2.3.4 (currently running on FM) limited only to BL2, so I think it should cause no more troubles.
What you basically need is to manipulate with LimitToRegistered item in SRV file. There are several ways you can do that: Using !cfg command manually for temporary change. You may also put such command into a SET file together with other settings required for an event and call all at once using !si x. Scheduled commands (in FULL version) will also work, both !cfg and !si. Just beware that doing !rld reverts server settings back to defined defaults, erasing all changes done by !cfg commands.
Interesting idea, surely. Also possible, I think, but requiring two, maybe three new items in SRV file. And also two new messages, one saying privately to the additional connection being kicked why this action was taken, one announcing the reason (optionally) to everyone else on server. Question is what can be done about repeated connects, I guess nothing. Banning anyone for trying to connect to a server with slots limited by limad level is not an option. So in the end you may see MANY kicks from virtually full host, which could become tiresome for everyone connected and trying to connect.
Connecting people will have no way to know if they will not be kicked suddenly, which may lead to desparation, later to hatred (no doubt towards the stupid tool that's kicking them for stupid reasons). So I'm kind of reluctant to implement this feature, I see it as too limiting and not exactly transparent. So, maybe not so interesting idea after all.
Limads will be able to race if they have level at least equal to AllowJoining in CFG file (or higher). With sufficient level the following joining checks are skipped for them: registered names, time lock, repeated joining, licence level, rank level, safety level. Defined intake/mass restrictions and prohibited cars are always applied to everyone, no exceptions.
Airio 2.3.4 is released. It corrects (hopefully) issues from previous compiles and also adds new things suggested and required by some people, such as:
Limads definable on server level.
Grid order manipulation after qualification and possibility to require pitting/spectating only from pitlane.
Support for instance and server descriptions shown as tooltips on Airio servers page.
Support for time-locking only in race.
Settable race restart/end countdown period, also support for e.g. !re 60.
Better support for registered usernames for some event.
Continuous help screens for limads and admins.
The FULL version add also a some new things:
Possible limad descriptions and showing driver status.
Preferential race join to certain number of people with best session times, e.g. !sa 24.
Server and LFSW lap times overview commands, !pbs and !prs.
Possible spectate for car reset in race, while free reset is allowed in practice/qual.
Almost every new version brings some new issues, caused by the fact not all situations and configuratings can be fully tested. I'll be grateful for any strange behaviour descriptions and obvious bug reports. Enjoy.
Ah, right... But even if I use a SET file to execute all commands at once it only works if I use the !cfg command to modify the LimitToRegistered item, right? Well this should work, but as you said it will be set to default if I do some config things on an other server and need to use !rld... So - sorry for the more work - a new command to turn event mode on/off would be nice and helpful for the future...
Another thing that could work an may be very usefull would be the possibility to be able to load another server config file - simmular to the !si command... !scfg x would load and activate a Airio.srv.x.x.txt file...
FULL version 2.3.4 show error when I use any command and after this shutdown Airio. Previous version works fine.
I use linux server and mono:
mono --version Mono JIT compiler version 2.2 (tarball Sun Mar 15 08:58:04 EDT 2009) Copyright (C) 2002-2008 Novell, Inc and Contributors. [URL="http://www.mono-project.com"]www.mono-project.com[/URL] TLS: __thread GC: Included Boehm (with typed GC) SIGSEGV: altstack Notifications: epoll Architecture: x86 Disabled: none
Shift+I works. Error when I use !ver command. I see this on linux console. Airio.log show !ver and no more text.
Opening connection : CONN OK Airio connected to Okram Server - 0.5Z - S2 ** ERROR:mini.c:11270:mono_resolve_patch_target: assertion failed: (patch_info->data.bb->native_offset) Stacktrace: at LiveForSpeed.InSim.Airio.Airio.ProcPreMsg (string) <0xffffffff> at LiveForSpeed.InSim.Airio.Airio.ProcPreMsg (string) <0x00260> at LiveForSpeed.InSim.Airio.Airio.Message_Handler (LiveForSpeed.InSim.Aegio.Connection,LiveForSpeed.InSim.Aegio.Event/Message) <0x0039d> at LiveForSpeed.InSim.Aegio.Connection.OnMessage (LiveForSpeed.InSim.Aegio.Event/Message) <0x00034> at LiveForSpeed.InSim.Aegio.Connection.ListenTCP () <0x0059a> at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) <0xffffffff> Native stacktrace: /usr/lib/libmono.so.0 [0x1cb3f2] [0x82140c] [0x821416] /lib/libc.so.6(gsignal+0x50) [0x92f460] /lib/libc.so.6(abort+0x188) [0x930e28] /lib/libglib-2.0.so.0(g_assertion_message+0x123) [0x598813] /lib/libglib-2.0.so.0 [0x598cad] /usr/lib/libmono.so.0 [0x12c57e] /usr/lib/libmono.so.0 [0x1e7b96] /usr/lib/libmono.so.0 [0x12b34d] /usr/lib/libmono.so.0 [0x157153] /usr/lib/libmono.so.0 [0x158511] /usr/lib/libmono.so.0(mono_compile_method+0x24) [0x237ba4] /usr/lib/libmono.so.0 [0x1d51e1] [0x414066] [0x7b88fe] [0x7a9605] [0x667f23] [0x61d618] /usr/lib/libmono.so.0 [0x158ea7] /usr/lib/libmono.so.0(mono_runtime_invoke+0x73) [0x238e33] /usr/lib/libmono.so.0(mono_runtime_delegate_invoke+0x44) [0x2390a4] /usr/lib/libmono.so.0 [0x27f88a] /usr/lib/libmono.so.0 [0x2f9476] /usr/lib/libmono.so.0(GC_start_routine+0x45) [0x31ee65] /lib/libpthread.so.0 [0xab251f] /lib/libc.so.6(clone+0x5e) [0x9e804e] Debug info from gdb: (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 0xb7f826f0 (LWP 6938)] [New Thread 0x5759b90 (LWP 6954)] [New Thread 0x24ebb90 (LWP 6952)] [New Thread 0x23c6b90 (LWP 6950)] [New Thread 0x113ab90 (LWP 6946)] [New Thread 0x6627b90 (LWP 6945)] [New Thread 0xcebb90 (LWP 6943)] [New Thread 0x76db90 (LWP 6942)] [New Thread 0xe37b90 (LWP 6941)] [New Thread 0x528b90 (LWP 6940)] [New Thread 0x427b90 (LWP 6939)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) 0x00821416 in __kernel_vsyscall () 11 Thread 0x427b90 (LWP 6939) 0x00821416 in __kernel_vsyscall () 10 Thread 0x528b90 (LWP 6940) 0x00821416 in __kernel_vsyscall () 9 Thread 0xe37b90 (LWP 6941) 0x00821416 in __kernel_vsyscall () 8 Thread 0x76db90 (LWP 6942) 0x00821416 in __kernel_vsyscall () 7 Thread 0xcebb90 (LWP 6943) 0x00821416 in __kernel_vsyscall () 6 Thread 0x6627b90 (LWP 6945) 0x00821416 in __kernel_vsyscall () 5 Thread 0x113ab90 (LWP 6946) 0x00821416 in __kernel_vsyscall () 4 Thread 0x23c6b90 (LWP 6950) 0x00821416 in __kernel_vsyscall () 3 Thread 0x24ebb90 (LWP 6952) 0x00821416 in __kernel_vsyscall () 2 Thread 0x5759b90 (LWP 6954) 0x00821416 in __kernel_vsyscall () * 1 Thread 0xb7f826f0 (LWP 6938) 0x00821416 in __kernel_vsyscall () Thread 11 (Thread 0x427b90 (LWP 6939)): #0 0x00821416 in __kernel_vsyscall () #1 0x00ab9996 in nanosleep () from /lib/libpthread.so.0 #2 0x002dcec8 in ?? () from /usr/lib/libmono.so.0 #3 0x00ab251f in start_thread () from /lib/libpthread.so.0 #4 0x009e804e in clone () from /lib/libc.so.6 Thread 10 (Thread 0x528b90 (LWP 6940)): #0 0x00821416 in __kernel_vsyscall () #1 0x00ab8495 in sem_wait@@GLIBC_2.1 () from /lib/libpthread.so.0 #2 0x00258e03 in ?? () from /usr/lib/libmono.so.0 #3 0x0027f7ee in ?? () from /usr/lib/libmono.so.0 #4 0x002f9476 in ?? () from /usr/lib/libmono.so.0 #5 0x0031ee65 in GC_start_routine () from /usr/lib/libmono.so.0 #6 0x00ab251f in start_thread () from /lib/libpthread.so.0 #7 0x009e804e in clone () from /lib/libc.so.6 Thread 9 (Thread 0xe37b90 (LWP 6941)): #0 0x00821416 in __kernel_vsyscall () #1 0x00ab9996 in nanosleep () from /lib/libpthread.so.0 #2 0x002f87e0 in SleepEx () from /usr/lib/libmono.so.0 #3 0x0027eba6 in ?? () from /usr/lib/libmono.so.0 #4 0x00630177 in ?? () #5 0x000000c8 in ?? () #6 0x08826c04 in ?? () #7 0x00e370b8 in ?? () #8 0x008f2056 in ___tls_get_addr_internal () from /lib/ld-linux.so.2 #9 0x00630115 in ?? () #10 0x000000c8 in ?? () #11 0x003f2d88 in geteuid () from /usr/lib/libmono.so.0 #12 0x00061f40 in ?? () #13 0x00e37b74 in ?? () #14 0x08811e00 in ?? () #15 0x003f2d88 in geteuid () from /usr/lib/libmono.so.0 #16 0x00e371f8 in ?? () #17 0x0062f83d in ?? () #18 0x000000c8 in ?? () #19 0x08826c04 in ?? () #20 0x00061f40 in ?? () #21 0x0062f9a5 in ?? () #22 0x0882fa94 in ?? () #23 0x00000000 in ?? () Thread 8 (Thread 0x76db90 (LWP 6942)): #0 0x00821416 in __kernel_vsyscall () #1 0x00ab919b in read () from /lib/libpthread.so.0 #2 0x001cb52e in ?? () from /usr/lib/libmono.so.0 #3 <signal handler called> #4 0x00821416 in __kernel_vsyscall () #5 0x0092f460 in raise () from /lib/libc.so.6 #6 0x00930e28 in abort () from /lib/libc.so.6 #7 0x00598813 in g_assertion_message () from /lib/libglib-2.0.so.0 #8 0x00598cad in g_assertion_message_expr () from /lib/libglib-2.0.so.0 #9 0x0012c57e in ?? () from /usr/lib/libmono.so.0 #10 0x001e7b96 in ?? () from /usr/lib/libmono.so.0 #11 0x0012b34d in ?? () from /usr/lib/libmono.so.0 #12 0x00157153 in ?? () from /usr/lib/libmono.so.0 #13 0x00158511 in ?? () from /usr/lib/libmono.so.0 #14 0x00237ba4 in mono_compile_method () from /usr/lib/libmono.so.0 #15 0x001d51e1 in ?? () from /usr/lib/libmono.so.0 #16 0x00414066 in ?? () #17 0x0076c808 in ?? () #18 0x007b8cf8 in ?? () #19 0xb7234c04 in ?? () #20 0x00000000 in ?? () Thread 7 (Thread 0xcebb90 (LWP 6943)): #0 0x00821416 in __kernel_vsyscall () #1 0x00ab9996 in nanosleep () from /lib/libpthread.so.0 #2 0x002f87e0 in SleepEx () from /usr/lib/libmono.so.0 #3 0x0027eba6 in ?? () from /usr/lib/libmono.so.0 #4 0x00630177 in ?? () #5 0x0000000a in ?? () #6 0x00063c40 in ?? () #7 0x00ceb178 in ?? () #8 0x008f2056 in ___tls_get_addr_internal () from /lib/ld-linux.so.2 #9 0x00630115 in ?? () #10 0x0000000a in ?? () #11 0x00000000 in ?? () Thread 6 (Thread 0x6627b90 (LWP 6945)): #0 0x00821416 in __kernel_vsyscall () #1 0x00ab6432 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x002e07b8 in ?? () from /usr/lib/libmono.so.0 #3 0x002e3354 in _wapi_handle_timedwait_signal_handle () from /usr/lib/libmono.so.0 #4 0x002e33bc in _wapi_handle_wait_signal_handle () from /usr/lib/libmono.so.0 #5 0x002fd9d7 in WaitForSingleObjectEx () from /usr/lib/libmono.so.0 #6 0x00282af0 in ?? () from /usr/lib/libmono.so.0 #7 0x0027f7ee in ?? () from /usr/lib/libmono.so.0 #8 0x002f9476 in ?? () from /usr/lib/libmono.so.0 #9 0x0031ee65 in GC_start_routine () from /usr/lib/libmono.so.0 #10 0x00ab251f in start_thread () from /lib/libpthread.so.0 #11 0x009e804e in clone () from /lib/libc.so.6 Thread 5 (Thread 0x113ab90 (LWP 6946)): #0 0x00821416 in __kernel_vsyscall () #1 0x009e8836 in epoll_wait () from /lib/libc.so.6 #2 0x002838e2 in ?? () from /usr/lib/libmono.so.0 #3 0x0027f7ee in ?? () from /usr/lib/libmono.so.0 #4 0x002f9476 in ?? () from /usr/lib/libmono.so.0 #5 0x0031ee65 in GC_start_routine () from /usr/lib/libmono.so.0 #6 0x00ab251f in start_thread () from /lib/libpthread.so.0 #7 0x009e804e in clone () from /lib/libc.so.6 Thread 4 (Thread 0x23c6b90 (LWP 6950)): #0 0x00821416 in __kernel_vsyscall () #1 0x00ab6432 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x002e07b8 in ?? () from /usr/lib/libmono.so.0 #3 0x002e3354 in _wapi_handle_timedwait_signal_handle () from /usr/lib/libmono.so.0 #4 0x002e33bc in _wapi_handle_wait_signal_handle () from /usr/lib/libmono.so.0 #5 0x002fd9d7 in WaitForSingleObjectEx () from /usr/lib/libmono.so.0 #6 0x00282af0 in ?? () from /usr/lib/libmono.so.0 #7 0x0027f7ee in ?? () from /usr/lib/libmono.so.0 #8 0x002f9476 in ?? () from /usr/lib/libmono.so.0 #9 0x0031ee65 in GC_start_routine () from /usr/lib/libmono.so.0 #10 0x00ab251f in start_thread () from /lib/libpthread.so.0 #11 0x009e804e in clone () from /lib/libc.so.6 Thread 3 (Thread 0x24ebb90 (LWP 6952)): #0 0x00821416 in __kernel_vsyscall () #1 0x00ab6432 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x002e07b8 in ?? () from /usr/lib/libmono.so.0 #3 0x002e3354 in _wapi_handle_timedwait_signal_handle () from /usr/lib/libmono.so.0 #4 0x002fd8bc in WaitForSingleObjectEx () from /usr/lib/libmono.so.0 #5 0x0027c1b0 in ?? () from /usr/lib/libmono.so.0 #6 0x007727b0 in ?? () #7 0x000bec78 in ?? () #8 0x00000453 in ?? () #9 0x00001193 in ?? () #10 0x00000001 in ?? () #11 0x024eb018 in ?? () #12 0x003f2d88 in geteuid () from /usr/lib/libmono.so.0 #13 0x00000000 in ?? () Thread 2 (Thread 0x5759b90 (LWP 6954)): #0 0x00821416 in __kernel_vsyscall () #1 0x00ab6432 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x002e07b8 in ?? () from /usr/lib/libmono.so.0 #3 0x002e3354 in _wapi_handle_timedwait_signal_handle () from /usr/lib/libmono.so.0 #4 0x002fd8bc in WaitForSingleObjectEx () from /usr/lib/libmono.so.0 #5 0x00282a60 in ?? () from /usr/lib/libmono.so.0 #6 0x0027f7ee in ?? () from /usr/lib/libmono.so.0 #7 0x002f9476 in ?? () from /usr/lib/libmono.so.0 #8 0x0031ee65 in GC_start_routine () from /usr/lib/libmono.so.0 #9 0x00ab251f in start_thread () from /lib/libpthread.so.0 #10 0x009e804e in clone () from /lib/libc.so.6 Thread 1 (Thread 0xb7f826f0 (LWP 6938)): #0 0x00821416 in __kernel_vsyscall () #1 0x00ab9996 in nanosleep () from /lib/libpthread.so.0 #2 0x002f87e0 in SleepEx () from /usr/lib/libmono.so.0 #3 0x0027eba6 in ?? () from /usr/lib/libmono.so.0 #4 0x00630177 in ?? () #5 0x0000000a in ?? () #6 0x087b34c4 in ?? () #7 0xbff2f018 in ?? () #8 0x008f2056 in ___tls_get_addr_internal () from /lib/ld-linux.so.2 #9 0x00630115 in ?? () #10 0x0000000a in ?? () #11 0x003f2d88 in geteuid () from /usr/lib/libmono.so.0 #12 0x00000000 in ?? () ================================================================= Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= Aborted
It happens sporadically, especially with /restart and /end commands. For these two I added special timers checking if the command was actually carried out, repeating it several times if necessary.
Funnily though, even with just track and laps, it IS still rotating, even though it apparent'y shouldn't. 
