Half-life: Invasion source update #260
Comments
Hi :)
Yep, we can create separate branch with your changes, but some things in your commit looks unclear:
I think It's not so hard to rebase and split your commits via
FMod live and exists for many platforms, but it's proprietary software. And steam version of GoldSource has client commands So there simple solution to play mp3: |
|
I think we need some automated or at least documented way how to rebase mods on our HLSDK tree. Like:
|
There no reason to update scripts for all build systems. |
Nope.
For invasion all already done by mod author:
Just say
It's not so hard to merge manually for me. |
|
Hi! Thanks for taking a look.
Not on purpose. :) What seems to be a revert is actually either of the following three:
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.
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
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? |
|
Sorry, seemed to miss this part:
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. |
Nope.
There good guide: Also, you can move to commit 3db3772 After that use cherry-pick for your commit(or copy-and-paste your changes) and rebase history. |
Alright, good to know.
So far I've managed to do almost exactly what you you've asked above (can be seen in my recent push) like add
intermediate commits, but something tells me it's probably too literal and not enough? |
|
@nekonomicon Luckily the code still compiles (fingers crossed I didn't end up breaking anything rather than fixing). |
|
Can you not touch changes from previous commits and just rewrite history or use method from my previous post? |
|
Do not replace crowbar code: There only need to add miss animations and sound: |
That seemed perfectly reasonable, so did that (but had the entire branch reuploaded in the process, so the commit ids have changed now).
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. |
|
ah... probably crowbar code from invasion does not have holster and some miss/hit animations yet. |
Yep, it did not. I've tried to make edits to crowbar (using the original upstream code) as you suggested, and got back to square one: 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 |
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. |
No changes here: Is it needed on server side? |
Ok. |
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.
Nope it isn't. Good catch, forgot about that. Gonna remove, but as a new commit. |
|
@nekonomicon |
|
I see you have just replaced files for handgrenade.cpp, python.cpp, mp5.cpp, health.cpp and shotgun.cpp. Which reason to move this function definition? |
|
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 I've replaced only the files, which I knew I couldn't fix by directly trying to merge with With With 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:
And on that note, of the two things above, I did whatever was within my ability, skill level and time constraints, for both points:
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. Why do I still want this merged? Specifically for the very reason that I've:
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). |
|
Ok. I understand.
I can try to rewrite it later.
Any contributions are welcome, but little criticism may be needed sometimes. |
|
@RoyShapiro branch invasion was added. |
|
First of all, Thank you!
Not at all! 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 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).
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. Meanwhile, |
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. HL: Invasion based on HLSDK 2.1 and probably will be better to disable client weapons for this mod.
@FreeSlave said, PrimeMusicStream callback works in steam, but required to use |
|
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. 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! |
|
If this may help, I previously ported HL: Invasion to the latest HL SDK (2.4). Not to be confused with the first port I released back in 2016 : 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
Various in-game bugs and issues in code were fixed, many of which were backported from 2016 version : Fixesmalortie/hl-invasion@2227b51 Note: In hlsdk-portable/fsniper.cpp there is a subtraction assignment operator on the right (-= 1.5). See malortie/hl-invasion@67896a4 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. |
|
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 (710fb2b) 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. 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? |
|
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) malortie/hl-invasion@3dffbec 2 - Merge of original source code into HL SDK 2.4: (start) malortie/hl-invasion@3dffbec 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) malortie/hl-invasion@a74e367 4 - The rest of the commits are either part of the aforementioned fixes or related to the notable changes (see my first post). |
|
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 3db3772
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:
***@***.***
<jlecorre/hlinvasion@695cfb6>
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
<#260 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQX4ZGUOZ5YIX7FB7GRK3M3VS5IQHANCNFSM526DUENA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
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
cmakeon 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!
The text was updated successfully, but these errors were encountered: