Please or Register to create posts and topics.

preventing gun pickup for certain players

PreviousPage 2 of 3Next

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.

- Science isn't about why, it's about why not!

@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? :D 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 :thumbup:

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 :D

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? :D
...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....

ImageImageImageImageImageuseful tools and stuff here on TWP :thumbup:
[spoiler]ImageImageImageImageImage[/spoiler]

I don't know what I've been doing wrong before, but now I can parent stuff to the players. Mystery.. :P
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 :)

- Science isn't about why, it's about why not!
lord_blex wrote:
I don't know what I've been doing wrong before, but now I can parent stuff to the players. Mystery.. :P
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! :thumbup:

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 :wink:

ImageImageImageImageImageuseful tools and stuff here on TWP :thumbup:
[spoiler]ImageImageImageImageImage[/spoiler]

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.

- Science isn't about why, it's about why not!

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.

Falsi sumus crusto!

I've heard enough never to carve that I don't even know how to do it :P
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?

- Science isn't about why, it's about why not!

Hm. No, it shouldn't.

Did you enable the cordon after creating it?

Falsi sumus crusto!

Yes, I did.

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

- Science isn't about why, it's about why not!

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?

Falsi sumus crusto!
PreviousPage 2 of 3Next