Forum posts

That's defined here:
Server only code:
https://github.com/ValveSoftware/halflife/blob/master/dlls/player.cpp#L2911

Shared physics code:
https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/pm_shared/pm_shared.c#L1952
https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/pm_shared/pm_shared.c#L2021

Standing to ducking transition code: https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/pm_shared/pm_shared.c#L2045

When the player is dead it's changed to be on the ground:
Server only code: https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/dlls/player.cpp#L1409
https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/dlls/player.cpp#L1456

Shared physics code: https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/pm_shared/pm_shared.c#L2892

The constant is defined here for server code: https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/dlls/util.h#L420

Physics code:
https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/pm_shared/pm_shared.c#L86
https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/pm_shared/pm_shared.c#L79
https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/pm_shared/pm_shared.c#L80

Note that the server only constant is used by other code as well, so don't change the constant itself, just define a new one.

As usual it's defined twice, you can rework it if you want.

If you're using the Github SDK, that's projects/vs2010/projects.sln.

Get Visual Studio 2017 Community, Sourcetree (Git user interface) and the source code from Valve's Github.

Visual Studio 2017: https://www.visualstudio.com/downloads/
Sourcetree: https://www.sourcetreeapp.com/
Source code: https://github.com/ValveSoftware/halflife

This documentation explains where to get the address used to clone Git repositories: https://help.github.com/articles/which-remote-url-should-i-use/

Here's a Sourcetree tutorial: https://confluence.atlassian.com/sourcetreekb/clone-a-repository-into-sourcetree-780870050.html

Take the HTTPS URL from Valve's Half-Life repository and clone it using Sourcetree, then you can open the project file projects.lsn located in "projects/vs2010". This contains the client and server libraries for Half-Life, Ricochet and DeathMatch Classic. You may remove the latter 2 if you don't want them.

After that it's basically the same as any other C++ project, but you should make sure you understand the basics of the language first, then read tutorials about Half-Life programming.

Here's a good C++ tutorial: http://www.cplusplus.com/doc/tutorial/

Here are some Half-Life tutorials: http://twhl.info/tutorial.php?cat=1

This looks like a lot of work, so take it slow and one at a time. Get Visual Studio installed and follow tutorials for C++ first so you understand it.

You will likely have issues with it, everybody does at first. It's not an easy language to learn but the most important thing is to keep at it. If you don't understand something, just ask.

If you need help with C++ in particular you can ask for help here: https://www.reddit.com/r/cpp_questions/
https://stackoverflow.com/

If you don't have much experience using Google you should try to use it to find answers first. Prefix your searches with "C++" to narrow it down.

Unfortunately there is no easier way to mod Half-Life. Some of us are working to make things easier. What you're trying to do should be possible with HLEnhanced eventually, but it's not ready yet.

If you don't want to learn how to program or can't, one of us can provide you with the necessary changes. It doesn't sound like a lot of work, but i do recommend learning to program if you want to do more advanced modding later on.

Looks like that system is even more complicated, existing code still uses materials.txt as in the SDK, but the client uses this new material system for effects like bullet impacts and the like.

I found Tool Box Lux RAD here: https://gamebanana.com/tools/5591
Gen Surf here: https://gamebanana.com/tools/5589

The website for Radiant is here: http://radiant.robotrenegade.com/
The website for QuArK is here: http://quark.sourceforge.net/infobase/index.html

FGD files i'll need more specific info on, afaik the latest fgds are still around and support Hammer 3.5 era features.

I'll get mirrors for these tools up later on.

It may be useful to make a new version of Tool Box Lux RAD that's integrated with a set of tools that can work on GoldSource as a whole, like the Source SDK lists all the tools.

Since rad file editing is so straightforward it may be easier to have one main tool that has the utility stuff built into it. I've thought of doing that before, so it may be useful.

Do you mean things like this: http://web.archive.org/web/20010308202415/http://www.vlatitude.com:80/resources.php

That might still be recoverable.

I've made a website that hosts backups of old Half-Life tools. Most of this is from Slackiller and a Gamefront mirror, but i'll add more stuff as needed. All files are hosted on Github.

https://samvanheer.github.io/Half-Life-Tools-Backup/

Credits to Shepard for making the HLEnhanced website, which i've used as a base for this.

Currently hosted are the Slackiller HL Programs page and all the Half-Life SDKs that i could find.

This includes SDKs 1.0, 2.0, 2.1, 2.2 and 2.3, including separate releases of files.

An interesting thing to note is that the early SDK releases required the signing of an NDA prior to allowing the creation of a mod. Mods also had to be hosted on an FTP server in order to be made visible to the Custom Game browser.

I'm currently going through the list of utilities on the Gamefront mirror (https://gamefront.online/files/listing/pub2/Half_Life/Tools_and_Utilities) to mirror anything useful.

