Announcement: Be excellent to each other.


Caravel Forum : DROD Boards : Bugs : Telepathic eyes. (3.1.48 (but not apparently addressed since))
New Topic New Poll Post Reply
Poster Message
Jacob
Level: Smitemaster
Rank Points: 3741
Registered: 10-01-2004
IP: Logged

File: Bug.hold (759 bytes)
Downloaded 34 times.
License: Public Domain
icon Telepathic eyes. (0)  
Activating an eye with a clone (in range) results in the activation of another eye (not in range).
It's a bit more complicated than that, so have made a hold.

Tab up to the top clone, and wait once to activate the top eye. You'll see the bottom eye also becomes activated (red line graphic). Tab again to the bottom right eye to demonstrate that it is activated without having actually seen anyone.
Click here to view the secret text


____________________________
New to DROD? You may want to read this.
My Holds and Levels:
Click here to view the secret text

10-08-2007 at 06:37 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
TFMurphy
Level: Smitemaster
Rank Points: 3117
Registered: 06-11-2007
IP: Logged
icon Re: Telepathic eyes. (0)  
They're not telepathic: they're just treating any Clone as a target that can wake them up, just like Decoys. Clones are considered valid 'appearances' for monsters to mistake as the player, even though their "target finding" routine won't search for them. Stalwarts are the same.

Note that it doesn't *have* to be an actual Clone, Decoy or Stalwart. Characters using any of these appearances will also wake up eyes. (Characters using Beethro appearance don't, amusingly enough)

Changing this isn't too difficult: the important function is bIsMonsterTarget in MonsterFactory.h (which tests for Clones, Decoys and Stalwarts). *What* to change is another matter and up for debate (adding Beethro might be an idea, for example).

Oh, and just to note what other uses bIsMonsterTarget has, it's also used by Guards (but they assume that they're already looking at either the player, a decoy or a stalwart), standard Monsters (only for checking whether the player is Player Roled into one of the three) and Swordsmen (as part of their IsTarget routine, but this seems to be only used for detecting the player, so it goes back to Player Role Clone again). So we can keep that in mind. If we don't want to change bIsMonsterTarget, then we can simply have Evil Eyes have their own MonsterTarget routine to keep things easy.

[Last edited by TFMurphy at 10-08-2007 07:18 PM]
10-08-2007 at 07:11 PM
View Profile Send Private Message to User Show all user's posts This architect's holds Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 5056
Registered: 02-04-2003
IP: Logged
icon Re: Telepathic eyes. (0)  
TFMurphy wrote:
Note that it doesn't *have* to be an actual Clone, Decoy or Stalwart. Characters using any of these appearances will also wake up eyes. (Characters using Beethro appearance don't, amusingly enough)

Changing this isn't too difficult: the important function is bIsMonsterTarget in MonsterFactory.h (which tests for Clones, Decoys and Stalwarts). *What* to change is another matter and up for debate (adding Beethro might be an idea, for example).
Yikes. Beethro NPCs should be added to that set of entities that can wake evil eyes.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.
10-08-2007 at 07:17 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
Jacob
Level: Smitemaster
Rank Points: 3741
Registered: 10-01-2004
IP: Logged
icon Re: Telepathic eyes. (0)  
TFMurphy wrote:
They're not telepathic: they're just treating any Clone as a target that can wake them up, just like Decoys. Clones are considered valid 'appearances' for monsters to mistake as the player, even though their "target finding" routine won't search for them. Stalwarts are the same.

I'd understood that the clones were being treated as decoys. The telepathy thing was a joke and you don't even need the top eye to demonstrate this behaviour. I still think this is a bug, or at least unintuitive behaviour. This is how I understand it:
1) Decoys will activate eyes if in line of sight even if Beethro's invisible and even if they're outside of "smelling" range.
2) Visible Beethro/clone will activate eyes only if in line of sight.
3) Invisible Beethro/clone will only activate eyes only if in line of sight and in smelling range (if you start up the hold and wait, the bottom eye does not become active)
This hold (and variations) demonstrates that
4) Inactive and invisible Beethro/clone will activate eyes if in line of sight EVEN IF outside of smelling range. (If you start the demo and switch to the clone, the bottom eye does become active. Equally, if you stay as Beethro, the top eye becomes active - which is expected)
So clones and Beethro switch to decoy behaviour when inactive. In other words, they gain the ability to activate eyes outside of smelling range when invisible and in the eye's line of sight. I don't understand why this should be the case.

____________________________
New to DROD? You may want to read this.
My Holds and Levels:
Click here to view the secret text


[Last edited by Jacob at 10-08-2007 08:30 PM]
10-08-2007 at 08:28 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
TFMurphy
Level: Smitemaster
Rank Points: 3117
Registered: 06-11-2007
IP: Logged
icon Re: Telepathic eyes. (+1)  
My assertation was more based on clarifying that you didn't even need to activate an eye with an in-range active clone to get the other eye to activate - the subject title and your first sentence seemed to initially suggest "one eye talking to the other".

Anyways, regarding your more detailed notes, invisibility only protects the player - clones do not inherit it unless they are active.

That said, Clones also activate eyes even if the current Player Role is not something that would currently wake eyes. So two decisions should probably be made:

1) Should Clones of differing player roles activate eyes if the Player is not a target?

2) Should Clones of the player be invisible if the player is invisible?

Both of these would require slightly more involved code for Evil Eyes. Let's see...

MonsterFactory could have bIsMonsterTarget changed such that M_CLONE tests both the wAppearance of the swordsman and bIsTarget. Not sure how best to do that just yet.

As for (2), if we wanted clones to inherit invisibility, we'd have to have a seperate check for them alone, and it would have to be for *actual* clones and not characters with the M_CLONE appearance. That's a little more involved too, and it also depends on how bIsMonsterTarget is changed, so that bears some thinking about.
10-08-2007 at 09:26 PM
View Profile Send Private Message to User Show all user's posts This architect's holds Quote Reply
Jacob
Level: Smitemaster
Rank Points: 3741
Registered: 10-01-2004
IP: Logged
icon Re: Telepathic eyes. (0)  
Sorry about the confusion. My point is really as expressed in the second post; it's just coincidental that one eye is activated at the same time as the other.

