Forum posts

Posted 4 months ago2024-07-15 13:37:30 UTC
in MESS 1.2.3 is now available Post #348990
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.
Lei Shi Lei ShiFRS石磊
Posted 4 months ago2024-07-15 13:24:56 UTC
in REMEC doesn't work? Post #348989
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?
expert2expert2
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
Lei Shi Lei ShiFRS石磊
Posted 4 months ago2024-07-14 20:24:12 UTC
in MESS 1.2.3 is now available Post #348988
What are you planning, Kimilil? 😃
Posted 4 months ago2024-07-14 17:15:52 UTC
in Commndmenu in Ricochet is disabled Post #348987
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.
Posted 4 months ago2024-07-14 15:52:14 UTC
in MESS 1.2.3 is now available Post #348986
map2prop 1.0 and mess 1.2.3 releasing within a week of each other is really something. good job to both of you :D

now to update my stuff with the power of the two combined >:D
Posted 4 months ago2024-07-14 15:25:07 UTC
in MESS 1.2.3 is now available Post #348985
Awesome, fantastic work! 🥳
Posted 4 months ago2024-07-14 15:04:54 UTC
in MESS 1.2.3 is now available Post #348984
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: Documentation: 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. :)
Posted 4 months ago2024-07-14 15:01:11 UTC
in REMEC doesn't work? Post #348983
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.
Posted 4 months ago2024-07-14 12:42:26 UTC
in REMEC doesn't work? Post #348982
Posted 4 months ago2024-07-14 12:19:44 UTC
in REMEC doesn't work? Post #348981
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
expertexpert
Lei Shi Lei ShiFRS石磊
Posted 4 months ago2024-07-13 15:24:44 UTC
in How to modify the fonts in scorboard-HLDM Post #348980
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

User posted image
The player hits the trigger_changelevel and loads map2

map2 (broken)

User posted image
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)

