Half-Life: Anti-Climax is my take on the "battle you have no chance of winning" the G-Man offers you once you decline his job offer at the end of the Half-Life campaign. Is there truely no chance to win or can you lead Gordon to victory and freedom?

Post tutorial Report RSS Fixing sound and beam issues on save/load

If you encounter problems with ambient_generic or env_beam after saving and loading in Half-Life single player, here's how to solve the problems!

Posted by on - Advanced Mapping/Technical

During my playtests I've encountered some problems after loading from a saved game. One is a problem with repeating sounds and the other with beams. I hard trouble finding this information, so I want to share it here for other modders. Thanks to Solokiller for helping me solving these issues!

1. Repeating sounds
Problem: After loading a saved game, a bunch of ambient_generics that were previously triggered all go off at the same time, again.

Solution: Tick flag 32 (Not Toggled) on all non-looped sounds.

Explanation: If an ambient_generic is not set to 'not looped', the entity will remain active after being triggered. Upon loading a saved game, these sounds are being retriggered. This is useful for looping background sounds, so they don't fall silent after a reload, but you definatly don't want this behaviour from any non-looping sounds.

2. Messed up beams
Problem: All beams no longer start or end from the designated start or end position after loading a saved game.

Solution: Don't use the env_beam as the starting (or ending) point for your beam, but use 2 info_targets as start and ending of your beam.

Explanation:
When an env_beam is created on map load, the model index is set to 0, which means it's treated as a point entity by the engine. After loading up a saved game, however, the env_beam already has a model (the sprite it is rendering) and is nolonger considered a point entity. So, originally the beam was between 2 point entities and now suddenly is between a point entity and a model entity.

Also: env_beam stores its start and end positions in existing variables: 'origin' for start point, 'angles' for end. Since the restore swaps the start and end entities to make an entpoint type beam, it uses the beam entity for its end, but it sets the start entity position first, which means it does this:

pev->origin = pStart->pev->origin;
pev->angles = pEnd->pev->origin;

Where pEnd->pev is the same as pev. So it basically does this:

pev->origin = pStart->pev->origin;
pev->angles = pev->origin;

Which creates a beam with 0 length, which can cause problems in the engine.

I hope this helped a few people out there!

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: