Kismet Teleport Action Problem

[Shisho2k]

I had set up two portals, and two trigger actors with delayed Ontouch events to call the Teleport Action.

The issue I'm having is that at one point the target (being the event instigator/players only) was going to the correct destination. Then I did a copy and paste of these interp actors, and pointed the teleports to the actors themselves. Now it seems the destination is always the interp actors on the sending end.

I even switched the connectors to see if I didn't have them mixed up. Same result. The teleport trigger just keeps sending the player to the interp actor it's next to. Is there some kind of weird reference thing that happens with actors when you copy and paste them?

Any suggestions? =)

[Alhanalem]

Yes. The pasted actors take the original object names. So you will have to go back and check all the references.

When you copy and paste, there is a naming conflict, because the object being pasted has the same object name as the original if it's still present. When you paste, it keeps that name and the actor with the same name gets renamed. This is a side effect from allowing a CUT and paste to keep the same object name on the actor.

[Shisho2k]

Thanks, that clears it up. That would be nice if it didn't work like that. XD

Is there a way to rename it? Or do you have to create new ones from the content browser?

[Shisho2k]

Seems to have been my copy and pasted triggers causing this issue still. It must of just been using the logic the closet one somehow? Deleted and replaced one, and it works now.

[Shisho2k]

Ugh, actually it keeps coming back every time I make some changes.

[Alhanalem]

No, you can't name objects yourself, they're assigned by the system sequentially.

[Shisho2k]

No, you can't name objects yourself, they're assigned by the system sequentially.

It appears my problem here is that the event delays weren't doing the trick. It does appear that you're being spit out (since the portal is a bit elevated), but it's retriggering and sending you back without noticing.

Makes sense now, considering the opposite trigger hasn't been triggered so it doesn't have to delay before reloading, it's ready to fire as you come over.

Added a delayed enabled/disabled fixed it, so I'm probably going to work some sort of flag logic perhaps to prevent it.

I wonder if there's a way to associate a reference to each player triggering it, so it doesn't necessarily shut off for second player. Would be weird for like 4 players having to wait to use it one at at time. Any thoughts on that?