preventing gun pickup for certain players
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. 
useful tools and stuff here on TWP 
[spoiler]
[/spoiler]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?
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!
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. 
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.