As stated in the other answers, collision is only initially being handled between the two game objects that are colliding. You need to have a script on one of the two objects involved in the collision, and have it relay information back to the player, somehow.

## Potential problems with same-named objects colliding

In your example, you have a script that is *on* an object named "`triggerCube`". You *also* check to see if the *other*`col.name == "triggerCube"`, suggesting that both objects are named "`triggerCube`".

It is important that you are aware that ***both*** cubes will trigger a collision. This means that if both cubes have the `EndPoint` script, they will each run their own version of `OnCollisionEnter`, where they will each see the opposite `triggerCube` and determine that `(col.name == "triggerCube") == true`.

'Why is this important', you might ask? Well, it means that your logic will be run *twice*. Under some logic, this won't *appear* to mess things up; but you might have some fatal errors, as a result. You could also have situations where the "`Player`" tag jumps an extra game object, depending how you have things set up, as both `triggerCube` objects detect a collision and *individually* instruct the player to 'hop objects'.

I will *assume* only *one* of the `triggerCube` objects contains the `EndPoint` script, which allows quick assurance that the logic will only process *once*. You may also want to look at an alternate question, ["Check which object triggered another"][1].

## Alerting the `Player` object to collision

Ultimately, you need to be able to identify the `Player` script, to push action to the player when your two `triggerCube` objects collide. You can do this several ways, each of which has their advantages and disadvantages. We will *assume* that the script attached to your player is called *Player*.

Here are three easy ways to set up your reference:

 * **Use Unity Editor:** If your only making the jump once, this is the quickest and most reliable way to go.
 * **Use a static script:** If your only keeping one instance of the player, this might be the quickest way to go. Beware: If you do not properly *ensure* that you only have *one* `Player`, your going to have a bad time.
 * **Find the reference on the fly with tags:** If you only have one `Player` tag at a time, this might be the more reliable way to go. Than again, if you have a lot of objects in your scene, you might find that this method is slow to work itself out.

### Passing the reference via Unity Editor
Having a public reference allows you to manually set the reference using drag and drop, in the Unity Editor. 

This is a good way to test out certain functionality, while ensuring correct reference. This is also a good way to go when the reference is some what *static* - that is, *if the script should not move from that game object*, your reference should always work properly. This is also, arguably, the easiest way.

If you have to perform this sort of action *again*, i.e. it is not a 'one-time only' event, this is probably not the best solution. If you *still* go this way, you will still have to ensure that the reference is properly set up again, when you move to the next 'player object'. Since your now in-game, you will have to reset the reference *without* the Unity Editor, so your better off just using one of the more adaptable solutions from the start.

    public class EndPoint : MonoBehaviour
    {
        public Player player;

        void OnCollisionEnter(Collision other)
        {
            if(other.gameObject.name == "triggerCube")
            {
                player.NextPlayer();
            }
        }
    }

    public class Player : MonoBehaviour
    {
        public void NextPlayer()
        {
            // Move tag to next object;
        }
    }

### Keeping a `static` reference to `Player`
Having a `static` reference allows you to guarantee access to your script, but you should remember that to be static, a script can not have instanced variations in play. While you are not hard-bound by this constraint in *using* `static`, if you do not follow the logic, bad things will happen.

You could consider attaching the script to your new 'player object' with each `NextPlayer()`, if you need to move players more than once. ***If your logic insists that multiple `Player` scripts be at play at the same time, this will not work for you.*** If you have multiple `Player` scripts, with only one at play at a single time, you still need to make *absolute* sure that `Player.me` references the *active* version of your `Player` script. Even with precision, that could be tricky.

    public class Player : MoboBehaviour()
    {
        public static Player me; // cheeky self-reference

        void Start()
        {
            me = this;           // set up the self-reference
        }

        public void NextPlayer()
        {
            // Move tag to next object;
            // Attach this script to the next object;
            // That way, this static script can be kept,
            // but it still references the next object with this.gameObject
        }
    }

    public class EndPoint : MonoBehaviour
    {
        void OnCollisionEnter(Collision other)
        {
            if(other.gameObject.name == "triggerCube")
            {
                Player.me.NextPlayer();
            }
        }
    }

### Finding `Player` on the fly with tags

Another option you have is to locate the player using the same tag you wish to change.

This solution is more likely to work on the fly, in a variety of circumstances. That said, we are relying on checking all objects for the `Player` tag; while the scenario you describe seems to imply only one `Player` tag will be in use (so we are not worried about finding the wrong object), you have to keep aware of how many game objects are currently in your scene. As your logic has to sort through more objects to find the player, it will take longer to complete its operation.

    public class EndPoint : MonoBehaviour
    {
        Player player;

        void OnCollisionEnter(Collision other)
        {
            if(other.gameObject.name == "triggerCube")
            {
                FindPlayer();
                Player.NextPlayer();
            }
        }

        void FindPlayer()
        {
            GameObject.FindWithTag("Player");
        }
    }

    public class Player : MonoBehaviour
    {
        public void NextPlayer()
        {
            // Move tag to next object;
        }
    }

## Moving the "`Player`" tag

Now that's all sorted out, changing the tags should be quite easy. Simply calling `gameObject.tag = ` in a script should give you the ability to change its tag. That said, you ***must*** ensure you set a tag that has previously been set in the [Tags & Layers Manager][2].

If it was not already obvious, you will have to retrieve a reference to your 'new player object', just as you had for your player. *You should be able to do this in effectively the same way as you would to identify the initial 'player object'.*

You may consider using a different method to that which you used for `Player`. Keep in mind that since you may not be calling any real script logic on the other side, yet, you may not have an actual *script* on the other side. You can store a reference to the *direct game object* with `GameObject nextPlayerObject`, and work your way from there.


  [1]: https://gamedev.stackexchange.com/questions/123804/check-which-object-trigger-another "Check which object trigger another @ GameDev"
  [2]: https://docs.unity3d.com/Manual/class-TagManager.html "Tag Manager @ Unity Manual"