I now understand what's going on - clones and Beethro (as demonstrated in the example hold, and this is replicable in other situations too) lose invisibility when not active, allowing them to behave like decoys.
It seems to me that they shouldn't. After all, Beethro has drunk the potion, and once you switch back to him, he's still invisible. Furthermore, invisibility is inherited by clones, which is evident when you stitch to them. Why anyone should lose it is unclear. Admittedly, one could make some cool puzzles from this (limited, I think, solely to the interaction with eyes), but still...
So my answer to your question number 2 is Yes, in my view. (I'm assuming you're referring to what happens when they're inactive)

About question 1 - I'm confused, can the clone be different to the player (e.g. goblin player with Stalwart/Beethro clone). I've never been able to generate this, and if not, I don't understand what you mean. If the behaviour is that cloned goblins activate evil eyes, while goblins (player goblins, that is) don't, then this is counterintuitive.

I get the feeling I'm not understanding question 1. But I'd say that clones of the player should activate the eyes in the same way the player role would.


____________________________
New to DROD? You may want to read this.
My Holds and Levels:
Click here to view the secret text

10-08-2007 at 09:44 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
TFMurphy
Level: Smitemaster
Rank Points: 3117
Registered: 06-11-2007
IP: Logged

File: DROD Evil Eye.patch (2.8 KB)
Downloaded 18 times.
License: Public Domain
icon Re: Telepathic eyes. (+3)  
By question 1, I did indeed mean that a Goblin Player Role that was currently being ignored by Evil Eyes could have clones that were not ignored, yes. Clones always mimic the player's appearance, even NPC clones.

===

Anyways, been looking at (2) (whether clones should be invisible or not) to see what all it would require if changed, since (1) seems to require a bit more tinkering with underlying code for various places, if we want to do it properly. (2), on the other hand, is doable just with EvilEye.cpp.

The attached code are the changes I've been testing. I switched wSX and wSY to find the player exactly since GetSwordsman isn't very useful in this context: we don't care about NPC Beethros unless our gaze passes over them, and if it does, we'll find them normally through GetMonsterTypeAt and bIsMonsterTarget (once it detects M_BEETHRO, anyways) to identify them and wake up. They'll never be invisible, so we only have to care about the player.

I seperated out bPlayerIsTarget and bPlayerVisible so that we can combine the check for clones and player at the same time. This way, we check against bPlayerIsTarget as a hard restriction on whether real clones (and the player) can be detected. bPlayerVisible, however, is overruled as usual by being within the smell range of the eye.

I also put in a way to tell the difference between an NPC and a real clone, because real clones can be invisible (the only reason NPCs should be detected are their appearance - I don't think they should mimic invisibility as well). However, this is kind of a kludge, and mostly due to the fact that I had to have EvilEyes explicitly test bPlayerIsTarget even for NPC Clones.

The ideal solution is to fix bIsMonsterTarget - if that's done to only allow M_CLONE to pass if the player is a target, then that's great, and this part of the code can be rewritten a little better: we could defer the NPC Clone testing to bIsMonsterTarget instead of lumping it with the bPlayerIsTarget portion of the if statement.

Still not sure exactly how best to go about bIsMonsterTarget though.

Anyways, that's what I've got so far.
10-08-2007 at 10:49 PM
View Profile Send Private Message to User Show all user's posts This architect's holds Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 5056
Registered: 02-04-2003
IP: Logged
icon Re: Telepathic eyes. (0)  
TFMurphy wrote:
Still not sure exactly how best to go about bIsMonsterTarget though.
Offhand, I'd say a simple and powerful way to implement this change is to make this a virtual method:

virtual bool CMonster::IsMonsterTarget() const {switch (this->eType) {... } }

and override it for CClone and CCharacter (that's probably it) wherever specific monster or player state needs to be queried for the entity in question.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.
10-09-2007 at 04:34 AM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
TFMurphy
Level: Smitemaster
Rank Points: 3117
Registered: 06-11-2007
IP: Logged
icon Re: Telepathic eyes. (0)  
Heh, yeah, that would work. I'd gotten as far as thinking of some kind of wrapper function, but got distracted by other things, and my lack of experience was hindering seeing that so simply.

In that case, wouldn't we just use virtual bool IsMonsterTarget() const {return false;} for Monster.h, override it for Stalwarts and Decoys with 'return true', and that would then just leave Clone and Character, which can easily query the player's appearance.

Hmmm... though that'd still need a way of dealing with the player. IsFlying (as an example) gets around it by having a seperate function back in MonsterFactory.h which only contains roles for the player and characters. If such a function was coded for the player only and used to check for player-cases, that should work.

If that sounds good and doesn't have any glaring errors in it, I'll see how the actual code in practice works on my version of the source.
10-09-2007 at 04:58 AM
View Profile Send Private Message to User Show all user's posts This architect's holds Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 5056
Registered: 02-04-2003
IP: Logged
icon Re: Telepathic eyes. (0)  
TFMurphy wrote:
In that case, wouldn't we just use virtual bool IsMonsterTarget() const {return false;} for Monster.h, override it for Stalwarts and Decoys with 'return true', and that would then just leave Clone and Character, which can easily query the player's appearance.
Exactly!
Hmmm... though that'd still need a way of dealing with the player. IsFlying (as an example) gets around it by having a seperate function back in MonsterFactory.h which only contains roles for the player and characters. If such a function was coded for the player only and used to check for player-cases, that should work.
Sorry, I'm tired now and don't remember what the case involving the player was. I'll reread the thread in the morning, but I trust your judgment. You know what you're doing.
If that sounds good and doesn't have any glaring errors in it, I'll see how the actual code in practice works on my version of the source.
On a related note, it was a design decision to have clones not inherit the player's invisibility state when the player transfers to one of them -- that attribute just follows the player wherever he goes. That was in part due to programmer laziness and time constraints. However, if altering this behavior wouldn't affect any current holds, I personally don't have a problem with changing this behavior in the next patch if it seems useful to modify. I'm ambivalent about that myself, though.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

[Last edited by mrimer at 10-09-2007 05:37 AM]
10-09-2007 at 05:35 AM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
Jacob
Level: Smitemaster
Rank Points: 3741
Registered: 10-01-2004
IP: Logged
icon Re: Telepathic eyes. (0)  
mrimer wrote:
On a related note, it was a design decision to have clones not inherit the player's invisibility state when the player transfers to one of them -- that attribute just follows the player wherever he goes.

What?? But clones do inherit invisibility! (I.e. make a clone, make Beethro step on an invisibility potion - Beethro is invisible, switch to clone - the clone is invisibile). That's what this post hinges on really. I'm pretty sure this behaviour has been used (at least in a contest entry in Sept '07's contest).

____________________________
New to DROD? You may want to read this.
My Holds and Levels:
Click here to view the secret text

10-09-2007 at 11:31 AM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
Briareos
Level: Smitemaster
Avatar
Rank Points: 3516
Registered: 08-07-2005
IP: Logged
icon Re: Telepathic eyes. (+1)  
Jacob wrote:
mrimer wrote:
On a related note, it was a design decision to have clones not inherit the player's invisibility state when the player transfers to one of them -- that attribute just follows the player wherever he goes.
What?? But clones do inherit invisibility! (I.e. make a clone, make Beethro step on an invisibility potion - Beethro is invisible, switch to clone - the clone is invisibile).
I guess what he meant was that not all clones automatically have the same visibility as Beethro - i.e. the player's invisibility is not automatically inherited by all existing and future clones, but it's only transferred along with "Beethro's conciousness", so to speak.

____________________________
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
R.I.P. Robert Feldhoff (1962-2009) :(
10-09-2007 at 11:46 AM
View Profile Send Private Message to User Send Email to User Visit Homepage Show all user's posts Quote Reply
TFMurphy
Level: Smitemaster
Rank Points: 3117
Registered: 06-11-2007
IP: Logged

File: DROD Evil Eye Take 2.patch (8.5 KB)
Downloaded 20 times.
License: Public Domain
icon Re: Telepathic eyes. (+3)  
Here's version 2 of the modifications. It includes both (1) and (2), but it's pretty easy to disable either.

To disable (1) (Clones of different player roles being a target): simply don't have an override for IsMonsterTarget Clones and remove the Clone check for the override in Character.cpp.

To disable (2) (Inactive clones are not invisible): remove the M_CLONE check when bIsTarget is set, and simply set it true in all cases if the Monster is a target.

I went for a base IsMonsterTarget routine of return bIsMonsterTarget(this->wType); and left bIsMonsterTarget in: that way we can use either as necessary and it's easier to update. As a result, I didn't need to override for Stalwarts and Decoys (I think this is what you were originally driving at - hard-coding a return true or return false is just more work if we already have bIsMonsterTarget to update). Clones and Characters still needed overrides of course.

For clones, I have them defaulting to being targets if pCurrentGame doesn't exist or the Player is using M_NONE (in either case, clones will default to looking like clones, so this seemed like the best way to handle these cases). They're easily changed if we want something different. Tests that revolve around the player only still use bIsMonsterTarget, which is fine.

I've also mucked around with that little pre-2.0 kludge you had in by changing it into a Do-While loop relying on a boolean test done at the start of each loop (but only terminating at the end of each loop). I did this primarily because the kludge completely duplicates effect code, so any change would've required changing both copies - this didn't seem very nice.

However, while I was looking at it, I noticed two things with the original code, which seemed to be bugs to me, which this combination into Do-While fixes. These are the apparent bugs, both of which occurring if the player (well, any target anyways, but player is easiest to see) is on top of an obstacle that blocks the eye's gaze and is invisible:

1) If the player is exactly 5 squares away from the Evil Eye, then the Evil Eye doesn't wake. This occurred because wDist was increased a further time (to 6 if the obstacle was 5 squares away) before the "object on obstacle" kludge was used. I checked to see if this was really compatible with pre-2.0, but DROD:AE wakes up eyes when you're on the first obstacle even if you're 5 squares away. So this seems like a bug. (Oh, JtRH has this same code, so if this is fixed, then JtRH will need changing too.)

2) If the player is invisible, it usually can't be seen by the reflected gaze of an eye. However, if the player is on an obstacle and the length of the gaze is 4 or less (5 or less if the above fix is used), then the eye will wake up because bReflected isn't checked. Again, this seems inconsistent, and is due to a difference between the two effect codes: perhaps introduced when Mirrors were added to the first part but not the second?

Anyways, I've tested the current code with characters of various appearances, real clones, real stalwarts, different player roles, invisibility, and losing stealth in the majority of these combinations - haven't seen any problems yet. Haven't seen any demo breakages in TCB and a few other quick test holds either (is there an easy way to get DROD to report back all demos that seem corrupt to it?) That's not to say that no bugs can possibly exist - but if they do, they're being less than obvious.

Hope that all helps.

[Last edited by TFMurphy at 10-09-2007 04:21 PM]
10-09-2007 at 03:36 PM
View Profile Send Private Message to User Show all user's posts This architect's holds Quote Reply
Briareos
Level: Smitemaster
Avatar
Rank Points: 3516
Registered: 08-07-2005
IP: Logged
icon Re: Telepathic eyes. (+1)  
TFMurphy wrote:
is there an easy way to get DROD to report back all demos that seem corrupt to it?
Deleting all demos for some/all holds then importing a player export with demos for them should log corrupt demos to drod.log.

np: Supermayer - The Lonesome King (Supermayer Save The World)

____________________________
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
R.I.P. Robert Feldhoff (1962-2009) :(
10-09-2007 at 03:54 PM
View Profile Send Private Message to User Send Email to User Visit Homepage Show all user's posts Quote Reply
TFMurphy
Level: Smitemaster
Rank Points: 3117
Registered: 06-11-2007
IP: Logged
icon Re: Telepathic eyes. (0)  
Ahah. Though now that I try that, I note that it deletes broken demos when it does so. Useful for a player... a little inconvenient for when I want to see *why* they broke. Ah, well, I guess I'll just be sure to backup files each time I want to try this. Thanks.
10-09-2007 at 04:10 PM
View Profile Send Private Message to User Show all user's posts This architect's holds Quote Reply
Briareos
Level: Smitemaster
Avatar
Rank Points: 3516
Registered: 08-07-2005
IP: Logged
icon Re: Telepathic eyes. (+1)  
TFMurphy wrote:
Ahah. Though now that I try that, I note that it deletes broken demos when it does so. Useful for a player... a little inconvenient for when I want to see *why* they broke.
Uh... how about actually commenting out that part while you're hacking away at the code anyway? :P

But TBH, I wish this was entirely optional (flag in the INI file?) so I as a player could also compare what exactly went wrong...

np: Supermayer - Planet Of The Sick (Supermayer Save The World)

____________________________
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
R.I.P. Robert Feldhoff (1962-2009) :(
10-09-2007 at 04:29 PM
View Profile Send Private Message to User Send Email to User Visit Homepage Show all user's posts Quote Reply
TFMurphy
Level: Smitemaster
Rank Points: 3117
Registered: 06-11-2007
IP: Logged
icon Re: Telepathic eyes. (0)  
Briareos wrote:
Uh... how about actually commenting out that part while you're hacking away at the code anyway? :P

Eh, means having to change it every time I get a new version of the source, having to edit it out every time I make a new diff patch, and finally worrying whether I might have introduced a bug by commenting out the wrong thing ^_^; Altogether not really worth it when I can just backup the files and be done with it.

But yes, an option would be nice.
10-09-2007 at 04:37 PM
View Profile Send Private Message to User Show all user's posts This architect's holds Quote Reply
Jacob
Level: Smitemaster
Rank Points: 3741
Registered: 10-01-2004
IP: Logged
icon Re: Telepathic eyes. (0)  
Sorry, just to confirm, is it intended behaviour for a clone to lose invisibility when not controlled by a player or a bug?

I can see that this is an optional change in your patch, but what is the "canonical" behaviour that's going to be used in 3.1?

I guess this question is aimed at mrimer.

____________________________
New to DROD? You may want to read this.
My Holds and Levels:
Click here to view the secret text

10-22-2007 at 09:44 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 5056
Registered: 02-04-2003
IP: Logged
icon Re: Telepathic eyes. (0)  
The intended behavior in 3.0 was that only the "active clone" (i.e. the player) has invisibility. For 3.1...I haven't decided whether to change this. I don't know which published rooms it would affect, which influences our decision.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.
10-23-2007 at 07:48 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 5056
Registered: 02-04-2003
IP: Logged
icon Re: Telepathic eyes. (0)  
I've looked through the code changes and I'm tentatively okay with them as I understand them. To make sure I understand correctly, the changes in diff#2 are (tell me if I'm wrong):

* Clones (including NPC clones) are now targetable when and only when the player is targeted by monsters
* Fixed a problem with evil eye's wakeup criteria on edge cases

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.
11-01-2007 at 09:52 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
TFMurphy
Level: Smitemaster
Rank Points: 3117
Registered: 06-11-2007
IP: Logged
icon Re: Telepathic eyes. (0)  
Pretty much. Clones (both normal and NPCs) rely on the player being the target (and default to targets if the player is not in the room). The largest difference between a normal Clone and an NPC one is that NPCs don't inherit the player's invisibility, while with the Take 2 patch I posted, normal inactive Clones *do* inherit invisibility.

If we don't want inactive clones to be invisible, then just remove the check in the Evil Eye's gaze code:
   bIsTarget = pMonster->wType == M_CLONE ? bPlayerVisible || bCanSmell : true;


Not sure if any rooms actually use invisible Clones - maybe someone could run a quick search to see how many rooms have both Invisibility Potions and either Clones or Clone Potions?

And yeah, the recode to change the while loop into a do/while loop helps fix the two edge cases regarding an invisible player standing on a wall/obstacle either in the reflected line of sight or on the edge of an Evil Eye's gaze.

[Last edited by TFMurphy at 11-01-2007 10:09 PM]
11-01-2007 at 10:08 PM
View Profile Send Private Message to User Show all user's posts This architect's holds Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 5056
Registered: 02-04-2003
IP: Logged
icon Re: Telepathic eyes. (0)  
Okay. Since clones now properly share invisibility, I'm making a change in the front end so they also appear invisible (i.e. transparent) to the player so they understand the state is shared, but I don't think I should draw AOEs or anything like for the player.

I think you're more familiar with how the edge cases work for eyes than I am at present. What should the fix for 2.0 code be? Just making the exact same changes as you made here?

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

[Last edited by mrimer at 11-01-2007 10:17 PM]
11-01-2007 at 10:13 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
TFMurphy
Level: Smitemaster
Rank Points: 3117
Registered: 06-11-2007
IP: Logged
icon Re: Telepathic eyes. (+1)  
I think the big thing was that there was the "++WDist" at the start of the kludge: since it already did this at the end of the while loop, it increased the distance by one more than necessary.

However, simply making the changes I did to implement the whole thing into a single loop should do the trick, since there's no difference in the actual execution part of the loop. Just to explain how the change I made work: bContinueGaze is a boolean that takes the result of bContinueGaze. Whether it's true or false doesn't matter until after the current loop finishes, so even when it's false, we can still continue to check the results of the gaze hitting the obstacle before the loop ends.

Technically, since bContinueGaze starts as true, we could use a while loop instead of a do/while loop: it doesn't actually matter whether it's checked at the end of the current loop or the start of the next loop.

Also, while I'm looking at this again, it occurs to me that we might not have enough out-of-bounds checking. Not sure if it'll affect anything, but at the moment, we're still considering the loop effects even if the gaze ends by going off the room's edge. Might be an idea to have an additional check there and only run the loop's effect if we have a valid square to work with.
11-01-2007 at 10:38 PM
View Profile Send Private Message to User Show all user's posts This architect's holds Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 5056
Registered: 02-04-2003
IP: Logged
icon Re: Telepathic eyes. (0)  
TFMurphy wrote:
Also, while I'm looking at this again, it occurs to me that we might not have enough out-of-bounds checking. Not sure if it'll affect anything, but at the moment, we're still considering the loop effects even if the gaze ends by going off the room's edge. Might be an idea to have an additional check there and only run the loop's effect if we have a valid square to work with.
Yeah, we should break if the gaze has exited room boundaries. I've made this change in build 58.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.
02-28-2008 at 06:08 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
New Topic New Poll Post Reply
Caravel Forum : DROD Boards : Bugs : Telepathic eyes. (3.1.48 (but not apparently addressed since))
Surf To:


Forum Rules:
Can I post a new topic? No
Can I reply? No
Can I read? Yes
HTML Enabled? No
UBBC Enabled? Yes
Words Filter Enable? No

Contact Us | CaravelGames.com

Powered by: tForum tForumHacks Edition b0.98.8
Originally created by Toan Huynh (Copyright © 2000)
Enhanced by the tForumHacks team and the Caravel team.