Did you apply Scales? Seems like on export theres a skeleton mismatch in size. You can also verify by importing the SMD back into a new blender file and see if the skeleton is scaled differently. Your weight links seem fine as it wouldnt export if not, basically 1 bone per vertex

As for MDL viewer, HLAM is the new thing to replace Jed's:
https://github.com/SamVanheer/HalfLifeAssetManager/releases/tag/HLAM-V3.0.0

This tends to happen with MS3D too, for some reason bones will get flipped. Check this out.

I have recently been working on a BP12 for a HL mod and compiled my model to find out that the bones and animations have been messed up. I am fairly new to Blender Source Tools, so I don't know if that's the problem, or if it has to do with my modeling and rigging specifically. When exporting the SMD, it said something about weight links. All of the vertex groups' weights are set to zero, unless I'm forgetting something.
Any and all feedback is much appreciated.
: )

New release https://github.com/FreeSlave/halflife-featureful/releases/tag/featureful-2024-07-24

Changelog

Rain and snow weather effects

Added rain and snow effects similar to ones used in Counter Strike and Condition Zero, but toggleable and configurable.

Use the following entities to spawn rain and snow:

• env_rain - global or localized rain.
• env_snow - global or localized snow.
• func_rainvolume - brush entity for localized rain.
• func_snowvolume - brush entity for localized snow.

Both global rain and global snow can be present on the map.

The new demo map weather_demo has been added to the sample mod for rain and snow demonstration.

Other entities

• The special value *player is supported in most places where the *locus is supported to allow refer to the player. In singleplayer it will always find the player. In multiplayer it acts like *locus, but allow only players.
• Added Don't reset trigger counter on deactivation spawnflag for trigger_timer (can be useful when trigger number limit is set).
• Added Pass caller as activator spawnflag for trigger_relay.
• Added Ignore Hold Time spawnflag for trigger_camera.
• Added Stop by player input parameter for trigger_camera.
• Added Target when turned off parameter for trigger_camera.
• Added Calc Position as an option to calculate value from calc_position (this allows to calculate the value of one calc_position based on the other calc_position).
• Added Calc Velocity as an option to calculate value from calc_subvelocity (this allows to calculate the value of one calc_subvelocity based on other calc_ entities).

Console commands

• Now you can set the use-type sent via the fire command. Use fire on <targetname> or off <targetname> to send On and Off input. Use fire set <targetname> <value> to send the numeric input (e.g. for game_counter).
• The entities_count command now supports the argument - the classname - to report the number of entities having the specified classname.
• Add give_intentory and remove_inventory commands to give and remove player inventory items. This can be used for debugging purposes. The first argument is the item name. The second (optional) argument is the number of items of this type to give or remove.

To have textures flow naturally around curves like this, select the face on the straight brush, then hold alt and then right-click the first face on the curve. Then, select that first face, hold alt and right-click the second face along the curve. Continue this until you reach the end of the curve and the textures should line up correctly.

How to make textures on curved surface not look like garbled messes? Even if I give all the textures same surface properties they still look disjointed.

https://imgur.com/a/h-attvxN4

Such a pity you can't take him with you... (spoilers)

This is a very good example, for beginners. There's this one too, slightly more complicated.

TWHL Tower: Source is now out!
https://twhl.info/vault/view/6928

Usually tram prefabs are already set up to be tracktrains. Try find an example track train setup with both train and path tracks to study how they work as a system, then replicate with your own.

@jamie how do i get it to work? and how to make it? i already got the tram prefab tho

func_tracktrain should work

im a bit new to J.A.CK And mapping and i want to make some maps inspired by half life, and what i want in those said maps is trains! the trains at the start of half life is what i wanted

so give me some help on how to make it, please :3

Just follow the installation steps again, I don't know why there is no problem. It can now compile entities that the code can recognize, and I can interact with entities in the game.

I did see it. It tells me that I cannot execute the copy file "zs_test.remec.map".
"$bspdir/$file.$ext" is the sixth step of the usage tutorial to do this. ** Executing...
** Command: Copy File
** Parameters: e:\csproj\maps/zs_test.map E:\CSProj\maps/zs_test.remec.map

• Could not execute the command:

Copy File e:\csproj\maps/zs_test.map E:\CSProj\maps/zs_test.remec.map

• Windows gave the error message:

"操作成功完成。"

** Executing...
** Command: C:\HL\Tools\remec\remec.exe
** Parameters: ""e:\csproj\maps/zs_test.remec.map"" jack "E:\STEAM\steamapps\common\Half-Life"

[2024-07-16 20:13:27.661] [remec] [error] [src\main.cpp:132]: vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
[2024-07-16 20:13:27.665] [remec] [error] [src\main.cpp:133]: class std::invalid_argument: e:\csproj\maps/zs_test.remec.map does not exist!
[2024-07-16 20:13:27.665] [remec] [error] [src\main.cpp:134]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Ok, I think I get it. Apart from func_buyzone, there are really no more entities that can be used to separate teams at the moment, but I can use the "choke point" of level design theory to alleviate this problem.

This is what I see when I run it on a map that contains a single remec_lit_model entity, and the resulting map file contains a cycler_sprite and a func_detail. What does your compile log look like?

Thank you for reminding me, I almost only read.log files before. I can't use my personal computer right now. I will get back to you about compilation as soon as possible.

Have you tried asking the authors of Remec for help?

He's closed his page, and I can't find any more contact information. I tried to search his name on Google, but I'm not sure it was him because I didn't see the same information.

The on/off state refers to how it reacts when it receives an 'on' or 'off' signal from a trigger_relay.

Imagine a museum hall with multiple security lasers. Every laser is covered by a trigger_multiple, and all those triggers will trigger a door that has an automated turret behind it. When the player walks through a laser, the door opens, and the turret starts firing at the player. But what happens when the player walks through another laser? Normally, triggering an entity will toggle it, so by triggering the door again, it closes, and the player is safe again.

One way to solve this is to use an mtl_trigger_switch to trigger the turret door (as both its on target and its off target). The trigger_multiple's then need to send an 'on' signal to this trigger-switch (either by triggering a trigger_relay that sends an 'on' signal to the trigger-switch, or by using the +nameofswitchentity target pattern, so MESS will automatically generate a trigger_relay for you). If the player walks through a laser, it'll send an 'on' signal to the trigger-switch, which then triggers the turret door. If the player walks through a second laser, another 'on' signal is sent to the trigger-switch, but because it's already in the 'on' state it won't do anything, and the turret door will remain open. You can also add a security button for disabling the turret system, by making a button that sends an 'off' signal to the trigger-switch.

---

I don't know whether this can help with making a stronghold capture mode - I assume you're talking about Counter-Strike, and I assume that you would need some way of differentiating between teams. I'm not familiar enough with CS to know whether there are any entities that can do that.

In other words: if you can make a capture mode with existing entities, then you can probably use MESS to simplify that into one or two template entities. But if it's not possible with existing entities, then MESS can't help you either.

C:\HL\Tools\remec\remec.exe "$path/$file.remec.$ext" jack "E:\STEAM\steamapps\common\Half-Life" $bspdir/$file.$ext

That last bit ($bspdir/$file.$ext) won't do anything, REMEC doesn't let you set the output path.

Either way, you should check whether the compile log contains any errors: This is what I see when I run it on a map that contains a single remec_lit_model entity, and the resulting map file contains a cycler_sprite and a func_detail. What does your compile log look like?

New release https://github.com/FreeSlave/halflife-featureful/releases/tag/featureful-2024-07-15

Changelog

Fast recruiting

New commands recruit_followers and disband_followers allow players to recruit all nearby friendly NPCs or call off everyone who is following the player by pressing one button. This is similar to fast recruiting of ally soldiers in Field Intensity.

The list of monsters affected by these commands is controlled by features/followers.json file.

Feature changes

• New feature in featureful_server.cfg: vortigaunt_armor_charge. Enable to allow friendly vortigaunts to give armor to the player (similar to HL2, experimental feature). The amount of armor is configured by sk_vortigaunt_armor_charge skill value. The vortigaunt must have the free energy to perform charging.
• hud_color command is no longer available by default. Set hud_color.configurable feature in featureful_client.cfg to true to enable the HUD color configuration by user.
• Add hud_scale.default and hud_scale.configurable features to featureful_client.cfg.
• Removed hud_autoscale_by_default feature in featureful_client.cfg. Set hud_scale.default to 0 to enable autoscale by default.

Entities

game_player_settings

• game_player_settings now can set the player's armor to 0 (set =0 as value), add and substruct armor by a provided value.
• game_player_settings now can add and substruct the player's health.
• Spawnflags of game_player_settings are deprecated now. Weapons are now configured via parameters instead. It allows to remove specific weapons as well.
• game_player_settings can now remove the specified amount of ammo (use a negative value).

trigger_changevalue

• Added Treat new value as parameter for trigger_changealue which allows to tell how the new value is treated.
• Added Action parameter for trigger_changevalue.

Calc entities

• Added Scale factor parameter for calc_ratio.
• Added more transformations for calc_ratio (from later versions of SoHL).
• Added calc_numfromvec - calculate a single numeric value from the vector.
• Added calc_vecfromnums - calculate the vector from three numeric values.
• Added Max and Min parameters for calc_eval_number.
• The result of calc_eval_number is now getting stored only if evaulation has succeeded. Trigger after operation is now called only if evaulation has succeeded. Added Trigger on calculation fail parameter.
• Added Report as vector parameter for calc_eval_number.
• Added Mod, Find Max and Find Min operators for calc_eval_number.
• Added Third operand parameter for calc_eval_number - it allows to do computations on 3 parameters using the same entity.

Other entities

• Added Armor Damage and Do Armor Damage spawnflags for trigger_hurt_remote (compatibility with Sven Co-op).
• Added Player Invulnerable spawnflag for trigger_camera (compatibility with Sven Co-op).
• Added Position and Direction parameters for particle_shooter.
• Added Direction parameter for env_smoker.
• Added Landmark parameter for trigger_teleport (compatibility with Spirit of Half-Life).
• Added new entity item_pickup. It can give a specified inventory item to the player on pickup (as an alternative to player_inventory).
• item_security icon is no longer shown in history of picked up items on the security card pickup unless the HUD sprite is set explicitly in the entity parameters. In general it's advised to use item_pickup instead.
• Added Forward activator for trigger_timer.
• Added Trigger on arrival for info_teleport_destination (compatibility with Sven Co-op).

Bugfixes

• trigger_hurt_remote doesn't push the player anymore (it was unintended effect).
• Fixed Entity to play from parameter of ambient_generic not working properly sometimes.
• Fixed env_smoker not emitting the correct number of smokes after the repeated activation.
• Inventory items HUD icons are no longer shown again when reloading the game.

Player inventory changes

• The name length of player inventory items is no longer limited by 23 characters.
• Inventory items are removed upon player's death.

Console commands

• Added calc_position and calc_velocity commands to get the position and velocity reported by the specified entity.

FGD changes

• Added ZHLT properties to brush model entities (like func_wall, etc.). Note that you still need to include zhlt.fgd in order to have access to compiler-specific entities like func_detail.
• Added Glow Shell as render fx option in fgd.
• Improved descriptions of some calc_ entities.

Changes to the demo map

• Added examples of relative teleport and seamless teleport.
• Added an elaborate example showing the usage of trigger_changevalue and some calc_ entities.

Have you tried asking the authors of Remec for help?

Can "mtl_trigger_switch" be used to create a Battlefield like capture stronghold mode? I noticed this sentence: “It remembers its own state, so sending an 'on' or 'off' signal to this entity when it's already in that state won't do anything. "Maybe not implementing this game mode, Or maybe I have a problem understanding.

Thank you for your help. I have tried, but it is still not solved. It still doesn't translate into something the code can recognize.
Could you take a look at it again, please? Copy File
$path/$file.$ext $path/$file.remec.$ext
C:\HL\Tools\remec\remec.exe
"$path/$file.remec.$ext" jack "E:\STEAM\steamapps\common\Half-Life"
$bspdir/$file.$ext

What are you planning, Kimilil? 😃

Boys I discover strange thing. I'm working on a project for Ricochet and got wonder I the comand menu dosnt work, even if the the coman for enabling it is present in the console. I draged few custom ones in the Ricochet directory and I wasnt able to active them. I dont know wen come to my mind and though maybe this bug from years updates. After that I downloded the Won version of Ricochet is put cl_dll folder in ricochet_addon's folder, because the addon folders also can load and dll files without overwrith the original ones. Still didnt apear, but still didnt apier, but I got better scorboard. After that came to my mind to try the HL client dll....
... and boom I got working comand menu, but with missing sounds and missing hud.
I know the source of Ricochet is avaible and if someone what to recompile it it can enable the comand menu to work.

map2prop 1.0 and mess 1.2.3 releasing within a week of each other is really something. good job to both of you

now to update my stuff with the power of the two combined >:D

Awesome, fantastic work! 🥳

Now available: MESS 1.2.3!

The biggest new feature is a conversion mode that can convert between .map, .rmf and .jmf formats. This mode also supports TrenchBroom groups and layers, which can be useful if you're migrating to (or from?) TB. It also supports setting a cordon area, selecting specific VIS groups and setting the 'wad' property, so it can be used for automated .map exporting.

I also added two new template entities: one for switching different targets based on an on/off state, and one for generating brush-based text using Makkon's techdc fonts. Of course, you can also create and share your own templates entities and automation scripts.

Besides these big changes, there is also a large number of smaller improvements and bugfixes, which you can read about below. Please let me know if you encounter any problems or if you have suggestions - either in this thread, on Discord, or by creating an issue on Github.

Download links:

• MESS 1.2.3 downloads
• Check out the tutorials for example maps!

Documentation:

• Setup guide for J.A.C.K. & Hammer and setup guide for TrenchBroom - Read this to get started.
• Tutorials - Tutorials about covering terrain, using template entities and other topics.
• Configuration - Config files make it possible to create game-specific setups.
• Template entities - A set of entities that make complex things simple.
• Template behaviors - Scripts that automatically generate entities or apply bug workarounds.
• Macro entities - The workhorse entities of MESS that make the template instancing system work.
• Scripting - Use basic scripts for randomizing things, or write advanced scripts for generating levels.
• File conversion - How to convert between .map, .rmf and .jmf files.

Major features:

• Added a file conversion mode that can convert between .map, .rmf and .jmf files (including TrenchBroom .map files, with groups and layers).
• The file conversion mode also supports cordon areas and VIS group filtering, so it can be used as a .map exporter.
• Added a new special property for replacing textures: _mess_replace_texture.
• A new template entity: mtl_trigger_switch, which can trigger different targets when it's turned on or off.
• Another new template entity: q1_brush_text, which generates text using Makkon's techdc font textures.

Other changes and improvements:

• Template entities now have custom editor sprites (only works in J.A.C.K.).
• Entity definitions in .ted files can now contain MScript expressions (in strings), which enables custom editor sprites and models.
• Added delay properties to cs_trigger_roundstart.
• Target patterns now also support delays for single targets.
• Added support for v122 .jmf files (for the J.A.C.K. update that added background images).
• Macro entities can now insert sub-templates from other maps.
• macro_insert entities can now create instances with an absolute position and scale.
• The special _mess_merge_entity_master property now only marks an entity as master if its value is true (not empty or 0).
• The special _mess_allow_rewrite_rules and _mess_deny_rewrite_rules properties now use commas to separate multiple paths.
• MESS can now also read .rmx and .jmx files (backup versions of .rmf and .jmf).
• Added a -norewrite command-line flag that disables rewrite rules (for testing).
• In .ted files, @MESS; directives without a matching @MESS opening directive are now ignored.

