Players getting stuck in cart

Discussion in 'Mapping Questions & Discussion' started by Suyo, Oct 2, 2013.

  1. Suyo

    Suyo L1: Registered

    Messages:
    6
    Positive Ratings:
    1
    For the past few days, I've been trying to get a cart to roll up a slope and down another. While it does correctly follow the path, there's another problem - that being the players near it.
    This happens especially often if a player is in front of the cart and is pushed by it. As soon the cart reaches the downwards slope, the cart will rotate, "fall" onto the player and get him stuck. He then is taken along for a ride down the track, and as soon the cart turns back when it reaches the flat track, the player is stuck in the ground.

    [​IMG]

    I tried everything I could think about - making the cart a prop_dynamic, making the cart a prop_physics_override, disabling cart collisions, making the slope flatter, trying different sizes and shapes for the func_train, copying the cart from Badwater (which has a slope which works fine), adding point_push or trigger_push to get players out of the way, and even having two seperate func_trains, one for moving the cart and a second, bigger one with rotation disabled acting as a clip. None of these worked.

    I have no idea what else I could do. Right now I have placed kill triggers below the ground so people get killed instead of stuck, but that's obviously not a perfect solution. Does anyone have an idea as to what I could do to fix this?
     
  2. Egan

    aa Egan

    Messages:
    1,302
    Positive Ratings:
    1,478
    This was happening for me too on plr_reserve, I tried everything you tried as well but also to no avail. Instead of kill triggers you could use a teleporter to teleport the player above the cart - but that could also get players stuck into things and others anyway. (landmark teleporter would be less jumpy but would yeild the same potential result of just having the player stuck inside something anyway).

    So, yea, I donno, I hope Boojum comes in here and blows both our minds with something we missed.
     
  3. A Boojum Snark

    aa A Boojum Snark Toraipoddodezain Mazahabado

    Messages:
    4,767
    Positive Ratings:
    5,508
    A few things that come to mind that could be related:
    "no user control" and "unblockable by players" flags enabled on the tracktrain.
    "debris" flag enabled when using prop_physics_override.
    Pardon the stupid-check, but have a train_watcher looking at the tracktrain. I'm sure you have it but that actually makes the train use cleaner collisions.
    Track props have collisions disabled.

    Big stretch, but... what axis is your slope on? Is it the same as badwater? Thinking about it, the only slopes in badwater are on the same axis (though opposite directions) and it is possible there is some Source finaggery going on with collision math.
     
    • Thanks Thanks x 2
  4. Suyo

    Suyo L1: Registered

    Messages:
    6
    Positive Ratings:
    1
    Turns out the stupid-check has been the correct guess. It's actually not a payload mode, so I didn't think I'd need it, and didn't know it would improve collisions. So it does work fine now. The only problem is that the train watcher adds the payload tag, even though it doesn't fit, so I'll have to figure something out with that. Disabling or killing the train watcher will keep the changed collision behaviour, but not remove the tag... but hey, at least it works.

    I did have an alternative solution set up following Egan's suggestion - I had two info_target set up, with one moved 1 hammer unit up and 1 hammer unit forward. The teleport trigger below the ground then had the global and local landmarks set to these two, resulting in the player being pushed into that direction. Sometimes you would end up on top of the cart, sometimes not, it was quite weird - but I guess it's a solution for those who do have their train watcher set up and it still doesn't work.
     
    • Thanks Thanks x 1
  5. A Boojum Snark

    aa A Boojum Snark Toraipoddodezain Mazahabado

    Messages:
    4,767
    Positive Ratings:
    5,508
    tag? Not sure what you mean by that.
     
  6. Suyo

    Suyo L1: Registered

    Messages:
    6
    Positive Ratings:
    1
    The sv_tags convar, which lists settings on the server, such as "norespawntime", or "bots". It also contains the current gamemode, so people could look for a mode based on these tags. You can see it on the right side in the server browser. The train watcher makes TF2 think the map is a PL map, which means that A) the game will show "Payload" as gamemode in the intro message B) TF2 will add "payload" to sv_tags.
     
    Last edited: Oct 3, 2013
  7. A Boojum Snark

    aa A Boojum Snark Toraipoddodezain Mazahabado

    Messages:
    4,767
    Positive Ratings:
    5,508
    Oh, hmm. Is it another mode or "no" mode? I'm not sure if setting a HUD override in the tf_gamerules would have any affect on that.
     
  8. Suyo

    Suyo L1: Registered

    Messages:
    6
    Positive Ratings:
    1
    The map is primarily a KOTH map, but TF2 recognizes it as Payload - which means that's what is in the tags, and also on both the briefing text and gamemode name in the briefing.
    Placing the train watcher seems to override anything else, which is weird because other entities, like the KOTH logic entity, seem to have no such effect. Even when changing the map prefix to koth_ it won't be corrected, that will only change the gamemode title on the briefing screen, the text in the briefing and the tag still belong to Payload.

    The HUD setting does not help, it just changes the HUD (which I had to do, too, since it was overridden by team_train_watcher). I have sent the TF team a mail asking whether they have any ideas for forcing a gamemode, or getting the alternative collision behaviour without the train watcher, I hope they respond.
     
    Last edited: Oct 3, 2013