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.

My question is if there is an upside or downside to using one method instead of another and which one is better.

You could take a look at the speaker entity. It plays a sentence from sentences.txt at a random interval between 3 and 10 minutes. Using a sentence group (sentences with the same name but different number suffix) will make it choose a random sentence from the group.

It's used a lot in the original Half-Life campaign where it adds random background noises. In these cases multiple speaker entities are used together to make the sounds play more often. An example would be c2a5c, where four speaker entities set to play the FAR_WAR sentence group to add an ambiance of distant combat.

If you're mapping for HL, you can take a look at predefined sentence groups in sentences.txt and see if any fits your need. If you're making a mod, you could create a new custom sentence group that fits exactly your need.

I would like to create a map with random ambience sounds, but i'm not able to create a system that is able to complete such task correctly. I was trying with a looped multimanager, that triggered certain sounds in a specific time, (sound1 every 20 secs, sound2 every 10 secs, etc.), but it's not exactly random.

Your guess of it having something to do with the HULL sizes is correct.
While player-on-pushable collisions uses the pushable's bounding box, the pushable's collisions with the level uses clipping hulls instead.

Clipping hulls date back to Quake. Essentially, instead of continuously testing mesh-on-mesh collisions (very expensive), the player and pushables are simulated as a single point, and collision hulls are pre-calculated by expanding the solid level geometry by an appropriate amount (e.g. 16 units horizontally and 36 units vertically for HULL1). This way collisions are tested using point-on-mesh instead, which is computationally very cheap. It performs better, and that's why the engine uses this instead of bounding boxes.

It might be possible to force it to use bounding box instead, I'm guessing changing the pev->movetype to MOVETYPE_STEP should get it to use similar collisions as monsters, though it's not guaranteed to be better.

As you all probably know, the physics of a func_pushable in HL1 are pretty janky, the collisions being specially bad. The correct brush size can make a difference.

I did some tests and found out that the only XY (length/widht, will not consider height here) sizes that seem to work well are 32x32 and 64x64 units. I guess this has to do with the sizes of hulls #1 to 3 (see here). With brushes of those exact sizes, a func_pushable works and looks alright. With other sizes, HL will try to use the next biggest hull:

• A brush smaller than 32x32 will act like it was 32x32. So it will collide will walls too "soon", leaving a visible gap. So for example a 24x24 brush will leave a gap of 8 units of empty space on both sides between the wall and itself.
• Brushes larger than 32x32 but smaller than 64x64 will behave as the latter. A 48x48 brush will leave a gap of 16 units on each side. BUT this will only happen if both dimensions are larger than 32x32 (otherwise 32x32 will be used). So for example a 32x256 brush will stick 224 units into the wall in the Y dimension.
• A brush larger than 64x64 will act like it was 64x64. So it will partially stick into walls. A 96x96 brush will stick 32 units into the wall on both sides.

Strangely enough, when I render the entity's bounding box everything seems to be right, it's the same size as the brush. I don't know why the engine doesn't use that for collision testing.

Changing the "size" property (point, player, big, duck) makes absolutely no difference. When I look at the source code it's not clear what it does...

Is there any way to improve this? (Apart from switching to HL2, that is).

As always, this looks really great 👍

Explain exactly what you mean.

hey you never know for sure if it's actually coming out

Mind that time we set a release date? What was I thinking?? Probably something like, "3D Realms aren't going to hire me in early 2021 and cause me to delay the mod indefinitely. That'd be crazy!" That being said, we're making progress on this again now and I dare say that some of the new sections I've added or the old areas I've improved upon are pretty damn fun now. Just need to get this thing over the line now. Stay tuned!

Hard to believe it's finally coming out. Going back to the start of this thread and seeing that it started in mid-2021 is crazy. Golf claps all round.

I think i got misunderstood. I didn't mean series of animations blend together to create another animation. (For better explanation look up for the animations of tfc playermodels) I mean i need something flexible. It should work like simple math, overlay this with that and get this etc.

Surprisingly enough, this is not well documented on any site, but its possible. I know the security guard model uses this for the shooting animations, but im not so sure.

I am asking this because i am wondering. (And kind of asking this because i kind of remember and believe that tfc had interpolated/overlaid animations.)
If it's indeed possible then how is it done?

Possible causes:
1) The actual model files are missing (not on your hard drive)
2) The directory path cannot be found. (Original mapper could have put stuff on multiple Hard drives for instance)
3) Original mapper, compiled on a "windows PC", you are using Linux and camelCase letters are being used. (e.g. Check if an shown "Error" has a name like MyFlyingModel1.mdl in Hammer but when you check on you hard drive the file is named myflyingmodel1.mdl, Solution: Change/use lower-case and re-compile map.)