Different numbers of players needed to push each cart in PLR

Mokagogo

L1: Registered
Jun 21, 2009
32
1
Intro

Hi all; I'm working on a new PLR map which will have some slightly unusual characteristics. Rather than going into all the details on this first post, I'll just outline the basics and the specific problem. All my entities were initially in ABS's gametype VMF and also tested in plr_lumberyard.

The Premise

1: The OnNumCappersChanged2 output from the trigger_capture_area around each cart sends the number of players capping as an output to a logic_case (just as in ABS's library).

2: The logic_case looks at this input. If it's -1 or 0 (cart blocked or no players on the cart), it sets one of the two values in a separate logic_compare entity to 0. If there's 1 or more players capping, it sets that value to 1.

3: There's one logic_case for each cart; but each logic_case submits one of the two values to that single logic_compare entity.

4: The logic_compare entity compares a value (1 or 0) from each of the red and blue carts. From the comparison, it decides which cart to move in which direction, and sets the carts' speeds.

Now, the whys and whats of the directions and speeds aren't important. The problem relates to registering players as capturing in the first place, and translating that through.

The problem

Any Blu player on the Blu cart registers correctly as pushing it. It all works.

But in order to register as capping the red cart, you either have to get a scout on it, or 2 red players. One player is not enough.

Due to the way this logic_compare compares values which are either 1 or a 0, a scout on each cart will result in a block, and no cart moving. But a scout on blu and a non-scout on red, will still move blu. It's like one single pusher is not enough to register on the red cart, for some reason.

The 'Number of [RED/BLUE] players to cap' on the trigger_capture_area is set to 1 for both teams for both carts. That's pretty standard I believe; so I don't think it's that.

*edited* P.S. I just remembered: a possibly-related, possibly-not thing is that no matter whether anyone's pushing the carts, from the very start of the level they are making a kind of engine noise, possibly similar to the rolling noise, or at the very least a motor sort of noise. But they don't move without someone pushing. I haven't changed the sounds.


Does anyone have any idea, from this information, of the sort of bug or misplaced setting / unconsidered factor that might be causing this?


Many thanks for any and all suggestions,

Mokagogo
 
Last edited:

A Boojum Snark

Toraipoddodezain Mazahabado
aa
Nov 2, 2007
4,775
7,669
Honestly, I haven't a clue what you're going on about. You've given too much detail without saying the broad objective, so I can't even say if the problem is a flaw in your chain or rather that the entire approach is incorrect.
 

Mokagogo

L1: Registered
Jun 21, 2009
32
1
Well, there are a couple of alternative approaches I looked at before I settled on this one.

A friend requested that I make a map where both teams fight to control a single cart on a payload track, each pushing it in opposite directions. It seemed like a fun idea and I had some thematic notions of a good map setting and purpose. First I tried doing it with a single cart object cap-able by both teams, where one team capping would push it back and the other team would push it forward; that didn't work.

So I decided to use both carts. I'd duplicate the path-tracks so that the payload race tracks were overlapping for RED and BLU, but have each set of tracks travelling in the opposite direction to the other set. Then I'd start both carts in the middle, offset from each other by a few metres. Then I would combine their relative numbers of people capping, using the logic_compare, and then as the result of the logic_compare, move one cart backwards along its track whilst moving the other cart forwards at the same speed. In that way the carts always stay in the same position relative to each other, and whichever team has control of the carts pushes them toward their objective and away from their enemy's.

So that's the broad objective. And it works fine. One cart goes back as the other goes forward; you can block each other, and so on. But the issue is the one I mentioned in the post before this one. You need either a scout or 2 people in order to cap Red.

I could PM a link of a stripped-down .VMF to interested parties. If you need it in order to make a suggestion, I'd be eager to do that. I'm finding the weak link in the chain hard to debug in this instance.

Another odd and probably unrelated thing is that the cart dispenser (using the normal mapobj_ et cetera entity) replenishes health fine, but not ammo. That's not normal, is it?
 

A Boojum Snark

Toraipoddodezain Mazahabado
aa
Nov 2, 2007
4,775
7,669
A friend requested that I make a map where both teams fight to control a single cart on a payload track, each pushing it in opposite directions. It seemed like a fun idea and I had some thematic notions of a good map setting and purpose. First I tried doing it with a single cart object cap-able by both teams, where one team capping would push it back and the other team would push it forward; that didn't work.
That's what [ame=http://forums.tf2maps.net/showthread.php?t=5933]pl_waste[/ame] is. The prefab for which you can get here.

Dunno if that changes anything for you. If you still want to use the PLR system and use two carts... it could be done, though you might even be able to use the PLR hud with a single cart, I've never tried that though.
 

Mokagogo

L1: Registered
Jun 21, 2009
32
1
Thanks for the info. I'll take a look at the prefab in the next couple of days (about to travel). It'll be interesting to see what approach was taken.