MScript changes:

• Added bitwise operators (>>, <<, &, ^, |, ~).
• Added support for hexadecimal number literals.
• New first and last functions for taking the first or last item from an array.
• New incglobal convenience function, for incrementing a global counter.
• hasflag and setflag functions now available in rewrite rules.
• New trunc function for truncating numbers.
• New ted_dirs and ted_path functions, for accessing files from other template entity directories.
• The trace function is now also available in .ted files.
• Object literals can now use strings as keys, and objects can now be indexed.
• New upper and lower functions for strings.

Bugfixes:

• Fixed that attached templates weren't positioned correctly (related to the special properties _mess_attached_template_map and _mess_attached_template_name).
• Fixed that using cs_trigger_roundstart would cause MESS to fail.
• Fixed that an mtl_trigger_random without targets would cause MESS to fail.
• Fixed that mtl_trigger_periodic didn't support target patterns.
• Fixed that the behavior of the -config parameter didn't match the documentation (when leaving out the file extension).
• Fixed that _mess_merge_entity_master properties weren't removed from entities that didn't also have a _mess_merge_entity_id property.
• Fixed that J.A.C.K.-style help texts in .ted files could not be parsed.
• Fixed that the output was always written in .map format, even if the output path extension was .rmf or .jmf.
• Fixed that if no output path was given, and the input file was an .rmf or .jmf file, it would be overwritten (now, a .map file with the same name is generated).
• Fixed that a macro_brush could select the wrong texture if the first brush of a template brush entity had the ORIGIN texture.
• Fixed that duplicate targets in a multi-target pattern were ignored.
• Fixed that some MScript expressions that contained strings weren't parsed correctly.
• Fixed that a macro_template without anchor and selection_weight properties didn't use the documented default values.
• Fixed that mtl_env_model didn't take dynamically set flags into account.
• Fixed that the 'kill', 'show' and 'hide' target patterns didn't check the pattern keyword was followed by a space character.

---

Again, special thanks to Windawz, Loulimi and kimilil for their feedback, and all the others that contacted me about MESS during the past 4 years.

The problem appears to be that you're creating a copy of the exported map file in the original directory ($path), but you're telling REMEC to look in the 'maps' folder of your game or mod ($bspdir):

C:\HL\Tools\remec\remec.exe $bspdir/$file.remec.$ext jack E:\STEAM\steamapps\common\Half-Life

Change $bspdir to $path, and add double quotes around the map path to ensure that any space characters in directory names won't cause any trouble:

C:\HL\Tools\remec\remec.exe "$path/$file.remec.$ext" jack "E:\STEAM\steamapps\common\Half-Life"

REMEC should do some logging so next time you can also check your compile log for errors.

You can see the installation steps here: https://gitlab.com/merisanu.alex/remec/-/blob/master/README.md?ref_type=heads

I followed the setup steps for readme.md, but the entities were not converted to entities that the game code recognized after compilation.
I checked it several times, but I couldn't find the cause.
I want to know how to solve this problem, Please help me..
Copy File
$path/$file.$ext $path/$file.remec.$ext
C:\HL\Tools\remec\remec.exe
$bspdir/$file.remec.$ext jack E:\STEAM\steamapps\common\Half-Life

Well I find the way to edit them, but actualy I cant make the text it to look better, but rather worse.

I've seen this problem before, and it's usually a case that the trigger positions between the two maps are too close together. You say you can transition from map1 to map2, but can you then go back? I would expect you cannot.

Basically, if you pass through a trigger_changelevel and you are in contact with another trigger_changelevel, it will be deactivated to prevent an infinite loop of going between levels. You want to set it up so that the trigger to return to the previous level is a few distances behind the player.

map1

The player hits the trigger_changelevel and loads map2

map2 (broken)

The player loads into map2, but the trigger_changelevel is in the same place, so they touch it immediately and would return to map1. This would in turn have them touching the trigger to go to map2 again and so we have a potential infinite loop. The game code prevents this and disables all trigger_changelevels.

map2 (fixed)

The player loads into map2 where they hit the trigger in map1 and can continue forward without hitting the trigger again. The transition back to map1 is further behind them, to ensure they're not running into it immediately and looping between map1 and map2

An easier way to achieve this is to use an env_beam to periodically strike a func_button. The button can then trigger the env_blood to emit particles. The beam can be toggled (or explicitly enabled or disabled by sending it an 'on' or 'off' signal with a trigger_relay) to toggle the particle effect.

The button's health and the beam's damage must be set to something higher than 0 (1 health and 0.1 damage will do just fine). This ensures that the button gets activated when it's hit by the beam. You'll also need to make sure that the beam goes through the button. The easiest way to do that is probably to let the beam use itself as starting entity and to place an info_target behind the button as ending entity. The beam's Life + Strike again time determine how often the button will be hit (if Life is 2 and Strike again time is 0, the button will be hit once every 2 seconds). Set the button's 'Wait before reset' to something low (0.1 or so) so that it can be hit again before the beam strikes again.

I'm using this setup in my mtl_trigger_periodic template entity.

It worked! Thanks so much for the help, I was really confused for a moment but the drawing and the example map really helped a lot. You're a legend!

yes

This is interesting, it seems that changing the Hull size (size) property of a func_pushable makes no difference at all, because it never gets passed to the CPushable::KeyValue() method. So, the following code never gets to run:

switch (bbox)
{
case 0: // Point
    UTIL_SetSize(pev, Vector(-8, -8, -8), Vector(8, 8, 8));
    break;

case 2: // Big Hull!?!?    !!!BUGBUG Figure out what this hull really is
    UTIL_SetSize(pev, VEC_DUCK_HULL_MIN * 2, VEC_DUCK_HULL_MAX * 2);
    break;

case 3: // Player duck
    UTIL_SetSize(pev, VEC_DUCK_HULL_MIN, VEC_DUCK_HULL_MAX);
    break;

default:
case 1: // Player
    UTIL_SetSize(pev, VEC_HULL_MIN, VEC_HULL_MAX);
    break;
}

Perhaps size is one of those special properties, like friction, that are handled automatically by the engine?

Plus, even if that code got to run, the call to SET_MODEL() inside the CPushable::Spawn() method, which is run later, sets the size also, so pev->mins and pev->maxs would be overwritten (not 100% sure of this). This must be why the func_pushable ends up with an accurate bounding box, same size as the brush.

Erty said:
Maybe you could force it to use the pointhull, and do your own collision checks using its bounding box. The performance won't be as good as with cliphull-based collisions, of course.

Do you mean implementing my own collision system inside the entity code, using tracelines or something?

Let's say theres a setup of three maps. If I go through map 1 to map 2, there is no problem. But if I try to get from map 2 to map 3 after that the trigger does not do anything. Yet, if I load into map 2 via the console, the trigger into map 3 works as it should. The trigger also functions if I load a save in map 2. Any ideas?

In your typical multi_manager loop, you set the Multi-threaded flag and have it target whatever is supposed to repeatedly trigger, and after some delay it'll trigger itself. Triggering the multi_manager again will only create more loops, so instead of a button to start the loop we can use a trigger_auto to start it from the beginning of the map, and instead of triggering the target directly we can use a trigger_relay, but we'll leave the relay's target empty to begin with.

To connect the target to the loop, we let the button target a trigger_changetarget (we can name it turn_on) to change the relay's target to our env_blood. We can use another trigger_changetarget (sharing the same name as the first) that will change the button's target to turn_off.
Now we create another pair of trigger_changetarget, both named turn_off. One will change the relay's target back to empty, and the other will change the button's target to turn_on. It might be a bit complicated, but here's an example map for such a toggled loop:

i think you can do that with featureful SDK

I am trying to make a shower that when you press a button it targets an env_blood entity that is supposed to be repeated indefinitely until the button is pressed again which stops it. I have seen that you can do it with a multi_manager that targets itself but I can't seem to be able to turn it off, so does anybody know if there's a way to make it toggleable, or better yet, if there's a better alternative to making a shower.

(please excuse the low quality)

It worked, after a couple of attempts. Thanks.

I'm sorry, I was wrong. My brain must have had a hiccup last night. Of course changing the pev->movetype to MOVETYPE_STEP won't help, and monsters uses the cliphulls as well for entity-to-world collisions.

Maybe you could force it to use the pointhull, and do your own collision checks using its bounding box. The performance won't be as good as with cliphull-based collisions, of course.

Thanks for the tip. Tried it, but no luck, the collisions stay the same. For reference, these are the possible values:

// edict->movetype values
#define MOVETYPE_NONE 0 // never moves
//#define    MOVETYPE_ANGLENOCLIP    1
//#define    MOVETYPE_ANGLECLIP        2
#define MOVETYPE_WALK 3           // Player only - moving on the ground
#define MOVETYPE_STEP 4           // gravity, special edge handling -- monsters use this
#define MOVETYPE_FLY 5            // No gravity, but still collides with stuff
#define MOVETYPE_TOSS 6           // gravity/collisions
#define MOVETYPE_PUSH 7           // no clip to world, push and crush
#define MOVETYPE_NOCLIP 8         // No gravity, no collisions, still do velocity/avelocity
#define MOVETYPE_FLYMISSILE 9     // extra size to monsters
#define MOVETYPE_BOUNCE 10        // Just like Toss, but reflect velocity when contacting surfaces
#define MOVETYPE_BOUNCEMISSILE 11 // bounce w/o gravity
#define MOVETYPE_FOLLOW 12        // track movement of aiment
#define MOVETYPE_PUSHSTEP 13      // BSP model that needs physics/world collisions (uses nearest hull for world collision)

// edict->solid values
// NOTE: Some movetypes will cause collisions independent of SOLID_NOT/SOLID_TRIGGER when the entity moves
// SOLID only effects OTHER entities colliding with this one when they move - UGH!
#define SOLID_NOT 0      // no interaction with other objects
#define SOLID_TRIGGER 1  // touch on edge, but not blocking
#define SOLID_BBOX 2     // touch on edge, block
#define SOLID_SLIDEBOX 3 // touch on edge, but not an onground
#define SOLID_BSP 4      // bsp clip, touch on edge, block

I've tried several combinations (some like TOSS and BOUNCE are very funny to watch), but it seems HL will always use hull-based collisions when it comes to entity vs. world. The code that decides this must be probably in that one part we can't touch (the engine).

There's no reason for hollowing out solid brushes for "performance" reasons.
If the hollow volume is big enough, it'll even produce more clipnodes as Urby says, just wasting away the clipnode budget for no good reason.

If those brushes are world brushes, it's even less reason to do so as any outside and unseen faces will be stripped out by the compilers automatically anyway.

Manually NULLing faces is an optimisation step you only should do if you need to. Otherwise you're just wasting time that could have gone to actually building the map.

Be more specific.

In terms of the RAD compile, the NULL faces would not be rendered in either case. These would appear identical in game. The downside to the hollowed out brush is an increase in clip nodes. It is no longer a single solid face, but rather a hollow box with five internal solid faces. A friend pointed out to me that it would also be far more time consuming to be hollowing out unseen faces like this.

I'm not sure why you'd ever want or need to do that.