Teleport options

[Loobinex]

Currently the behavior is inconsistent. I've got a testmap with a vampire trapped in a lair surrounded by dirt. So completely disconnected to the rest of the dungeon.

• When I press L, I teleport to the library
• When (from the initial position) I press F, I do not teleport to the fight, but to the dungeon heart.

Pressing F does work when there's a path to walk there.

[Loobinex]

You've skipped the last zoom key, 'zoom to annoyed creature', is that on purpose?

[AdamPlenty]

Currently the behavior is inconsistent. I've got a testmap with a vampire trapped in a lair surrounded by dirt. So completely disconnected to the rest of the dungeon.

* When I press L, I teleport to the library

* When (from the initial position) I press F, I do not teleport to the fight, but to the dungeon heart.

Pressing F does work when there's a path to walk there.

That's intentional. Do you think it'd be better if you could teleport to fights the creature can't otherwise get to?

[Loobinex]

Well, consistency is key. If you can teleport to rooms you can't otherwise get to, why not fights/CtA as well?

[AdamPlenty]

Well, consistency is key. If you can teleport to rooms you can't otherwise get to, why not fights/CtA as well?

The reason I made Call to Arms have the 'Can you get there otherwise?' requirement is because otherwise it can be abused; all you have to do is place a CtA right inside enemy territory, possess a creature, and cast Teleport and hey presto! Is it really a good idea to remove that requirement?

[Loobinex]

I hate how inconsistent teleport was in the first place,... normally you can cast CtA on a teleporting unit and get it to teleport to places anyway, but indeed when you have inaccessible spaces this is not the case. There's a topic on this on keeperklan

The current behavior is:

• Units can teleport only to places they can get to normally
• In possession, units can teleport to the heart/lair always. So you can teleport through locked doors no problem,...

The new behavior will introduce issues no matter what I see. Think of this scenario (A): 1) You drop units into a fight outside your dungeon. The door reaching your dungeon is locked, so units cannot walk there. 2) You possess the vampire, fight until you are about to die, then teleport home. 3) When you can heal, you heal, so you can fight again. You now press F and teleport to the fight -> you cannot.

This is really confusing, that you can teleport only one way, and very hard to understand. Here you DO want to be able to teleport to all fights.

Now think of this scenario (B): 1) You have used a reveal special to see blue 2) When blue digs out a room, you drop an imp onto the dirt before blue claims it 3) When blue imps start to fight your red imp, you possess your vampire and teleport into the dungeon you cannot get to normally.

It is clear that in this scenario, you clearly should not be able to teleport into the dungeon. So you DO NOT want to be able to teleport to all fights.

I also think it's important that mistresses and vampires don't start teleporting to rooms you've put behind locked doors, since that would make dungeon management impossible.

How about these requirements:

• Outside of possession, the current behavior will stay, and vampires will teleport only to places they can access
• In possession you can teleport though all locked doors, but not to places that are truly inaccessible (like walled in enemy dungeons). This includes your own rooms.
• However, due to magical reasons, the exception to this is his lair, and the dungeon heart where the vampire can always teleport too.

[AdamPlenty]

This should only affect teleporting in possession, not where creatures teleport of their own volition. How do you suggest we make doors an exception to the "blocking slab" rule? This sounds to me like we need another "can the creature get here?" function, but with doors excluded somehow.

[Loobinex]

According to mefisto(see the link), there's already such a function for when they try to take paydays.

[AdamPlenty]

According to mefisto(see the link), there's already such a function for when they try to take paydays.

I've had a look, but I'm not sure where that is. I've noticed however, that creatures do head for a Treasure Room on paydays even if they can't get there, and only stop when they encounter a locked door.

[Loobinex]

I found the solution, use: if (creature_can_navigate_to(thing, &cta_pos, NavRtF_NoOwner)

[Loobinex]

Seems pretty good at this point. Is there anything you feel like should still be done? I'm still pretty convinced that teleporting to hero gates is an undesired feature.

[AdamPlenty]

Seems pretty good at this point. Is there anything you feel like should still be done? I'm still pretty convinced that teleporting to hero gates is an undesired feature.

Not sure this is a major thing, but could it check the next room if the one selected is unreachable, and if there is no reachable room of the selected type, have the default behaviour? Not sure how that could be implemented though.

[Loobinex]

Well, there's a count_player_rooms_of_type function, it tells you how much rooms of said type you have. You could put this chunk of code inside a loop, and only if all room types cannot be accessed, go to the default:

                if (rkind > 0)
                {
                    room = nearest ? find_room_nearest_to_position(thing->owner, rkind, &thing->mappos, &distance) : room_get(find_next_room_of_type(thing->owner, rkind));
                }
                if (!room_is_invalid(room))
                {
                    room_pos.x.val = subtile_coord_center(room->central_stl_x);
                    room_pos.y.val = subtile_coord_center(room->central_stl_y);
                    allowed = creature_can_navigate_to(thing, &room_pos, NavRtF_NoOwner);
                    if (!allowed)
                    {
                        if (find_random_valid_position_for_thing_in_room(thing, room, &room_pos))
                        {
                            allowed = creature_can_navigate_to(thing, &room_pos, NavRtF_NoOwner);
                        }
                    }
                }