NVIDEA Clipping Bug and Radeon Target Ring Bug Fix!
- Thread starter Sabraaz
- Start date
rawfullemayo
Dalayan Beginner
Chiming in to also +1 to the fix at post #71 in this thread. After a looong time of being frustrated with this bug, and having to run 3D Analyzer batch files, which seemed to frequently crash clients at zoning, etc., this completely fixed my problem and allows me to use EQW again. No first-person melee bug and targeting ring works. You are a god damned hero sodquester2.
Working on Win8.1 64-bit
Nvidia GeForce GTX 660
Working on Win8.1 64-bit
Nvidia GeForce GTX 660
Moraelintz
Dalayan Elder
Is there any way to push this out in the next patch?
Daffie
Dalayan Pious Diety
Did you do the hex edit correctly? I just tried walk/run and didn't have an issue.
Furrygamer
Dalayan Adventurer
I am pretty sure he is talking about with the patcher OR the program recommended on the first page.
Looking into whether or not this is something we could make standard in the patcher.
Either way, huge find sodquester. Will definitely be throwing you some fame and remaking this thread with your information at the top. Reply or send me a message with the character name you would like it on.
Either way, huge find sodquester. Will definitely be throwing you some fame and remaking this thread with your information at the top. Reply or send me a message with the character name you would like it on.
lynnettell
Dalayan Elder
Ditto to post 71. A few things for those of us who go WTF, edit WHAT?! I'm gonna break something...
I had to get HxD from cnet as well (just google it). Make sure on Win 7 you run as administrator.
Use CTRL G (thanks, Daffie!) to search for the listed offset. Where your cursor ends up is where you want to typey type the new stuff in. It automatically is set to overwrite, so don't be a dipshit like me the first time & try to delete & add new stuff in.
I just copied a copy of my .dll & tossed it in My Documents in case I did break something. When I messed up, I opened it again and said NO to saving changes.
EDIT: Forgot to add, THANK YOU! And yep, it works.
I had to get HxD from cnet as well (just google it). Make sure on Win 7 you run as administrator.
Use CTRL G (thanks, Daffie!) to search for the listed offset. Where your cursor ends up is where you want to typey type the new stuff in. It automatically is set to overwrite, so don't be a dipshit like me the first time & try to delete & add new stuff in.
I just copied a copy of my .dll & tossed it in My Documents in case I did break something. When I messed up, I opened it again and said NO to saving changes.
EDIT: Forgot to add, THANK YOU! And yep, it works.
Pecannius
Dalayan Elder
@sodquester2 deserves an ungodly amount of fame! Also thanks for including this in the patcher. Got all ready to try to get this working and just logged in instead to see it was already fixed. Woot!
jules4099
Dalayan Elder
I'll be mild disappointed if this doesnt happen.
If you're having issues with the patcher, make a thread in Technical Support with any info you have on the problem. Using the zip file is not a supported method of keeping your files up to date especially since it uses considerably more bandwidth if everybody were to use it each time a small file was changed.
This is a great fix, but I do question something about it.... I'm ignorant of the hex editing behind this fix and what actually makes it work, but I was under the (perhaps mistaken) impression that this all boiled down to something wrong with the way the SoD client renders things relative to X, Y, Z axes. This might have explained why, in specific zones and prior to this fix, a character standing at or very near to location 0, 0, 0 would occasionally see artifacts of the target ring circling the field of view. If the player would move forward strictly along the X axis, for instance, the ring would clearly move in a single (albeit completely wrong) direction until it slipped off the screen and disappeared unless the player backtracked near 0, 0, 0. In other words, the target ring was there all along but its coordinates were apparently not being matched up appropriately.
I could be imagining this, but I also wonder if this played into the way the /loc system's coordinates in our client are handled "backwards" to the way I apparently remember them on Live -- our coordinates are ordered Y, X, Z with the NW corner being positive/positive instead of X, Y, Z the NE corner being positive/positive.
Assuming there really is some strange disconnect between the way axes and rendering are handled, my question is this: Is the 3D targeting ring being "animated" properly? Obviously, it is being rendered correctly as we're all able to see what we're targeting, and the ring moves in tandem with the targeted PC or NPC, but is the actual animation of the ring itself actually supposed to "suck inward" toward the targeted PC/NPC at all times? I was under the impression that it was meant to be animated such that it circled about the character so that the target was all the clearer.
This pic shows an example of a custom targeting ring circa 2008, and although I'm unable to see it in action, it seems to me the guild's name ("Midnight Tempest") would have been animated such that it is meant to circle the player, with the ornamental/geometric circle pattern rotating a fixed distance about the player in order to give a clear designation as to what is being targeted. (If our "sucking inward" animation were applied, this guild name on this custom targeting ring would zoom inward every few seconds and be completely illegible, making such a custom targeting ring pointless in this first place....)
On the flip side, our fix yields a targeting ring that, as I said, constantly "sucks inward" toward the player, meaning that the ornamental/geometric circle pattern only comes around every ~4 seconds, and the rest of the time the target ring is just a nondescript (and somewhat hard to see) "cloud". Here is a screenshot of what the targeting ring looks like maybe 75% of the time, at least on my end:
However, every few seconds, it gets around to rendering the ornamental/geometric pattern which I believe is meant to animate about the Z axis of the player instead of intermittently being "sucked in" toward the player:
Am I imagining this whole thing? Is this entire, long-winded post unfounded?
Sorry to have wasted your time in reading it, if so!
But if there really is something to this, does it once again come down to a disconnect between X, Y, Z axes and 3D rendering? And if so, is there any way to "fix" this fix?
I could be imagining this, but I also wonder if this played into the way the /loc system's coordinates in our client are handled "backwards" to the way I apparently remember them on Live -- our coordinates are ordered Y, X, Z with the NW corner being positive/positive instead of X, Y, Z the NE corner being positive/positive.
Assuming there really is some strange disconnect between the way axes and rendering are handled, my question is this: Is the 3D targeting ring being "animated" properly? Obviously, it is being rendered correctly as we're all able to see what we're targeting, and the ring moves in tandem with the targeted PC or NPC, but is the actual animation of the ring itself actually supposed to "suck inward" toward the targeted PC/NPC at all times? I was under the impression that it was meant to be animated such that it circled about the character so that the target was all the clearer.
This pic shows an example of a custom targeting ring circa 2008, and although I'm unable to see it in action, it seems to me the guild's name ("Midnight Tempest") would have been animated such that it is meant to circle the player, with the ornamental/geometric circle pattern rotating a fixed distance about the player in order to give a clear designation as to what is being targeted. (If our "sucking inward" animation were applied, this guild name on this custom targeting ring would zoom inward every few seconds and be completely illegible, making such a custom targeting ring pointless in this first place....)
On the flip side, our fix yields a targeting ring that, as I said, constantly "sucks inward" toward the player, meaning that the ornamental/geometric circle pattern only comes around every ~4 seconds, and the rest of the time the target ring is just a nondescript (and somewhat hard to see) "cloud". Here is a screenshot of what the targeting ring looks like maybe 75% of the time, at least on my end:
However, every few seconds, it gets around to rendering the ornamental/geometric pattern which I believe is meant to animate about the Z axis of the player instead of intermittently being "sucked in" toward the player:
Am I imagining this whole thing? Is this entire, long-winded post unfounded?
Sorry to have wasted your time in reading it, if so!But if there really is something to this, does it once again come down to a disconnect between X, Y, Z axes and 3D rendering? And if so, is there any way to "fix" this fix?
Daffie
Dalayan Pious Diety
EQ Interface has a ton of custom target rings. You can check them out to see if they move or not: http://www.eqinterface.com/downloads/index.php?cid=72&dp=0&sh=full&so=desc&sb=lastupdate For example, I am using the Silver Dream from Silver's Dream
Edit - If you open your own TargetIndicator.ini and find/replace
Edit - Just to give some more info I found about the TargetIndicator.ini:
Edit - If you open your own TargetIndicator.ini and find/replace
with
The pulsing issue will be fixed. (If the game is running, you need to physically use the command "/indicator on" in order to load your changes. I actually added this little tip to the .ini.) I've upped a re-formated TargetIndicator.ini that already has this done: TargetIndicator.ini
Edit - Just to give some more info I found about the TargetIndicator.ini:
Code:
[instructions]
Overview
--------
The target indicator is 4 concentric circles textured in such a way that a repeating
texure is UV animated towards the center. Each con color can have completely different
settings. It is not a particle effect, it is a specially generated procedural object that works independantly of other visual effects and can be toggled on/off in the options window. There is a command, /indicator [on|off] which performs the same function. When the indicator is turned on (via the typed command), this ini file is reloaded and exiting the game should not be required in order to tweak settings or images to your satisfaction.
Section: TargetIndicator
This section defines properties common to all indicators. The entries have the following purposes:
* Additive : Set this to 1 to enable additive rendering mode for the ring, 0 for alpha blend.
* PointCount : This is the number of points that the ring will use to define the circle.
There are four circles that reprsent the ring, each has their fade level determined by the fade/opaque settings above.
Sections: Trivial, VeryEasy, Easy, FairMatch, Difficult, Deadly, Assist, Mark0, Mark1, Mark2, Mark3.
These sections can be used to configure the target indicator differently for each consider type. The entries have the following purpose:
* Texture : The prefix of the texture to use. ".tga" is appended before opening. If FrameCount is above zero, it will format the filenames as "Texture%d.tga" to allow you to load any number of frames of animation to use for the indicator. Please note that this is a fairly memory intensive way to animate a texture so limiting the number of frames is a good idea. Performance may vary dramatically for various cards.
* FrameCount : How many frames of texture to try to load.
* Duration : How many milliseconds to show each frame of the animated texture. A value of zero will cause a new frame to be selected with each targetting change.
* TwistFactor : This is a control value that is intended to control how fast each circle of vertices in the target indicator rotates on the Z axis relative to each other. Changing this to any value besides 1.0 will probably not produce anything worth looking at, but it won't break anything either.
* TwistSpeed : This value was intended to rotate the entire indicator on the Z-axis but unfortunately it does not work as intended at this time. This will get corrected in the future but for now you probably want to just leave it at 0.0 unless you want the target indicator to "pulse".
* TextureScale : How much of the entire texture is visible at one time.
* TextureSpeed : How fast to move the texture towards the center in texels/msec.
* ScaleMin : Not used at this time. This and the other two scale values were intended to be used to expand the ring when targets are changed, but unfortunately this part was not completed.
* ScaleMax : Not used.
* ScaleSpeed : Not used.
* Alpha : The transparency, combined with any texture alpha values.
* Red, Green, Blue : Tinting (ie. Vertex color) for the ring.
* FadeStart : How far from the target does the ring begin to fade out.
* FadeEnd : The distance of the last visible point on the ring.
* OpaqueStart : The distance from the target that the ring begins to become visible.
* OpageEnd : The distance from the targe that the ring is fully visible
* InitialLength : This is an override on the FadeEnd value, and is intended to be used to make the ring quickly expand to full size using the GrowSpeed as the rate of expansion.
* GrowSpeed : How fast to expand the target ring to full size. A value of 1 will make it instantly appear.
* FloorOffset : How far off the ground to place the ring.
Last edited: