Forum posts

Hi and welcome to TWHL! It's nice to see someone with passion for learning to mod HL 🙂

Textures, whether for models or for maps, are very similar in requirements and how they're made. You can follow The303's map texture guide here.
For the image editor I can recommend Gimp. Alternatively there's also Paint.net, and for the final conversion to 8BPP BMP (AKA 256 colours indexed BMP) I recommend IrfanView as it does a really great job at preserving the colour quality. All three are free.

As for why the image loses quality when converting to 8BPP it's simply because you're reducing the amount of colour values that exists in the image, typically from 16,777,216 different colour values (24bit RGB) to only 256 colours!

For model viewers, these days it's recommended to use HLAM as it's far more up-to-date and have a lot of nice features.

Ah, I see. Thanks for the update, Solokiller!

Could you take a screenshot of your door's keyvalues with SmartEdit disabled?

Please post your solution, so that others that stumble upon this thread may learn from it. 🙂

I haven't messed around with GMod in quite some years, but could you give some more details?

When loading fails, is that only happening on a particular map?
And when you say loading works from a different map, is that any other map, or a specific map?

You can use a multisource as a logic AND gate (i.e. all inputs must be ON at the same time).

Make sure it's only your two trigger_multiple entities that are targetting the multisource.

That's not a bug but instead a common level design error known as a Leak. It means that the level isn't properly sealed (all entities must be contained within world geometry).

This guide can help you fixing those leaks.

"model 0" is the worldspawn model, i.e. all world brushes (including func_detail).
The coordinates you get is the lower bounds (-X, -Y, -Z) and upper bounds (X, Y, Z) and the problem brush is within that box.
If it's hard to visualise this bounding box, you could make a box brush with those bounds, or use the Cordon Tool to limit the map to those bounds, and look if there's any misshapen brushes in there (either world brush or func_detail).

Hm, at a first glace it looks fine to me. Nothing that seems out of place and it doesn't seem like there's any direct contact, geometric or trigger-wise, between the trigger_hurt and the trigger_gravity volumes.

I ended up working longer than I expected today and so I think I'll wait until tomorrow to set up a DoD config and compile and test this myself, sorry.
If you want to, you could compile it yourself with -chart argument on the compile tools and check for warnings and any limits being reached, and run the map with developer 2 and check for any console messages when the trigger_hurt is triggered.

If you want, you could upload your map in the vault and link it here and I can take a look at it after work tomorrow.

I don't think any of your other triggers are affecting the trigger_gravity entities, as trigger_gravity cannot be toggled.

trigger_gravity doesn't define a volume of a certain gravity but instead defines a volume where a new gravity is set, and stays at this new gravity value until a different trigger_gravity is entered.
Is it possible you didn't take this behaviour into account in your map?

Hey and welcome!

Compile logs are for the most part humanly readable and will contain a lot of useful information about the compilation process.
Near the end of the log you have the message:

There was a problem compiling the map.
Check the file C:\Program Files (x86)\Steam\steamapps\common\Half-Life\valve\maps\Q3.log for the cause.

which means you had one or more problems in the map which will be described further up in the log.

The quickest way to find problems in the log is to open it in a text editor and search for "error" (serious problems preventing compilation) and then for "warning" (less serious problems that doesn't prevent compilation but can cause issues in the compiled map).
The messages you find tend to be very self-explanatory and often tell you how to fix them. In other cases when it's more unclear you can look up the error message at Tommy14's compile error page.

In your case you'll find the warning message: "Warning: === LEAK in hull 0 ==="
That means there's a leak in your map and you can use this guide to find and fix it: Tutorial: How to fix those leaks

---

As for why the map turns out fullbright when there's a leak, it's because leaks prevents VIS and RAD from running, and RAD is the compile tool that generates lightmaps. Without lightmaps, the map becomes fullbright.

It does exist in GoldSrc, it's used to halt execution of the following commands until the next frame (often used complex binds to prevent multiple commands happening on the same frame).
I don't think the GoldSrc version takes any arguments though, only ever waiting a single frame.

Hi and welcome!

First of all it sounds like you're using very old compile tools (as it doesn't automatically add CLIP to the sky), I highly recommending switching to Vluzacn's ZHLT v34.

Secondly to make invisible walls and such it's better to use CLIP texture. It creates a collision mesh in the shape of the brush it's applied to.

As for the reason why the {invisible texture didn't turn invisible, it's because the brush covered in it must be tied to a solid entity such as func_wall with the render mode set to Solid (this render mode removes the masking colour from {-prefixed textures, most of the time this is the blue colour). In most cases it's better to use NULL texture instead (removes the face completely).

When making signs you pretty much have to do it using brushes.

A common and easy technique is to make it a thin brush and tie it to func_detail and set Passable to Yes (zhlt_noclip 1). This prevents it from both chopping the walls it's placed on, as well as generating unnecessary clipnodes the player might collide with. Another technique is to actually embed it in the wall and either use the Clipping Tool to cut out a hole for the sign:

---

or, a bit more advanced technique is a sort of mix of the two. Embed the sign in the wall as with the second technique, but instead of clipping a hole in the wall leave it as it is and tie the sign to a func_detail again. This time set the Detail level (zhlt_detaillevel) to 1 and the Priority when faces overlap (zhlt_coplanarpriority) to 1 as well.

It will do a lot of Z-fighting in the editor (flickering) but in-game it's the sign that will be visible without any Z-fighting (because of the zhlt_coplanarpriority keyvalue).

The problem has nothing to do with the compilers (you'll likely find the infodecal entities in the entity lump of the compiled BSP).

What is actually happening here is that decals only work with the special textures from the game/mod's decals.wad file, and you've used normal textures from halflife.wad

Seems like efs didn't post an update here so I'll do it.
The problem was the landmark. I assume that particular issue was fixed then.

I got your DM.

So you're having trouble with level changes where the player spawns at map origin in the second level.
In that case you should check that

• There is an info_landmark in both levels and named the same (without any special symbols or non-latin letters)
• Both levels have a trigger_changelevel pointing to the corresponding map of the level change (i.e. the first level pointing to the second, and the second pointing to the first). It must do this even for one-way level transitions (in this case the second level's trigger_changelevel can be placed outside the playable area to keep the player from going back).

If you haven't already, check out Tutorial: Changing Levels guide as it's very helpful for learning about level transitions.

There are plenty of people here that can help, depending on the problem/issue.

Start by telling us what problems you've been having, one at a time.
Tell us what you wanted to do, what you expected to happen, what you've tried, and what actually happened instead.

Yeah, it was around late 2010s, Discord really took off soon after its release.

Though he decline of forums have been going on for longer, alongside the growing popularity of social media platforms such as FB and Twitter. Unlike forums, these platforms are designed to bring tons of personalised content directly at the users.
Between the two, it's kind of like the choice between having a bag of candy handed to you or going to the kitchen and cook a healthy dinner. The latter has higher quality, but the former gets you instant gratification for no effort. It's no surprise which one is more popular, despite the downsides.

Sledge is an open source level editor for Goldsrc.
Unfortunately not being developed anymore, and the Tools and Resources page says "Unfinished and rather unstable - use with caution"

It's very much not dead.

Just because it's not a spammy memedump, or has as much activity as a chat platform, it doesn't mean it's dead. It's just quiet and that tends to be the case for forums in this age where forums are not as popular as they used to be (which is a shame). People are still around and reading and posting, just might take some hours or days between posts.

As far as I know Valve haven't given us an estimate yet

You're getting the "padev.wad not found" error message because you have some textures from that WAD in your map, but you don't have the WAD in your mod folder or haven't used the -wadinclude padev argument on the CSG compiler.

To make things easier, use a game configuration in your editor that only uses the standard set of HL textures (and zhlt.wad):

halflife.wad
decals.wad
liquids.wad
xeno.wad
zhlt.wad

Now if you're using JACK, in the editor hit Alt+P (or go to Map -> Check for problems) and it should list several Invalid texture ('<texture name>') errors. These cannot be fixed by the editor so you have to fix it manually:
Open the texture browser and enable the checkbox for Only used textures.
All textures with a black-purple checkerboard is an invalid texture, so click it and hit Replace... and for the replacement (right side) type in "C1A0_W1" for example.
Do this for all invalid textures until there are no more errors when you Check for problems (Alt+P).

After that, compile the map and make sure the BSP is placed in your mod's maps folder, launch your mod and start up the map.

I highly encourage keeping the valve folder free of any custom content. The valve_addon folder (enabled in Options -> Content -> Allow custom addon content), or even better your mod's directory, should be used instead.

Make sure you don't have a duplicate of your WAD in the valve folder, and make sure the one in your mod's folder is up-to-date with your changes.

As for the problem in hand, it's possible the textures in your WAD are named the same as textures from stock Half-Life WADs, such as halflife.wad.
This causes a naming conflict where (iirc) the texture of the first WAD to load will replace any subsequent textures of the same name.
If that's the case, you simply just have to rename your textures and fix the references in your map in the level editor.

The keyvalue Trempler is referring to is actually zhlt_embedlightmap 1.
Semi-transparent render modes (Texture and Additive) don't embed lightmaps by default and as such appear fullbright. The keyvalue tells the compile tools (VHLT and derivative) to do it anyway, though only the compile-time lightmap will be used so it will not change with toggled lights. Here's an example from Sven Manor demonstrating the effect.

Just to add to what Alexis said:
The HL SDK does not yet contain any of the 25th Anniversary game code changes, such as implementation of func_vehicle. So if you want any of these features in your mod you will just have to wait.

As for what is there:
After downloading the HL SDK from your Steam Library and pressing Launch it will open up Hammer, the level editor. This is only a small part of the tools and content the SDK provides which you can easily access by right-clicking the shortcut in your Steam Library, and go to Manage -> Browse local files.

In the main directory you will find various documents about HL modding, and several sub-directories.
Most of the tools sub-directories contain very outdated tools which you can find more updated replacements for in the Tools and Resources page.
Models sub-directories will have source files for many different models, while Prop Models is a library of lots of decorative models you can use for your maps.
The Texture Wad Files directory has the standard set of WAD files that comes shipped with Half-Life.

---

If you're interested in the game code, you can look at the Github repository Alexis linked or you could head on over to the Half-Life Programming - Getting Started guide.

func_wall_toggle will alternate between two states when triggered:

• Solid and visible
• Non-solid and invisible

You can make it always be invisible by using NULL texture.

I also recommend experimenting with these entities on your own. Testing, trying and failing are the best ways to learn. 🙂

Both I and Archie linked to the Entity Guide page for the entity, but basically it's a brush entity that toggles between a solid visible state and a non-solid invisible state.
Essentially triggering it makes it disappear from the game, and triggering it again makes it re-appear.

Or instead of a func_door, an invisible (for example using {invisible texture and Render Mode set to Solid) func_wall_toggle can work to keep the zombie and scientist from "seeing" each other until it's triggered.

That's the problem though. We don't know exactly what Combined wants because he hasn't described that yet. Just wait for him to elaborate.

What do you mean by "static"? If you want it to idle in place and not attack nearby scientists, you could set the Prisoner (16) flag.

Using the model key (or zhlt_usemodel targetting an env_sprite using the model for example) you can set most brush entities to use a model instead (remember to give them an ORIGIN brush where you want the model's origin to be), but that'll replace the entire brush model including the cliphulls resulting in it having no collisions as kimilil says.
(Also if using model you need to make sure the model is already precached in the map somewhere otherwise it'll crash).

Using game code would be the better way to go. That it's not already in the SDK doesn't mean it cannot be done.

You could implement a sort of "attach model" key directly in func_pushable for your mod that places a model at the origin and updating its position within the pushable's Move() method, or even more useful would be implementing an entity that can "parent" one entity to another so they move together, like trigger_setorigin in Sven Co-Op or the movewith (iirc) feature in Spirit of Half-Life.
It's possible the Featureful SDK already has some entity parenting feature that you could use, so that's worth checking out.

awkook's method is better done just using an invisible func_breakable (e.g. covered entirely in NULL texture), or completely replaced by a gibshooter, as it's only there to spawn gibs.

Either way, for the first step you'll use the func_train as both UrbaNebula and awkook already suggested (for how to use it, check the entity guide page UrbaNebula already linked). This will make a brush that moves any path you define for it (such as straight down in your case) and rest at the end.
If this is all you need, then no more is needed to be done.

---

Any step after that is for creating any secondary effects, for example the brush breaking into pieces when it hits the scientist (this is what awkook was explaining). If you wish to do this, there's at least 3 ways to trigger the effects:

1. Timed from when the brush starts falling
2. Using the Fire On Pass (message) key of a carefully placed path_corner
3. Have the scientist trigger it using its Take Damage TriggerCondition

For the effects themselves, as I said earlier you could use an invisible func_breakable or a gibshooter to spawn whatever gibs you want (even from the ceiling where the brush starts falling from, to simulate it breaking from/through there). An env_render targetting the brush can be used to turn it invisible, or a trigger_relay can KillTarget it to remove it from the game, if you want your brush to "break" on collision. It's up to you to find out exactly what you want to happen and when.

1 Timed:

When you trigger the brush to start falling, have a delayed trigger for your effects. You can calculate this by measuring the distance between the brush' start position and its position when it collides with the scientist (for example 100 units). If you made it fall with a speed of 800 units/second, then the delay should be distance / speed = time. In this example, 100 / 800 = 0.125 seconds.

2 Fire On Pass:

path_corner has a Fire On Pass key that can be used to trigger something when a func_train, well, passes it. Just place it where the geometric center of the train would be when it collides with the scientist.

3 TriggerCondition:

If the scientist is never going to be hurt in any other way, you can use it's TriggerTarget key set to trigger the effects and TriggerCondition set to Take Damage (2) and it'll trigger the effects once the train starts hurting it.

Basically you'll want two light entities:

• One for the initial light (name it for example no_flicker)
• Then the same light but with a flickering Custom Appearance and the Initially dark (1) spawnflag set (name this one flicker)

The link to the Custom Appearance page contains the patterns for the various Appearance presets, so copy one of those for your flickering light.

Then you'll want a multi_manager to toggle both lights at the same time, that way the normal light will be replaced by the flickering one. Just let your trigger target the multi_manager. It should look something like (with SmartEdit off):

You need to use Custom Appearance (pattern) instead of Appearance (style) to make a switchable flickering light

Tutorial: Retina Scanners and Other NPC-Only Locked Doors just finished writing a tutorial that explains more in detail how to do that second question

I know, which is why I started writing one a few days ago when helping someone in the Discord with the same thing

For the first: here's the entity guide page for the entity you'll use.

For a button that's only useable by a NPC, a trick is used where the button itself doesn't do anything (alternatively play a "no access" sound or sentence).

Instead a scripted_sequence is used. In a very basic setup, it uses the Search Radius key (value of roughly 100 units or so, depending on how far/near the monster needs to be before starting the sequence) and Target Monster set to the classname of the NPC you want to use (for example monster_scientist) and Move to Position set to Walk and Action Animation set to the sequence you want it to play (such as retina for monster_scientist).
Then you'll want the scripted_sequence's target to be whatever you want to be triggered when successfully unlocked by the NPC.

Of course it can be made more complicated by chaining multiple scripted_sequences or having the target of the unlocking sequence be a multi_manager that controls a chain of events to take place.

Any tutorial for editing textures should be helpful, whether it's for map or model doesn't matter, it's the same format either way: 8BPP BMP with dimensions that are multiples of 16 up to 512x512.
The wiki and The303's guide should be plenty helpful for that.

For the actual recolouring you'll have to export the texture you want to edit using a model viewer like Solokiller's Half-Life Asset Manager and opening each weapon's viewmodel. Then you have to change the colour mode in your editor to RGB or similar (in GIMP it's Image -> Mode -> RGB) and then you're able to modify the colours freely without being limited to the palette. You can either use a tool to shift the hues (such as GIMP's Hue-Saturation) or paint the colour on a separate layer above with a colour/hue/etc blend mode. There are many ways one could go about this and looking up guides in a search engine for "<editor> recoloring" or something like that can be helpful if you've never done that before.

Afterwards just follow any guide to convert back to 8BPP BMP and use HLAM again to import the texture back to each viewmodel.

The Unified SDK already has item_helmet and item_armorvest in it, in src/game/server/entities/items/items.cpp.

For the toolset read this section. The project is in a different version, hence the need to follow that section to set the correct version.
Note that you have to use Visual Studio 2019 or 2022 and use the Visual Studio Installer to install the required components.

The process of adding new entities requires editing the game code, we have guide for it here.

It's a bit more complicated process than adding them to the FGD, and you will need to compile those changes into the DLLs your mod will use (the guide does a great job at walking you through this).
In your case it'd be mostly be copying or inheriting from the CItemBattery class in items.cpp.

You can also check out Solokiller's Unified SDK which has Blue Shift (which has those entities in it) merged in with it. Just be aware it's still a work-in-progress project.

Okay so, this was not an issue experienced in HLDM, but experienced while running NGHL with Parabot and only when testing a specific custom map?

A little troubleshooting trick, which also helps when asking for help with issues, is to try to isolate away as many variables as possible.

• If the issue appeared while testing a custom map, test it again on a stock map. If the issue remains, then you've isolated the map from the equation.
• Are you running any plugins/mods? Disable those any test again. Issue still there? Then it wasn't because of the plugins/mods.
• ...and so on.

This makes it easier for you to track down where and what the issue is.

Not doing this sort of variable isolation leads to making the wrong conclusions, such as saying the issue here is with HLDM, when you haven't tested without any plugins or mods or custom clients on vanilla maps.

It's very hard for anyone using NGHL who may have encountered the problem to notice your thread and help you out, as neither the title or first post mentions NGHL at all.

And yes, it is for speedrunning. So it's possible any HL speedrunning communities might be of more help regarding the client.

"If using the "Instantaneous" movement type with no "Idle Animation", the script will freeze the monster after it is teleported.

From scripted_sequence page in the Entity Guide.

Try making it a habit to read the Entity Guide page for any entities you're unfamiliar with or struggling with. The Notes section in these pages are very useful and often explain behaviour not obvious from the keyvalues.

The New Gauge client is non-vanilla and is most likely the cause of the issue.
Satchels were tested and confirmed to work in both legacy and anniversary branches of HL.

As I suggested in the other thread, have the scripted_sequence target its own targetname.

Just tested that satchels work fine in HLDM running on the anniversary edition.

So first thing first: Are you pressing alternate fire (right-click by default) to detonate the satchels? The behaviour was changed in the anniversary edition to do this.

If not that, then you'll need to provide the details you left out of your post:

• Is this running the anniversary edition or the legacy branch?
• Is this HLDM or multiplayer in a mod?
• Are you using any plugins?