Please or Register to create posts and topics.

Temporarily kill one player in a co-op map

Page 1 of 2Next

I don't know if there's already a thread for this; I ran a few searches and nothing obviously directly relevant turned up.

What I'm trying to do is have the level start with the two bots falling into a shredder. Or rather, Pbody falling in and Atlas landing on some debris. The plan is that Atlas has to find and activate a repair device early in the level (not going to keep player 2 out of action for too long) to bring Pbody back.

So far I have Pbody dying when she falls in the shredder, simple enough. Obviously she then respawns, so I added a trigger just below the player spawn points that disables Pbody's spawn. Which works. Sort of. What happens now is that Pbody is invisibly stuck inside the shredder, and keeps re-exploding every few seconds. Which is obviously kind of annoying.

Is it possible to kill one player and have them completely absent until a different spawn entity is enabled?

EDIT: Also, may as well ask while I'm here, I have an effect where the Portal Gun has a built in torch, which flickers when picked up for a few seconds until it stays steady. I wanted to set up a binding to let the player control the torch, but it requires sv_cheats, so I don't really want to leave that enabled all the time. And I couldn't get the binding to work anyway.

But it's kind of a pain, because obviously the notification of sv_cheat changes appears on screen, turning on during the flicker for about one and a half seconds, then turning off again. I don't suppose there's any way I can hide the messages, is there?

Sorceror Nobody wrote:
But it's kind of a pain, because obviously the notification of sv_cheat changes appears on screen, turning on during the flicker for about one and a half seconds, then turning off again. I don't suppose there's any way I can hide the messages, is there?

Create a point_servercommand (I think so? :P) anywhere in your map. Now, create a logic_auto anywhere in your map and add the following output:

OnMapSpawn > (Name of your point_servercommand) > Command > hud_saytext_time 0

Also, have a trigger at the very end of your map:
OnTrigger > (Name of your point_servercommand) > Command > hud_saytext_time 12
Just so it'll have people's text working again.

As for the other problem, I'm not entirely sure. What you could do is have P-Body trapped in the assembler. Whenever Atlas fixes it, the assembler will dispense P-Body. That's my only idea.

My Hammer Maps
[Released] Power Interference
[Released] Rust and Dust (Spotlight Map!)
[Released] Multiportal

Yes, the player entity must always exist. It can't just disappear. But you could build a dark toolsblack room with a point_teleport in it set to teleport "red", then trigger it, and have a trigger_kill kill her when the assembler is fixed.

Falsi sumus crusto!

The teleport method sounds good, I'll give that a try. Thanks for the quick replies! ^_^

Instead of annoying the player and forcing them to see blackness etc. I would actually change their view to the other players' so they can see what their partner is doing and perhaps give them advice(?). Of course you would need to inform the player that they can't actually do anything yet - shredder / stuck.

https://developer.valvesoftware.com/wik ... ultiplayer

Using a camera would require parenting it to the other player - unless there is some thrifty console command someone knows of.

?????????????????????????????TWP Releases | My Workshop

Yeah, I'm not too sure if it's even a good idea to temporarily kill off a player. Some might be open to this, but make it brief.

Perhaps, if it's possible, it would be more interesting if the other player was in a cage that was slowly lowering in goo (or, easier, a slow moving elevator). They might shoot portals from that place, still do something, but still be in a tight spot. If you're hell bent on not making them do anything, add glass around the trap, so they can see stuff and communicate.

It could be even cooler if there was some mechanism to temporarily raise the elevator again, drawing time (it's more exciting if this can't be done again and again though). Though, again, if you're going to make this last, let the victim be able to shoot portals and affect the map remotely.

It's literally, Pbody falls in shredder, Atlas walks to pick up Portal Gun, Atlas walks to other end of room to find an opening in the wall, short corridor, portal on wall, portal through hole in ceiling, another short linear corridor, and fall into the room where Atlas will find and activate the reconstructors. Player 2 will be out of action for a couple of minutes tops, unless player 1 is really slow in finding the linear path for some reason.

I like the idea of Pbody having Atlas's view while out of action. It ties into another query I came up with, regarding the ping tool. I was thinking I'd just disable the ping tool until Pbody comes back, because it sure looks weird if Pbody uses it in a black space where it appears basically right in front of camera because the walls are tight around her to prevent any movement. So the interesting question I guess is whether player 2 would be able to ping in player 1's view if I parented the camera. Doesn't matter if they can't, since they at least won't see their own pings right in front of them (I guess they'd still appear in the distance, though? Which kinda ruins the immersion... I may still just disable the ping tool).

As for said disabling, I know unbinding F should work, since I had to repair my own keybinding for that after originally messing about trying to bind F to the torch as mentioned in the initial post. Obviously I'll rebind F to the ping tool as soon as Pbody is brought back if I do go down this route. Though I dunno if unbinding will affect both players by default, or only Atlas, since he's always the host? Hmm, I guess I'll find out when I try. Some questions are simply answered by experiment :3

EDIT: Oh, yeah, how would I go about parenting the camera to player 1? The linked article isn't entirely clear. For one thing, which field exactly is the one that has to be set to Atlas, Target Entity? Also, I believe the !player target name only works for single player... though I guess as long as in multiplayer it hits player 1 by default it'll still work, even if that method is a bit crude. Although then I have to reset Pbody's camera to normal, unless killing the camera controller entity works (though in my experience killing entities tends to leave them in the state they're in, so I won't count on that), so I suppose I'd still need a target name for player 2. Are there specific entity target names for the players in co-op?

P-Body is "red" and Atlas is "blue". Surprisingly intuitive. :P

Falsi sumus crusto!

Latest problem: Pbody picks up a portal gun, which is identical (literally. Copied entity, minus the torch flicker-related commands) to the one Atlas picks up, and it behaves very strangely. Firstly, it doesn't seem to pick up properly, though it seems to be functional. The noise it makes is somehow incomplete; hard to say in what way, but it is. Secondly, the portal gun reappears on the floor about seventeen seconds later, even when I add a OnPlayerPickup > !self > Kill to it. It very occasionally only grants Pbody one portal, and sometimes throws the tutorial button prompts at me. Picking it up the second time seems to fix things, but nothing I've tried can do away with the peculiarity.

In other news I'm still not sure how to make the camera thing work, but I've set that aside while I deal with this oddity and the general construction of the level. Work on polish after building. Apart from when it gets really weird, like this.

I was thinking about parenting a point_viewcontrol to each player, if player a dies, the point_viewcontrol at player b is activated, so player a can follow player b, while being able to rotate the camera as (s)he likes. This can be done with an offset, but I don't know if that's favorable.

Haven't tested it but it might be worth a shot ;)

Page 1 of 2Next