Hi friends,
I have an important issue on a SM extension I'm developing which seems to be caused by Linux environment reasons and not by a MM/SM bug, but I only can conceive it's better to first ask here, hoping any advanced guy has any clue. Here's my setup:
- OS: Windows 10
- IDE: VSCode (Windows)
- SRCDS is installed under WSL 2 (Windows Subsystem for Linux)
- Game/mod of interest: HL2DM
My problem is that, while both running normally the server (not GDB debugging) and with GDB manually
on command line only, SourceMod correctly loads using HL2DM files (e.g.
sourcemod.2.hl2dm.so, gamedata and such), and my extension and everything works great. but, when I debug via VSCode (which uses a native GDB integration tool,
https://code.visualstudio.com/docs/c...json-reference), then SM detects it as wrong game/mod instead (concretely SSDK2013), causing it to complain about missing gamedata for instance (which is normal for base SSDK2013 mods; some gamedata files have been missing for it for long).
The left picture shows the affected execution when debugging from VSCode, and the right one reflects an stable launch with command line GDB debugging, highlighting the HL2DM SM binary being correctly loaded.
I guess VSCode messes up symbols somehow, but my debugging JSON script doesn't apparently contain anything wrong (which I attach below if anyone is used to the same IDE and tools, containing few minor edits to expand some variables from dependent base configs), so I don't know what could be different from debugging from command line, which works fine.
Would anyone happen to know what this wrong game detection could be caused for? Or even anything in general terms, really.
Overall the issue limits me in that I wish to work with breakpoints while I'm developing, and due to this limitation I can only print debug with logging as an alternative.
Many thanks
Threaded Mode