Pete's Place :: Mapping :: Problems

What I wanted

For my Lab17: SlimeLab map, I needed a huge, heavy door to allow passage between the East end of my lab and the caverns outside. I did not want it to behave as a normal door (ie, reverse when blocked) so I modelled it as a func_train. Additionally, there had to be two func_buttons to trigger my "door" -- and when one button was pushed, it had to trigger the other button, so that the two buttons remained synchronised.

What I did

I modelled my "door", placed the two buttons, and set them up as follows:

A func_train with Name set to 'bigdoor', being the door itself.
Two path_corner entities, 'bigdoor_up' and 'bigdoor_down', to mark the closed and open positions of the door. The 'bigdoor_down' had its 'Wait for retrigger' flag set; 'bigdoor_up' had a Wait here delay of 60 seconds.
Two func_button entities, both with Name and Target set to 'bigdoor'. The idea is that pressing one button triggers both the door, and the other button. I knew that this approach would work, because I had done the same thing (with three buttons) to control a func_door entity in Lab17: Storage. Allowing for the speed of the door (slow) and the time the door would stay open, both buttons had a Delay before reset of 90 seconds.

What happened

It didn't work. Pushing either button appeared to trigger the door, because it started making the movement noise I'd assigned to it, but the door never actually moved -- and, of course, it continued to make its noise until we quit out of the game.

It was especially frustrating, because this door was one of the last two operable items I had placed in the level, and the other didn't work either. Oh, and the level, by this stage, had a 25.5 hour compile time! Whatever was wrong, there was not going to be a quick fix.

How I fixed it

Troubleshooting

Because of the huge compile time, I finally realised that the best way to troubleshoot the failed door was to create a new, empty level with one large room, and copy all the troublesome elements into it -- making for a 10 second compile time and ease of getting to the bits that needed testing. I did this, copying across the func_train and its related path_corner entities, and one of the func_button entities.

I played around with everything for a little while, but could see nothing obviously wrong, so I compiled and tested my mini-level. Of course, the door worked. I scratched my head a little more, and finally mentioned it to one of my play-testers, who suggested the obvious: bring both buttons into the level. I hadn't bothered because I knew the two-button-plus-door combination worked. So I copied the other button into the level, tested it -- and the door no longer worked!

It seems that while a func_door is quite happy to share the name of two or more self-referencing func_buttons, a func_train is not.

Solution

Perhaps there are other ways to resolve this issue; my solution was to use a multi_manager:

Add a multi_manager with a Name of 'bigdoor_mm'.
Change the Target of both func_buttons to 'bigdoor_mm'. Change the Name of one to 'bigdoor_b1', and the other to 'bigdoor_b2'.
Add the following three key/value pairs to the multi_manager:
- bigdoor: 0.01
- bigdoor_b1: 0.01
- bigdoor_b2: 0.01

This then worked perfectly, as intended.