Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get HL2SB compiling #7

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

luttje
Copy link
Contributor

@luttje luttje commented Jun 6, 2024

Pardon the messy commit. I turned off code formatting too late and checking every file line-by-line to fix it is too time consuming (plus I've been at that for some time, getting this to compile).

This PR is the result of my own project being merged over top HL2SB. My own project is the result of a fresh clone from [SourceSDK 2013 by Valve] (https://github.com/ValveSoftware/source-sdk-2013) with HL2SB code slowly copied over to it.

It is pretty late, so I'm just info dumping a bit now, some notes/todo's:

  • I commented the mounting of games and addons, because I wasn't using it in my project. Its still disabled here
  • Same goes for the ARGG, I have yet to enable it:
    broken ARGG
  • On launching the game you'll get two asserts which you can pass by clicking "Ignore Asserts in This File" (the second assert repeats a hundred times and ends up spamming your console)
    assert one
    assert that spams
  • It seems I commented the player model selectionin hl2mp_gamerules.cpp under ClientSettingsChanged because my project didnt require it
  • Same for episodic content like IsAlyxInDarknessMode
  • I included the HL2SB game project here, because its required to test and play. Having it in a seperate repo seems cumbersome to me, besides I:
    • made some changes to the cfg/settings*.src files to enable the gamemode picker.
    • I fixed the gameinfo.txt using deprecated keyvalues
    • Fixed the Lua code which didn't provide the required first argument to surface.AddCustomFontFile
    • Do let me know if you all want to keep it separated. But I think a monorepo might be more useful to keep every souce file in sync. We could create a GitHub action to compile and zip a release here as well, to make it easier to download for non-technical users.
  • To prevent future formatting trouble, I propose including a .clang-format. We can direct our IDE's to respect that in the future. I've included an example.
  • These changes by tonysergi are included, since I copied those over in my project, on which this merge is based.
  • I called the missing PlayerUpdateFlashlight
  • Added a getting started, to help contributors going
  • Added a little bash script (src/setupprojects.sh) to quickly setup debugging (because the vpc scripts mess that up when they touch the vs project files)
  • There's an occasional heap error in CClassMap::Add and RemoveAllScripted caused by removing items whilst iterating forward. Should reverse the loop instead, e.g:
void CClassMap::RemoveAllScripted(void) {
    int c = m_ClassDict.Count();
    int i;

    for ( i = c - 1; i >= 0; i-- )
    {
        classentry_t *lookup = &m_ClassDict[i];
        if ( !lookup )
            continue;

        if ( lookup->scripted )
        {
            m_ClassDict.RemoveAt( i );
        }
    }
}

I've done my best to remove any changes I made that are irrelevant to this project. However I've likely missed some.

I'm making this a draft merge. I'd like some guidance on how to best clean this PR up, so the merge becomes reviewable.

Additional notes

I'll use this list to track additional issues I find in my own project, that need fixing in HL2SB as well. They're not all related to this PR, so feel free to ask me to make separate PR's/issues for each of them.

  • Implement this fix for animations: https://developer.valvesoftware.com/wiki/SDK_Known_Issues_List_Fixed#Thirdperson_player_animations_look_like_.22Ice_Skating.22
  • Change const char *zipPath = NULL; to const char *zipPath = relativePath; in luacachefile.cpp to fix constructing cache files
  • Ensure the lua_cache path is added as a search path, so downloaded gamemodes actually load if the client doesn't already have it in their gamemodes folder. I did this by adding this to the end of luasrc_ExtractLcf (and refactoring it slightly so the gamePath var is available in the same scope): This can also be done by properly implementing mountaddons.cpp (which I had removed in my mod)
#ifdef CLIENT_DLL
    // Add the cache folder to the Lua path, so clients can load files from it.
    char cacheDirectoryPath[MAX_PATH];
    Q_strncpy( cacheDirectoryPath, gamePath, sizeof( cacheDirectoryPath ) );
    Q_strncat( cacheDirectoryPath, "\\" LUA_PATH_CACHE, sizeof( cacheDirectoryPath ), COPY_ALL_CHARACTERS );
    filesystem->AddSearchPath( cacheDirectoryPath, "MOD" );
#endif
  • In luamanager.cpp the content path is incorrectly added relatively (should be absolute). Replace filesystem->AddSearchPath( contentSearchPath, "MOD" ); with something like:
#ifdef CLIENT_DLL
    const char *gamePath = engine->GetGameDirectory();
#else
    char gamePath[256];
    engine->GetGameDir( gamePath, 256 );
#endif
    Q_strncpy( contentSearchPath, gamePath, sizeof( contentSearchPath ) );
    Q_strncat( contentSearchPath, "\\gamemodes\\", sizeof( contentSearchPath ) );
    Q_strncat( contentSearchPath, gamemode, sizeof( contentSearchPath ) );
    Q_strncat( contentSearchPath, "\\content", sizeof( contentSearchPath ) );

    filesystem->AddSearchPath( contentSearchPath, "GAME" ); // I made this GAME, so the source engine is able to download content to clients

@andrewmcwatters andrewmcwatters self-requested a review June 6, 2024 22:19
@andrewmcwatters
Copy link
Member

andrewmcwatters commented Jun 6, 2024

I agree it's time to reunify these repositories. We did it back in the Google Code days for a specific reason that no longer applies. We should push binaries to Releases so we don't end up inflating the repository in the same way we bloated the trunk history way back.

I agree with your approach of using ValveSoftware/source-sdk-2013 and then reintroducing hl2sb. I think I'm forced to not attach this repository to the fork network there simply because Half-Life 2: Sandbox existed before their repository was released, so we literally predate them since the mod was first built on the 2006 branch.

I think your approach across the board and what you chose to include is great.

I'll try to do the hardwork of replicating this patch while preserving individual diffs. I'd like us to be able to see specific commits that address individual concerns. So for example, we could git cherry-pick Tony's work to be imported and preserve the commits.

Edit: While we're at it, do we want to move to Visual Studio 2022?

Maybe the process for replicating this patch is something like:

  • Fork ValveSoftware/source-sdk-2013
  • Port to Visual Studio 2022
  • git cherry-pick from tonysergi/source-sdk-2013
  • cp hl2sb-src/* source-sdk-2013
  • Verify build
  • Manually verify diffs
  • Reintroduce history into master
  • git tag
  • Create a new release

Roughly speaking, of course. Building from upstream should take place first. Of course if we could also automate this from GitHub Actions, that would be ideal. I've failed to do it in the past, though, but at the time I was using vs2013. Maybe I could get it to work with vs2022.

@luttje
Copy link
Contributor Author

luttje commented Jun 7, 2024

Do you think its worth the hassle of keeping in sync with valve's repo? I imagine with source 2 now, that the older engines may get neglected.

Also another option for a cleaner merge might be to apply a code styling to all files in the master branch of hl2sb-src, committing that. Afterwards doing the same to these changes, then commit a PR. It should reduce the changes to only code and no formatting

@andrewmcwatters
Copy link
Member

andrewmcwatters commented Jun 7, 2024

Yeah, I doubt we'll ever see another push to source-sdk-2013, so it's probably not important. Even if we hypothetically needed to synchronize across disparate histories, git sort of lets you do it, it just tells you that you shouldn't.

I use the same approach for normalizing code formatting, so I figured we'd do that, yes.

@luttje
Copy link
Contributor Author

luttje commented Jun 7, 2024

I went ahead and did it since it seemed easy enough: luttje@137d5ef

This diff is a lot cleaner and should be easier to work with.

Given the whole XZ utils incident rocking our open-source world recently, I think it might be a good exercise for us if you pick a clang-format styling and apply that to this repo. Then I'll propose a new PR into that so the changes can be cleanly inspected.

For reference, here's my process:

  1. Created a new branch fix/clean-merge

  2. Copy over HL2SB game files, commit

  3. Add .clang-format with style rules

  4. Run command: find . -regex '.*\.\(cpp\|hpp\|cc\|cxx\|c\|h\)' -exec clang-format -style=file -i {} \;

  5. Commit

  6. Switch to fix/get-it-to-compile (this PR branch)

  7. Applied the same .clang-format and command to this branch, copied all files somewhere else

  8. Switch to fix/clean-merge

  9. Copy all changed files over to fix/clean-merge (replacing all), commit

For better formatting in the future we should use // clang-format off / and // clang-format on around macro sections (e.g: see compiledcaptionswap.cpp), since it doesn't seem possible to get those to style nicely.

@andrewmcwatters
Copy link
Member

I'm in communication with a Russian community about bringing on another developer, so I haven't lost sight of this. I'm just juggling at the moment.

@luttje
Copy link
Contributor Author

luttje commented Aug 10, 2024

Alright!

I'm pretty far with my own project (which I'll eventually open-source). It's turning out very similar to HL2SB and Garry's Mod, except I'm heading more in the same direction as Garry's Mod: naming Lua bindings differently from source engine functions, customizing Lua, etc. So I feel like both can exist fine side-by-side.

Once it's a bit easier to make PR's here I will make some, of course in the style of the HL2SB project where they mimic the source engine naming/functionality as closely as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants