Half-life: Invasion source update

[RoyShapiro]

Hello!

I've been a fan of the French Half-life: Invasion (https://www.moddb.com/mods/half-life-invasion) mod since 2002. In 2015 JujU (the mod's lead programmer) released it's source code on ModDB: https://www.moddb.com/mods/half-life-invasion/downloads/invasion-source-code

Recently I wanted to replay this nostalgic mod on a Debian Linux system and discovered this amazing repo with compile-able codes for many of the HL1 popular mods, but Invasion was, sadly, absent.

So, I got a bit motivated and did my best trying to make the mod's old source code compile-able with this new code base on my system.

The results can be found here: https://github.com/RoyShapiro/hlsdk-xash3d/tree/invasion

In the current state, the code compiles for 32-bits with cmake on Debian Linux 11 and the mod can be successfully played from start to finish with all of the crucial features working (including mp3-music which I had to port to GStreamer, as I don't even know if FMod is still alive anymore).

Originally, I had hoped to submit a Pull Request to this great repo, but it's organized so, that the mod's source codes are provided as branches, and it's not possible to make a pull request to a branch that doesn't exist upstream.

So, I'll just humbly leave it here. If it's good enough to be merged, maybe I can interest the maintainers of this repo to create an upstream branch for the mod?

If not, at least this might be of interest to people, who, like me, love this old mod and would like to play using a Modern Xash3d build.

Thank you!

[nekonomicon]

Hello!

Hi :)

Originally, I had hoped to submit a Pull Request to this great repo, but it's organized so, that the mod's source codes are provided as branches, and it's not possible to make a pull request to a branch that doesn't exist upstream.

So, I'll just humbly leave it here. If it's good enough to be merged, maybe I can interest the maintainers of this repo to create an upstream branch for the mod?

Yep, we can create separate branch with your changes, but some things in your commit looks unclear:

1. You have reverted changes from previous commits.
2. It will be better to make separate commits with minor changes to make your changes more readable and maintainable(merge source code, update build scripts, update readme, fix compilation, etc)

I think It's not so hard to rebase and split your commits via git rebase.

In the current state, the code compiles for 32-bits with cmake on Debian Linux 11 and the mod can be successfully played from start to finish with all of the crucial features working (including mp3-music which I had to port to GStreamer, as I don't even know if FMod is still alive anymore).

FMod live and exists for many platforms, but it's proprietary software. GStreamer is bloat and it's a bad choice for portable builds. Also, engine API has undocumented callback PrimeMusicStream on client-side for mp3 playing(broken in the latest steam version of GoldSource, but works in Xash3D): https://github.com/FWGS/hlsdk-xash3d/blob/thegate/engine/cdll_int.h#L293=

And steam version of GoldSource has client commands mp3 play/stop: https://twhl.info/wiki/page/VERC%3A_MP3_playing_entity_with_Steam

So there simple solution to play mp3: https://github.com/FWGS/hlsdk-xash3d/blob/thegate/cl_dll/hud.cpp#L184=

[a1batross]

I think we need some automated or at least documented way how to rebase mods on our HLSDK tree.

Like:

1. Detect what HLSDK version used (probably by comparing client and server interface headers?)
2. Git pull HLSDK of that version
3. Make a diff with mod sources
4. Review it
5. Try to automatically apply on top of hlsdk-xash3d or if it fails, manually merge it.

[nekonomicon]

WARNING! While I've tried editing the make files for other build systems, only cmake build was actually tested. Also, the mod won't work correctly with Android (due to lack of true VGUI), MSVC6 (haven't edited true VGUI compilation in, as IDK how to do that properly) and wscript (same reason). The premake5.lua was also edited and should, in theory, compile (as it contains VGUI compilation directives), but gstreamer wasn't edited in. If you can edit the VGUI in or fix any of those other build systems - you're more than welcome to do so!

There no reason to update scripts for all build systems. We need to choose only one. Core engine developers hates cmake and uses waf, but modders hates waf and want to use cmake. MSVC6 support is non-critical(in 2022) Android.mk is deprecated. contrib folder was made for non-maintainable scripts and code. Currently, waf useful only for mobile platforms and DOS. https://github.com/FWGS/hlsdk-xash3d/issues/105

[nekonomicon]

Detect what HLSDK version used (probably by comparing client and server interface headers?)

Nope. As example HLSDK 2.0-2.1 didn't have weapons code and train sounds on client side yet. Only guns was predicted. Also, some mods was made on Spirit of Half-Life, will be need to diff more 15 versions.

I think we need some automated or at least documented way how to rebase mods on our HLSDK tree.

For invasion all already done by mod author: https://github.com/jlecorre/hlinvasion/commit/695cfb6570e244bd025ecd3cabcb37aa2bb3e49e

Git pull HLSDK of that version Make a diff with mod sources Review it

Just say diff -udpw

Try to automatically apply on top of hlsdk-xash3d or if it fails, manually merge it.

It's not so hard to merge manually for me.

[RoyShapiro]

Hi! Thanks for taking a look.

@nekonomicon

You have reverted changes from previous commits.

Not on purpose. :) What seems to be a revert is actually either of the following three: a) A result of me using a commit 3db3772bff576cc0cb7fd0a380090d3c8794de5c as the base, so some changes could've been made later. b) > 3. Make a diff with mod sources -- that exact thing, this step is also why some of JujU's French comments got screwed by encoding differences. c) Some code, such as client weapons is simply a bit incomprehensible to me, last I modded Half-life it was still a WON version :) And JujU's code also mostly used server-based weapons (I guess it's not too critical, considering it's a singleplayer mod anyway? Correct me if I'm wrong.)

GStreamer is bloat and it's a bad choice for portable builds.

I was afraid that would be the case, so that's why I've made it optional. It's currently possible to compile without -DUSE_GSTREAMER and it will use a "null player", so there will be no music, but it will work. That's how I've tested it. GStreamer was simply the thing I was most familiar with and could get done in a reasonable amount of time.

broken in the latest steam version of GoldSource

Purely IMO, but if it ruins compatibility with GoldSource, it's probably something best left optional (like GStreamer in the current version).

I'll look at https://github.com/FWGS/hlsdk-xash3d/blob/thegate/cl_dll/hud.cpp#L184= when \ if I'll have the time, though.

It's not so hard to merge manually for me.

Well, that's kind of exactly what I tried, and look at the list of issues I had to fix (most of them popping up after trying to actually playtest the mod). So that's why we're here, I guess :D

If you still consider the current version mergeable, what actions are required of me?

[RoyShapiro]

Sorry, seemed to miss this part:

It will be better to make separate commits with minor changes to make your changes more readable and maintainable(merge source code, update build scripts, update readme, fix compilation, etc) I think It's not so hard to rebase and split your commits via git rebase.

I can try to do some of that (like separate source & make lists and base off of the latest master commit), but to a limited extent. If you can provide some more specific steps crucially necessary it'll be easier for me, I'm not a GitHub regular so I can be "slow" on some of that stuff.

[nekonomicon]

c) Some code, such as client weapons is simply a bit incomprehensible to me, last I modded Half-life it was still a WON version :) And JujU's code also mostly used server-based weapons (I guess it's not too critical, considering it's a singleplayer mod anyway? Correct me if I'm wrong.)

Nope. It's not critical. As example Azure Sheep and They Hunger has server-side weapons code and porting it to client can break mod features and compatibility in multiplayer.

I can try to do some of that (like separate source & make lists and base off of the latest master commit), but to a limited extent. If you can provide some more specific steps crucially necessary it'll be easier for me, I'm not a GitHub regular so I can be "slow" on some of that stuff.

There good guide: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

Also, you can move to commit https://github.com/FWGS/hlsdk-xash3d/commit/3db3772bff576cc0cb7fd0a380090d3c8794de5c and start from this commit in new branch:

git checkout 3db3772
git checkout -b invasion-dev

After that use cherry-pick for your commit(or copy-and-paste your changes) and rebase history.

[RoyShapiro]

@nekonomicon

Nope. It's not critical.

Alright, good to know.

There good guide: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

So far I've managed to do almost exactly what you you've asked above (can be seen in my recent push) like add

(merge source code, update build scripts, update readme, fix compilation, etc)

intermediate commits, but something tells me it's probably too literal and not enough? See, it's probably my big dumb mistake, but I wasn't really keeping much intermediate steps (_at least until I've finally figured out the VGUI segfault in the vguiOrdiControl.cpp, because until that moment I wasn't really sure if the entire thing was ever going to fly, so to speak).

[RoyShapiro]

@nekonomicon Okay, I've split the commits as best I could, using all the backups I kept to this point (admittedly less than ideal, I just discovered that one of the commits breaks some of the French comments in the code). I don't think I will be able to split them any more without "hand-holding" and telling me precisely what to do, I'm afraid.

Luckily the code still compiles (fingers crossed I didn't end up breaking anything rather than fixing).

[nekonomicon]

Can you not touch changes from previous commits and just rewrite history or use method from my previous post?

[nekonomicon]

You can squash 2 latest commits: https://github.com/RoyShapiro/hlsdk-xash3d/commit/503be44b576afca3e503b885953f94a0ca41607f https://github.com/RoyShapiro/hlsdk-xash3d/commit/0b25a499fb2dccc5fdc0b3d3c9c760c18eafd18f

And edit commits https://github.com/RoyShapiro/hlsdk-xash3d/commit/75be0cac8145be25b9c7878a506243eda6006e32 and https://github.com/RoyShapiro/hlsdk-xash3d/commit/e290f609c75be586622a7ed06809ddca6f51562a to avoid changes here: https://github.com/RoyShapiro/hlsdk-xash3d/commit/e290f609c75be586622a7ed06809ddca6f51562a#diff-e4a8e5378d26122ab06bb30413b54dbc922af0ec048366f2a5fba9845baf0522R28 https://github.com/RoyShapiro/hlsdk-xash3d/commit/e290f609c75be586622a7ed06809ddca6f51562a#diff-e4a8e5378d26122ab06bb30413b54dbc922af0ec048366f2a5fba9845baf0522R46 https://github.com/RoyShapiro/hlsdk-xash3d/commit/75be0cac8145be25b9c7878a506243eda6006e32#diff-ae6308788ae1e5acea708a79bc04caae85c5e862474a42b4b633fa2b21df908eR28 https://github.com/RoyShapiro/hlsdk-xash3d/commit/75be0cac8145be25b9c7878a506243eda6006e32#diff-ae6308788ae1e5acea708a79bc04caae85c5e862474a42b4b633fa2b21df908eR198 https://github.com/RoyShapiro/hlsdk-xash3d/commit/75be0cac8145be25b9c7878a506243eda6006e32#diff-ae6308788ae1e5acea708a79bc04caae85c5e862474a42b4b633fa2b21df908eR218 https://github.com/RoyShapiro/hlsdk-xash3d/commit/75be0cac8145be25b9c7878a506243eda6006e32#diff-ae6308788ae1e5acea708a79bc04caae85c5e862474a42b4b633fa2b21df908eR176

[nekonomicon]

Do not replace crowbar code: https://github.com/RoyShapiro/hlsdk-xash3d/commit/e290f609c75be586622a7ed06809ddca6f51562a#diff-b930f31f8c8c19eb20c32b01a3964e597b6edebcd5c961270417b9db27b7cdb8R1

There only need to add miss animations and sound: https://github.com/FWGS/hlsdk-xash3d/blob/theyhunger/dlls/crowbar.cpp#L210= and remove string with PLAYBACK_EVENT_FULL: https://github.com/FWGS/hlsdk-xash3d/blob/master/dlls/crowbar.cpp#L204=

[RoyShapiro]

@nekonomicon

You can squash 2 latest commits: (compile list merge with upstream) And edit commits ... and ... (merge of server and client) to avoid changes here: (a lot of compile list back and forth)

That seemed perfectly reasonable, so did that (but had the entire branch reuploaded in the process, so the commit ids have changed now).

Do not replace crowbar code...

That's... probably gonna be much harder. I never understood the whole event playback thing since it was introduced (yep back in the early 2000's), so I honestly just replaced the code for a few of the stubborn weapons with Julien's original one making changes only where they were absolutely necessary to get it to compile and work. When I tried "dumb merge" at first (what with diff and all that) the crowbar simply had no animations at all, replacing the code with full Julien's original one (except a few minor edits) helped.

[nekonomicon]

ah... probably crowbar code from invasion does not have holster and some miss/hit animations yet.

[RoyShapiro]

@nekonomicon

ah... probably crowbar code from invasion does not have holster and some miss/hit animations yet.

Yep, it did not. However, simply removing the code referencing the CROWBAR_HOLSTER animation is trivially easy.

I've tried to make edits to crowbar (using the original upstream code) as you suggested, and got back to square one: I have no first-person animations what-so-ever.

Edit 0: This seems to be "fixed" by removing "UseDecrement" from weapons.h crowbar declaration, but now all the animations and sounds are screwed (only appear when the mouse button is released, the sounds overlap one another and it seems as though it makes far more actual attacks then there are animations and sounds).

Edit 1: Finally found a way to keep the semi-upstream code for the crowbar (still needs Decal code from Julien and removing missing animations) & have animations that aren't screwed, but that requires me to override the SendWeaponAnim method of CBasePlayerWeapon in CCrowbar, specifically, it requires int skiplocal to be 0 to work, yet still have UseDecrement return true for what seems to be other timings. IMO, it's a bad solution (no other weapon requires this method to be overriden), and, in comparison, it's best to keep the old Julien's code.

[nekonomicon]

Finally found a way to keep the semi-upstream code for the crowbar (still needs Decal code from Julien and removing missing animations) & have animations that aren't screwed, but that requires me to override the SendWeaponAnim method of CBasePlayerWeapon in CCrowbar, specifically, it requires int skiplocal to be 0 to work, yet still have UseDecrement return true for what seems to be other timings.

You can just disable CLIENT_WEAPONS definition

[RoyShapiro]

You can just disable CLIENT_WEAPONS definition

Yes, probably... But as far as I looked it up, it's also used by a whole lot of other things (client.cpp, crossbow.cpp, egon.cpp, glock.cpp, hornetgun.cpp, player.cpp, squeakgrenade.cpp, tripmine.cpp, util.cpp, weapons.cpp, weapons.h just to name a few), and since I don't fully understand how it works, there is a very high chance it will turn into a proverbial rabbit hole for me. Someone who knows much more about the whole server / client code than me will need to take a look at it. I'd rather not touch things I do not understand. For now I can either leave the crowbar as it is (with overriden method) or revert the commit to go back to Julien's code.

[nekonomicon]

That seemed perfectly reasonable, so did that (but had the entire branch reuploaded in the process, so the commit ids have changed now).

No changes here: https://github.com/RoyShapiro/hlsdk-xash3d/commit/1cb7507b4c9802868b2bffd521c9638ed3280108#diff-ae6308788ae1e5acea708a79bc04caae85c5e862474a42b4b633fa2b21df908eR30 https://github.com/RoyShapiro/hlsdk-xash3d/commit/1cb7507b4c9802868b2bffd521c9638ed3280108#diff-ae6308788ae1e5acea708a79bc04caae85c5e862474a42b4b633fa2b21df908eR214 https://github.com/RoyShapiro/hlsdk-xash3d/commit/c08690f2648426e5b7d3c482a51ad4149829b1a9#diff-e4a8e5378d26122ab06bb30413b54dbc922af0ec048366f2a5fba9845baf0522R30

Is it needed on server side? https://github.com/RoyShapiro/hlsdk-xash3d/commit/c08690f2648426e5b7d3c482a51ad4149829b1a9#diff-e4a8e5378d26122ab06bb30413b54dbc922af0ec048366f2a5fba9845baf0522R48

[nekonomicon]

Yes, probably... But as far as I looked it up, it's also used by a whole lot of other things (client.cpp, crossbow.cpp, egon.cpp, glock.cpp, hornetgun.cpp, player.cpp, squeakgrenade.cpp, tripmine.cpp, util.cpp, weapons.cpp, weapons.h just to name a few), and since I don't fully understand how it works, there is a very high chance it will turn into a proverbial rabbit hole for me. Someone who knows much more about the whole server / client code than me will need to take a look at it. I'd rather not touch things I do not understand.

Ok.

[RoyShapiro]

No changes here: (list)

Sorry, I don't understand what changes are expected there anymore. I made it so, that there aren't a lot of CMakeLists.txt backs and forths, like there were yesterday. I also made sure that the new commits to those (like barnacle fix, crowbar fix, e.t.c.) are present.

Is it needed on server side?

Nope it isn't. Good catch, forgot about that. Gonna remove, but as a new commit. (And... I made a bit of a mess with it, had to commit, revert than commit again. Grrr.)

[nekonomicon]

Sorry, I don't understand what changes are expected there anymore. I made it so, that there aren't a lot of CMakeLists.txt backs and forths, like there were yesterday. I also made sure that the new commits to those (like barnacle fix, crowbar fix, e.t.c.) are present.

https://github.com/FWGS/hlsdk-xash3d/commit/1397f3ab4f43da5dc6f472e86d2bbaf44ddb25be https://github.com/FWGS/hlsdk-xash3d/commit/d8b05d12d52ba390b1b8dceca784f35a13f42934

[RoyShapiro]

@nekonomicon Thank you for your patience and bearing with me as I try to get my head around some of git stuff! I've just pushed a commit that should have the changes required. Please, check if everything is okay now: https://github.com/FWGS/hlsdk-xash3d/commit/e0400761b9072739137f65957118af8513d87b88 also see https://github.com/RoyShapiro/hlsdk-xash3d/blob/invasion/CMakeLists.txt for tgmath edit. (On that note, please note that mid-process I deleted & repushed the entire branch (probably a very sub-optimal thing to do), but git keeps yesterday's commits it seems, yet they are not longer actual and apparently don't contain changes that have actually been made.)

[nekonomicon]

I see you have just replaced files for handgrenade.cpp, python.cpp, mp5.cpp, health.cpp and shotgun.cpp. It's not good, because this files already contains some fixes. Also, in health.cpp was code for vibration on mobile devices. And probably need to check rpg code.

Which reason to move this function definition? https://github.com/RoyShapiro/hlsdk-xash3d/commit/c08690f2648426e5b7d3c482a51ad4149829b1a9#diff-9a89cee5255b2d426f6fd055e300f740fa59283181927c51058c6f7cde1ec590R89

[RoyShapiro]

@nekonomicon

Yes. And where the fixes are still applicable, since none of the weapons mentioned are their original vanilla-HL selves, Julien tweaked every one of them to higher or smaller extent, that is indeed not ideal. That said, "just replaced" isn't, perhaps, entirely correct. I've tried "Just replacing", and, off the top of my head, that wouldn't work with weapons.h and some other (admittedly minor, in most cases) annoyances.

I've replaced only the files, which I knew I couldn't fix by directly trying to merge with diff and then patch, thus keeping most code from both versions intact, and then trying to fix whatever inconsistencies appeared.

With health.cpp, it was a case of how Julien's code treats damage to the body parts (each can be healed separately) and how it messages the front-end about which parts were hurt how. Originally, the entire code got screwed in a diff misapplication of it to a particular place in the code where it managed to surprisingly not break anything so far as for it to cause something obvious, like not to compile at all. Since I know little about the client messaging system and didn't know where the code ended up, it took me on a few sleepless nights long wild goose chase trying to figure out why I'm getting "excepted 1 bytes, got 15", e.t.c. all over the console, and when I thought I fixed that, why the new healing system wasn't working. The entire code got replaced as part of debugging effort, and when it was done, it was too late to change back. As for vibration, I do not know how the vibration works, and personally don't even have anything aside from regular bloatware installed on my phone, LOL. On a serious note, though, this mod relies heavily on a True-VGUI, without which you won't be able to open a lot of gameplay-critical doors (keypads!, hello Deus Ex!) and finish the play-through. And as I haven't seen a way to compile the code for Android with the True-VGUI, fixing this should probably be higher on the priority list than vibration.

With "Which reason to move this function definition?", very likely the same applies (a diff patch application mishap), but since no harm was done, there was no reason to fix that which ain't broken.

With all the weapons you've mentioned, except rpg (which is completely different from it's vanilla counterpart), the main, yet not the only problem, were client-side animations, just like with the crowbar. Compared to the health system mentioned above, which I got pretty intimate with trying to fix, I simply do not understand that technique, what with all the playback .sc events, e.t.c, and Julien's code worked well enough for 20+ years (not to mention he didn't use events either, even though they were already present in SDK), so fixed just enough nothing stops it from continuing to work, especially since the mod is singleplayer, and thus patching every known hole because of the cheaters isn't critical...

...unless not doing so: 1) Introduces entirely new bugs, that weren't present in the mod originally due to the change in outlying environment (that being the SDK and the engine itself). 2) Hurts portability.

And on that note, of the two things above, I did whatever was within my ability, skill level and time constraints, for both points: 1) The non-exhaustive list of new bugs that have appeared during actual playtesting (given my experience with the original version of the mod) due to the change in the SDK and/or engine and have been since fixed, can be found in both README.md and cl_dll/crutches.h. 2) Equally-wise, to illustrate the second thing, while I agree with the point that GStreamer was not the most elegant or portable solution, it was something that I could do within a reasonable timeframe, that allowed a previously non-portable feature (mp3 music) to be more portable, or, if the specific solution isn't applicable to some environment (Playstation Classic, anyone?), gracefully disable-able (try compiling without both DUSE_FMOD and DUSE_GSTREAMER), both were not available originally.

The Hippocratic Oath states "First do no harm". Due to the limitations of my ability, skill level and time constraints, there was a choice of what not to harm: Either the fixes in the new SDK (with which the mod, from a potential player's perspective, wasn't working at all - no animations, segfaults, you name it), or the original code of the mod (which has been working for 20+ years and just needed more portability). Obviously, within the scope of my original goal (which can be defined as "play the mod on Linux, using Xash3d, with all original features working"), I chose the latter. Going through every file and researching every fix introduced by the new SDK, especially where undocumented in way which could used as a quick reference, was never part of said goal, due to not being within my ability, skill level and time constraints. There is a good saying "Know your limits" or "Know when to stop". I stop right there, as I've admittedly reached (and even surpassed in some cases) my current limits.

Why do I still want this merged?

Specifically for the very reason that I've:

• Successful accomplished my original goal ("It fre**ing works!" (TM)).
• Want to share the results with others who might find them useful (regardless of whether just to play the mod or to continue where I left off).
• The beauty of Open Source is specifically that other, more knowledgeable people, like yourself for example, may continue where I left off, if they so desire. And, like with kick-starter, the desire is usually higher, when a significant part of the work is already done. But it needs to be more exposed to the interested parties, and it lying silently in a fork by some random guy (me) who knows where on GitHub doesn't give it said exposure.

I hope I have sufficiently defended my approach.

Exactly no offense was meant anywhere (I know I can get harsh sometimes, please excuse me if anything sounded out of place).

[nekonomicon]

Ok. I understand.

With health.cpp, it was a case of how Julien's code treats damage to the body parts (each can be healed separately) and how it messages the front-end about which parts were hurt how. Originally, the entire code got screwed in a diff misapplication of it to a particular place in the code where it managed to surprisingly not break anything so far as for it to cause something obvious, like not to compile at all. Since I know little about the client messaging system and didn't know where the code ended up, it took me on a few sleepless nights long wild goose chase trying to figure out why I'm getting "excepted 1 bytes, got 15", e.t.c. all over the console, and when I thought I fixed that, why the new healing system wasn't working. The entire code got replaced as part of debugging effort, and when it was done, it was too late to change back. As for vibration, I do not know how the vibration works, and personally don't even have anything aside from regular bloatware installed on my phone, LOL. On a serious note, though, this mod relies heavily on a True-VGUI, without which you won't be able to open a lot of gameplay-critical doors (keypads!, hello Deus Ex!) and finish the play-through. And as I haven't seen a way to compile the code for Android with the True-VGUI, fixing this should probably be higher on the priority list than vibration.

With "Which reason to move this function definition?", very likely the same applies (a diff patch application mishap), but since no harm was done, there was no reason to fix that which ain't broken.

With all the weapons you've mentioned, except rpg (which is completely different from it's vanilla counterpart), the main, yet not the only problem, were client-side animations, just like with the crowbar. Compared to the health system mentioned above, which I got pretty intimate with trying to fix, I simply do not understand that technique, what with all the playback .sc events, e.t.c, and Julien's code worked well enough for 20+ years (not to mention he didn't use events either, even though they were already present in SDK), so fixed just enough nothing stops it from continuing to work, especially since the mod is singleplayer, and thus patching every known hole because of the cheaters isn't critical...

I can try to rewrite it later.

The Hippocratic Oath states "First do no harm". Due to the limitations of my ability, skill level and time constraints, there was a choice of what not to harm: Either the fixes in the new SDK (with which the mod, from a potential player's perspective, wasn't working at all - no animations, segfaults, you name it), or the original code of the mod (which has been working for 20+ years and just needed more portability). Obviously, within the scope of my original goal (which can be defined as "play the mod on Linux, using Xash3d, with all original features working"), I chose the latter. Going through every file and researching every fix introduced by the new SDK, especially where undocumented in way which could used as a quick reference, was never part of said goal, due to not being within my ability, skill level and time constraints. There is a good saying "Know your limits" or "Know when to stop". I stop right there, as I've admittedly reached (and even surpassed in some cases) my current limits.

Any contributions are welcome, but little criticism may be needed sometimes. If something looks bad I think may be not bad to say about that or even to try to teach contributor.

[nekonomicon]

@RoyShapiro branch invasion was added.

[RoyShapiro]

@nekonomicon

First of all, Thank you! I sincerely appreciate both you taking your time to deal with my haphazard code and trying to help me make it better and especially so for merging it. And I have learned a lot already, for example, re-basing and squashing commits is a new skill to me, since my native environment doesn't require me to do that a lot.

If something looks bad I think may be not bad to say about that

Not at all! However, since we people haven't yet learned to read each others minds, adding context of what to expect, on both sides, is very helpful to reach an understanding.

For example, on my side, I hope it has become clearer that I didn't replace the weapon files "blindly", as in "I'll just drop it there and forget about it, since I don't care". The concerns about code containing potential fixes were actually carefully taken into consideration and measured against my ability and time constraints to do things better, rather than worse. Including evaluating the "what the harm could be if" factor, see the multiplayer vs singleplayer code robustness argument above for instance.

The crowbar code is actually a great example: I could try to successfully (in terms of "it works") update the code of other weapons in the similar vein, trying to preserve most of the fixes, but if would result in new weird solutions similar in nature to "SendWeaponAnim" override, and while this also works, it's IMO, not elegant and an obvious crutch, made worse by the fact that I don't entirely understand the crucial part of it, being why it's absence causes the timings to fail (more specifically why the UTIL_WeaponTimeBase gets set to 0.0f for client weapons, e.t.c.). As such I couldn't not guarantee that the resulting code will be "better", as it may, than the mostly untouched original code, that had withstood the test of time.

On the other hand it wasn't clear to me until now, whether I could expect a successful merge without having to go at lengths to do a lot of additional work of questionable quality, as described in detail above, which, while it probably would've followed closer to the project guidelines, would've been more volatile in nature (and probably would've raised a lot more very reasonable questions).

even to try to teach contributor.

On that note, what I really struggle and want to understand, is precisely the reason behind me not updating the weapons code: the whole .sc event thing and client prediction remains a mystery to me to this day, even though I first ran into it about 19 years ago. Back then I noticed Valve kind of wanted the weapon code to be non-hardcoded, which was welcome, but a lot of mods had .sc files that clearly weren't actually functioning, as the code within was often simply a copy-paste of, say, a glock code. Yet, removing the files themselves did prevent the weapons from functioning. Combined with the fact that I knew very little about C++ back in the day, that rendered the whole thing entirely incomprehensible. While working on this code now, I have discovered, that the events are seemingly not actually being played back, yet the presence of the file allows the server to send a message to the client to do other things, like play an animation directly, which seems to be the mechanism a lot of mod authors have seemingly abused to avoid dealing with the actual .sc files. Am I correct in that assumption?

Meanwhile, If time permits, I intend to try and make a non-Gstreamer implementation of the music player if there are sufficient playback control functions present - Julien's code uses playlists and actively watches for the current track to end to initiate the next one using a callback.

[nekonomicon]

On that note, what I really struggle and want to understand, is precisely the reason behind me not updating the weapons code: the whole .sc event thing and client prediction remains a mystery to me to this day, even though I first ran into it about 19 years ago. Back then I noticed Valve kind of wanted the weapon code to be non-hardcoded, which was welcome, but a lot of mods had .sc files that clearly weren't actually functioning, as the code within was often simply a copy-paste of, say, a glock code. Yet, removing the files themselves did prevent the weapons from functioning. Combined with the fact that I knew very little about C++ back in the day, that rendered the whole thing entirely incomprehensible. While working on this code now, I have discovered, that the events are seemingly not actually being played back, yet the presence of the file allows the server to send a message to the client to do other things, like play an animation directly, which seems to be the mechanism a lot of mod authors have seemingly abused to avoid dealing with the actual .sc files. Am I correct in that assumption?

Valve made player movement and client local weapon prediction systems as part of big lag compensation mechanism for multiplayer games like DeathMatch Classic and Ricochet. Main purpose of this mechanism is to reduce server load and to prevent usage of cheats like speed hack. Also, Valve had plans to make scripting system, but It was canceled and engine currently just checks if .sc-files exists. And specially for TFC was written vgui library to make in-game menus. All this features was backported to Half-Life, but in HLSDK 2.0-2.2 weapons was not fully predicted on client yet. Only events on client side for guns was made plus weapons code was partially broken. In HLSDK 2.3 weapons already fully predicted on client, but all broken: https://www.youtube.com/watch?v=uKkJPFmDW9Q

HL: Invasion based on HLSDK 2.1 and probably will be better to disable client weapons for this mod.

Meanwhile, If time permits, I intend to try and make a non-Gstreamer implementation of the music player if there are sufficient playback control functions present - Julien's code uses playlists and actively watches for the current track to end to initiate the next one using a callback.

@FreeSlave said, PrimeMusicStream callback works in steam, but required to use mp3 play cmd before first call for initialization. Also, I think miniaudio is good choice for such purpose too.

[RoyShapiro]

Very interesting video. I always wondered where these bugs came from, as I didn't remember them from the earlier versions. Especially the crazy crowbar. Reminds of how they added a bridge in Surface Tension to lead to pipe you were originally supposed to jump on next to the famous "satchel grunt" at one point.

So the pre-Steam .sc events were a lie... Just like the cake.

I'll take a look at miniaudio, so far seems very promising!

Thanks!

[malortie]

If this may help, I previously ported HL: Invasion to the latest HL SDK (2.4). https://github.com/malortie/hl-invasion

Not to be confused with the first port I released back in 2016 : https://github.com/malortie/hl-invasion-old

In the new version, all changes were reapplied from scratch, using KDiff3 to ensure all original mod changes wouldn't go unnoticed. The entire mod source code has been reviewed, all features were retested and compared against the original mod to ensure it behaved as intended.

Notable differences with the original code :

Differences

- All weapons code adapted to work with client side event system - Player tank driving code also working on client side in ItemPostFrame - CMusic uses Steam MP3 player instead of FMOD - Added new data in music track list files to indicate the duration of each MP3 music since I haven't found another way to get it - Check if it's an audio file or music track list file - CHudSniper uses TriAPI to draw scaled sprites according to screen resolution, instead of regular sprites drawing functions - Changes to clientside fog code to make it functional

Various in-game bugs and issues in code were fixed, many of which were backported from 2016 version :

Fixes

https://github.com/malortie/hl-invasion/commit/2227b51e9f0e266d82531bdff93e40019e6b7daf https://github.com/malortie/hl-invasion/commit/d4fd7169fa2ac5e81fcc3a67a9bfa65353abc2d0 https://github.com/malortie/hl-invasion/commit/fd010a837485faa307b1ac6cc720dfce14fb4858 https://github.com/malortie/hl-invasion/commit/d652036acae600cc77a6f7c681e01e17e5539d95 https://github.com/malortie/hl-invasion/commit/a74be7f6003b2b12842cdb2295e4e04a88ce91c1 https://github.com/malortie/hl-invasion/commit/0beea5510c4dc1b5b2d3eb76be7f4217b21562ec https://github.com/malortie/hl-invasion/commit/07d451659bb190654a4fbf92b54eba2a903e5868 https://github.com/malortie/hl-invasion/commit/aee18ac6149e666ceeefc0be5d0ebab840f1e6d9 https://github.com/malortie/hl-invasion/commit/afbe720a2480ded0f263026ffd64d44b5ef35c0a https://github.com/malortie/hl-invasion/commit/7ac5efd98a0b37a061d99746ed674b3bbdecae44 https://github.com/malortie/hl-invasion/commit/1167b97a09b7ce991019f3cf64232848bd15040e https://github.com/malortie/hl-invasion/commit/db8654a1fd92a58d9369d0012ffba079532d8a2b https://github.com/malortie/hl-invasion/commit/fd6b3d89d60cc02ca774db19c5fd4238498bd121 https://github.com/malortie/hl-invasion/commit/ef6717bb365a7be4ca21b4514d283d71982bfccc https://github.com/malortie/hl-invasion/commit/4259a9c7835e6d607265baf4bbd502781b3cd3a6 https://github.com/malortie/hl-invasion/commit/6a0da9e49e40739b85d8796a6a91e50377f244f5 https://github.com/malortie/hl-invasion/commit/57604cc7dbdfd5414e0ccfba3f1b87deb4ddef9d https://github.com/malortie/hl-invasion/commit/75d8f2832f8f2b9ad2c1940a4630dbcc5c8a71cb https://github.com/malortie/hl-invasion/commit/b77dd03de9869b5abae31ea3ecf0ff50e9696adc https://github.com/malortie/hl-invasion/commit/fa5a1f2a8d5d1194048f75468177b435b2736111 https://github.com/malortie/hl-invasion/commit/638ea286a913d86d42314264400675b5876e084b https://github.com/malortie/hl-invasion/commit/0bfd13fb66dba565ec9dc6e6b7832250eeb903ac https://github.com/malortie/hl-invasion/commit/8e680ac5c2172b04581739c936b41796873e33e6 https://github.com/malortie/hl-invasion/commit/f05f312c7f75b7ce0932a9c75a925aa386271c27 https://github.com/malortie/hl-invasion/commit/b3214e83a0d547387abca1eee183184575c07dde https://github.com/malortie/hl-invasion/commit/56c239762d65c336ea6c95d837ad13ca7ebf7711 https://github.com/malortie/hl-invasion/commit/b456a4589a5d8214eaef6fb0a020a817b7104706 https://github.com/malortie/hl-invasion/commit/97a3279a91dbf5a0733b0cf6dd3e8a07151fe988 https://github.com/malortie/hl-invasion/commit/c541983840d68f3aa1f90d5de851d00f662c8564 https://github.com/malortie/hl-invasion/commit/88c57d6d2c5f16ab15f3de16df43cf9115216988 https://github.com/malortie/hl-invasion/commit/bd34ee17c2dbd73cb819888ea17bf34f032d8d04 https://github.com/malortie/hl-invasion/commit/6c2503a2fb1c278d6a228e866765a8c9ea175b91 https://github.com/malortie/hl-invasion/commit/cc7a4974a0cc696e9c8e3528e44c8a1023d2477d https://github.com/malortie/hl-invasion/commit/97b2ebf18d7666704ce679182d72fe3e1a6011ab https://github.com/malortie/hl-invasion/commit/a90aa13edcfa01be2c896e86dcd3fc2327392a60 **Note:** In [hlsdk-portable/fsniper.cpp](https://github.com/FWGS/hlsdk-portable/blob/invasion/dlls/fsniper.cpp#L206) there is a subtraction assignment operator on the right (-= 1.5). See https://github.com/malortie/hl-invasion/commit/67896a42f0dd04d6312842220c2feb25e69dbe9c for a fix.

If there's interest for moving weapons to client side and/or possibly improve stability, I would recommend to try and rebase my port changes on top of the current branch, or start from a new hlsdk-portable branch if such approach is considered.

Note: As of September 6th, I will be busy and will have less time to spend on game modding for an undetermined amount of time, but if you have general questions regarding my port and/or fixes listed above, let me know and I'll try to respond whenever I can find spare time.

[RoyShapiro]

@malortie

Hello!

It is obvious you did a much more thorough and neat job of modernizing and updating the Invasion code than I did, however, given that we're working with Xash instead of Vanilla Source SDK / Engine, I have the following concerns:

Xash FWGS is portable and cross-platform, and, as such is not tied to Steam, and has portability improvements, like say, input system improvements (see input_xash3d.cpp, touchscreen support which is something I didn't take into account either, e.t.c), portability fixes and so on.

I am not sure if Steam music player will work on Xash as is. If it won't, it will be necessary to implement some other music implementation, such as the one I wrote for miniaudio (https://github.com/FWGS/hlsdk-portable/commit/710fb2bb5e0fe88edd3b3e24bcff08e0c8400d18) or something else similar and not tied to Steam to make music work on Xash.

Vanilla Source Engine code will also likely need certain fixes to compile natively on Linux / BSD / Android e.t.c e.t.c, see my own struggle with the fact Android version doesn't currently have VGUI implementation AFAIK, and the aforementioned touchscreen support. To be frank, Linux / PlayStation Classic (BSD) compatibility was what motivated me to do my version in the first place.

Then we have weird bugs I run into which may or may not be Xash specific, such as a hard crash on l2m3 during the green acid exploding tank scripted sequence (that makes strange use of func_doors for sound effects and causes a crash) and cameras on l3m3 (monster_camera) having Thinks and pSprite in m_SaveData causing the game to crash when save is attempted or when their respective triggers are touched. You can take a look at my code to see what (admittedly band-aid like) changes I did to work around that (you may have addressed this already, but I currently don't have enough time to look through all the fixes, sorry).

Would you be willing to address these concerns / "port" your code to Xash?

[malortie]

@RoyShapiro

Unfortunately, I will be busy for a while and won't have time to look into porting my code to Xash.

In regards to monster_camera and l2m3 section, the only things I found in my notes are tests I did when testing features. I don't recall having encountered crashes with these. I also don't recall having crashes when playing the original mod release.

Additional information

1 - Span of commits for HL: Invasion:

(start) https://github.com/malortie/hl-invasion/commit/3dffbecf650e846672a71437cf0d8d752b7cf9a3 (end) https://github.com/malortie/hl-invasion/commit/67896a42f0dd04d6312842220c2feb25e69dbe9c

2 - Merge of original source code into HL SDK 2.4:

(start) https://github.com/malortie/hl-invasion/commit/3dffbecf650e846672a71437cf0d8d752b7cf9a3 (end) https://github.com/malortie/hl-invasion/commit/bbcfe0468966d31e29e6f7cbd4fd58bf12b06510

These also include small adjustments to make the code compilable. It should be possible to make a diff between those and compare against the current branch to ensure all changes of original mod source code are present.

3 - Weapons and tank code conversion to client side:

(start) https://github.com/malortie/hl-invasion/commit/a74e36797525747fbb88018bc6c1a45345b6570d (end) https://github.com/malortie/hl-invasion/commit/d38340bbbe6372606d9c4e7b737a994c46c129c2

4 - The rest of the commits are either part of the aforementioned fixes or related to the notable changes (see my first post).

[RoyShapiro]

Hi! Thanks for taking a look.

@nekonomicon

You have reverted changes from previous commits. Not on purpose. :) What seems to be a revert is actually either of the following three: a) A result of me using a commit 3db3772bff576cc0cb7fd0a380090d3c8794de5c as the base, so some changes could've been made later. b) > 3. Make a diff with mod sources -- that exact thing, this step is also why some of JujU's French comments got screwed by encoding differences. c) Some code, such as client weapons is simply a bit incomprehensible to me, last I modded Half-life it was still a WON version :) And JujU's code also mostly used server-based weapons (I guess it's not too critical, considering it's a singleplayer mod anyway? Correct me if I'm wrong.)

GStreamer is bloat and it's a bad choice for portable builds. I was afraid that would be the case, so that's why I've made it optional. It's currently possible to compile without -DUSE_GSTREAMER and it will use a "null player", so there will be no music, but it will work. That's how I've tested it. GStreamer was simply the thing I was most familiar with and could get done in a reasonable amount of time.

broken in the latest steam version of GoldSource Purely IMO, but if it ruins compatibility with GoldSource, it's probably something best left optional (like GStreamer in the current version).

I'll look at https://github.com/FWGS/hlsdk-xash3d/blob/thegate/cl_dll/hud.cpp#L184= when \ if I'll have the time, though.

It's not so hard to merge manually for me. Well, that's exactly what I tried, and look at the list of issues I had to fix (most of them popping up after trying to actually playtest the mod). So that's why we're here, I guess :D

If you still consider the current version mergeable, what actions are required of me?

On Fri, Jul 8, 2022 at 1:09 AM nekonomicon @.***> wrote:

Detect what HLSDK version used (probably by comparing client and server interface headers?)

Nope. As example HLSDK 2.0-2.1 didn't have weapons code and train sounds on client side yet. Only guns was predicted. Also, some mods was made on Spirit of Half-Life, will be need to diff more 15 versions.

I think we need some automated or at least documented way how to rebase mods on our HLSDK tree.

For invasion all already done by mod author: @.*** https://github.com/jlecorre/hlinvasion/commit/695cfb6570e244bd025ecd3cabcb37aa2bb3e49e

Git pull HLSDK of that version Make a diff with mod sources Review it

Just say diff -udpw

Try to automatically apply on top of hlsdk-xash3d or if it fails, manually merge it.

It's not so hard to merge manually for me.

— Reply to this email directly, view it on GitHub https://github.com/FWGS/hlsdk-xash3d/issues/260#issuecomment-1178278056, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQX4ZGUOZ5YIX7FB7GRK3M3VS5IQHANCNFSM526DUENA . You are receiving this because you authored the thread.Message ID: @.***>