I also took the various SDK source codes and made branches that show the evolution of the multiplayer and single player codebases:
Multiplayer codebase: https://github.com/SamVanheer/Half-Life-Tools-Backup/commits/hl1_src_mp
Singleplayer codebase: https://github.com/SamVanheer/Half-Life-Tools-Backup/commits/hl1_src_sp
Difference between the multiplayer and singleplayer codebases in 2.3: https://github.com/SamVanheer/Half-Life-Tools-Backup/commits/hl1_src_2.3_diff

I didn't catch most of the file removals (if any), just the removal of the "dedicated" directory in 2.4 (Github release).

The file you're looking for is sound/materials.txt, it assigns materials to each texture. The file contains an explanation as to how it works.

Codewise you need to consider a few things:
https://github.com/ValveSoftware/halflife/blob/master/pm_shared/pm_shared.c#L191
https://github.com/ValveSoftware/halflife/blob/master/dlls/sound.cpp#L1539

The same code is in 2 places, the former is used by physics code on both the client and server side, the latter is only used on the server side to handle things like crowbar hitting a wooden box sort of thing.

Adding new materials is a bit clunky, bear with me:
First you need to define a constant used to identify it, that's done in 2 places:
https://github.com/ValveSoftware/halflife/blob/master/pm_shared/pm_materials.h#L21
https://github.com/ValveSoftware/halflife/blob/master/pm_shared/pm_shared.c#L92

You also need to define a constant that this first one gets converted to so it can be used more easily:
https://github.com/ValveSoftware/halflife/blob/master/pm_shared/pm_shared.c#L104

Converted in this function:
https://github.com/ValveSoftware/halflife/blob/master/pm_shared/pm_shared.c#L441

Now you need to handle the actual sound playback. This time it's in 3 places:
https://github.com/ValveSoftware/halflife/blob/master/pm_shared/pm_shared.c#L322
https://github.com/ValveSoftware/halflife/blob/master/dlls/sound.cpp#L1687
https://github.com/ValveSoftware/halflife/blob/master/cl_dll/ev_hldm.cpp#L156

All are identical but use different ways to do it due to different engine interfaces.

Yes, it sucks, it should be easier, but this is GoldSource.

If you need help i can quickly clean this up and make it use a single definition for everything, and bypass the hardcoded limits too if you need it.

Oh no, own goal!

https://github.com/ValveSoftware/halflife/blob/master/cl_dll/hud_spectator.h
https://github.com/ValveSoftware/halflife/blob/master/cl_dll/hud_spectator.cpp

You'll need to rework it so it renders when you're alive, that's this code: https://github.com/ValveSoftware/halflife/blob/master/cl_dll/hud_spectator.cpp#L610

g_iUser1 is taken from the server's pev->iuser1 for the player.

BOOL CTrolley::CheckMeleeAttack1( float flDot, float flDist )
{
// ALERT(at_aiconsole, "CheckMelee(%f, %f)\n", flDot, flDist);

if (flDot >= 0.7)
{
if (flDist <= 50)
return TRUE;
}
return FALSE;
}

Anything within 50 units and in front of the trolley gets ammo every time it attacks. The conditions for attacks is based on how much ammo they've got, however you return R_AL in IRelationship if they have enough ammo, which can cause the AI to still consider it. Return R_NO instead, see if that changes anything.

Also, your conditions aren't correct, if the player has exactly 100 ammo it relies on default relationship settings. Change the

if ( pTarget->ammo_9mm > 100 )

to

if ( pTarget->ammo_9mm >= 100 )

I'm assuming your code correctly updates ammo_9mm, which is SDK behavior. If it does not, you should correct that.

Then you should try setting fixangle to 1 right after that, it should tell the engine to set exactly that angle.

Why are you using the WON version? Most mods were made with the Steam version in mind, so they may have surpassed the limits of the older engine build.

Yeah, the QC file should tell us what's up. Make sure to list which animations are used.

Which animation has the event, and when is it used, as in which act is it associated with? ACT_MELEE_ATTACK1/2 or something else? It might be triggering for all players at all times, so the act itself may need changing.

Replace CBasePlayer with CBaseEntity, it'll work.
Try using m_hEnemy != NULL instead of just m_hEnemy, so:

if( m_hEnemy != NULL && m_hEnemy->IsPlayer() )

How are you setting the angles on the server side? You need to use pev->fixangle to force the engine to set a particular angle, and both pev->angles and pev->v_angle need to be set to be correct.

CTrolley is a monster, and i'm assuming TROLL_AE_ATTACK_RIGHT is an event in an animation triggered as a melee attack on a player.

