[hlcoders] c1a4i rcbot metamod svencoop crash
-- -- [ Picked text/plain from multipart/alternative ] hello, A question about: How to locate an error that happens when loading a map? running svencoop3.0 on a standalone dedicated server. when loading one of the half-life single player maps, c1a4i the following error, pops up: Fatal Error-Dedicated Server SZ_GetSpace: Tried to write uninitialized sizebuf_t: ??? hlds installation up to date win32 server engine version 30 half-life base content version 8 this occurs when using rcbot 1.3, 1.4 beta and metamod 118,119, 119p28 or metamod-p this map is a valve map extracted from the half-life.gcf with some entity mods by the sven team. also crashes with the original unmodified valve map. on two different server hardware configurations. XP Home, p4 2.8ghz, 1gb ram. also XP Pro p3 1.0ghz 512mb ram sp2. no ie7 typically using serverdoc to monitor the hlds server. it will relaunch the hlds server using sdautomap when it crashes. serverdoc is loaded at boot time as a scheduled task, no need to login to XP. can stop, start, restart with different command line options, via small builtin web server hlds.exe -console -game svencoop -insecure -nomaster +sv_lan 1+map *sdautomap=c1a1* map c1a1 is loaded at server startup. sometime later... c1a4b loads, rcbot initializes, a bot is spawned. single handed, he kills the bad guys; reaches the trigger_changelevel and beep! server crash. about 25 seconds tic by serverdoc relaunches the half-life server automatically loading the last map. c1a4b loads and the story repeats. even when no bot is spawned. one or more players fight to the end of the level and beep! server crash don't know how to get more information on what is causing the crash. svencoop fourms no help, rcbot forums no joy. perhaps some interaction between the server loading the map and rcbot initialization with metamod and svencoop3.0 notes: there is no crash when using the standalone version of rcbot.dll in the liblist.gam without metamod also, no crash on first the run. fresh install of rcbot with rcbot_mm.dll in the metamod plugins.ini plus, listening server does not crash. if anyone has an idea of how to get more information about what is causing this crash I would be willing to listen. thank you. developer 2 server log files with three bots. L1121000.txt L 11/21/2006 - 15:28:03: Log file started (file "logs\L1121002.log") (game "svencoop") (version "47/1.1.2.0/3382") L 11/21/2006 - 15:28:05: "botKiLLa<2>" has entered the game L 11/21/2006 - 15:28:05: "botKiLLa<2>" say "yo" L 11/21/2006 - 15:28:07: "bl33tch<3>" has entered the game L 11/21/2006 - 15:28:10: "env_explosion" killed "supa gorge<1>" with "env_explosion" L 11/21/2006 - 15:28:12: "env_explosion" killed "bl33tch<3>" with "env_explosion" L 11/21/2006 - 15:28:24: "worldspawn" killed "botKiLLa<2>" with "worldspawn" L 11/21/2006 - 15:28:25: "monster_houndeye" has been killed by "supa gorge<1>" L 11/21/2006 - 15:28:26: Kick: "supa gorge<1><>" was kicked by "Console" L 11/21/2006 - 15:28:26: "supa gorge<1>" disconnected L 11/21/2006 - 15:28:26: Kick: "botKiLLa<2><>" was kicked by "Console" L 11/21/2006 - 15:28:26: "botKiLLa<2>" disconnected L 11/21/2006 - 15:28:26: Kick: "bl33tch<3><>" was kicked by "Console" L 11/21/2006 - 15:28:27: "bl33tch<3>" disconnected L 11/21/2006 - 15:28:27: [META] ini: Begin re-reading plugins list: c:/fourth/valve/steam/steamapps/user/half-life/svencoop/addons/metamod/plugins.ini L 11/21/2006 - 15:28:27: [META] ini: Read plugin config for: Hook Mod L 11/21/2006 - 15:28:27: [META] ini: Read plugin config for: RCBot For Half-Life L 11/21/2006 - 15:28:27: [META] ini: Finished reading plugins list: c:/fourth/valve/steam/steamapps/user/half-life/svencoop/addons/metamod/plugins.ini; Found 2 plugins L 11/21/2006 - 15:28:27: [META] dll: Updating plugins... L 11/21/2006 - 15:28:27: [META] dll: Finished updating 2 plugins; kept 2, loaded 0, unloaded 0, reloaded 0, delayed 0 L 11/21/2006 - 15:28:27: Log file closed L1121001.txt L 11/21/2006 - 15:28:27: Log file started (file "logs\L1121003.log") (game "svencoop") (version "47/1.1.2.0/3382") L 11/21/2006 - 15:28:27: Loading map "c1a4i" L 11/21/2006 - 15:28:27: Server cvars start L 11/21/2006 - 15:28:27: Server cvar "allow_spectators" = "1.0" L 11/21/2006 - 15:28:27: Server cvar "coop" = "0" L 11/21/2006 - 15:28:27: Server cvar "deathmatch" = "1" L 11/21/2006 - 15:28:27: Server cvar "DF_hook_on" = "1" L 11/21/2006 - 15:28:27: Server cvar "edgefriction" = "2" L 11/21/2006 - 15:28:27: Server cvar "max_queries_sec" = " 3.0" L 11/21/2006 - 15:28:27: Server cvar "max_queries_sec_global" = "30" L 11/21/2006 - 15:28:27: Server cvar "max_queries_window" = "60" L 11/21/2006 - 15:28:27: Server cvar "metamod_version" = " 1.19p28" L 11/21/2006 - 15:28:27: Server cvar "mp_autocrosshair" = "0" L 11/21/2006 - 15:28:27: Server cvar "mp_banana" = "1.0" L 11/21/2006 - 15:28:27: Server cvar "mp_consistency" = "1" L 11/21/2006 - 15:28:27: Server cvar "mp_flashlight" = "1" L 11/21/2006 - 15:28:27: Serve
[hlcoders] Help identify crash cause on closed source please
-- [ Picked text/plain from multipart/alternative ] Hi, I keep getting crashes randomly when playing my mod, the mdmps all agree on the same stack trace, but it's on the closed side so I don't know how to fix it. Almost all the mdmps I had said the stack was: >kernel32.dll!7c812a5b() kernel32.dll!7c812a5b() user32.dll!77d50577() tier0.dll!009124e9() tier0.dll!00901db0() engine.dll!0db6dbad() Except one, which was the oldest one: >kernel32.dll!7c812a5b() kernel32.dll!7c812a5b() user32.dll!77d50577() tier0.dll!009124e9() tier0.dll!00901db0() filesystem_steam.dll!0d1696ab() filesystem_steam.dll!0d15dd0a() filesystem_steam.dll!0d15be43() filesystem_steam.dll!0d15329d() filesystem_steam.dll!0d1532e6() When it crashes it says it failed on DirectX Present() - pure virtual function call. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
Identifying the individual commands to block is a hard problem, which makes me wonder if this isn't why Valve just went with the nuke switch regarding backwards compatibility and blocked everything. (Or perhaps they discovered a filesystem exploit in the field using the client's console. I doubt that, though, or this wouldn't have been optional.) When I tried to name off the individual commands that are simply too valuable not to have access to (connect, playgamesound, etc, etc), the list gets very long. In the end, it even included the infamous alias and bind commands. Even though these are evil commands for griefing players, for the very same reason, they're important for "white hat" administrators when they need to help newbies out. I run a number of newbie servers for my beta testing and I've found that new players have no grasp of the console and are very confused with how to bind anything custom or interesting (for stats, +jetpacks, etc). Giving the server access to help them bind (at their request) is an important tool we have to improve usability in the game. In addition, it's awfully helpful to get notified of +/- sorts of custom commands by creating, for example, a +jetpack alias on the client that sends the command to the server. In those cases, warning the user of the alias/bind (and allowing them to block it) would be an appropriate remedy. I wanted to respond before this thread died away completely, but this has really hurt the community in ways I couldn't have envisioned before. Typically, when Valve updates something major internally, it breaks things and plugin authors scramble to fix them. Often, the coders accept blame because they were using some unsupported trick or prying in areas Valve doesn't recommend. This time however, plugin authors are being blamed when they're using the supported commands they were given long ago. In the past, plugin writers have been yelled-at (by Valve even) when plugins doing unsupported things break lots of servers. Yet now everyone was using a supported API and with one flick of a switch, it was killed quietly without any nod to how impactful it would be. It's had a very dampening effect on the scripting community, blowing away swaths of popular scripts that relied, indirectly, on engine->ClientCommand(). True, the command is unreliable, it's risky, and half of its functionality works server-side, but that doesn't change the fact that it was heavily used in the field. As a platform, Source surely can't violate backwards compatibility like this without giving us some sort of new alternative (or identifying existing alternatives). Hopefully Valve will either unrestrict the most secure commands or code server-side replacements for those we've lost. At the very minimum, Valve should do better in communicating major regressions in backwards compatibility. If they can do that, it will at least prepare those gaming communities that stick around for the inevitable breaks. Best of luck, -Mattie http://mattie.info/cs/ - Original Message - From: "David Anderson" <[EMAIL PROTECTED]> To: Sent: Saturday, November 18, 2006 1:18 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco Yes, good point, that's unfortunate but true. I can't say I'm a good person to ask which commands, as I'm not very familiar with the client :) But I can take a guess that anything having to do with binds/aliases or client-side settings (i.e. cl_*) is fair game. I just think that at the very least, things that are sent from the server and aren't handled by the client should be properly passed back to the server. Obviously, users can use IServerPluginHelpers to simulate this, but I'm a big stickler for preserving backwards compatibility. Especially in this case when we're not even dealing with binary hacks. ~dvander http://www.bailopan.net/ Nick wrote: You have mentioned some good points. I am curious though which commands you would restrict? About it being default on, the problem is that users that know enough to enable cl_restrict_server_commands 1, are not the ones that need the command the most. The users that do not know how to set "cl_restrict_server_commands 1" are the users that need it enabled the most. On 11/18/06, David Anderson <[EMAIL PROTECTED]> wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailop
