[TFC] Execution order of map configs reveresed

[pizzahut2]

This is a new client side issue which is caused by the bug fix for https://github.com/ValveSoftware/halflife/issues/2108 .

With developer 1 the console says that the game is executing mapdefault.cfg and then the current map's cfg file, however it actually executes them the other way round (1st map cfg file, then mapdefault.cfg ).

This partially defeats the purpose of having a default cfg file for maps. Individual settings made in a map's config are overruled by the mapdefault.cfg .

[SamVanheer]

I tested this and this is what i got:

couldn't exec mapdefault.cfg
execing well.cfg
WELL CFG LOADED 

When starting map well.

Note for testers, you'll need to set a couple info keyvalues: https://www.quaddicted.com/webarchive/www.planetfortress.com/tftech/tfcconfig.shtml

Or do this in the console and then restart the server:

setinfo ec 1
setinfo em 1

I take it the problem is the commands inside the cfg are being executed out of order?

[pizzahut2]

Don't know about inside, it usually doesn't matter. However the configs should be executed in a particular order.

[SamVanheer]

I suspect this problem happens because the exec commands are being added to the filtered command buffer, but the commands parsed out of the cfg files are added to the regular buffer.

That buffer is not executed until the next frame, because command buffer execution is done like this:

void Cbuf_Execute()
{
  Cbuf_ExecuteFromBuffer(&cmd_text, true);
  Cbuf_ExecuteFromBuffer(&filteredcmd_text, false);
}

So to fix this the commands parsed out of cfg files should either be added to the buffer that the exec command is being executed from, or the order of execution should be preserved.

The former is fairly easy to implement, the latter would require a lot of refactoring that would likely break any mods (like AMX) that rely on the internal command buffer code working as before.

Alternatively the exec command could be added to the regular buffer even with filtering enabled (in TFC's case only). From what i can tell the validation code can handle cases where malicious commands follow valid ones in the same command string so it should remain secure.

[pizzahut2]

Not much time right now, anyway just to make it clear.

I have map specific text comms which primarily change the keyboard binds. Since there are between 2000 and 3000 TFC maps, I don't have such configs for every map, thus default text comms (from mapdefault.cfg) should be used in this case.

If the configs are executed in the wrong order, the binds inside the mapdefault.cfg take precedence (over the current map's config) because they are (wrongly) executed after the cfg file of the current map. So basically, I end up with the default comms for every map.

Console says the exec order is (for example)

mapdefault.cfg (default comms for when there's no map specific cfg) rock2.cfg (map specific comms)

But it actually executes them like this:

rock2.cfg (map specific comms) mapdefault.cfg (default comms for when there's no map specific cfg)

[SamVanheer]

Confirmed, i added an echo command to mapdefault.cfg and the order is reversed, but only for the sets of commands in both cfgs, individual commands are not reversed.

Manually executing both cfg files works as expected: exec mapdefault.cfg;exec well.cfg

execing mapdefault.cfg
mapdefault 
mapdefault2 
execing well.cfg
WELL CFG LOADED 

So the problem is in how the exec command adds commands from the cfg file to the buffer.

It does have to do with the exec commands being in the filtered command buffer. I'll explain by showing the order of commands.

When running the exec commands yourself, the commands are all in the regular buffer:

exec mapdefault.cfg
exec well.cfg

When mapdefault.cfg executes, the command is first removed from the buffer, the exec command then adds all commands to the regular buffer.

echo mapdefault
echo mapdefault2
exec well.cfg

These commands will then execute in that order, as expected.

But now that exec commands from the server are added to the filtered command buffer, this changes. Filtered buffer:

exec mapdefault.cfg
exec well.cfg

When mapdefault.cfg is executed, the contents of both buffer are as follows: Regular:

echo mapdefault
echo mapdefault2

Filtered:

exec well.cfg

Then well.cfg executes: Regular:

echo WELL CFG LOADED
echo mapdefault
echo mapdefault2

Filtered:

//Nothing

So what exec does is it adds all commands to the beginning of the buffer. This worked before because those commands would then be executed immediately. But now, all exec commands are executed first, the commands added in reverse order and then executed the next frame.

To fix this, exec commands sent from the server that are allowed to execute (i.e. gamedir == tfc) must be added to the regular buffer to function properly.

I recommend adding a new function to the client.dll API that can be used to let mods decide if exec should be allowed from servers. It's more robust and doesn't break functionality:

DLLEXPORT int HUD_AllowClientCmd( const char* pszCmd )
{
    if( !strcmp( pszCmd, "exec" ) )
    {
        return 1;
    }

    return 0;
}

//In ValidStuffText
if( !cl_funcs.pAllowClientCmd || !cl_funcs.pAllowClientCmd( "exec" ) )
    bDenyCmd &= Q_stristr(cmd, "exec") == 0;

Alternatively, mods can work around it by making their own exec command and forwarding it using the unfiltered client command engine function gEngFuncs.pfnClientCmd.

[pizzahut2]

individual commands are not reversed.

Indeed, just tested this.

execing mapdefault.cfg execing 2fort.cfg 2fort.cfg - start 2fort.cfg - end MAPDEFAULT.CFG - START MAPDEFAULT.CFG - END

[i486]

@SamVanheer

Always appreciated of your passion and skill for CS. I hope Valve recognizes your skill and implement/fix all the bugs/ideas you collected over the years.

[pizzahut2]

@kisak-valve @johndrinkwater @triage-valve This has been fixed, however it requires using the latest tfc "dll", which server owners have been avoiding so far due to this bug: https://github.com/ValveSoftware/halflife/issues/1070

[SamVanheer]

For those that are interested, this was fixed by moving the code to execute cfg files to the engine. A new client engine command with ID 59 has been added with the following parameters:

byte IsClassCfg
if IsClassCfg != 0 && IsClassCfg == 1
    byte ClassIndex

So if it's a class cfg command the index of the class is used to determine the correct file to execute. If not then it will execute mapdefault.cfg and then if the level name is not too long (<= 4094 on Linux) the map specific cfg, if it exists.

This only works for TFC.

5 things:

1. Please release patch notes when you release updates
2. Mark issues as fixed on this issue tracker when you fix things
3. Try not to hardcode the fixes because the codebase is already messy enough as it is
4. Open source the whole thing so we can fix it ourselves. That way it can be done properly, with an exec command that cannot be exploited and so other issues like the one pizzahut linked to can be fixed
5. Talk to us

[mikela-valve]

Hey @SamVanheer, first off, sorry for the lack of communication. I'd intentionally withheld the first set of patch notes temporarily and had hoped to release them shortly after this release cycle settled down a bit but that went on much longer than I'd intended. I plan to have a complete set of patch notes covering the last set of releases posted on Monday. I'll also be actively updating issues that I work on here in the future.

What I'd hoped to accomplish from this release set was to establish a high water mark for how secure things will be then dial anything back that is too restrictive, this issue being a prime example of that. For the moment I thought that moving the script exec'ing from TFC into the engine was safest since it retains the current behaviour while removing the requirement for the client to trust the configs specified by the server.

Regarding allowing mods to configure whether or not exec is allowed, what I worry about is that it's putting a bit too much trust back into the server, though I do agree that there should be a way for users directly or through mods to be able to enable more functionality. One possibility I was thinking of was allowing the client to specify a whitelist of allowed config files, but I'd definitely be open to suggestions.

Open sourcing is a possibility though it will likely take some time to work out, though I did speak to Alfred a bit about it before so I'm aware of some of what that would entail. I'll open a new issue to discuss it if and when I have more information.

Last, as @pizzahut2 pointed out, server owners aren't using the latest TFC versions (which I unfortunately wasn't aware of, sorry) which obviously doesn't work well with the engine change so I've fixed #1070 in the latest TFC beta released today which I'll promote to public on Monday if things seem to be working well over the weekend. If there are other issues that are similarly blocking adoption of newer versions, please let me know and I'll prioritize them accordingly. I also have changes staged for several other issues that I should be able to release to beta soon, which I'll be sure to mark the associated issues for.

It's awesome to see the dedication and passion for these games, so I'll definitely be doing what I can to support the community going forward.

[SamVanheer]

Thanks for the reply.

I wasn't aware that the patch notes were delayed, thanks for elaborating on that.

The exec fix is good, it's just that the same code could've been put in the TFC client dll. The only difference on the server side would be using a gmsgExec global instead of 59 to send the message, as well as adding a size value to the beginning to prevent message corruption (done by the engine).

My suggestion regarding the callback was to put it on the client side, so the server wouldn't get to decide which commands are allowed to have full execution privileges, but i can see how that could still allow for abuse.

I found an issue with the new engine command, as well as commands in general that i reported on HackerOne. I can't see the structure of the engine well enough to be sure if there's a serious issue here or not, but you should have enough information to investigate it with.

Regarding open sourcing, it would certainly be nice to have. We don't know what's preventing that from happening, so could you elaborate on what's going on, or is that something you can't comment on at this time? Personally i'd like to see it be possible for us to make custom engines that can be on Steam and that can reference original content (without including it), but i think that the Steamworks license may be an issue here.

I think any standalone games made like this that use original Half-Life content would have some check that says "Requires ownership of Half-Life" or something to that effect, similar to how mods that are on Steam are listed as Half-Life mods now. For example Half-Rats Parasomnia has this: https://store.steampowered.com/app/638360/HalfRats_Parasomnia/

I'm aware of server owners using older binaries, i'll keep an eye out for any other issues that are keeping them from updating so that can be resolved. If it hasn't been reported yet i'll make new issues for them.

Thanks again for taking the time to fix these issues, and for responding to us. It really means a lot to us for Valve to continue supporting the community.

[MaZDuR]

Greetings, I have tested this new update with my servers and have nothing but success to report.. ..with one exception. Whatever changes took place seems to have caused a problem with the tfc modification 'NeoTF'

I would normally bring this to the support of the developer of the mod, but this project was abandoned about a decade ago (ps: thanks for still supporting tfc)

I don't expect anything to be done, but hopefully somebody here can figure out if its possible for something to be done to fix this.

under engine version 8196 with the latest tfc.so servers running NeoTF crash when a player entity is spawned. here is the output from the server console when foxbot tries to spawn a bot: Creating bot... L 04/15/2019 - 04:03:48: FATAL ERROR (shutting down): NUM_FOR_EDICT: bad pointer FATAL ERROR (shutting down): NUM_FOR_EDICT: bad pointer

I also planned on sending you the debug.log, but I peeked at its contents and was honestly surprised at how underwhelming the information it provided was, maybe theres some more info you guys have on your end?

CRASH: Mon Apr 15 04:07:04 UTC 2019
Start Line: ./hlds_linux -game tfc -console +port 27015 +maxplayers 24 +map badlands -debug -timeout 1 -dll addons/metamod/dlls/metamod.so -pidfile hlds.15.pid
End of crash report
----------------------------------------------

Any status on that infecting feigned spies issue? I think that's the only 'game breaking' bug that remains now, but as its a very rare case anymore I don't see it as something that needs much attention.

[SamVanheer]

I took a look at your crash issue, first the resources needed to debug this: NeoTF source code: http://www.geocities.ws/neotfmod/download.html foxbot code for bot creation: https://github.com/APGRoboCop/foxbot/blob/e045ed4f4a361733ffaf836182bd20d614cd7fbc/bot.cpp#L788

I'm guessing GET_INFOBUFFER is where the bad pointer error is happening. It called NUM_FOR_EDICT and BotEnt isn't changed after the bot is created.

I ruled out the edict_t type having a different size (compared to the latest Github SDK) and the pointer should be valid since it's returned from the engine.

I don't see anything that could be causing this, so unless the binaries differ from this code it should work.

Debugging this with a debugger attached will probably help.

Could you link to a download for your copy of NeoTF and foxbot so the exact same versions can be tested?

For reference, the infecting feigned spies issue is this one: #1002

[MaZDuR]

https://www.tfcrefugees.com/resources/neotf-linux-server.85/

I was able to reproduce this with foxbot disabled, the server will also crash when players attempt to connect. (Happens at the end of precaching resources) I was using metamod 1.21p38 if that matters.

Neotf became closed source around the time adminop popped up big (2003ish?) Because the source code was being used without permission. I will see about running it with a debugger after work tonight.. for now I have elected to run the server with the outdated tfc.so and neotf functions normally

[SamVanheer]

And it doesn't happen without Metamod enabled, right?

If so there must be some change in a public interface, but i checked the existing server interfaces and they're still the same as before. A call stack showing the crash would be nice to have.

It could also be some code in a Metamod plugin that's hooking into existing internal code in the engine or TFC but i'd need to see the code for that, so a call stack would narrow it down a lot.

[MaZDuR]

No no no, the issue is occurring with neotf (as far as I'm aware) I haven't tested it without metamod, I will try running it with only neotf and tfc loaded and see what the result is.

I'm going to set it up with gdb when I get home from work to provide more info, I'm not very good with this stuff, but it looks like I just need to get the backtrace from a crash? Going to follow this post for debugging. https://forums.alliedmods.net/archive/index.php/t-1467.html

[SamVanheer]

Yes that should do the trick.

[MaZDuR]

Well.. I tried to do some debugging.. when trying to run just Neotf (without metamod) I run into an issue of it not properly loading the original tfc.so

LoadLibrary failed on 1▒t▒▒▒▒▒▒▒▒: 1▒t▒▒▒▒▒▒▒▒: cannot open shared object file: No such file or directory
Host_Error: Couldn't get DLL API from 1▒t▒▒▒▒▒▒▒▒!
FATAL ERROR (shutting down): Host_Error: Couldn't get DLL API from 1▒t▒▒▒▒▒▒▒▒!

[Inferior 1 (process 18806) exited with code 0377]
No stack.

When trying to run it with metamod, I get the following.. (Note: I was going to connect and get the error, but I got this before trying to connect

L 04/15/2019 - 20:54:04: Server cvar "amx_nextmap" = "dustbowl"
[New Thread 0xf02ffb40 (LWP 19659)]

Thread 1 "hlds_linux" received signal SIGSEGV, Segmentation fault.
0xf2b056fc in NTF_BodyQueueFix(void) ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/NeoTF/dlls/NeoTF_i486.so
#0  0xf2b056fc in NTF_BodyQueueFix(void) ()
---Type <return> to continue, or q <return> to quit---
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/NeoTF/dlls/NeoTF_i486.so
#1  0xf2adab5d in NeoTFStartFrame(void) ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/NeoTF/dlls/NeoTF_i486.so
#2  0xf2af0933 in StartFrame(void) ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/NeoTF/dlls/NeoTF_i486.so
#3  0xf34f7cd8 in main_hook_function_void(unsigned int, enum_api_t, unsigned int, void const*) ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#4  0xf34fa8e1 in mm_StartFrame() ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#5  0xf7715268 in SV_Physics () at ../engine/sv_phys.c:1985
#6  0xf770d166 in SV_Frame () at ../engine/sv_main.c:9282
#7  0xf76d4e12 in _Host_Frame (time=0.00108446996) at ../engine/host.c:1404
#8  0xf76d51d2 in Host_Frame (time=0.00108446996, iState=1,
    stateInfo=0xffffd30c) at ../engine/host.c:1522
#9  0xf76f9b7c in CEngine::Frame (this=0xf77916c0 <g_Engine>)
    at ../engine/sys_engine.cpp:245
#10 0xf76f6ea3 in CDedicatedServerAPI::RunFrame (this=<optimized out>)
---Type <return> to continue, or q <return> to quit---

and when trying to connect as a normal player (foxbot disabled)

L 04/15/2019 - 20:58:43: [NEOTF] NeoTFClientPutInServer: 0xf37fab34 (Player<1><STEAM_0:1:901100><>)
L 04/15/2019 - 20:58:44: FATAL ERROR (shutting down): NUM_FOR_EDICT: bad pointer
FATAL ERROR (shutting down): NUM_FOR_EDICT: bad pointer
[Thread 0xefbfdb40 (LWP 20485) exited]
[Thread 0xefcfeb40 (LWP 20484) exited]
[Thread 0xf06feb40 (LWP 20480) exited]
[Thread 0xf2084b40 (LWP 20478) exited]
[Thread 0xf13ffb40 (LWP 20477) exited]
[Thread 0xf1dbeb40 (LWP 20475) exited]
[Thread 0xf7bd5940 (LWP 20471) exited]
[Thread 0xf07ffb40 (LWP 20487) exited]
[Inferior 1 (process 20471) exited with code 0377]
No stack.

Here is the cleanest console output I could gather

[root@esclan:/srv/symlink/lowgrav] 30s # ./gdb.sh
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./hlds_linux...done.
Starting program: /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/hlds_lin                                                                                                                                                             ux -game tfc -console -debug +port 27015 +ip 66.151.244.232 +maxplayers 8 +map 2                                                                                                                                                             fort -dll addons/metamod/dlls/metamod.so
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
warning: Corrupted shared library list: 0x8057960 != 0x0

Console initialized.
Using breakpad crash handler
Setting breakpad minidump AppID = 20
Forcing breakpad minidump interfaces to load
dlopen failed trying to load:
/root/.steam/sdk32/steamclient.so
with error:
/root/.steam/sdk32/steamclient.so: cannot open shared object file: No such file                                                                                                                                                              or directory
warning: Corrupted shared library list: 0x8059cb0 != 0xf7df5610
Looking up breakpad interfaces from steamclient
Calling BreakpadMiniDumpSystemInit
warning: Corrupted shared library list: 0x805a7e0 != 0xf7ec67b4
Protocol version 48
Exe version 1.1.2.2/Stdio (tfc)
Exe build: 15:52:40 Apr  3 2019 (8196)
STEAM Auth Server
Server IP address 66.151.244.232:27015
warning: Error reading shared library list entry at 0x1f0

   Metamod version 1.21p38 Copyright (c) 2001-2013 Will Day
     Patch: Metamod-P (mm-p) v38 Copyright (c) 2004-2018 Jussi Kivilinna
   Metamod comes with ABSOLUTELY NO WARRANTY; for details type `meta gpl'.
   This is free software, and you are welcome to redistribute it
   under certain conditions; type `meta gpl' for details.

warning: Corrupted shared library list: 0x80d01f0 != 0x0
warning: Corrupted shared library list: 0x80a90c0 != 0xffffd73b
[S_API FAIL] SteamAPI_Init() failed; SteamAPI_IsSteamRunning() failed.
[New Thread 0xf2a80b40 (LWP 20989)]
[New Thread 0xf20ffb40 (LWP 20990)]
[New Thread 0xf1dffb40 (LWP 20991)]
CAppInfoCacheReadFromDiskThread took 1 milliseconds to initialize
[Thread 0xf1dffb40 (LWP 20991) exited]
[New Thread 0xf1affb40 (LWP 20992)]
[New Thread 0xf19feb40 (LWP 20993)]
[New Thread 0xf16ffb40 (LWP 20994)]
CApplicationManagerPopulateThread took 1 milliseconds to initialize (will have w                                                                                                                                                             aited on CAppInfoCacheReadFromDiskThread)
[Thread 0xf19feb40 (LWP 20993) exited]
[Thread 0xf16ffb40 (LWP 20994) exited]
[New Thread 0xf13ffb40 (LWP 20995)]
[New Thread 0xf12feb40 (LWP 20996)]
[New Thread 0xf11fdb40 (LWP 20997)]
[Thread 0xf13ffb40 (LWP 20995) exited]
dlopen failed trying to load:
/root/.steam/sdk32/steamclient.so
with error:
/root/.steam/sdk32/steamclient.so: cannot open shared object file: No such file                                                                                                                                                              or directory
Looking up breakpad interfaces from steamclient
Calling BreakpadMiniDumpSystemInit
[New Thread 0xf19feb40 (LWP 20998)]
warning: Error reading shared library list entry at 0x1740
warning: Error reading shared library list entry at 0x1b30
[New Thread 0xf1dffb40 (LWP 20999)]

"ntf_version" is "1.9.0"
"sv_contact" is ""
logaddress_del:  No addresses added yet
logaddress:  72.5.195.177:27502
Server logging data to file logs/L0415322.log
L 04/15/2019 - 21:00:18: Log file started (file "logs/L0415322.log") (game "tfc"                                                                                                                                                             ) (version "48/1.1.2.2/Stdio/8196")
Connection to Steam servers successful.
   VAC secure mode is activated.
L 04/15/2019 - 21:00:18: Server cvar "neotf" = "1"
L 04/15/2019 - 21:00:18: [NEOTF] Registering user messages...
L 04/15/2019 - 21:00:21: [NEOTF] NeoTFStartFrame: Detected bodyque entity.
L 04/15/2019 - 21:01:06: "Player<1><STEAM_0:1:901100><>" connected, address "71.161.72.123:27005"
L 04/15/2019 - 21:01:06: [NEOTF] NeoTFClientConnect: 0xf37fab34 (71.161.72.123)
Rcon from 72.5.195.177:60286:
rcon 829974638 "********" status
L 04/15/2019 - 21:01:06: Rcon: "rcon 829974638 "********" status" from "72.5.195.177:60286"
hostname:  -[EVIL]- Low Grav -Get Your Float On!!-
version :  48/1.1.2.2/Stdio 8196 secure  (20)
tcp/ip  :  66.151.244.232:27015
map     :  2fort at: 0 x, 0 y, 0 z
players :  1 active (8 max)

#      name userid uniqueid frag time ping loss adr
1 users
Rcon from 72.5.195.177:55119:
rcon 829974638 "********" sv_visiblemaxplayers
L 04/15/2019 - 21:01:06: Rcon: "rcon 829974638 "*********" sv_visiblemaxplayers" from "72.5.195.177:55119"
"sv_visiblemaxplayers" is "-1"
L 04/15/2019 - 21:01:06: "Player<1><STEAM_0:1:901100><>" STEAM USERID validated
L 04/15/2019 - 21:01:08: [NEOTF] NeoTFClientPutInServer: 0xf37fab34 (Player<1><STEAM_0:1:901100><>)
L 04/15/2019 - 21:01:08: FATAL ERROR (shutting down): NUM_FOR_EDICT: bad pointer
FATAL ERROR (shutting down): NUM_FOR_EDICT: bad pointer
[Thread 0xf1dffb40 (LWP 20999) exited]
[Thread 0xf19feb40 (LWP 20998) exited]
[Thread 0xf11fdb40 (LWP 20997) exited]
[Thread 0xf12feb40 (LWP 20996) exited]
[Thread 0xf1affb40 (LWP 20992) exited]
[Thread 0xf2a80b40 (LWP 20989) exited]
[Thread 0xf7bd5940 (LWP 20978) exited]
[Inferior 1 (process 20978) exited with code 0377]
No stack.

and here is the contents of my gdb.sh script, just in case

#!/bin/sh
#
#       Copyright (c) 2002, Valve LLC. All rights reserved.
#
#   a wrapper script for the main hl dedicated server binary.
#   Performs auto-restarting of the server on crash. You can
#   extend this to log crashes and more.
#

# setup the libraries, local dir first!
export LD_LIBRARY_PATH=".:$LD_LIBRARY_PATH"

# -dll addons/NeoTF/dlls/NeoTF_i486.so
# -dll addons/metamod/dlls/metamod.so
gdb -ex 'run -game tfc -console -debug +port 27015 +ip 66.151.244.232 +maxplayers 8 +map 2fort -dll addons/metamod/dlls/metamod.so' -ex bt -ex quit ./hlds_linux
#echo "gdb set (hlds_linux)"
#run -game {{HLDS_GAME}} -console +port {{SERVER_PORT}} +maxplayers {{HLDS_MAXPLAYERS}} +map {{HLDS_MAP}} -debug -timeout 1 -dll addons/metamod/dlls/metamod.so

I am still using the -beta beta branch.. I am assuming it is using the same files as the update that was pushed today.. I am not very familiar with linux, and even less so with debugging, but I have a feeling I did something wrong considering all the lines starting with 'warning: Corrupted shared library list'

If theres any other details I can provide to help troubleshoot this, let me know.

[mikela-valve]

@SamVanheer Notes are now posted for TFC, CS and HL1 with the rest to come:

https://steamcommunity.com/games/20/announcements/detail/3754222541410866604

https://steamcommunity.com/games/10/announcements/detail/3604477853344293460

https://steamcommunity.com/games/70/announcements/detail/3751970741595192232

_{Sent with GitHawk}

[Uiharu]

Thanks for posting, to be honest, many of us were wondering what got updated.

[SamVanheer]

@MaZDuR you'll need to put a breakpoint on the code that prints the bad pointer error message because it's not crashing, it's shutting down. When it gets hit, you can generate a backtrace.

See this page for information on how to set break points

Put a break point on the function called NUM_FOR_EDICT. It'll be hit whenever it's called so the first time it does, use break +2 to move the break point position to the error printing code. Then enter continue to continue execution.

This should result in the break point hitting only if the error occurs.

When it hits use the backtrace command to generate a call stack. That should tell us which function is calling it and roughly when the problem is occurring.

[MaZDuR]

I was unsuccessful with getting it to break on the error message.. are you sure the error message is at +2 from NUM_FOR_EDICT? it appears to be hitting it on every frame

Thread 1 "hlds_linux" hit Breakpoint 2, NUM_FOR_EDICT (e=0xf380f4f8)
    at ../engine/pr_edict.c:522
522     in ../engine/pr_edict.c

Thread 1 "hlds_linux" hit Breakpoint 1, NUM_FOR_EDICT (e=0xf380f4f8)
    at ../engine/pr_edict.c:519
519     ../engine/pr_edict.c: No such file or directory.
(gdb) break +2
Breakpoint 2 at 0xf76f1444: /home/buildbot/buildslave_hl1/goldsrc_linux/build/GoldSrc/linux/../engine/pr_edict.c:+2. (2 locations)
(gdb) c
Continuing.

Thread 1 "hlds_linux" hit Breakpoint 2, NUM_FOR_EDICT (e=0xf380f4f8)
    at ../engine/pr_edict.c:522
522     in ../engine/pr_edict.c
(gdb) info stack
#0  NUM_FOR_EDICT (e=0xf380f4f8) at ../engine/pr_edict.c:522
#1  0xf76ecfa5 in FindEntityByString (pEdictStartSearchAfter=0xf380f4f8,
    pszField=0xf282894f "classname", pszValue=0xf2828943 "item_tfgoal")
    at ../engine/pr_cmds.c:1348
#2  0xf27e1355 in UpdateFlagCarrierList() ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/foxbot/foxbot_mm.so
#3  0xf2802a70 in StartFrame() ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/foxbot/foxbot_mm.so
#4  0xf34f7cd8 in main_hook_function_void(unsigned int, enum_api_t, unsigned int, void const*) ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#5  0xf34fa8e1 in mm_StartFrame() ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#6  0xf7715268 in SV_Physics () at ../engine/sv_phys.c:1985
#7  0xf7706a58 in SV_ActivateServer (runPhysics=1) at ../engine/sv_main.c:7226
#8  0xf76da689 in Host_Map (mapName=0xffffcca0 "2fort", loadGame=false,
    mapstring=<optimized out>, bIsDemo=<optimized out>)
    at ../engine/host_cmd.c:1297
#9  0xf76dcd19 in Host_Map (loadGame=false, mapName=0xffffcca0 "2fort",
---Type <return> to continue, or q <return> to quit---
    mapstring=0xffffcc60 "map 2fort \n", bIsDemo=<optimized out>)
    at ../engine/host_cmd.c:1280
#10 Host_Map_f () at ../engine/host_cmd.c:1451
#11 0xf76bda4e in Cmd_ExecuteStringWithPrivilegeCheck (
    text=0xffffcd60 "map 2fort ", bIsPrivileged=<optimized out>,
    src=<optimized out>) at ../engine/cmd.c:1196
#12 0xf76bdc8d in Cmd_ExecuteStringWithPrivilegeCheck (bIsPrivileged=true,
    src=src_command, text=0xffffcd60 "map 2fort ") at ../engine/cmd.c:1155
#13 Cbuf_ExecuteFromBuffer (buf=0xf77a13b4 <cmd_text>, bIsPrivileged=true)
    at ../engine/cmd.c:244
#14 0xf76bdcb2 in Cbuf_Execute () at ../engine/cmd.c:262
#15 0xf76d7758 in Host_InitializeGameDLL () at ../engine/host_cmd.c:221
#16 0xf76f7967 in Sys_InitGame (
    lpOrgCmdLine=0x80571e0 "-game tfc -console -debug +port 27015 +ip 66.151.244.232 +maxplayers 8 +map 2fort -dll addons/metamod/dlls/metamod.so -steam",
    pBaseDir=0x804ca52 ".", pwnd=0x0, bIsDedicated=1)
    at ../engine/sys_dll2.cpp:806
#17 0xf76f9c1a in CEngine::Load (this=0xf77916c0 <g_Engine>, dedicated=true,
    basedir=0x804ca52 ".",
    cmdline=0x80571e0 "-game tfc -console -debug +port 27015 +ip 66.151.244.232 +maxplayers 8 +map 2fort -dll addons/metamod/dlls/metamod.so -steam")
    at ../engine/sys_engine.cpp:193
#18 0xf76f7465 in CDedicatedServerAPI::Init (
---Type <return> to continue, or q <return> to quit---
    this=0xf778cd20 <__g_CDedicatedServerAPI_singleton>,
    basedir=0x804ca52 ".",
    cmdline=0x80571e0 "-game tfc -console -debug +port 27015 +ip 66.151.244.232 +maxplayers 8 +map 2fort -dll addons/metamod/dlls/metamod.so -steam",
    launcherFactory=0x8049dd0 <CreateInterfaceLocal(char const*, int*)>,
    filesystemFactory=0xf7643d40 <CreateInterface(char const*, int*)>)
    at ../engine/sys_dll2.cpp:1189
#19 0x08049bcf in RunServer () at ../dedicated/sys_ded.cpp:646
#20 0x08049472 in main (argc=15, argv=0xffffd534)
    at ../dedicated/sys_ded.cpp:1146

I am going to continue trying to find out where I need to set the breakpoint to stop it before the crash, but other than looking at the stack every time the breakpoint is hit or just guessing how many lines I should offset the breakpoint.. either way, this may take me a while.

[SamVanheer]

It might be 3 if the opening { counts. I'm not sure how it works since i've never used it myself.

[MaZDuR]

Nope, wasnt able to get it to break on error, but heres this

(gdb) backtrace
#0  NUM_FOR_EDICT (e=0xf37fd408) at ../engine/pr_edict.c:522
#1  0xf76ed054 in GetEntityIllum (pEnt=0xf37fd408) at ../engine/pr_cmds.c:1362
#2  0xf27fe630 in UTIL_SavePent(edict_s*) ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/foxbot/foxbot_mm.so
#3  0xf2802762 in Sys_Error(char const*) ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/foxbot/foxbot_mm.so
#4  0xf34f3df7 in api_caller_void_args_p(void const*, void const*) ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#5  0xf34f7cd8 in main_hook_function_void(unsigned int, enum_api_t, unsigned int, void const*) ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#6  0xf34fa690 in mm_Sys_Error(char const*) ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#7  0xf76f506d in Sys_Error (error=0xf7745cd6 "NUM_FOR_EDICT: bad pointer")
    at ../engine/sys_dll.c:556
#8  0xf76f1472 in NUM_FOR_EDICT (e=0xf3358720 <CBaseMonster::AlertSound()>)
    at ../engine/pr_edict.c:526
#9  0xf76ecfa5 in FindEntityByString (
---Type <return> to continue, or q <return> to quit---
---Type <return> to continue, or q <return> to quit---
    pEdictStartSearchAfter=0xf3358720 <CBaseMonster::AlertSound()>,
    pszField=0xf2218240 "classname", pszValue=0xf22034a1 "player")
    at ../engine/pr_cmds.c:1348