This means that m_hEnemy (https://github.com/ValveSoftware/halflife/blob/master/dlls/basemonster.h#L40) is the player. Use that member variable to give ammo to the correct player, in other words GiveAmmo should look like this:

int CTrolley :: GiveAmmo( CBasePlayer* pPlayer, int iCount, char *szName, int iMax )
{
if (pPlayer->ammo_9mm <= 100)//limite de munición para que te recargue

{
pPlayer->GiveAmmo(600,"9mm",600);
return TRUE;

}

return FALSE;
}

And HandleAnimEvent should do this:

if( m_hEnemy && m_hEnemy->IsPlayer() )
{
CBasePlayer* pPlayer = static_cast<CBasePlayer*>( static_cast<CBaseEntity*>( m_hEnemy ) );
GiveAmmo( pPlayer, 600,"9mm",600 );
}

I should note that GiveAmmo ignores the values you're giving it and is always giving those amounts, so make sure you update it to use the input values if you want that to work correctly.

You need to show the code that calls GiveAmmo, also this should only ever give ammo to the player with the lowest entity index, regardless of distance.

Just tell us which version you're using and what kind of errors you're getting. This isn't helping.

Wally can edit palettes: http://www.slackiller.com/hlprograms/wally_155b.exe

Sidenote: somebody really needs to back up slackiller's site before it goes down, that stuff is getting hard to find.

If studiohdr_t::textureindex is 0 then the textures were loaded from a T.mdl, which is apparently stored in model_t::texinfo.

This is an mtexinfo_t pointer, but actually stores a model_t*, and contains the texture data. You need to call Mod_Extradata on this model to get the studiohdr_t* that contains the texture data.

Unfortunately, it seems that Mod_LoadStudioModel doesn't save the actual texture data.
It only copies the model data up to where the texture data starts (texturedataindex is a byte offset into the file, effectively the size of the file up until the texture data), so even if you do get the texture header it'll still crash if you try to use it.

You'll have to manually load the file again if you want the texture data.

Which version are you using? Like VS 2015 Community, or VS 2015 Enterprise, etc. The community edition should never expire.

What exactly are you having trouble with when getting Visual Studio to work?

IIRC you need to use multiple scripted sequences, and play around with the idle and action animations so that it loops the animation you want until you trigger the script you want to play.

That's because of social media and modern tv/web only showing people when they're successful, not when they fail.

The CPU's gonna be doing a lot more soon: https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

Yes, shaders rely on what is referred to as shader programs, which are comprised out of multiple shaders (vertex, fragment, compute shaders to name a few examples).
Overall it's called retained mode, as opposed to immediate mode. (retain state from before, like model data as opposed to uploading it every frame).

Shaders can be used on embedded systems (OpenGL ES), but it's not exclusive to that, you can use it anywhere that the OS provides support for it, usually through drivers provided by GPU manufacturers.

That's not a glitch it's just another teleporter meant to take you into the chessboard realm.

I've had similar things happen in Hammer, it would leave behind the other entity with an infinitely large brush when i merge 2 entities.

Counter-Map is a good resource for CS specific stuff: http://countermap2.com/

I think that may be a mirror though.

He didn't even mention C#...

That can happen what you're using entities that can spawn other entities, like respawning weapons, monstermakers, multi_managers with the multithreaded flag set, etc.

Also, please try to use the edit button instead of double posting.

If your map is already pushing the limit then it will definitely go above the limit when people start playing it. Every player is an entity, every weapon they pick up is another entity, etc.
The game also changes behavior when the number of entities gets too low, so item spawning logic will be different.

Multiplayer maps made for vanilla games probably shouldn't be too heavy on the number of entities for that reason.

I wouldn't try to go for a specific maximum because new entities can still be created while playing. Just use 2048, it's the maximum and it won't make any real difference.
Remember, this engine is 19 years old, even at its worst it won't really tax modern computers.

Check this: https://steamcommunity.com/app/70/discussions/0/864975399699995140/

You may need to specify some additional options.

Well that was the plan to begin with, i am going to make some breaking changes so any maps you're making will stop working once that's done.
The tool i spoke of before to update existing maps should be enough to fix this, assuming i can get the various file format specs to implement it.

I got the files, but i haven't downloaded them yet. I'm currently taking care of some college work first, then i'll have time to work on mod stuff.

Be careful when turning complex brushwork into func_pushable, the physics in this game is pretty simple and won't work that well with it, it'll clip through walls and other objects.

IIRC You can sort of cheat by using 1 unit high clip brushes on the ground to fit to the physics mesh for the object, it'll visually bump into objects when you do that.

I noticed that somebody posted part of the RMF file format spec on the VDC (https://developer.valvesoftware.com/wiki/Rich_Map_Format), so i checked to see if Sledge supports it too.

Apparently you figured it out quite well, with a few unknowns though: https://github.com/LogicAndTrick/sledge/blob/feature/simplification-project/Sledge.Providers/Map/RMF22.txt

I did a little digging and found that the unknown field in the RMF format is the camera tool version number.

I have to support RMF operations myself at some point when i get to work on a tool to update map data, so it's nice to see that somebody already figured it out.

It looks like you can find the rest of the unknown fields in the Source 2003 leak, but i suppose that'd be illegal.