- Admin
- #1
ADVANCED MAPPING TECHNIQUE
This has been coming up a lot lately, so I thought I'd make a topic, and link it to the tutor.
Due to buginess that has existed since MS1.3, and has only gotten worse over the years, you cannot chain two or more monster spawns together reliably, as it makes MSC's head explode thusly. You cannot, for instance, have monster spawn #1 spawn a dozen spiders, and then trigger monster spawn #2 with #1's fireallperish when they are all dead. It works about 50% of the time, and is even less reliable in multiplayer situations. (No, I've no idea why, best I can figure it has something to do with trigger ownership).
Fireallperish is also unreliable if the monsters in the spawns have varying amounts of lives.
As of DEC2007a, we have the monster gibbing crap, which also complicates matters. We seem to have reduced it, but are no closer to a cure.
Thus (using Dridje's wolf map as an example, sorta):
You can even keep using that same target and targetname for the trigger_counter - you just need to create more trigger_counter's with the same name and increase the count for each, changing the target and killtarget names accordingly. (So 20 for wave1, 40 for wave2, 60 for wave3, assuming you want 20 wolves per wave).
Note that the wolves have 0 lives (unlimited) - this means you *can* count by death instead, if need be, and it won't matter how many wolves get gibbed, save that the players will be forced to kill some extra ones before the next wave spawns.
Remember that the Half-Life.fgd wants trigger_counter to be a brush entity. This means, like monster spawns, or any trigger_ entity, it has to be tied to a brush, or it will vanish the next time you load the map in hammer. This also means, if it is in a location where the players can touch it, you'll have to add a the "no clients" flag.
Ye can download an example map here: http://www.thothie.com/msc_dev3/wolf_test.rar
That is NOT FN FRIENDLY - don't run it on FN, or we'll send Dom DeLuise after you, with nipple clamps.
EDIT: Changes since this was written up (due to patches):
Two things be different.
For one, yer better off using the point entities: ms_monsterspawn and ms_counter, to save on resources. ms_monsterspawn and ms_counter are identical to the brush entities msarea_monsterspawn and trigger_counter, save that they are point entities.
For two, as be covered in the changelog, the default behavior, when a monster spawn is deleted, is no longer to delete-fade the critters tied to it. Rather, it just stops more from spawning. If you want the creatures to vanish when the spawn is deleted, you must add the "Additional Params" (params) "set_dosr" (short for "die on spawn removal"). Even then, the monster will either die when the spawn is removed, or fade, if he spawned <2 seconds ago (while still invulnerable), should suicide slightly afterwards. Either way, you aren't "robbed of xp" when the monster you were thwacking on has its spawn removed.
The fireallperish event on a monster spawn should still be viable, so long as it isn't activating another monster spawn, and so long as every creature tied to the spawn has the same number of lives.
This has been coming up a lot lately, so I thought I'd make a topic, and link it to the tutor.
Due to buginess that has existed since MS1.3, and has only gotten worse over the years, you cannot chain two or more monster spawns together reliably, as it makes MSC's head explode thusly. You cannot, for instance, have monster spawn #1 spawn a dozen spiders, and then trigger monster spawn #2 with #1's fireallperish when they are all dead. It works about 50% of the time, and is even less reliable in multiplayer situations. (No, I've no idea why, best I can figure it has something to do with trigger ownership).
Fireallperish is also unreliable if the monsters in the spawns have varying amounts of lives.
As of DEC2007a, we have the monster gibbing crap, which also complicates matters. We seem to have reduced it, but are no closer to a cure.
Thus (using Dridje's wolf map as an example, sorta):
You can even keep using that same target and targetname for the trigger_counter - you just need to create more trigger_counter's with the same name and increase the count for each, changing the target and killtarget names accordingly. (So 20 for wave1, 40 for wave2, 60 for wave3, assuming you want 20 wolves per wave).
Note that the wolves have 0 lives (unlimited) - this means you *can* count by death instead, if need be, and it won't matter how many wolves get gibbed, save that the players will be forced to kill some extra ones before the next wave spawns.
Remember that the Half-Life.fgd wants trigger_counter to be a brush entity. This means, like monster spawns, or any trigger_ entity, it has to be tied to a brush, or it will vanish the next time you load the map in hammer. This also means, if it is in a location where the players can touch it, you'll have to add a the "no clients" flag.
Ye can download an example map here: http://www.thothie.com/msc_dev3/wolf_test.rar
That is NOT FN FRIENDLY - don't run it on FN, or we'll send Dom DeLuise after you, with nipple clamps.
EDIT: Changes since this was written up (due to patches):
Two things be different.
For one, yer better off using the point entities: ms_monsterspawn and ms_counter, to save on resources. ms_monsterspawn and ms_counter are identical to the brush entities msarea_monsterspawn and trigger_counter, save that they are point entities.
For two, as be covered in the changelog, the default behavior, when a monster spawn is deleted, is no longer to delete-fade the critters tied to it. Rather, it just stops more from spawning. If you want the creatures to vanish when the spawn is deleted, you must add the "Additional Params" (params) "set_dosr" (short for "die on spawn removal"). Even then, the monster will either die when the spawn is removed, or fade, if he spawned <2 seconds ago (while still invulnerable), should suicide slightly afterwards. Either way, you aren't "robbed of xp" when the monster you were thwacking on has its spawn removed.
The fireallperish event on a monster spawn should still be viable, so long as it isn't activating another monster spawn, and so long as every creature tied to the spawn has the same number of lives.
Last edited:
