Hey, I have a new problem regarding my 4-player map.
I basically want to have two portal guns for two players in the same area. The problem with this is that you can still pick up a weapon after you already have it. So you can just pick up your teammate's portal gun as well. Is there a way to identify players, so you can only pick up one of the guns? I know there is in simple coop, because you have the two "teams". But in my case both players could be of the same color. So can this be done somehow?

EDIT: I just got another idea, if there isn't a way to tell players from each other. I always get my ideas after I write a question here. This is a great forum
So in one of the maps, there was a flashlight following the player everywhere. How was that done and can it be done in multiplayer? Because then I could check that entity instead of the player itself.

I don't know how this could be accomplished. What I do know is that there is a limit to the amount of portals in a map, so a four-player map will not work if everyone has portal guns. I believe the limit is 3 linked pairs of portals, but even then just staring at a portal will cause major lag and some of the walls will turn invisible. However, if you DO manage to overcome this limit, I would suggest having a seperation section where the two players are seperated then given guns.

Good luck, and I hope to see a finished map incorporating 4 players; if you can.

In regards to the flashlight following the player, that was just an env_projectedtexture parented to the player model. You obviously can't use that as the entity, but maybe find something else, give it a name, and then use triggers and name filters.

@lord_blex: I'd suggest you to cover your portalguns with some invisible textured func_brush so the guns are ungrabbable even though the players hit +USE. Then surround it by a filtered trigger brush that would deactivate the invisible func_brush depending on which player touches it. In order to do this filtering (and also do it for that other thread of yours), you must check and test different filters from here.

(The only con here is that there would be an annoying block around the guns that players will crash with)

The problem with 4 players is that you should know any specific atribute (like some players' ID) to be able to filter your triggers... In Portal2 single player you refer to the player by !player, in coop by just player for both or blue / orange to refer to each of them... but I don't the heck know in the case of 4! You should investigate that by any debugging command once they are all spawned in game.

I cannot seem to parent anything to a player. I had a trigger that would parent itself to its activator upon triggering, then I tried a mug (prop_dynamic) and a func_brush, but non of them worked. Though I might just be messing something up. How should I do this?

josepezdj wrote:
The problem with 4 players is that you should know any specific atribute (like some players' ID) to be able to filter your triggers. [...] You should investigate that by any debugging command once they are all spawned in game.

Won't players have different IDs every time? And even if they don't: if I release this map and for some reason 15 players decide to log in, I would have to prepare for all of them..

Honestly, I would stick with a 2 player map. Portal 2 was definitely not built for more than 2 players. Even if you do manage to get the logic set up, performance might take a hit due to there being more than 2 people.

And about Identifying Players: Maybe use Skins? Have 1 player using ballbot.mdl and the other using ballbot_skin_black.mdl [or another one]? Just an idea. If you can get 4 players, start them off in seperate rooms with triggers that send changemodel [modelname] to a point_clientcommand. Just be sure to include the model in the map!

Ultiman9711 wrote:
Honestly, I would stick with a 2 player map. Portal 2 was definitely not built for more than 2 players. Even if you do manage to get the logic set up, performance might take a hit due to there being more than 2 people.

And about Identifying Players: Maybe use Skins? Have 1 player using ballbot.mdl and the other using ballbot_skin_black.mdl [or another one]? Just an idea. If you can get 4 players, start them off in seperate rooms with triggers that send changemodel [modelname] to a point_clientcommand. Just be sure to include the model in the map!

I'm not really worrying about performance. We tried this thing on a livestream, we had 16 people in the game and everything was pretty smooth. You obviously can't do it if you are playing on a toaster, but I think it should be working fine for most of the people. Especially with just 4 players.
The different skins for the players is a nice idea, I might do it. Though I'm currently more interested in making the game itself recognize the different players..
And about giving up: I actually tend to give up stuff I have worked on a lot, just because I don't feel like doing it anymore. I have tons of unfinished Minecraft and Portal maps on my computer.. But as long as I find something interesting, that's all I do all day. So I will be keep doing this as well, until I run out of juice and leave it lying in bits. (See what I did there? ) Or I just finish it. You never know

The point of switching the model is that you can then use a filter_activator_model to differentiate them.

FelixGriffin wrote:
The point of switching the model is that you can then use a filter_activator_model to differentiate them.

Wow, yeah, I didn't realize that.. :$
The problem with that is that I can't assign the skin on spawn. A, because I don't actually know who's gonna be in which team and B, (just as that was my problem in the other topic) if more people joined the map for whatever reason, that would break the whole thing. (I might shouldn't worry about that, but I feel like preventing this is the elegant solution.)
And why I feel that my first statement is a problem, is just because it would be weird if the characters would suddenly change upon exiting the starting area. So if I could solve the problem with the parenting thing that would be great.* If I can't, I might go with this. Or just make a portal gun dispenser. That would work too..

*Btw only one person commented on that. Is it possible? I might just be doing something completely wrong. It might seem that I actually know anything about Hammer, just because I'm doing a 4 player map, but I can assure you, that is not the case at all I just don't feel like doing a "put the cube on the button"-level, even for my first one. So I might need a bit more explanation than usual.

With a script you can assign it whenever you want, and give each character a unique skin. I'll help you with it if you want.

Thank you, but what I was trying to say is that I didn't want to change the skin way after spawn, unless there was no other way, because it would be a weird, unexplained thing to do. (And I can't change it directly at spawn for the reasons described above.) So I only want this solution as a last resort.

@lord_blex: Man, if you don't really know a lot about hammer mapping, wouldn't it be better to just make a coop map or maybe single player one? It's not necessary to makea a simple and plain map putting cubes on buttons like you said, but you can create a complex map too. To me, adding multiple players doesn't really imply to develop a good map... However, I do think that what you're trying to achieve is interesting

I think you should go step by step...

1. First of all, no matter what approach you finally choose, you'll need to refer to any of the players somehow in order to do filtering. There must be some way of doing so. Unfortunately I don't know for 4+ players

2. Secondly, a change of approach: use ungrabbable weapon_portalgun with the flag "Start Constraint" checked. You'll need to check out for any output to "wake" that gun up from that state (I haven't tried so far and I'm not in front of my computer atm) on demand (meaning depending on the player). If you can't achieve it, you can use a respawning system as you mentioned above (a point_template plus an env_entity-maker that spawn a grabbable portalgun, that's without checking the flag "Start Constraint"... and do not forget to kill the ungrabbable gun too!)

3. In order to do that filtering (dropping a grabbable gun and kill the ungrabbable one), I can only think of trigger brushes (trigger_multiple for example) plus a filter. There are many filter options but first you need to know how to identify the players, and depending on that, to choose the right one

4. Another approach for identifying each player, you could make it depend in the way you introduce players in the map... btw how do you do indeed? ...You could use a sort of "player spawner", 4 of them. Maybe this way you could add one trigger brush per spawner in the dropping way after the info_coop_spawn, and "mark" each player with !activator and the user inputs/ouputs

I don't have many more ideas....

I don't know what I've been doing wrong before, but now I can parent stuff to the players. Mystery..
So what I did is I put a pair of triggers and func_brushes a bit before the players get the guns. When one of the triggers gets triggered, it parents a brush to the player that triggered it. The brushes have different names and that's what two other triggers with filters look for directly around the portal guns.
I still have two problems:
A, The triggers don't actually recognize the brushes. So what do I need to do, or what other entity should I use, to make that happen?
B, It would be great, if I could teleport my identifier to the player just after parenting. The trigger area where the player picks up the brush is not that small, but I would like to make the brush as small as possible. But if I do that without teleporting it directly to the player, there might be a huge offset between them. So how do I teleport something to the !activator of a trigger?

Thanks

lord_blex wrote:
I don't know what I've been doing wrong before, but now I can parent stuff to the players. Mystery..
So what I did is I put a pair of triggers and func_brushes a bit before the players get the guns. When one of the triggers gets triggered, it parents a brush to the player that triggered it. The brushes have different names and that's what two other triggers with filters look for directly around the portal guns.
I still have two problems:

Great way or marking players!

A. What flags have you checked in your trigger brushes? I think it's "Physics objects" that should be selected but I'm not completely sure. However, if you keep having problems with this, use a filter_activator_name to make the trigger be fired only by the desired brush name (you indicate the name of your brush inside the filter entity's properties, name that filter and put the name of the filter in the "filter name" property inside your trigger).

B. In order to do so, you can do this:

• Do not parent the func_bruhes to the player on mapspawn, but leave them all wherever and make one trigger_teleport surrounding each one (again look out for the flags to be checked in your trigger_teleports to make possible that the func_brushes trigger them, k? in the case you have problems, use again the filter_activator_name) with the property "Start Disabled" set to YES.

• Now you can parent to the players an info_target onmapspawn instead; name them. These are the remote destination that each of your func_brushes will be teleported to.

• In each of your trigger_teleports you'll need to specify what info_target will it be teleport

• Whenever the players trigger your triggers near the portalguns you need to use this output:

OnTrigger (or OnStartTouch) > [trigger_teleport_desired_name_here] > Enable

This will make your func_brush be teleported to the info_target that should be parented to the plaer

I just can't get the trigger to recognize a func_brush. I've been messing around with the flags and nothing.. Then I changed to a func_physbox, which definitely is a physics object and even that doesn't work.

Then comes my new problem, which is that my map doesn't want to compile. I put an underground dome in the map, put some brushes in it and since then the whole thing fails to compile, even if I delete the new stuff, or if I put a cordon just around a small area that I surely haven't modify. All I get is "DRASTIC MEMORY OVERFLOW: fell out of small block heap!" I haven't really found anything useful about this error message.

That usually means you have too many little func_details, for example, if you stuck a cylinder into a detail wall and carved it. Tie them together into bigger func_details or delete them.

I've heard enough never to carve that I don't even know how to do it
It does this even if I cordon an area that doesn't even have func_details. If I compile a cordoned area it shouldn't worry about anything outside it, should it?

Hm. No, it shouldn't.

Did you enable the cordon after creating it?

Yes, I did.

If I copy the whole map into a new file it all works just fine. Interesting..

Try doing that, then. Something must have just gone wrong with Hammer.

(I asked the cordon question because I didn't know at first that cordons had to be enabled, so I thought the tool was broken the first time I used it.)

EDIT: Wait, I know this error. You can get it if a texture isn't aligned to either world or face. Did you use an old version of the random wall generator recently?