Forum posts
I too would like a func_vehicle compo/contest.
thank you so much! i didnt even think of that! i appreciate the help man!
Perhaps a compo with func_vehicle?Great idea
![[-TR-] 3mirG](https://twhl.info/uploads/avatars/small/08034_71782.png)
In the first map of Xen, there is a hidden func_wall brush (with rendermode set to texture) on the island you mentioned as (the position of the first dead hev guy you see in xen).
You can even stand on top of it.
As you can see in the image, the origin of the entity is exactly on this func_wall. If you somehow remove the func_wall, the entity will fall into the void.
You can even stand on top of it.
![[-TR-] 3mirG](https://twhl.info/uploads/avatars/full/08034_71782.png)
so, when i place a monster_hevsuit_dead and set it to table ( the position of the first dead hev guy you see in xen) in sequence and the pose it will either:
A float in the air
B go into the floor/wall
does anybody know how to fix this?
ALSO i modified the fgd to give the monster_hevsuit_dead the playermodel and give the animation sequence the table option i would post the screenshot but i dont know how
A float in the air
B go into the floor/wall
does anybody know how to fix this?
ALSO i modified the fgd to give the monster_hevsuit_dead the playermodel and give the animation sequence the table option i would post the screenshot but i dont know how
Perhaps a compo with func_vehicle?
This post was made on a thread that has been deleted.
Some ideas have been tossed around in Discord, but nothing has been decided currently.
Posted 5 months ago2023-11-20 20:40:15 UTC
in Mappers/Modelers needed for Half Life Mod "Mr B's Big Adventure" Post #348071
in Mappers/Modelers needed for Half Life Mod "Mr B's Big Adventure" Post #348071
Interesting offer, do you have discord?
Are we gonna do a mapping competition for the anniversary??
While I don't have a proper full page on my site just yet, due to the big 25th update I thought id post some info on the process as we are likely to get this question asked a lot:
2. Replace the studiomdl.exe in this folder C:\Program Files (x86)\Steam\steamapps\common\Half-Life SDK\Model Tools with this one http://www.the303.org/backups/sven_studiomdl_2019.rar
(The current HLSDK studiomdl.exe is 2002 era old and is missing support for $texrendermode and other things. This is a modernized compiler that is compatable. To see new features see here: https://the303.org/tutorials/gold_qc.htm#AS
3. Navigate to C:\Program Files (x86)\Steam\steamapps\common\Half-Life SDK\Player Models\DMatch and make a copy of one of these, for example copy "gordon.qc" and rename it. Then navigate into "Highcount" and make a copy of the gordon folder and rename it to your modelname, and do the same for "lowcount"
NOTE: cl_himodels 1/0 is an old command that seems to be kinda hidden now. Basically it uses bodygroup to change from a high poly to a low poly model. by default iirc its set to 0 which uses the lowpoly variant. Its up to you if you want to use this feature but most people don't bother with it. If not then you just remove the "low" line in the bodygroup QC
4. In the QC file open it and fix up the look paths as they were set to valves names and also change the mesh names to what model you are using. This is an example:
For texturing methods and matching half-life style see here: https://the303.org/tutorials/gold_mdl_tex_links.htm
If you want color changing textures, see this guide: https://the303.org/tutorials/gold_remap.htm
If you want mic-activated jaw flap animation, see this guide: https://the303.org/tutorials/gold_flappyjaws.htm
6. When you are done you export the SMD into the high folder. Optionally you can make a lowerpoly version but not many people use this old LOD feature so you could just put the high being the only line in the bodygroup.
7. Its recommended to use crowbar.exe ( https://steamcommunity.com/groups/CrowbarTool ) as it has several features for the compiling process. Go to "Set up games" tab, and in the "Half-Life" tab, go to the "model viewer" and change its path to HLAM. Switch to the compile tab, choose your QC, make sure the Game configuration says "half-life". Press the compile button by default it makes a subfolder in the current dir. I use this until im happy with the model then I use the "game models" folder option. You will probably have some first time compile errors but heres a comprehensive list: https://the303.org/tutorials/gold_mdl_fix.htm
NOTE: If you are making custom animations for your model you must make a copy of the "player_shared.qc" rename it to something like "yourmodel", update the name of it in your main QC to point to it, then edit the player_shared_yourmodel.qc lines to have the new anims and make the names of those new anim SMD files unique so you don't overwrite the original SMD ones. Example like say idle_custom.smd. Also don't accidentally rename the sequence name to custom. It should look like this for example:
$sequence "idle" "idle_custom" fps 14 loop ACT_IDLE 1
8. To verify the model if It did succeed in compiling, click the button at the bottom to "use in view" and click "open viewer" or just use the "goto" button in the previous window to navigate to the model in its folder and open from there if you have associated mdl files with hlam.
9. Make any changes/recompile after verifying the model for any issues. Check all angles, check animations. If you think its good compile to models folder and launch the game. Useful testing commands to see your model:
start new server, password protect set at least 2 players
sv_cheats 1
thirdperson
cam_idealdist 128
cam_idealyaw 180
cam_idealpitch -30
voice_loopback 1 (if testing jaw-flap animation)
10. When you are sure its ready, then make your playermodel portrait: 164x200 BMP in 8bit indexed mode (but limit to 160 colors if not using color changing) . If doing the advanced color changing you will need to refer to this guide to get a working portrait to match: https://the303.org/tutorials/gold_remap.htm
INTRO:
- Before you start, Playermodels have limits compared to NPC models:
- You cannot add new animations to the existing set or change the order of the sequences
- You cannot change the FPS of animations, they are locked
- You cannot have sequences with more frames than the originals or else they will play too fast and will cut-off
- You cannot change the hitbox set (nice try)
- You cannot have skin changes (swappable body meshes are only for use in the cl_highmodels command)
- You can customize existing animations however you must make them fit within the same frames as the original and be keyed to match the same FPS as the originals
- You can add bones to the model as long as its parented off of existing and not inbetween existing bones (breaks hierarchy)
- You can have procedural mouth animations
- You can have color remapping
The method
1. Download the HalfLife SDK (Steam tools > Half-Life SDK) & HLAM ( https://github.com/SamVanheer/HalfLifeAssetManager )2. Replace the studiomdl.exe in this folder C:\Program Files (x86)\Steam\steamapps\common\Half-Life SDK\Model Tools with this one http://www.the303.org/backups/sven_studiomdl_2019.rar
(The current HLSDK studiomdl.exe is 2002 era old and is missing support for $texrendermode and other things. This is a modernized compiler that is compatable. To see new features see here: https://the303.org/tutorials/gold_qc.htm#AS
3. Navigate to C:\Program Files (x86)\Steam\steamapps\common\Half-Life SDK\Player Models\DMatch and make a copy of one of these, for example copy "gordon.qc" and rename it. Then navigate into "Highcount" and make a copy of the gordon folder and rename it to your modelname, and do the same for "lowcount"
NOTE: cl_himodels 1/0 is an old command that seems to be kinda hidden now. Basically it uses bodygroup to change from a high poly to a low poly model. by default iirc its set to 0 which uses the lowpoly variant. Its up to you if you want to use this feature but most people don't bother with it. If not then you just remove the "low" line in the bodygroup QC
4. In the QC file open it and fix up the look paths as they were set to valves names and also change the mesh names to what model you are using. This is an example:
$modelname "/player/skelepuncher/skelepuncher.mdl"
$cd "../player/"
$cdtexture "../dmatch/highcount/skelepuncher" //texture look in folder
$cliptotextures
$scale 1.0
$origin 0 0 36
// whole body
$bodygroup body
{
studio "../dmatch/lowcount/skelepuncher/skelepuncher-low" //remove this whole line if not using this feature
studio "../dmatch/highcount/skelepuncher/skelepuncher-high"
}
$include "../player/player_shared.qc"For texturing methods and matching half-life style see here: https://the303.org/tutorials/gold_mdl_tex_links.htm
If you want color changing textures, see this guide: https://the303.org/tutorials/gold_remap.htm
If you want mic-activated jaw flap animation, see this guide: https://the303.org/tutorials/gold_flappyjaws.htm
6. When you are done you export the SMD into the high folder. Optionally you can make a lowerpoly version but not many people use this old LOD feature so you could just put the high being the only line in the bodygroup.
7. Its recommended to use crowbar.exe ( https://steamcommunity.com/groups/CrowbarTool ) as it has several features for the compiling process. Go to "Set up games" tab, and in the "Half-Life" tab, go to the "model viewer" and change its path to HLAM. Switch to the compile tab, choose your QC, make sure the Game configuration says "half-life". Press the compile button by default it makes a subfolder in the current dir. I use this until im happy with the model then I use the "game models" folder option. You will probably have some first time compile errors but heres a comprehensive list: https://the303.org/tutorials/gold_mdl_fix.htm
NOTE: If you are making custom animations for your model you must make a copy of the "player_shared.qc" rename it to something like "yourmodel", update the name of it in your main QC to point to it, then edit the player_shared_yourmodel.qc lines to have the new anims and make the names of those new anim SMD files unique so you don't overwrite the original SMD ones. Example like say idle_custom.smd. Also don't accidentally rename the sequence name to custom. It should look like this for example:
$sequence "idle" "idle_custom" fps 14 loop ACT_IDLE 1
8. To verify the model if It did succeed in compiling, click the button at the bottom to "use in view" and click "open viewer" or just use the "goto" button in the previous window to navigate to the model in its folder and open from there if you have associated mdl files with hlam.
9. Make any changes/recompile after verifying the model for any issues. Check all angles, check animations. If you think its good compile to models folder and launch the game. Useful testing commands to see your model:
start new server, password protect set at least 2 players
sv_cheats 1
thirdperson
cam_idealdist 128
cam_idealyaw 180
cam_idealpitch -30
voice_loopback 1 (if testing jaw-flap animation)
10. When you are sure its ready, then make your playermodel portrait: 164x200 BMP in 8bit indexed mode (but limit to 160 colors if not using color changing) . If doing the advanced color changing you will need to refer to this guide to get a working portrait to match: https://the303.org/tutorials/gold_remap.htm
This post was made on a thread that has been deleted.
This post was made on a thread that has been deleted.
As UrbaNebula says, read the compile log. It will tell you exactly the reasons why it failed.
Keep an eye out (or use text search) for the key word
Keep an eye out (or use text search) for the key word
Error, and good to check for Warning as well as it might tell you about issues that didn't prevent compile but might affect the map nonetheless.
Today's update fixes the problems that broke Half-Life Updated and mods derived from it. I'm going to wait until they've released an SDK update before i touch anything since it'll be a while to stabilize everything.
There's a test branch for Opposing Force which means it'll receive an update soon as well. Expect the same for all GoldSource engine games to fix issues with the new engine update. I'd expect the SDK update to come after all games have been updated and fixed so it'll probably be a few weeks.
Until then use the
In case i don't have time to deal with the SDK update, here's the procedure for merging changes into Half-Life Updated:
1. Fork the newest version of the Half-Life 1 SDK
2. Make sure all files use UTF8 encoding (should hopefully be done by Valve already, but check first) and commit any encoding changes
3. add the
4. Commit formatted files
5. Add fork as remote to Half-Life Updated
6. Use git fetch to update remote info
7. Merge the commit that formatted files
8. Resolve merge conflicts; there will likely be many. Some changes are technically out of scope for the project like the game balance changes, i'd exclude those changes or make them conditional based on cvars (the Unified SDK uses configuration files for those changes so it'll need to be updated there instead)
9. Commit merge and push
That should cover it. I'd recommend using a separate copy of the source code to avoid messing up the one people normally use for development. Use a Git GUI like SourceTree, it makes things a lot easier.
There's a test branch for Opposing Force which means it'll receive an update soon as well. Expect the same for all GoldSource engine games to fix issues with the new engine update. I'd expect the SDK update to come after all games have been updated and fixed so it'll probably be a few weeks.
Until then use the
steam_legacy branch to develop, test and play mods.In case i don't have time to deal with the SDK update, here's the procedure for merging changes into Half-Life Updated:
1. Fork the newest version of the Half-Life 1 SDK
2. Make sure all files use UTF8 encoding (should hopefully be done by Valve already, but check first) and commit any encoding changes
3. add the
.clang-format file from Half-Life Updated and format all files (script in the Unified SDK or a Visual Studio extension can do this among other tools). Needed to avoid massive amounts of merge conflicts caused by whitespace and newline changes4. Commit formatted files
5. Add fork as remote to Half-Life Updated
6. Use git fetch to update remote info
7. Merge the commit that formatted files
8. Resolve merge conflicts; there will likely be many. Some changes are technically out of scope for the project like the game balance changes, i'd exclude those changes or make them conditional based on cvars (the Unified SDK uses configuration files for those changes so it'll need to be updated there instead)
9. Commit merge and push
That should cover it. I'd recommend using a separate copy of the source code to avoid messing up the one people normally use for development. Use a Git GUI like SourceTree, it makes things a lot easier.
Did you read the compile log? It failed to compile because of this error:
Error: Entity 5, Brush 0: SKY brushes not allowed in entityFind the brush entity that has a SKY texture and correct it.
Error: Brush type not allowed in entity
** Executing...
** Command: Change Directory
** Parameters: C:/Program Files (x86)/Steam/steamapps/common/Half-Life/valve
** Executing...
** Command: C:/Program Files (x86)/Steam/steamapps/common/Half-Life/mapping/J.A.C.K/halflife/tools/hlcsg_x64.exe
** Parameters: "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out"
hlcsg v3.4 VL34 64-bit (Aug 17 2015)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (vluzacn@163.com)
----- BEGIN hlcsg -----
Command line: "C:/Program Files (x86)/Steam/steamapps/common/Half-Life/mapping/J.A.C.K/halflife/tools/hlcsg_x64.exe" "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out"
Arguments: "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out" -low -wadautodetect
Entering C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out.map
Error: Entity 5, Brush 0: SKY brushes not allowed in entity
Error: Brush type not allowed in entity
Description: The map has a problem which must be fixed
Howto Fix: Check the file http://www.zhlt.info/common-mapping-problems.html for a detailed explanation of this problem
----- END hlcsg -----
** Executing...
** Command: C:/Program Files (x86)/Steam/steamapps/common/Half-Life/mapping/J.A.C.K/halflife/tools/hlbsp_x64.exe
** Parameters: "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out"
hlbsp v3.4 VL34 64-bit (Aug 17 2015)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (vluzacn@163.com)
----- BEGIN hlbsp -----
Command line: "C:/Program Files (x86)/Steam/steamapps/common/Half-Life/mapping/J.A.C.K/halflife/tools/hlbsp_x64.exe" "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out"
Arguments: "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out" -low -chart
** Executing...
** Command: C:/Program Files (x86)/Steam/steamapps/common/Half-Life/mapping/J.A.C.K/halflife/tools/hlvis_x64.exe
** Parameters: "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out"
hlvis v3.4 VL34 64-bit (Aug 17 2015)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (vluzacn@163.com)
----- BEGIN hlvis -----
Command line: "C:/Program Files (x86)/Steam/steamapps/common/Half-Life/mapping/J.A.C.K/halflife/tools/hlvis_x64.exe" "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out"
Arguments: "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out" -low
** Executing...
** Command: C:/Program Files (x86)/Steam/steamapps/common/Half-Life/mapping/J.A.C.K/halflife/tools/hlrad_x64.exe
** Parameters: "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out"
hlrad v3.4 VL34 64-bit (Aug 17 2015)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (vluzacn@163.com)
----- BEGIN hlrad -----
Command line: "C:/Program Files (x86)/Steam/steamapps/common/Half-Life/mapping/J.A.C.K/halflife/tools/hlrad_x64.exe" "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out"
Arguments: "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out" -low
** Executing...
** Command: Change Directory
** Parameters: C:/Program Files (x86)/Steam/steamapps/common/Half-Life
** Executing...
** Command: C:/Program Files (x86)/Steam/steamapps/common/Half-Life/hl.exe
** Parameters: -console -dev +map new_map_terrain_test3_out
** Command: Change Directory
** Parameters: C:/Program Files (x86)/Steam/steamapps/common/Half-Life/valve
** Executing...
** Command: C:/Program Files (x86)/Steam/steamapps/common/Half-Life/mapping/J.A.C.K/halflife/tools/hlcsg_x64.exe
** Parameters: "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out"
hlcsg v3.4 VL34 64-bit (Aug 17 2015)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (vluzacn@163.com)
----- BEGIN hlcsg -----
Command line: "C:/Program Files (x86)/Steam/steamapps/common/Half-Life/mapping/J.A.C.K/halflife/tools/hlcsg_x64.exe" "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out"
Arguments: "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out" -low -wadautodetect
Entering C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out.map
Error: Entity 5, Brush 0: SKY brushes not allowed in entity
Error: Brush type not allowed in entity
Description: The map has a problem which must be fixed
Howto Fix: Check the file http://www.zhlt.info/common-mapping-problems.html for a detailed explanation of this problem
----- END hlcsg -----
** Executing...
** Command: C:/Program Files (x86)/Steam/steamapps/common/Half-Life/mapping/J.A.C.K/halflife/tools/hlbsp_x64.exe
** Parameters: "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out"
hlbsp v3.4 VL34 64-bit (Aug 17 2015)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (vluzacn@163.com)
----- BEGIN hlbsp -----
Command line: "C:/Program Files (x86)/Steam/steamapps/common/Half-Life/mapping/J.A.C.K/halflife/tools/hlbsp_x64.exe" "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out"
Arguments: "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out" -low -chart
----- END hlbsp -----There was a problem compiling the map.
Check the file C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out.log for the cause.
** Executing...
** Command: C:/Program Files (x86)/Steam/steamapps/common/Half-Life/mapping/J.A.C.K/halflife/tools/hlvis_x64.exe
** Parameters: "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out"
hlvis v3.4 VL34 64-bit (Aug 17 2015)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (vluzacn@163.com)
----- BEGIN hlvis -----
Command line: "C:/Program Files (x86)/Steam/steamapps/common/Half-Life/mapping/J.A.C.K/halflife/tools/hlvis_x64.exe" "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out"
Arguments: "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out" -low
----- END hlvis -----There was a problem compiling the map.
Check the file C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out.log for the cause.
** Executing...
** Command: C:/Program Files (x86)/Steam/steamapps/common/Half-Life/mapping/J.A.C.K/halflife/tools/hlrad_x64.exe
** Parameters: "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out"
hlrad v3.4 VL34 64-bit (Aug 17 2015)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (vluzacn@163.com)
----- BEGIN hlrad -----
Command line: "C:/Program Files (x86)/Steam/steamapps/common/Half-Life/mapping/J.A.C.K/halflife/tools/hlrad_x64.exe" "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out"
Arguments: "C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out" -low
----- END hlrad -----There was a problem compiling the map.
Check the file C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\new_map_terrain_test3_out.log for the cause.
** Executing...
** Command: Change Directory
** Parameters: C:/Program Files (x86)/Steam/steamapps/common/Half-Life
** Executing...
** Command: C:/Program Files (x86)/Steam/steamapps/common/Half-Life/hl.exe
** Parameters: -console -dev +map new_map_terrain_test3_out
Please tell me about your maps utilizing
func_vehicle, I want to host them on my server!
It seems their fix doesn't work, just watched Bolloxed and his bright places are all olive and the hall with DNA spiral on the floor was lit incorrectly.
Well this really threw a wrench in things but at least we got a proper update to Half-Life for modern systems.
Yeah, they used the solution i mentioned to someone a while back. I never got around to applying it myself but it'll be merged in once the SDK update rolls around.
I do wish they'd make the anniversary edition a separate game as that would've avoided all of the problems. No need to switch branches, no broken games and mods and each game can be ported one at a time. And then a separate game/tool/app on Steam for mods to use to decouple game fixes from the mod version of the engine.
There must be a reason why they did it this way but it's causing a lot of headaches.
I do wish they'd make the anniversary edition a separate game as that would've avoided all of the problems. No need to switch branches, no broken games and mods and each game can be ported one at a time. And then a separate game/tool/app on Steam for mods to use to decouple game fixes from the mod version of the engine.
There must be a reason why they did it this way but it's causing a lot of headaches.
I'm converting cs_twhlkart2020 to hldm. CS WAD requirements have been eliminated by embedding the textures used, CT/T spawns have been replaced with DM spawns peppered throughout the map, and a lot of weapons/ammos/items have been added, though mostly curbside. I'm damn sure it's currently very imbalanced towards the spectators vs the drivers. I'd like to have a few other people go over it and rebalance the placements. Or, maybe, have archie or urby release a HLDM version with all their level design wisdom. gdrive link
The karts work great btw.
The karts work great btw.
Thanks to the new 25th anniversary update, the glorious counter-strike brush entity known as FUNC_VEHICLE is now available in Half-Life.
I have seedees tutorial on my site here for it: https://the303.org/tutorials/gold_func_vehicle.htm
If anyone has made an HLDM map with func_vehicle let me know, id want to play sometime
Current issues so far ive noticed:
-acceleration sounds seem to not play properly
-idle sounds seem to be very delayed
I have seedees tutorial on my site here for it: https://the303.org/tutorials/gold_func_vehicle.htm
If anyone has made an HLDM map with func_vehicle let me know, id want to play sometime
Current issues so far ive noticed:
-acceleration sounds seem to not play properly
-idle sounds seem to be very delayed
Im glad you noticed the delay in sound playback as well. Drives me nuts. Also, can you believe it, they added bullet impact sounds for the player!
Yeah, it's funny how it turned out 
Half-Life 25th anniversary version released
Valve has released the 25th anniversary version of Half-Life which has slight changes in how the filesystem interface works which causes all mods based on recent versions of Half-Life Updated to crash. I've identified the problem and i've pushed a fix to a separate branch: https://github.com/SamVanheer/halflife-updated/tree/dev-anniversaryUntil Valve releases a new SDK all projects will remain as-is. Use the
steam_legacy branch to run mods. You can access it by right-clicking Half-Life in Steam, opening Properties and going to the Betas tab:
Once the SDK has been released i'll update the SDKs to work with the new version.
Note that there are some bugs in the new version. There is a noticeable (half second) delay in sound playback so they'll probably be fixing bugs before any SDK updates can be expected.
Please don't report mod crashes as bugs on the Half-Life Updated issue tracker because it's currently out of our hands. Check the Half-Life issue tracker and search before you post.
Valve literally just released the 25th Anniversary Update that fixed gl_overbright
Half-Life Asset Manager V2 Beta 12 released
Half-life Asset Manager V2 Beta 12 has been released: https://github.com/SamVanheer/HalfLifeAssetManager/releases/tag/HLAM-V2.0.0-beta012Changes:
- Removed dot in file extension to fix file associations not working when installed using offline installer
May be you've seen this YouTube video:
(Author is not exactly correct on when overbright feature was cut from Goldsource though. Early 00s Steam builds still had it, I was introduced to HL with Condition Zero when it was already on Steam and still had overbright.)
Posting this video on HLFX forum started a discussion that resulted in fixing display of lightmaps and in couple other bugfixes like lighting of outdoor models.
Thanks to user Decay for lurking VOGONS forums and figuring out how to implement it in Xash3D.
https://www.moddb.com/engines/xash3d-engine/downloads/original-looking-lightmaps-and-textures
More screenshots: https://imgur.com/a/ahntAbu
before
after
Posting this video on HLFX forum started a discussion that resulted in fixing display of lightmaps and in couple other bugfixes like lighting of outdoor models.
Thanks to user Decay for lurking VOGONS forums and figuring out how to implement it in Xash3D.
https://www.moddb.com/engines/xash3d-engine/downloads/original-looking-lightmaps-and-textures
More screenshots: https://imgur.com/a/ahntAbu
beforeafter
This post was made on a thread that has been deleted.
Ambiguous leafnode content errors happen when different faces on the same brush have a different type, like one having a water texture and another having a normal one. This can happen due to bad texture application but also when the compiler splits brushes and applies the wrong texture.
You can use func_detail to help avoid this or rework the geometry a bit but sometimes it's unavoidable.
You can use func_detail to help avoid this or rework the geometry a bit but sometimes it's unavoidable.
already compiled bsps? use newbspguy.
found the problem lol. i changed the normal model but i was playing with hd models.
other question: how can i change textures inside a map?
other question: how can i change textures inside a map?
did you forgot to save?
also please use HLAM.
also please use HLAM.
Hey Guys,
i am very new to the Half-Life "Modding" (if you can call it that). My problem right now is, that i changed the the back of Barneys Model, and it loads everything correctly in Jeds Model Viewer. The texture hast the same resolution and bit depth. However, when i restart Half-Life, Barney still has the original old Back Texture.
Thanks for everybody, who can help out!
i am very new to the Half-Life "Modding" (if you can call it that). My problem right now is, that i changed the the back of Barneys Model, and it loads everything correctly in Jeds Model Viewer. The texture hast the same resolution and bit depth. However, when i restart Half-Life, Barney still has the original old Back Texture.
Thanks for everybody, who can help out!
Yeah, we could make a plan on a Google docs with a hierarchical structure and the possibility to add comments. I can create it if that suits you.
I'm down for writing a number of beginner tutorials. I could allocate some time to write them all by New Year, just need a bit of a plan first.
Yeah we really need better beginner tutorials, the problem is that nobody has time to write all of that down. And any tutorial that explains everything people need to know will end up being very long due to how many terms there are, the amount of history, etc.For now we really just need a starting point for beginners, not to make it comprehensive. I could work on it, but we would need to decide how it will relate to existing beginner tutorials and to Admer’s planned tutorial.
To be honest, I’m wondering how to fix this, I can’t even imagine what it is and where to start?
Yeah we really need better beginner tutorials, the problem is that nobody has time to write all of that down. And any tutorial that explains everything people need to know will end up being very long due to how many terms there are, the amount of history, etc.
I thought about making pages that list every kind of fatal error the engine can produce along with an explanation (easy enough to find by searching for Sys_Error calls and Host_Error calls using a disassembler) but that also takes time.
Also needed is a page containing all of the old update notes from the pre-Steam HL website and the old Steampowered news site before they switched to Steampipe since that's all lost now outside of archive.org, but again that takes time to dig through and assemble. There's also information in the old mailing lists that isn't documented anywhere else.
I thought about making pages that list every kind of fatal error the engine can produce along with an explanation (easy enough to find by searching for Sys_Error calls and Host_Error calls using a disassembler) but that also takes time.
Also needed is a page containing all of the old update notes from the pre-Steam HL website and the old Steampowered news site before they switched to Steampipe since that's all lost now outside of archive.org, but again that takes time to dig through and assemble. There's also information in the old mailing lists that isn't documented anywhere else.
It shouldn't make any difference performance-wise, but you can always fix them if you're worried about it.
I understand that this is another topic, but what kind of error is this, how critical is it, for wpoly for example?
It shouldn't cause water sounds to play.
I’m joining late in the discussion, so bear with me if I say something already mentionned. I read the posts but I might have missed something.
I learned mapping at an age where I barely knew how to use a computer. When I was told to go in the "File" menu I was looking for it in the Windows XP’s Start Menu, I didn’t understand what the tutorial mean by "extracting" something, and it took me years to understand I had to compile a map to play it and figure out that to create a mod I was supposed to edit "liblist.gam".
The TWHL wiki is a great source of information, but as I think was already mentionned, it looks absolutely daunting to me and to any real beginner.
I believe it is crucial to have clear distinction between an all-encompassing introductory tutorial for complete beginners that assume no previous knowledge, and more specialised guides and other specialised articles like glossaries and entity references. This would help beginners know where to start, and more advanced modders know where to find the information they are looking for.
This distinction must be made clear in the wiki homepage (by displaying a visible link to the introductory tutorial). The current wiki homepage simply lists articles which would seem extremely confusing to any beginners. For instance, after being scared by the sheer number of available pages, they would click on "Tools" as advised, and find an enormous number of things they are supposed to download, not knowing what they do.
In specialised articles, it would be great to display a small banner warning readers that it requires some skills and redirecting beginners to the introductory tutorial). This might sound overkill, but for the minority of confused beginners I think that will be very useful, and it does not need to take a lot of space.
For me, most of the effort needs to go in the introductory tutorial.
The situation is very difficult for a beginner arriving on TWHL. For instance, assuming a beginner manages to access the GoldSource tutorials homepage, they might not know what GoldSource really is, what is WON, what is modding. Maybe they’ll think they have to first do the "modding in general" section, then learn programming, to finally be able to reach the part about level design. They will also be discouraged if they see the sheer amount of pages in the category at the bottom of the page, not knowing they do not need to read all of them. Even if they get to Introduction to mapping, the introduction is very thin. What does the tutorial explain? What is a level editor? Maybe the user expects the level editor to be in-game as it is for other games.
It would then link to the mapping tutorial (e.g. "Learn to create maps for Half-Life / GoldSource games and mods"), explaining what it will allow the reader to do. It would also link to the programming tutorial, warning that it requires C++ knowledge.
At least for the mapping tutorial, any IT skills such as extracting a zip file or installing a program should be explained. It doesn’t take too long, especially with one or two screenshots. Having a page that covers the essentials of using a PC, might be useful Solo, but it’s best to include its relevant content directly in the beginner tutorial (it will be easier to understand and apply), instead of relying on it as a requirement. Similarly, a very small introduction to GoldSource, describing it as a collection of files that allow Half-Life and its mods to run and handle its graphics, audio, and AI is sufficient, instead of a full-blown article on the subject (for the beginner tutorial at least).
Mabe this is what you mean by the "in the beginning" tutorial that you intend to create Admer? I think it would be amazing to have such a tutorial.
Learn how to create maps and mods for Half-Life 1 and GoldSource games (the introductory tutorial)
- What games is this tutorial for: HL, CS, SC…, what is GoldSource, what is modding, how to learn mapping (link to tutorial)
- Screenshots / links to maps & mods created by the community, for illustration
- Link to navigate to the mapping tutorial
- Link to navigate to the programming tutorial
Learn how to create maps for GoldSource games (the mapping tutorial)
- Link to the parent tutorial (the introductory tutorial)
- What is mapping, examples of maps, etc.
- Link to the next chapter: "Installing the map editor"
- List of all the chapters of the tutorial
Installing the map editor
- Link to the parent tutorial (the mapping tutorial)
- Why you need to download a map editor
- How to download and install a map editor
- Link to the next chapter (setting up the map editor)
I learned mapping at an age where I barely knew how to use a computer. When I was told to go in the "File" menu I was looking for it in the Windows XP’s Start Menu, I didn’t understand what the tutorial mean by "extracting" something, and it took me years to understand I had to compile a map to play it and figure out that to create a mod I was supposed to edit "liblist.gam".
The TWHL wiki is a great source of information, but as I think was already mentionned, it looks absolutely daunting to me and to any real beginner.
I believe it is crucial to have clear distinction between an all-encompassing introductory tutorial for complete beginners that assume no previous knowledge, and more specialised guides and other specialised articles like glossaries and entity references. This would help beginners know where to start, and more advanced modders know where to find the information they are looking for.
This distinction must be made clear in the wiki homepage (by displaying a visible link to the introductory tutorial). The current wiki homepage simply lists articles which would seem extremely confusing to any beginners. For instance, after being scared by the sheer number of available pages, they would click on "Tools" as advised, and find an enormous number of things they are supposed to download, not knowing what they do.
In specialised articles, it would be great to display a small banner warning readers that it requires some skills and redirecting beginners to the introductory tutorial). This might sound overkill, but for the minority of confused beginners I think that will be very useful, and it does not need to take a lot of space.
For me, most of the effort needs to go in the introductory tutorial.
The introductory tutorial
I believe tutorial, to mean an article that explains and teaches modding from the very beginning, is an appropriate term, moreso that guide and especially explanation. Guide to me seems more appropriate for more advanced articles on specific techniques.The situation is very difficult for a beginner arriving on TWHL. For instance, assuming a beginner manages to access the GoldSource tutorials homepage, they might not know what GoldSource really is, what is WON, what is modding. Maybe they’ll think they have to first do the "modding in general" section, then learn programming, to finally be able to reach the part about level design. They will also be discouraged if they see the sheer amount of pages in the category at the bottom of the page, not knowing they do not need to read all of them. Even if they get to Introduction to mapping, the introduction is very thin. What does the tutorial explain? What is a level editor? Maybe the user expects the level editor to be in-game as it is for other games.
Content
That’s why we need a real introductory tutorial that would be all-encompassing and aimed at beginners (e.g. "Learn to create maps and mods for Half-Life 1 games"). This introductory tutorial would start by explaining for what games the tutorial is for (Half-Life 1, CS, Sven Co-op, etc.), what GoldSource is and why modding is similar on all GoldSource games, what modding is, and what can be done (creating maps, mods, etc.).It would then link to the mapping tutorial (e.g. "Learn to create maps for Half-Life / GoldSource games and mods"), explaining what it will allow the reader to do. It would also link to the programming tutorial, warning that it requires C++ knowledge.
At least for the mapping tutorial, any IT skills such as extracting a zip file or installing a program should be explained. It doesn’t take too long, especially with one or two screenshots. Having a page that covers the essentials of using a PC, might be useful Solo, but it’s best to include its relevant content directly in the beginner tutorial (it will be easier to understand and apply), instead of relying on it as a requirement. Similarly, a very small introduction to GoldSource, describing it as a collection of files that allow Half-Life and its mods to run and handle its graphics, audio, and AI is sufficient, instead of a full-blown article on the subject (for the beginner tutorial at least).
Mabe this is what you mean by the "in the beginning" tutorial that you intend to create Admer? I think it would be amazing to have such a tutorial.
Navigation
The current wiki navigation can suit specialised articles, but it should be made simpler and more straigtforward for beginner tutorials. The tutorial starting point page should list all pages of the tutorial, and only those links, so as not to confuse or discourage the read. Each page should link to the next and previous chapter, as well as to the starting point page. This could be done in the website’s code or, more probably, directly in the article content.Example
So, in the end, for the introductory tutorial, we might have something like this:Learn how to create maps and mods for Half-Life 1 and GoldSource games (the introductory tutorial)
- What games is this tutorial for: HL, CS, SC…, what is GoldSource, what is modding, how to learn mapping (link to tutorial)
- Screenshots / links to maps & mods created by the community, for illustration
- Link to navigate to the mapping tutorial
- Link to navigate to the programming tutorial
Learn how to create maps for GoldSource games (the mapping tutorial)
- Link to the parent tutorial (the introductory tutorial)
- What is mapping, examples of maps, etc.
- Link to the next chapter: "Installing the map editor"
- List of all the chapters of the tutorial
Installing the map editor
- Link to the parent tutorial (the mapping tutorial)
- Why you need to download a map editor
- How to download and install a map editor
- Link to the next chapter (setting up the map editor)
Specialised articles
By specialised articles, I mean any article that only address a specific topic and requires some previous knowledge, which is what the current wiki mostly contains. I think the main issue is with the navigation that should be improved, maybe by improving navigation between categories, maybe by making navigation more hierarchical (displaying only the top categories in the homepage), and moving the list of all pages of the category in a separate page, maybe in the results of a search request).Could this have any effect or what does this mean? The coordinates are different, but they all lead to worldspawn when you go to the coordinates through a search, and if you find it yourself, then there is usually emptiness. Could it be another problem with the clip brushes?
Warning: Ambiguous leafnode content ( EMPTY and SOLID ) at (-579,132,-86)-(-576,139,118) in hull 1 of model 0 (entity: classname "worldspawn", origin "", targetname "")
Warning: Ambiguous leafnode content ( EMPTY and SOLID ) at (-579,132,-86)-(-576,139,118) in hull 1 of model 0 (entity: classname "worldspawn", origin "", targetname "")
This works, thank you!
The
References to Mac development have been removed. Half-Life Updated no longer supports Mac builds and only the Steam version of Half-Life has a Mac version.
Steam will drop support for the last 32 bit Mac OS version in a few years, they dropped support for Mac OS 10.12 this last september and the last 32 bit version is MacOS Mojave (10.14). This is in response to Chromium dropping support for those versions since Steam uses Chromium for its user interface.
Chromium is dropping support for MacOS Mojave in their latest versions, as noted in this issue which tracks removal of code used to support older MacOS versions.
Chromium version M117 released a few months ago. Steam usually trails behind Chromium updates and will be updating to a version that no longer supports Windows 7 and 8.1 at the start of next year. Chromium M110 was the first version to drop support for those and released about a year ago.
Given the rate at which Steam updates its Chromium dependency it will likely drop support within 1-2 years.
Half-Life Programming - Getting Started tutorial has been updated to streamline the tutorial and remove obsolete information.References to Mac development have been removed. Half-Life Updated no longer supports Mac builds and only the Steam version of Half-Life has a Mac version.
Steam will drop support for the last 32 bit Mac OS version in a few years, they dropped support for Mac OS 10.12 this last september and the last 32 bit version is MacOS Mojave (10.14). This is in response to Chromium dropping support for those versions since Steam uses Chromium for its user interface.
Chromium is dropping support for MacOS Mojave in their latest versions, as noted in this issue which tracks removal of code used to support older MacOS versions.
Chromium version M117 released a few months ago. Steam usually trails behind Chromium updates and will be updating to a version that no longer supports Windows 7 and 8.1 at the start of next year. Chromium M110 was the first version to drop support for those and released about a year ago.
Given the rate at which Steam updates its Chromium dependency it will likely drop support within 1-2 years.
Posted 6 months ago2023-11-13 09:27:31 UTC
in Half Life live action short film + guitar cover (Last Legs, Vortal Combat, Triage At Dawn) Post #348029
in Half Life live action short film + guitar cover (Last Legs, Vortal Combat, Triage At Dawn) Post #348029
Half Life 2 - ‘Last Legs / Vortal Combat / Triage At Dawn’ (guitar cover + tab) [Soundtrack]
https://www.youtube.com/watch?v=N0VjEI2E2E8
<== Continued from previous post
All of my findings are included in the Github issue: https://github.com/SamVanheer/halflife-unified-sdk/issues/453
If there is a way to replicate the HUD's exact appearance in HTML then it probably won't work in RmlUi since it will likely depend on CSS features that RmlUi doesn't (yet) implement.
Until it's possible to render the HUD in RmlUi it isn't worth trying to integrate it into a mod.
I've also done some investigation work into how modern engines handle UIs to see if any of them provide their UI toolkits as standalone options that can be integrated into an engine this old.
My findings are as follows (not an exhaustive list):
This integration allows engine functionality to be used in the UI but precludes integration into other engines. None of these toolkits are available for standalone use, and even if they were they all use modern graphics APIs which makes integration even harder.
All of these toolkits are optimized for use in games, which means they update and render once a frame.
Another alternative is Chromium Embedded Framework 3 (CEF3), used to implement the UI in various desktop applications like Steam, Discord and Visual Studio Code (using Electron, a desktop application framework built on top of Chromium).
Chromium is designed to power web browsers; its architecture is designed around this use case. In practical terms this means Chromium uses subprocesses to perform tasks to prevent a browser tab from freezing the entire application, to prevent one tab from using exploits to read another tab's memory and other security and performance-related issues.
In part because of the use of subprocesses Chromium uses a lot more memory. Steam for instance uses around 470 MB of memory when running idle in the background. Discord uses 315 MB. It's possible for Chromium to use more memory then the rest of the game combined.
Chromium renders frames on its own, out of sync with the application. It's possible for Chromium to render more frames than your application needs, but also less, and probably lagging behind which can be a problem in a real-time environment like a game.
Additionally since pages are handled by subprocesses exposing Javascript APIs to UI logic isn't as cheap as it is with toolkits like RmlUi and Panorama. Half-Life's UI code accesses game state and in some cases modifies it as well which is complicated by the need to also communicate with the main game process.
GoldSource uses CEF1, an older single-process version of Chromium to render the HTML-based message of the day in Counter-Strike and Day of Defeat. It's been out of support for 10 years and can't even display the official Counter-Strike website due to a lack of support for modern secure connection technology. This integration is limited to rendering frames for display in VGUI2; it can't allow interaction between a website's Javascript and the game itself.
There aren't many cases of games using Chromium for their in-game UI. Here are some articles and discussions that covers the subject in more detail:
A couple mod teams have attempted to integrate Chromium into mods before (GoldSource and Source) but it has always led to failure due to the problems listed above and overall technical challenges involved with such a complex framework. If you really want to use it, you'd better prove it can be done properly first.
Based on my findings i'd say trying to integrate a new UI toolkit is a waste of time unless you can guarantee these things:
1. You can replicate the UI in HTML exactly as in the original without performance issues
2. The toolkit of choice can be integrated into a mod and works properly on Windows and Linux and when using the OpenGL and Software renderers (Software mode support can be dropped if needed, but for the Unified SDK in particular it's not an option without a major version change)
3. The implementation runs well in general and on older systems in particular. Given that Steam is dropping support for older platforms due to CEF as well this isn't a major challenge but Half-Life players tend to use older systems
This just about wraps up all work for V1.0.0. Everything that can be done in a reasonable timeframe has been done, all major issues have been dealt with and the last full test shows the games are working as expected. Once the remaining work listed above has been completed all projects are ready for a V1.0.0 release.
However, the full release of V1.0.0 will have to wait until after Valve has finished what they're working on to avoid having to release a patch in case there are any problems. People have noticed activity in a new password-protected branch that indicates the games are being updated with better controller and Steam Deck support.
No details are available so to avoid potential problems V1.0.0's full release has been delayed until these changes have been released by Valve. Given that controller support is implemented in the client dll which is part of the SDK this will likely mean mods will have to update to get the same changes.
That's probably meant to release on the 25th anniversary which is a week from now, so it shouldn't be a very long delay.
Once all of that stuff is sorted out all three of the Updated projects and the Unified SDK will be part of the twhl-community Github organization and will be maintained by the community.
The map decompiler will also be moved over after i've double-checked all of its features and the text color bug in Avalonia has been fixed.
Half-Life Asset Manager V2.0.0 will also receive a full release shortly once all of the above has been dealt with after which i will begin working on V3.0.0 which aims to replace the graphics code with modern OpenGL and to hopefully provide a fully functional Linux version.
I'd like to thank everybody for helping to develop and test these projects and hopefully they'll be fully released soon for everybody to try out and play with!
A new UI
I've looked into integrating RmlUi to determine which challenges are ahead in that area. I've experimented with replicating the look of the HUD in HTML, but so far i haven't been able to reproduce the exact method used which involves using a grayscale image colored with a specific value and whose alpha value is affected by the saturation of the color.All of my findings are included in the Github issue: https://github.com/SamVanheer/halflife-unified-sdk/issues/453
If there is a way to replicate the HUD's exact appearance in HTML then it probably won't work in RmlUi since it will likely depend on CSS features that RmlUi doesn't (yet) implement.
Until it's possible to render the HUD in RmlUi it isn't worth trying to integrate it into a mod.
I've also done some investigation work into how modern engines handle UIs to see if any of them provide their UI toolkits as standalone options that can be integrated into an engine this old.
My findings are as follows (not an exhaustive list):
- Unreal engine: Uses Unreal Motion Graphics, a tightly integrated toolkit that depends on other Unreal features like blueprints to function.
- Unity engine: Uses UGUI, a GameObject-based toolkit. Totally dependent on the engine to function and written in C#.
- Godot engine: Uses Godot UI, a tightly integrated toolkit that builds on Godot's class hierarchy.
- Source and Source 2 engines: Use Panorama, a tightly integrated toolkit that uses a web-like development stack using XML, CSS and Javascript. It integrates with the engine to allow features like particle systems and model rendering to be embedded in the UI itself. Panorama's XML is not strictly HTML; it's very similar but is an evolved form of VGUI (it uses `Panel`s just like all VGUI versions).
This integration allows engine functionality to be used in the UI but precludes integration into other engines. None of these toolkits are available for standalone use, and even if they were they all use modern graphics APIs which makes integration even harder.
All of these toolkits are optimized for use in games, which means they update and render once a frame.
Another alternative is Chromium Embedded Framework 3 (CEF3), used to implement the UI in various desktop applications like Steam, Discord and Visual Studio Code (using Electron, a desktop application framework built on top of Chromium).
Chromium is designed to power web browsers; its architecture is designed around this use case. In practical terms this means Chromium uses subprocesses to perform tasks to prevent a browser tab from freezing the entire application, to prevent one tab from using exploits to read another tab's memory and other security and performance-related issues.
In part because of the use of subprocesses Chromium uses a lot more memory. Steam for instance uses around 470 MB of memory when running idle in the background. Discord uses 315 MB. It's possible for Chromium to use more memory then the rest of the game combined.
Chromium renders frames on its own, out of sync with the application. It's possible for Chromium to render more frames than your application needs, but also less, and probably lagging behind which can be a problem in a real-time environment like a game.
Additionally since pages are handled by subprocesses exposing Javascript APIs to UI logic isn't as cheap as it is with toolkits like RmlUi and Panorama. Half-Life's UI code accesses game state and in some cases modifies it as well which is complicated by the need to also communicate with the main game process.
GoldSource uses CEF1, an older single-process version of Chromium to render the HTML-based message of the day in Counter-Strike and Day of Defeat. It's been out of support for 10 years and can't even display the official Counter-Strike website due to a lack of support for modern secure connection technology. This integration is limited to rendering frames for display in VGUI2; it can't allow interaction between a website's Javascript and the game itself.
There aren't many cases of games using Chromium for their in-game UI. Here are some articles and discussions that covers the subject in more detail:
- https://coherent-labs.com/posts/what-developers-should-consider-when-using-chromium-embedded-framework-cef-in-their-games/ (biased since the authors have their own HTML toolkit, no longer in development)
- https://www.guildwars2.com/en/news/inside-arenanet-chromium-embedded-framework-in-guild-wars-2/ (replacing the above CoherentUI toolkit with CEF to provide in-game website rendering, not general UI development)
- https://github.com/libgdx/libgdx/issues/7088
- https://old.reddit.com/r/gamedev/comments/50j40h/htmlcss_gui_system_for_c_game_engine_openglvulkan/ (Note: EAWebKit is mentioned here; it doesn't work on Linux)
A couple mod teams have attempted to integrate Chromium into mods before (GoldSource and Source) but it has always led to failure due to the problems listed above and overall technical challenges involved with such a complex framework. If you really want to use it, you'd better prove it can be done properly first.
Based on my findings i'd say trying to integrate a new UI toolkit is a waste of time unless you can guarantee these things:
1. You can replicate the UI in HTML exactly as in the original without performance issues
2. The toolkit of choice can be integrated into a mod and works properly on Windows and Linux and when using the OpenGL and Software renderers (Software mode support can be dropped if needed, but for the Unified SDK in particular it's not an option without a major version change)
3. The implementation runs well in general and on older systems in particular. Given that Steam is dropping support for older platforms due to CEF as well this isn't a major challenge but Half-Life players tend to use older systems
Remaining work to be done
- MIT license all community-written Updated & Unified SDK code
- Move projects to twhl-community organization
- Add any required documentation on development process that is currently missing
This just about wraps up all work for V1.0.0. Everything that can be done in a reasonable timeframe has been done, all major issues have been dealt with and the last full test shows the games are working as expected. Once the remaining work listed above has been completed all projects are ready for a V1.0.0 release.
However, the full release of V1.0.0 will have to wait until after Valve has finished what they're working on to avoid having to release a patch in case there are any problems. People have noticed activity in a new password-protected branch that indicates the games are being updated with better controller and Steam Deck support.
No details are available so to avoid potential problems V1.0.0's full release has been delayed until these changes have been released by Valve. Given that controller support is implemented in the client dll which is part of the SDK this will likely mean mods will have to update to get the same changes.
That's probably meant to release on the 25th anniversary which is a week from now, so it shouldn't be a very long delay.
Once all of that stuff is sorted out all three of the Updated projects and the Unified SDK will be part of the twhl-community Github organization and will be maintained by the community.
The map decompiler will also be moved over after i've double-checked all of its features and the text color bug in Avalonia has been fixed.
Half-Life Asset Manager V2.0.0 will also receive a full release shortly once all of the above has been dealt with after which i will begin working on V3.0.0 which aims to replace the graphics code with modern OpenGL and to hopefully provide a fully functional Linux version.
I'd like to thank everybody for helping to develop and test these projects and hopefully they'll be fully released soon for everybody to try out and play with!
<== Continued from previous post
This game was developed on machines that ran the game at about 20-30 FPS and everything was designed around that. The engine doesn't compensate for high framerates correctly in some cases and some game code also lacks proper compensation. Some of these issues have been fixed but the game will never work properly at high framerates because the render framerate is tied to the simulation framerate.
The engine was also designed to run at a maximum of 72 FPS, as seen in Quake 1's source code: https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/WinQuake/host.c#L494-L522
GoldSource lacks this limiter but it still won't work properly. The recommended framerate is either 30 or 60 FPS. 100 FPS generally works but in specific cases like elevators there might be glitches like NPCs taking damage, dying or getting gibbed due to getting stuck. Higher framerates will be more prone to glitches.
Modern engines typically lock framerates or decouple the simulation framerate from the render framerate to avoid these issues, unfortunately this can't be fixed in a mod without re-implementing the entire physics engine.
This was caused by an engine function that was re-implemented in game code to allow for better optimizations.
The faulty code looked like this:
Casting to int and then back to float causes the value to be rounded. The exact behavior is compiler-specific, in Microsoft's case this is equivalent to calling
Without the cast no rounding is performed and yaw angles will be slightly off, in some edge cases like those mentioned above this can cause NPCs to get stuck.
Finding the cause of this is 99% finding a reproducible case of the problem happening. The
Once that was found it was a simple matter of using version control to pinpoint which change introduced the problem and then finding the exact line of code. Comparing against the engine's version showed the missing cast.
This bug highlights the importance of being precise when recreating existing functionality, as well as making good use of version control. Without version control finding the cause would've been a lot harder.
This command is mainly intended to be used to automate generation of node graphs but it can be used to gather error logs for each maps as well, or to automate testing of scripting systems using map-specific scripts if your mod has that.
A related command called
Progress on the Unified SDK
Release candidate 3 is now available: https://github.com/SamVanheer/halflife-unified-sdk/releases/tag/UNIFIED-V1.0.0-RC003SDK Changes
- Reworked tripmine entities to use separate world model
- Don't allow executing sv_addbot with no parameters
- Added
ITEM_FLAG_SELECTONEMPTYflag to weapons that regenerate ammo to always be selectable and never show as red in hud history - Truncate yaw using cast to int instead of floor to match engine behavior (fixes NPC navigation in some maps)
- Fixed
ambient_musicnot being triggerable in radius mode - Added keyvalues to set barney & otis corpse bodygroups
- Fixed code analysis warnings when combining format result with string_view in ternary
- Speed up
sv_load_all_maps, automatically load first map & print more info, more consistent and robust behavior and addedstop_loading_all_mapscommand to stop this process - Build portable binaries and workaround gcc bug to allow the Linux version to run on architectures that are missing the C++ runtime version used by the game and to avoid problems with
std::regex - Additional fix for op4loader sound looping bug to stop looping when the NPC is removed
- Boosted volume to match original engine by multiplying by **8**
C# Changes
- Adjusted
MaxRange(far Z clipping plane) inc2a2ato fix graphical issues - Fixed Alien Slaves in
ba_canal1waiting for 5 seconds before attacking - Added upgrades to fix issues with barney, otis & scientists in specific levels (skin color & equipped weapons and items)
- Don't delete node graphs, update timestamps instead so graphs will be loaded from disk
- Updated third party dependencies and updated BSPToObj to account for changes in the vertex order used by Sledge library
- Add upgrade for
bell1.wavsound and pitch so the bell sound sounds like it does in the original game
Asset Changes
- Added separate tripmine world model
- Added scientist_cower models
- Reverted changes made to viewmodel animations to match the original games
- Updated test maps to account for code changes
- Fixed HEV suit sentences playing in Opposing Force and Blue Shift
- Changed event id for sounds played by scientists that shouldn't affect the mouth so scientists don't "talk" when a beep sound plays
- Add polygons to loader accordion spine
- Added
hlu_technology_demonstrationmap (unfinished, only contains a zoo of various NPCs and NPC models at this time)
Framerate issues in the GoldSource engine
Some people have reported issues that occur when playing at high framerates (100+ FPS) or when using cvars likehost_framerate to manipulate the framerate to run very high.This game was developed on machines that ran the game at about 20-30 FPS and everything was designed around that. The engine doesn't compensate for high framerates correctly in some cases and some game code also lacks proper compensation. Some of these issues have been fixed but the game will never work properly at high framerates because the render framerate is tied to the simulation framerate.
The engine was also designed to run at a maximum of 72 FPS, as seen in Quake 1's source code: https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/WinQuake/host.c#L494-L522
GoldSource lacks this limiter but it still won't work properly. The recommended framerate is either 30 or 60 FPS. 100 FPS generally works but in specific cases like elevators there might be glitches like NPCs taking damage, dying or getting gibbed due to getting stuck. Higher framerates will be more prone to glitches.
Modern engines typically lock framerates or decouple the simulation framerate from the render framerate to avoid these issues, unfortunately this can't be fixed in a mod without re-implementing the entire physics engine.
NPC navigation issues
Users reported NPCs having problems navigating in specific areas. Known occurences includeWe've Got Hostiles in the area after the first elevator and a soft-lock that sometimes occurs in Lambda Core level A, where the scientist holding the shotgun fails to move to the button to open the door.This was caused by an engine function that was re-implemented in game code to allow for better optimizations.
The faulty code looked like this:
float VectorToYaw(const Vector& forward)
{
if (forward[1] == 0 && forward[0] == 0)
{
return 0;
}
float yaw = atan2(forward[1], forward[0]) * 180 / PI;
if (yaw < 0)
{
yaw += 360;
}
return yaw;
}float VectorToYaw(const Vector& forward)
{
if (forward[1] == 0 && forward[0] == 0)
{
return 0;
}
float yaw = static_cast<int>(atan2(forward[1], forward[0]) * 180 / PI);
if (yaw < 0)
{
yaw += 360;
}
return yaw;
}Casting to int and then back to float causes the value to be rounded. The exact behavior is compiler-specific, in Microsoft's case this is equivalent to calling
std::round: https://learn.microsoft.com/en-us/cpp/c-language/conversions-from-floating-point-types?view=msvc-170Without the cast no rounding is performed and yaw angles will be slightly off, in some edge cases like those mentioned above this can cause NPCs to get stuck.
Finding the cause of this is 99% finding a reproducible case of the problem happening. The
Lambda Core occurrence didn't always happen, but the We've Got Hostiles one did.Once that was found it was a simple matter of using version control to pinpoint which change introduced the problem and then finding the exact line of code. Comparing against the engine's version showed the missing cast.
This bug highlights the importance of being precise when recreating existing functionality, as well as making good use of version control. Without version control finding the cause would've been a lot harder.
sv_load_all_maps command
Thesv_load_all_maps command has been modified a bit to deal with an engine bug that causes the game to crash or shutdown partway through loading all maps.This command is mainly intended to be used to automate generation of node graphs but it can be used to gather error logs for each maps as well, or to automate testing of scripting systems using map-specific scripts if your mod has that.
A related command called
sv_stop_loading_all_maps has been added to stop this process if necessary.
Node graphs
Node graphs are now bundled with mod installations instead of requiring them to be generated when a map is first loaded. This should make the first-time experience a lot smoother.New repositories in the TWHL Community Github organization
A few new repositories have been added:- HalfLifeSDKHistory: Contains each Half-Life 1 SDK release's source code as individual commits to allow viewing changes made in each update. There are also branches for the multiplayer version (lacks AI code) and a branch showing the difference between the singleplayer and multiplayer versions
- OldValveReleases: Contains modding files released by Valve, mostly old SDKs
- SlackillerDownloads: Contains files hosted on the old Slackiller modding website
- VHLT-V34: Contains the source code for VHLT V34 along with branches that remove disabled code paths for easier viewing. Also includes a copy of the VHLT V34 tools for completeness sake