There are probably a few ways to fix it it but you're going down the right path if my understanding of how RunUO and Razor are handling the actions you describe, though the fix is a bit more involved than editing one file. To those people with more knowledge about this, I would think the most helpful thing you could do is privately message Telamon and inform him of other ways one can do this so it's ensured its covered at all angles. He's the RunUO expert, not me and since my previous post was misinterpreted and used by folks to fuel existing feuds, it's probably in my best interest to just watch from the sidelines and go back to my little corner of the UO:R world.
Interesting. In my fix, I did the opposite. Personally, I think you should always return the proper "too far away" to the user, regardless if you are truly too far away or if the item doesn't exist. So, if an item that once existed in the world is gone, it will still say you're too far away or whatever. That is true in some deep philosophical level, right? In your fix, if the item still exists in the world, but you are too far away, you aren't informed about it. I would think you should be. Stepping through the code, when the item no longer exists, the targeted object is null. During the check in RunUO, it checks if it's a land target, mobile, etc, etc. At the end when it can't figure (because it no longer exists in the UO world) it out it just cancels and doesn't send a message So adding.. Code: OnTargetOutOfRange(from, targeted); To the else statement (right above where you put your code @Rad ) in Target.cs will give you that message even if the item doesn't even exist. This way, if you're too far away, you're still notified about it, but if the item doesn't exist, you don't know because you still get the too far away message. Though like I said, I'm no RunUO expert so I'll defer to those who are, I'm sure he already has it fixed and doesn't need us haha but in my testing this appears to work but I could be missing a specific use case.
