Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enemies should not be able to teleport or summon with targets out of sight #148

Closed
DominusExult opened this issue Feb 13, 2022 · 6 comments

Comments

@DominusExult
Copy link
Member

Especially with Liches, they shouldn't be able to teleport to or summon something at the Avatar without a line of sight. See Gotcha's forum post http://exult.info/forum/viewtopic.php?f=1&t=1791278&sid=cfc074524d41ae44dde03f0466733d9c.
A check for line of sight prevents this. Please let me know if I do this correctly and whether you can think of a place where this could break the game:

diff --git a/combat.cc b/combat.cc
index 75f9e87d..fbd3268c 100644
--- a/combat.cc
+++ b/combat.cc
@@ -234,6 +234,10 @@ bool Combat_schedule::teleport(
 	eman->add_effect(std::make_unique<Fire_field_effect>(src));
 	int sfx = Audio::game_sfx(43);
 	Audio::get_ptr()->play_sound_effect(sfx, npc);  // The weird noise.
+	// check line of sight now to give it the appaearnace of the spell 
+	// failing as in the original
+	if (!Fast_pathfinder_client::is_straight_path(npc, trg))
+		return false;
 	npc->move(dest.tx, dest.ty, dest.tz);
 	// Show the stars.
 	eman->add_effect(std::make_unique<Sprites_effect>(7, npc, 0, 0, 0, 0));
@@ -246,6 +250,9 @@ bool Combat_schedule::teleport(
 
 bool Combat_schedule::summon(
 ) {
+	Game_object *trg = npc->get_target();
+	if (!Fast_pathfinder_client::is_straight_path(npc, trg))
+		return false;
 	ucmachine->call_usecode(SummonSpellUsecode,
 	                        npc, Usecode_machine::double_click);
 	npc->start_std();       // Back into queue.

@drcode1
Copy link
Contributor

drcode1 commented Feb 14, 2022 via email

@DominusExult
Copy link
Member Author

Thanks! Added in e0a5530

@Dragon-Baroque
Copy link
Contributor

Dragon-Baroque commented Feb 14, 2022

Should you move the Line of Sight check up in Combat_schedule::teleport ? I mean before it creates the Fire Field at the point of departure, and along with the other test for letting the Avatar escape ?

I would assume a Lich, a Supra-Genius evil creature, be able to predict that the Teleport will fail by lack of Line of Sight and not even attempt it, much less create a Fire Field where it is standing.

@DominusExult
Copy link
Member Author

In the original the fire fields get created as well, so I thought mimicking this would be the best way to handle it. Without those fire fields it might look too boring, perhaps?

Something else I was thinking about there in regard to the combat difficulty setting. Maybe it would be a nice touch to allow monsters without line of sight to summon at harder and to teleport at hardest. So far the combat difficulty only handles hit points differently AFAIK

@Dragon-Baroque
Copy link
Contributor

In the original the fire fields get created as well.

If so then OK. Looks to me as a defect in the combat IA, but OK.

In that case, please replace the return false of the Line of Sight check in Combat_schedule::teleport, possibly also the one in Combat_schedule::summon, by a return true.

Because, as they are called, summon() and teleport() returning false do not mean the action has failed, but the action has not taken place, since only a true result adjusts the dexterity points and terminates the current action. The false result instead leaves the possibility for another action : strike instead of summon or walk instead of teleport.
As it stands your patch creates a Fire Field but does not inflict its cost in dexterity points or in time to the Lich.
Not that this changes much to a jailed Lich, but in an open area with sight obstructing walls, it might...

@DominusExult
Copy link
Member Author

Thanks for the explanation! Changed the teleport() function accordingly but left the summon() as I have no indication if the original did execute it.
And yes, it might be a defect in the original teleport() but no idea if we should leave it in or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants