Please or Register to create posts and topics.

force-dropping a cube

PreviousPage 2 of 2

Thank you, this testmap made me realize two things.
One, that something is wrong. I straight up copied your vmf into mine and it didn't work at all. The bsp you uploaded works just fine. 0.o
Two, I can't map. A little test map you made looks more interesting than my whole map :D (Though it might helps a bit that yours has some lighting.)

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

Np. It would be really helpful if you could check out what could be happening when it doesn't work out for you... for the sake of this thread and in order to identify possible details that one can missed in the case of trying a similar thinghy...

If you can reproduce the failure in a small map, you could post it here so we can help you out finding the issue ;)

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

Just found what the problem was, it's actually quite obvious. It worked in singleplayer, but not in multiplayer. I'm guessing it doesn't know who to run the +use on, because technically the !activator is the cube, not the player. Is there a simple solution for this that I'm missing, or do I have to mess around with a secondary trigger for the player? That would be my fourth brush entity in the same place...

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

Oh, true, this was your multiplayer map :D ... Have you tried using the entity point_broadcastclientcommand instead of the point_clientcommand to execute the command +Use/-Use?

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

Won't that E all players? That's not quite ideal..

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

It would. Try putting a logic_register_activator in your intro, with two trigger_onces to register the players as 1 and 2. Then fire your Use output through that entity, and the !activator will become whichever player you want.

Falsi sumus crusto!

For this I should actually know which player is holding the cube, shouldn't I? After reading the wiki it seems to me that I have to manually fire either the first or second registered activator. But if I knew who's holding the cube, I wouldn't have a problem in the first place.

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

Different triggers for red and blue, filter_activator_team or filter_activator_name?

Falsi sumus crusto!

Yes, that would work, but the reason I asked how to do this was because I didn't want to cram a fourth brush entity in the same place. But I guess I'll have to.
I actually had a solution with a second trigger for the player that would start disabled and enable every time the cube triggers its own trigger. Then the player's trigger can have the necessary outputs. It didn't seem too elegant, but it could work.
I certainly can't use team filters. I don't know if you remember this thread, but we are still talking about (more or less) the same 4-player map, so I can't be sure about player colors.

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

You can use the SetModel hack I described in that thread to distinguish them, or just use the script function SetTeam(int). ;)

Falsi sumus crusto!
PreviousPage 2 of 2