gaoesa

The minimizer part doesn't need to be injected and doesn't cause AV issues. The dll handling the raw input is injected to the launched ET process in my program, which probably caused that single time the AV flagged it.

It is unlikely that Windows minimizer would get implemented even if requested. The reasons are that it would require worker thread and system tray icon. If we would do it properly. Also, there are lot of external programs out there that have been used for years, so the investment of embedding it into the mod is mostly not worth it. @sol There is no lack of code samples. I have, in fact, made external program that handles minimizer and raw input. http://www.himalia.fi/forum/viewtopic.php?f=5&t=1178&sid=1d3b5b189944d7bb737114a18dc0b78e

The second problem is definitely caused by the client and the server version not matching.

WP_DEMOLITION , 40 WS_DEMOLITION , 24 Both values in decimal. EDIT: Former values higher then 40 increase by one, if there was no empty space before.

There has not been any false positives. It must do more then that. I was streaming admin with PBBans long time ago and all a player had to do was to change the etkey to get rid of the ban. Therefore, just streaming bans is not all it does to achieve a 99.9 percent success rate.

You can probably set the ETTV server GUID in the ClientConnect Lua hook, which will prevent getting kicked. It needs to be set before the ClientBegin. But the final solution requires changes in the mod to fix the issue. This was never tested. function et_InitGame(levelTime, randomSeed, restart) et.RegisterModname("ETTV fix for silEnT 0.8.0") end function et_ClientConnect( clientNum, firstTime, isBot ) local userinfo = et.trap_GetUserinfo( clientNum ) local protocol = et.Info_ValueForKey( userinfo, "protocol" ) if protocol == 284 then userinfo = et.Info_SetValueForKey( userinfo, "sil_guid", "EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE:2" ) et.trap_SetUserinfo( clientnum, userinfo ) end return 1 end This could work. I don't have ETTV for test, so please report back how it turns out.

PB streaming is not an effective way of banning. That uses only PB GUIDs. I'm not familiar with UNITYHUB. The autoban is not configurable. You can edit the bans of course. I do recommend being carefull with IP addresess, as most players have dynamic IPs. So after a while, it is very likely that after some time, the IP address in the ban can affect someone else then the intended player.

1. Automatic bans work with the same informations as normal bans. The silEnT GUID, PB GUID, IP address and hardware data if g_identOptions is set so. 2. The automatic bans are always 12 months long. 3. This one we can't do, because to do so we would need to validate the player GUIDs. I assume you meant the server sending the bans automatically to a mygamingtalk server or similar. We can't make official lists where there could end up innocent players. GUID spoofing in client is not hard to do. This is the reason why the mod has admin level protection system for example.

Please update your server to the latest version of the mod. According to splatterladder, it is currently 0.6.3 version. If there is a bug we can't fix or identify it from older versions.

The backtrace shows in which binary the crash happened. In this case there is only one line and it says ET.exe. It's not wrong to post crash reports here. In some cases we just don't have anything to work with as the crash happens in some binary that is not in our control. Please keep posting them when in doubt.

Does this happen to all players trying to connect? Could be happening because the redirect is missing the file the client is redirected to download.

Thank you for the report. Unfortunately, the report is showing the crash happening inside the ET.exe and not in the mod libraries.

One case that will make the omnibot library to crash is if the bots are dropped while they are connecting. This can happen by Lua through the et_ClientConnect hook. http://mygamingtalk.com/wiki/index.php/Silent_Lua#et_ClientConnect Make sure you don't have Lua scripts running and if that fixes the issue, go through the scripts to see which one is causing it.

Does this happen only with Omni-bots? Meaning without the bots, if any human players join and play the maps, there are no crashes? If you have Lua scripts running, please test also without those.

The g_mode 8 enables anyone picking up any weapon. If you don't want this, g_mode 2 (each class receives adrenaline, this does not depend on the medic skill) should be used.

This should be possible only with g_mode 8.

There is a method to read cvars from the clients.

Can you provide an example that will succesfully spoof this if string.sub(text,1,19) == "Vote Passed: [poll]" then Also, I don't know how to substitute et_Print with et_ConsoleCommand in this script, could you be more specific on how the passed poll vote can be captured with it. If there are issues, a new lua hook could be introduced to solve them.

It would not be logically tied to mute. Also, admins may want to inform the player of things while he is muted.

That is true and it is stated already for qagame. However, the 140 MB increase in the etded.x86 is significant enough to see there is an issue. Accompanied by the fact that it is already known before hand that there is a memory leak problem. These snapshots are, in my opinion, clear enough to point to the direction where the memory concerned in the topic is not being freed. That is why I posted about two snapshots instead of doing a cronjob task for it. The 6 MB with qagame can come from a number of naturally occurring differences and it is not enough to formulate conclusions.

The anon blocs are mostly memory allocated from the heap.

I don't see significant differences in these regarding qagame given that memory usage differences can be caused by other factors as well. One small leak we have found though, which happens when reading files with Lua scripts. 00000000ef112000 1492 1340 112 r-x-- qagame.mp.i386.so 00000000ef287000 52 52 52 rwx-- qagame.mp.i386.so 00000000ef294000 51236 46484 46484 rwx-- [ anon ] 00000000ef100000 1492 1324 112 r-x-- qagame.mp.i386.so 00000000ef275000 52 52 52 rwx-- qagame.mp.i386.so 00000000ef282000 51236 40912 40880 rwx-- [ anon ] The major concern seems to be with the etded.x86. 0000000008048000 408 376 0 r-x-- etded.x86 00000000080ae000 20 20 16 rwx-- etded.x86 00000000080b3000 8000 872 856 rwx-- [ anon ] 0000000008996000 149892 149888 149888 rwx-- [ anon ] 0000000008048000 408 376 0 r-x-- etded.x86 00000000080ae000 20 20 16 rwx-- etded.x86 00000000080b3000 8000 832 768 rwx-- [ anon ] 0000000009e77000 9360 9336 9336 rwx-- [ anon ]

It's only used with map voting.

It looks like there is something wrong with his client. The player is connected but is not providing lot of the data. You may be interested of g_identOptions flags 2 and 8, to automatically making sure every client provides full data. It is normal that still connecting clients would be missing some of the data, but in that case, the ident for example would say "CONFIRM LATER", at least in latest mod version.

This setting will control this http://mygamingtalk.com/wiki/index.php/Silent_Mod_Server_Cvar#g_minMapAge