User posted image
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
monster_urby monster_urbyGoldsourcerer
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.
Posted 4 months ago2024-07-10 19:46:36 UTC
in Is there a way to make a toggleable looping circuit? Post #348977
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! :biggrin:
Posted 4 months ago2024-07-10 16:46:12 UTC
in Improving accuracy of collisions with pushables? Post #348975
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?
Posted 4 months ago2024-07-10 07:54:47 UTC
in Is there a way to make a toggleable looping circuit? Post #348973
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.
User posted image
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.
User posted image
It might be a bit complicated, but here's an example map for such a toggled loop:
Loading embedded content: Vault Item #6924
i think you can do that with featureful SDK
Posted 4 months ago2024-07-10 00:25:59 UTC
in Is there a way to make a toggleable looping circuit? Post #348971
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.
Is this what you mean?Is this what you mean?
(please excuse the low quality)
Posted 4 months ago2024-07-09 00:41:58 UTC
in Random ambient sounds? Post #348969
It worked, after a couple of attempts. Thanks.
combine the walking anim with shooting anim and get strafing as a resultcombine the walking anim with shooting anim and get strafing as a result
Posted 4 months ago2024-07-08 18:48:57 UTC
in Improving accuracy of collisions with pushables? Post #348967
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.
Posted 4 months ago2024-07-08 17:19:05 UTC
in Improving accuracy of collisions with pushables? Post #348966
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).
Posted 4 months ago2024-07-08 12:28:02 UTC
in Map Optimization Question Post #348965
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.
Posted 4 months ago2024-07-08 11:46:52 UTC
in Map Optimization Question Post #348964
Be more specific.
Posted 4 months ago2024-07-08 11:34:16 UTC
in Map Optimization Question Post #348963
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.
monster_urby monster_urbyGoldsourcerer
Posted 4 months ago2024-07-08 11:01:19 UTC
in Map Optimization Question Post #348962
Filled in with 1 brushFilled in with 1 brush
Hollowed out and separated with 2 brushesHollowed out and separated with 2 brushes
My question is if there is an upside or downside to using one method instead of another and which one is better.
Posted 4 months ago2024-07-08 09:33:01 UTC
in Random ambient sounds? Post #348961
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.
Posted 4 months ago2024-07-08 02:01:43 UTC
in Random ambient sounds? Post #348960
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.
Posted 4 months ago2024-07-07 21:36:58 UTC
in Improving accuracy of collisions with pushables? Post #348959
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.
Posted 4 months ago2024-07-07 20:42:31 UTC
in Improving accuracy of collisions with pushables? Post #348958
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).
Posted 4 months ago2024-07-07 08:33:04 UTC
in Half-Life: The Core Post #348957
As always, this looks really great 👍
Explain exactly what you mean.
Posted 4 months ago2024-07-06 22:19:23 UTC
in TWHL Tower: Source Post #348955
hey you never know for sure if it's actually coming out ;)
Posted 4 months ago2024-07-05 17:10:34 UTC
in Half-Life: The Core Post #348954
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!"
User posted image
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!
User posted image
User posted image
monster_urby monster_urbyGoldsourcerer
Posted 4 months ago2024-07-05 16:59:54 UTC
in TWHL Tower: Source Post #348953
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.
monster_urby monster_urbyGoldsourcerer
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?
Posted 4 months ago2024-07-04 10:09:46 UTC
in Why are my custom models errors Post #348949
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.)
Posted 4 months ago2024-07-04 02:48:28 UTC
in TWHL Tower: Source Post #348948
A little annoyed I couldn't come up with any better ideas than literally just a first person shooter tutorial level, but oh well lol. Theres always TWHL Tower Source ^2
NovaDelta NovaDeltantx_cairostation_zone2
Posted 4 months ago2024-07-03 12:07:50 UTC
in TWHL Tower: Source Post #348947
Hey, everyone! I'm happy to announce that TWHL Tower: Source will release on the 19th of July.
https://www.moddb.com/mods/twhl-tower-source/news/release-date-announcement14
Dr. Orange Dr. OrangeSource good.
Posted 4 months ago2024-07-02 23:17:21 UTC
in Creating a texture swap for a mod Post #348945
Oh my bad, I did everything, but forgot to set the mod directory in J.A.C.K. !
Posted 4 months ago2024-07-02 22:31:59 UTC
in Creating a texture swap for a mod Post #348944
The process is exactly the same as any custom content for the mod: Place the custom assets in the corresponding folder in your mod's folder.

If you've already started working on your mod, you should have a folder at .../Steam/steamapps/common/Half-Life/<your_mod>.
Any custom models should then be placed in .../Steam/steamapps/common/Half-Life/<your_mod>/models.
This way when you launch the mod, it'll use the custom models instead of the vanilla models.

You can check out Tutorial: Setting up a Mod: Part 1 - Mod directory and liblist.gam (Steam) for more information about setting up a mod.
Posted 4 months ago2024-07-02 22:19:49 UTC
in Creating a texture swap for a mod Post #348943
I want to change the texture of the zombie monster for a mod, but only for the mod, rather than replacing the actual game files. How do I do that?
User posted image
Posted 4 months ago2024-07-02 14:41:08 UTC
in Problem with making a lift using func_train Post #348942
Instead of deleting the thread, how about sharing with us how you solved your problem so that other people can learn from your experience.

That's good Internet etiquette. "Nvm solved it" isn't.
Posted 4 months ago2024-07-02 13:11:02 UTC
in Problem with making a lift using func_train Post #348941
I created a lift which I wanted to start at the top path_corner and then go down to the bottom.

However when I press the button to turn on the lift it does start at the top path_corner like I wanted it to, but moves upwards instead of downwards, crushing the poor soldier to bits.
User posted image
I don't know what I'm doing wrong here. I used an origin brush before at both path corner points but that didn't solve anything either.

Edit: Never mind i solved this. There is no option to delete posts for some reason
Posted 4 months ago2024-07-01 15:14:10 UTC
in Half-Life Featureful SDK Post #348940
Ah I see what you mean, I never noticed it before because I use a low FX amount value for these window panes. I guess we can get away with a lightmap resolution of 1, this isn't Half-Life like its 1999 any more.
User posted image