#10 0xf21f8f15 in UTIL_FindEntityByString(CBaseEntity *, char const *, char cons                                                                                                                                                             t *) ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/NeoTF/d                                                                                                                                                             lls/NeoTF_i486.so
#11 0xf21f8f87 in UTIL_FindEntityByClassname(CBaseEntity *, char const *) ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/NeoTF/d                                                                                                                                                             lls/NeoTF_i486.so
#12 0xf21bdc50 in NeoTFPlayerPreThink(edict_s *) ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/NeoTF/d                                                                                                                                                             lls/NeoTF_i486.so
#13 0xf21e786f in PlayerPreThink(edict_s *) ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/NeoTF/d                                                                                                                                                             lls/NeoTF_i486.so
#14 0xf34f3df7 in api_caller_void_args_p(void const*, void const*) ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metam                                                                                                                                                             od/dlls/metamod.so
#15 0xf34f7cd8 in main_hook_function_void(unsigned int, enum_api_t, unsigned int                                                                                                                                                             , void const*) ()
   from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metam                                                                                                                                                             od/dlls/metamod.so
---Type <return> to continue, or q <return> to quit---
#16 0xf34fa980 in mm_PlayerPreThink(edict_s*) () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#17 0xf7719adf in SV_PlayerRunPreThink (time=<optimized out>, player=<optimized out>) at ../engine/sv_user.c:762
#18 SV_RunCmd (ucmd=0xffff940c, random_seed=0) at ../engine/sv_user.c:1002
#19 0xf76eee76 in PF_RunPlayerMove_I (fakeclient=0xf37fab34, viewangles=0xf37fac28, forwardmove=0, sidemove=0, upmove=0, buttons=0, impulse=0 '\000', msec=1 '\001') at ../engine/pr_cmds.c:2550
#20 0xf27da0ef in BotThink(bot_t*) () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/foxbot/foxbot_mm.so
#21 0xf2802aef in StartFrame() () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/foxbot/foxbot_mm.so
#22 0xf34f7cd8 in main_hook_function_void(unsigned int, enum_api_t, unsigned int, void const*) () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#23 0xf34fa8e1 in mm_StartFrame() () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#24 0xf7715268 in SV_Physics () at ../engine/sv_phys.c:1985
#25 0xf770d166 in SV_Frame () at ../engine/sv_main.c:9282
#26 0xf76d4e12 in _Host_Frame (time=162.697296) at ../engine/host.c:1404
#27 0xf76d51d2 in Host_Frame (time=162.697296, iState=1, stateInfo=0xffffd2fc) at ../engine/host.c:1522
#28 0xf76f9b7c in CEngine::Frame (this=0xf77916c0 <g_Engine>) at ../engine/sys_engine.cpp:245
#29 0xf76f6ea3 in CDedicatedServerAPI::RunFrame (this=<optimized out>) at ../engine/sys_dll2.cpp:1235
#30 CDedicatedServerAPI::RunFrame (this=0xf778cd20 <__g_CDedicatedServerAPI_singleton>) at ../engine/sys_dll2.cpp:1226
#31 0x08049c65 in RunServer () at ../dedicated/sys_ded.cpp:766
#32 0x08049472 in main (argc=15, argv=0xffffd534) at ../dedicated/sys_ded.cpp:1146

