Trying to open /home/coelho/.q3a/q3ut4/jump.log
connecting to database in database/
[OK] Opened!
[!] Deop requested by OTR]LockDownSP, 864EAAC99834CAC0099A71B8C0C91E56


#0 0x0000003ef889c928 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /usr/lib64/libstdc++.so.6#1 0x000000000040c076 in Db::idNickStruct::idNickStruct(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()#2 0x00000000004068c0 in Db::findPreciseIdNickViaNickOp(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#3 0x0000000000421730 in Analyzer::deop(char*) ()
#4 0x0000000000429f73 in Analyzer::main_loop() ()
#5 0x0000000000404c60 in main ()

Riscontrati due bug nelle opzioni generali:

-GENERAL_BOTLOG non accetta direttamente un file, vuole sempre almeno una cartella.
-GENERAL_PORT sembra essere ignorato.

Alcune opzioni vanno prese direttamente dal server se non specificate nel file di log, come per esempio il file di log del server.
Inoltre il loro controllo periodico, in modo che anche cambiando config e/o log il bot continui a funzionare.

Impostazioni automatiche del game server per essere utilizzato col bot (come la variabile sv_logsynch).

Caricamento di tutte le informazioni dei player tramite rcon status e rcon playerlist.

Suddividere analyzer in parser e controllo logico, ottenendo quindi 2 classi separate.

Sistemare per la guid 'unknown' (gestirla come caso particolare, come guid vuota).

Checks: mostra anche i warning nonstante il ban automatico.

Le ricerche per nick ritornano più volte gli stessi risultati.
Per esempio (puramente casuale):

id | nick |lvl
13 asd 1
15 lie 5
13 asd 1
115 mentor 7
15 lie 5


Ovviamente a causa di questo il deop per nick non funzia.

Sembra ci sia un bug in !teams, ecco la traccia:

[OK] Opened!
At: 2212206
At: 2212274 contains: 1089:14Kill: 9 10 28: Infantrie. killed BurningSniper by UT_MOD_SR8
At: 2212306 contains: 1089:15Item: 7 ut_weapon_deagle
At: 2212338 contains: 1089:15say: 14 ShiNWoLL: !teams
[!] Teams requested by ShiNWoLL, 5C5D284D639F5B41A3166CE2F0FFC3C4
Db::checkAuthGuid
Db::execQuery - select level from oplist where guid='5C5D284D639F5B41A3166CE2F0FFC3C4'
using database @: /home/zamy/BanBot/databaseCube/
Db::execQuery result code is: 0 sending value: 1
Red found: 7 Blue found: 2 Total: 9
Segmentation fault

Evidentemente c'è un errore negli if e/o nei cicli (analyzer.cpp, circa riga 2722).
Personalmente non riesco a trovare l'errore, butta un occhio anche te.

Da controllare dove è esattamente (se in db o analyzer):

[OK] Is an admin. Doing findop.
[-]Searching for ss.
Db::execQuery - select id,nick from oplist where nick='ss' limit 7;
using database @: /home/zamy/BanBot/databaseCube/
VDATA INFO
34
VDATA INFO
ss
Db::execQuery result code is > 0 sending value 1
Db::findPreciseIdNickViaNickOp
ANSWER 0 is -> 34ANSWER 1 is -> ssDb::execQuery - select id,nick,level from oplist where nick like '%ss%' limit 16;
using database @: /home/zamy/BanBot/databaseCube/
VDATA INFO
34
VDATA INFO
ss
VDATA INFO
100
Db::execQuery result code is > 0 sending value 1
Db::findAproxIdNickViaNickOp
ANSWER 0 is -> 34ANSWER 1 is -> ssANSWER 2 is -> 100search: 1 1
Segmentation fault

Nella funzione di ban c'era/c'è un bug.
Ora funziona, però tornava e continua a tornare true in caso di errore.
Maggiori dettagli in db.cpp.