preventing gun pickup for certain players
Quote from lord_blex on April 1, 2013, 11:05 pmThank 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.
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.

Quote from josepezdj on April 2, 2013, 6:58 am@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... [spoiler]btw how do you do indeed?
[/spoiler] ...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....
@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...

I don't have many more ideas....
Quote from lord_blex on April 2, 2013, 12:52 pmI 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
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

Quote from josepezdj on April 3, 2013, 5:44 amlord_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

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
Quote from lord_blex on April 5, 2013, 8:47 amI 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.
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.
Quote from FelixGriffin on April 5, 2013, 10:39 amThat 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.
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.
Quote from lord_blex on April 5, 2013, 3:46 pmI'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?
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?
Quote from FelixGriffin on April 5, 2013, 5:16 pmHm. No, it shouldn't.
Did you enable the cordon after creating it?
Hm. No, it shouldn't.
Did you enable the cordon after creating it?
Quote from lord_blex on April 5, 2013, 5:32 pmYes, I did.
If I copy the whole map into a new file it all works just fine. Interesting..
Yes, I did.
If I copy the whole map into a new file it all works just fine. Interesting..
Quote from FelixGriffin on April 5, 2013, 11:23 pmTry 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?
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?