Not sure if this is 100% where it crashes, but I see the error in the backtrace, hopefully I got something useful.

[SamVanheer]

Looks like it's passing the address for CBaseMonster::AlertSound as an edict pointer. I'm guessing the layout of an entity class was changed and a plugin was grabbing an edict from it, so now it instead gets a vtable entry.

The plugin name is cut off though, /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/NeoTF/d. Can you find the complete name?

[MaZDuR]

That is NeoTF, full path would be /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/NeoTF/dlls/NeoTF_i486.so

[root@esclan:/srv … 765aa81e-6e3f-4de6-9af4-f22d6777fbb8] 32s # ./gdb.sh
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./hlds_linux...done.
Function "NUM_FOR_EDICT" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (NUM_FOR_EDICT) pending.
Starting program: /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/hlds_linux -game tfc -console -debug +port 27015 +ip 66.151.244.232 +maxplayers 8 +map 2fort -dll addons/metamod/dlls/metamod.so
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
warning: Corrupted shared library list: 0x8057960 != 0x0

Console initialized.
Using breakpad crash handler
Setting breakpad minidump AppID = 20
Forcing breakpad minidump interfaces to load
dlopen failed trying to load:
/root/.steam/sdk32/steamclient.so
with error:
/root/.steam/sdk32/steamclient.so: cannot open shared object file: No such file or directory
warning: Corrupted shared library list: 0x8059cb0 != 0x0
Looking up breakpad interfaces from steamclient
Calling BreakpadMiniDumpSystemInit
warning: Corrupted shared library list: 0x805a7e0 != 0x8061abc
Protocol version 48
Exe version 1.1.2.2/Stdio (tfc)
Exe build: 15:52:40 Apr  3 2019 (8196)
STEAM Auth Server
Server IP address 66.151.244.232:27015
warning: Error reading shared library list entry at 0x1f0

   Metamod version 1.21p38 Copyright (c) 2001-2013 Will Day
     Patch: Metamod-P (mm-p) v38 Copyright (c) 2004-2018 Jussi Kivilinna
   Metamod comes with ABSOLUTELY NO WARRANTY; for details type `meta gpl'.
   This is free software, and you are welcome to redistribute it
   under certain conditions; type `meta gpl' for details.

warning: Corrupted shared library list: 0x80d01f0 != 0x0
warning: Corrupted shared library list: 0x80a90c0 != 0x0
warning: Error reading shared library list entry at 0x3f40
[Config] Reading foxbot_commanders.txt
[Config] foxbot_commanders.txt : Loaded 0 users
loading waypoint file: tfc/addons/foxbot/tfc/waypoints/2fort.fwp
loading area file: tfc/addons/foxbot/tfc/areas/2fort.far
[S_API FAIL] SteamAPI_Init() failed; SteamAPI_IsSteamRunning() failed.
[New Thread 0xf19f7b40 (LWP 2573)]
[New Thread 0xf0fffb40 (LWP 2574)]
[New Thread 0xf0cffb40 (LWP 2575)]
CAppInfoCacheReadFromDiskThread took 2 milliseconds to initialize
[Thread 0xf0cffb40 (LWP 2575) exited]
[New Thread 0xf09ffb40 (LWP 2583)]
[New Thread 0xf08feb40 (LWP 2584)]
[New Thread 0xf05ffb40 (LWP 2585)]
CApplicationManagerPopulateThread took 0 milliseconds to initialize (will have waited on CAppInfoCacheReadFromDiskThread)
[Thread 0xf08feb40 (LWP 2584) exited]
[Thread 0xf05ffb40 (LWP 2585) exited]
[New Thread 0xf02ffb40 (LWP 2586)]
[New Thread 0xf01feb40 (LWP 2587)]
[New Thread 0xf00fdb40 (LWP 2588)]
[Thread 0xf02ffb40 (LWP 2586) exited]
dlopen failed trying to load:
/root/.steam/sdk32/steamclient.so
with error:
/root/.steam/sdk32/steamclient.so: cannot open shared object file: No such file or directory
Looking up breakpad interfaces from steamclient
Calling BreakpadMiniDumpSystemInit
[New Thread 0xf08feb40 (LWP 2589)]
warning: Error reading shared library list entry at 0x15e0
warning: Error reading shared library list entry at 0x19d0

Thread 1 "hlds_linux" hit Breakpoint 1, NUM_FOR_EDICT (e=0xf380f4f8) at ../engine/pr_edict.c:519
519     ../engine/pr_edict.c: No such file or directory.
(gdb) c 1800
Will ignore next 1799 crossings of breakpoint 1.  Continuing.
Executing tfc/addons/foxbot/tfc/foxbot.cfg
[New Thread 0xf0cffb40 (LWP 2594)]

"ntf_version" is "1.9.0"
"sv_contact" is ""
logaddress_del:  No addresses added yet
logaddress:  72.5.195.177:27502
Server logging data to file logs/L0416296.log
L 04/16/2019 - 17:45:56: Log file started (file "logs/L0416296.log") (game "tfc") (version "48/1.1.2.2/Stdio/8196")
L 04/16/2019 - 17:45:56: Server cvar "neotf" = "1"
L 04/16/2019 - 17:45:56: [NEOTF] Registering user messages...
[Config] bot_chat has been set to 50
[Config] botskill_upper has been set to 1
[Config] botskill_lower has been set to 3
[Config] bot_skill_1_aim has been set to 25
[Config] bot_aim_per_skill has been set to 20
[Config] min_bots has been set to 0
[Config] max_bots has been set to 8
[Config] bot_total_varies has been set to 0
[Config] bot_team_balance (0) Off
[Config] bot_bot_balance (0) Off
[Config] bot xmas (0) off
[Config] bot_allow_moods has been set to 1
[Config] bot_allow_humour has been set to 1
[Config] defensive chatter is 1
[Config] offensive chatter is 1
[Config] bot_use_grenades has been set to 2
[Config] bot_can_use_teleporter on
[Config] bot_can_build_teleporter on
[Config] pause has been set to 5
L 04/16/2019 - 17:45:58: [NEOTF] NeoTFStartFrame: Detected bodyque entity.
Creating bot...

Thread 1 "hlds_linux" hit Breakpoint 1, NUM_FOR_EDICT (e=0xf37fb7c4) at ../engine/pr_edict.c:519
519     in ../engine/pr_edict.c
(gdb) info stack
#0  NUM_FOR_EDICT (e=0xf37fb7c4) at ../engine/pr_edict.c:519
#1  0xf76ed054 in GetEntityIllum (pEnt=0xf37fb7c4) at ../engine/pr_cmds.c:1362
#2  0xf27fe630 in UTIL_SavePent(edict_s*) () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/foxbot/foxbot_mm.so
#3  0xf2802762 in Sys_Error(char const*) () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/foxbot/foxbot_mm.so
#4  0xf34f3df7 in api_caller_void_args_p(void const*, void const*) () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#5  0xf34f7cd8 in main_hook_function_void(unsigned int, enum_api_t, unsigned int, void const*) () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#6  0xf34fa690 in mm_Sys_Error(char const*) () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#7  0xf76f506d in Sys_Error (error=0xf7745cd6 "NUM_FOR_EDICT: bad pointer") at ../engine/sys_dll.c:556
#8  0xf76f1472 in NUM_FOR_EDICT (e=0xf3358720 <CBaseMonster::AlertSound()>) at ../engine/pr_edict.c:526
#9  0xf76ecfa5 in FindEntityByString (pEdictStartSearchAfter=0xf3358720 <CBaseMonster::AlertSound()>, pszField=0xf2218240 "classname", pszValue=0xf22034a1 "player") at ../engine/pr_cmds.c:1348
#10 0xf21f8f15 in UTIL_FindEntityByString(CBaseEntity *, char const *, char const *) () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/NeoTF/dlls/NeoTF_i486.so
#11 0xf21f8f87 in UTIL_FindEntityByClassname(CBaseEntity *, char const *) () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/NeoTF/dlls/NeoTF_i486.so
#12 0xf21bdc50 in NeoTFPlayerPreThink(edict_s *) () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/NeoTF/dlls/NeoTF_i486.so
#13 0xf21e786f in PlayerPreThink(edict_s *) () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/NeoTF/dlls/NeoTF_i486.so
#14 0xf34f3df7 in api_caller_void_args_p(void const*, void const*) () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#15 0xf34f7cd8 in main_hook_function_void(unsigned int, enum_api_t, unsigned int, void const*) () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#16 0xf34fa980 in mm_PlayerPreThink(edict_s*) () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#17 0xf7719adf in SV_PlayerRunPreThink (time=<optimized out>, player=<optimized out>) at ../engine/sv_user.c:762
#18 SV_RunCmd (ucmd=0xffff940c, random_seed=0) at ../engine/sv_user.c:1002
#19 0xf76eee76 in PF_RunPlayerMove_I (fakeclient=0xf37fab34, viewangles=0xf37fac28, forwardmove=0, sidemove=0, upmove=0, buttons=0, impulse=0 '\000', msec=1 '\001') at ../engine/pr_cmds.c:2550
#20 0xf27da0ef in BotThink(bot_t*) () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/foxbot/foxbot_mm.so
#21 0xf2802aef in StartFrame() () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/tfc/addons/foxbot/foxbot_mm.so
#22 0xf34f7cd8 in main_hook_function_void(unsigned int, enum_api_t, unsigned int, void const*) () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#23 0xf34fa8e1 in mm_StartFrame() () from /srv/daemon-data/765aa81e-6e3f-4de6-9af4-f22d6777fbb8/./tfc/addons/metamod/dlls/metamod.so
#24 0xf7715268 in SV_Physics () at ../engine/sv_phys.c:1985
#25 0xf770d166 in SV_Frame () at ../engine/sv_main.c:9282
#26 0xf76d4e12 in _Host_Frame (time=0.0148258256) at ../engine/host.c:1404
#27 0xf76d51d2 in Host_Frame (time=0.0148258256, iState=1, stateInfo=0xffffd2fc) at ../engine/host.c:1522
#28 0xf76f9b7c in CEngine::Frame (this=0xf77916c0 <g_Engine>) at ../engine/sys_engine.cpp:245
#29 0xf76f6ea3 in CDedicatedServerAPI::RunFrame (this=<optimized out>) at ../engine/sys_dll2.cpp:1235
#30 CDedicatedServerAPI::RunFrame (this=0xf778cd20 <__g_CDedicatedServerAPI_singleton>) at ../engine/sys_dll2.cpp:1226
#31 0x08049c65 in RunServer () at ../dedicated/sys_ded.cpp:766
#32 0x08049472 in main (argc=15, argv=0xffffd534) at ../dedicated/sys_ded.cpp:1146

[SamVanheer]

Yeah it's definitely using CBaseEntity derived types. The layout must have changed in one of the last updates.

There's no way to fix this without changing the NeoTF source code, and this code doesn't appear to exist in the code i linked to. You should look for someone who has the code, otherwise you'll need to use the last revision of the open source version as a base.

[Joolleh]

After the last update class configs have to be executed manually. The setinfo commands don't appear to be having any effect. Any idea how to fix this anyone ?

[SamVanheer]

When i do setinfo ec 1 and then start a local server, choosing a class prints the echo statement from the class cfg file. Which commands did you use? When did you execute them? Before connecting to a server or after, in a cfg file, etc?

[MFKitten]

@mikela-valve open sourcing the engine would be amazing for the continued longevity and prosperity of the game(s) and mods of this era.

[Joolleh]

So the way it has been working for years is that when you change class, if you have custom settings in your class configs, they will be executed when you change class. Now, when in an online server ( i haven't checked anything else ) both when you join the server and choose a class for the first time and when you change classes the custom settings in your class configs don't execute anymore. But if you open the console and for example type exec medic.cfg any custom settings in that file will then execute. We in the remaining orgnised player base in Australia would really appreciate it if this change can be undone and things are put back the way they have always been. i.e the class configs again execute automatically when you change class. Here is an example of the sorts of custom commands I am talking about - this is from my soldier.cfg file

echo SOLDIER CFG LOADED

fps_max 119.5

alias prime1 "primeone;spk vox/mytimer;alias grens1 throw1" alias prime2 "primetwo;spk vox/mytimer;alias grens2 throw2" alias throw1 "throwgren;alias grens1 prime1" alias throw2 "throwgren;alias grens2 prime2" alias grens1 prime1 alias grens2 prime2 bind "e" "grens1" bind "f" "grens2" bind SPACE "+jump"

alias mrzoom_in "fov 110; sensitivity 80; developer 1; echo Zoom in!; developer 0; alias mrzoom mrzoom_out" alias mrzoom_out "fov 0; sensitivity 88; developer 1; echo Zoom out; developer 0; alias mrzoom mrzoom_in" alias mrzoom mrzoom_in

alias quick1 "tf_weapon_supershotgun;mrzoom;wait;alias quickweapon quick2" alias quick2 "tf_weapon_rpg;mrzoom;wait;alias quickweapon quick1" alias quickweapon quick1 bind "mouse2" "quickweapon"

bind "SHIFT" "grens2"

//bind "mouse2" "+shotty"

alias "+shotty" "tf_weapon_supershotgun" alias "-shotty" "lastinv"

bind "MWHEELUP" "dropitems;hijump"

sensitivity 88 r_drawviewmodel "0"

[SamVanheer]

@Joolleh have you done setinfo ec 1 and setinfo em 1 to enable execution of both types of configs?

[mikela-valve]

@SamVanheer Based on his reports it sounds like @Joolleh is either not running the latest TFC or is not playing on a server running the latest TFC I think? Most likely it's the server though since otherwise he'd be seeing missing usermsg console spam.

It would be a bit hacky, but I'm thinking that it might be better to add in TFC legacy support directly to the exec command rather than forcing clients and servers to both be running the latest version for everything to work (even if that is the ideal case). I'm thinking of switching exec back to being an unprivileged command specifically for TFC but having a whitelist in the command handler that allows only the TFC class configs, mapdefault or the current map config to run. This way a player running the latest client will at least be able to work with both old and new server versions.

[Joolleh]

Yes ive joined other servers where the problem doesnt exist. We are having trouble getting the server we play on most to do another update as they think we are wasting their time because the server is clearly still running. Strange how servers can get by with some sort of partial update. That isnt exactly an ideal situation.

[SamVanheer]

@mikela-valve sounds good, let's just hope everybody updates from the current version to the next one or the problem will be even more complicated.

[ChaosSpoofer]

While you're at it, is there any chance you could include the ability to automatically execute the civilian class config, just like the other 9 regular class configs? :D? It's always felt like an oversight that it wasn't given the same treatment, and it's always bugged me a bit that I've had to manually bind a key to execute its config whenever we play a Hunted-style map or whatever. =x

[mikela-valve]

@ChaosSpoofer, if you wouldn’t mind making a new issue to add support for that config I’d appreciate it. Thanks!

[Demon1986]

@mikela-valve

1426

need i say more?

[mikela-valve]

Thanks @Demon1986!

[ChaosSpoofer]

Thanks! I was away the past few days, I'm glad that the request already exists. XD

[Demon1986]

By the way @mikela-valve, will you also fix #1276?

[pizzahut2]

@mikela-valve

It would be a bit hacky, but I'm thinking that it might be better to add in TFC legacy support directly to the exec command rather than forcing clients and servers to both be running the latest version for everything to work (even if that is the ideal case). I'm thinking of switching exec back to being an unprivileged command specifically for TFC but having a whitelist in the command handler that allows only the TFC class configs, mapdefault or the current map config to run. This way a player running the latest client will at least be able to work with both old and new server versions.

I've tested this with the TFC client beta. Class and map configs now execute on old servers, however #2112 re-appears on these servers.

[pizzahut2]

Re-opening this for discussion (visibility).

[ChaosSpoofer]

@mikela-valve Additionally to what pizzahut just pointed out, automatic execution of civilian.cfg no longer seems to occur, either. =x

https://github.com/ValveSoftware/halflife/issues/1426

[mikela-valve]

@ChaosSpoofer That won't work on legacy servers as the server is what sends the command to exec the class configs, so those older servers don't have the change to send the exec for the civilian config.

[ChaosSpoofer]

@mikela-valve It doesn't seem to work on either updated servers or my own local listen server while running the Beta, though.

[mikela-valve]

Thanks @ChaosSpoofer. I took another look at the TFC exec commands and it found that the civilian class was specifically being blocked somewhere else. I've fixed that and will have an update shortly.

I also have a fix for the commands executing out of order that should work both for new servers as well as legacy servers. The problem was that both exec commands were sent as a single message exec mapdefault.cfg; exec currentmap.cfg which used to work because the first exec command would run, all of its commands would be put into the front of the command buffer and all be run, then the second exec command would run followed by all of its commands.

The privileged/unprivileged command split caused both exec commands to run before any of the commands that they added, so all commands from the second file would execute before the first. I've changed it to only run one command at a time from the unprivileged buffer rather than all of the commands while still running all commands in the regular buffer at once. So now the first exec should run, putting all of its commands into the regular buffer, then all of those commands would run, then the second exec will run and do the same.

[mikela-valve]

This is updated in beta build 8301 with the above changes.

[ChaosSpoofer]

Great, everything exec-wise seems perfect now. Thanks! :D

[SamVanheer]

@mikela-valve sorry to post on a closed issue, but since this is where open sourcing was discussed i'm putting it here: if open sourcing GoldSource is not an option it might be a good idea to consider porting HL1 to Source 2 instead and allowing us to make mods for it on that engine instead. Source 2 is much more powerful so i think it could be a suitable alternative.

I don't know if Valve is still planning to make Source 2 available for free for non-commercial use but that would make making mods a lot easier without the hassle of having to open source GoldSource.

Ultimately it's only necessary to permit modders to port content themselves to allow a HL1 port to be made, provided a full SDK is available.

Allowing content from Valve games built on GoldSource and Source to be ported to Source 2 for use in mods would be a big plus for Source 2 modding as well as HL1 and HL2 modding since it unifies all modding on the most powerful platform, and it would encourage people to move over and write documentation and tutorials which Source 2 will probably need since it's brand new.

I know you probably can't comment on anything like this, but i figured i'd suggest it just in case there are any plans or discussions going on internally at Valve.