I got stuck at following problem:
The first time i hit something with trace everything works fine, but as soon as i dont hit the object anymore, the cast still returns a valid casted object and that from an “unkown” input.
I dont get why, it seems like the out value from the Cast is cached and taken from when i first hit something with the trace, but that does not seem to make any sense.
Following shots are while in debugging/simulation at same breakpoint, how is that possible? (box trace does not hit anything here (return value is false))
I think nodes with an execute pin do cache results, so that might explain something.
However, the whole point of using interfaces, is not to use casting. So it’s really one or the other, no point in mixing them.
And ( sorry to drag on ), but I notice what you’re doing here, is a interaction highlight system. I can tell you from writing one myself, and helping others with this, that it’s not possible to ‘un-highlight’ from a central piece of code like this.
Imagine I have a book on a table, and both are interactive. I mouse over the book, it highlights, but then I move the mouse onto the table. The system now can’t un-highlight the book, because the table is now the hit actor. It’s even worse if you have a timer on the highlight.
The solution is, to write a parent interactive blueprint that knows how to highlight itself. Then, all you have to do, is send it the highlight message, via an interface and you’re done
Thanks for the reply. WIth caching I meant “between 2 ticks” that would be a big flaw or am i wrong.
And ( sorry to drag on ), but I notice what you’re doing here, is a interaction highlight system. I can tell you from writing one myself, and helping others with this, that it’s not possible to ‘un-highlight’ from a central piece of code like this.
For that reasion i (want) unhint the object as soon as i target a new/different non hintable object (it was the plan at least). For that reason i also checking if the current highlighting object matches the one targeted in the last frame.
I will rethink about your logic, but for educational interrest, where is the error in my implementation. That caching idea was an educational guess but i cannot imagine its realy the problem, since it would break so many programming paradigms.
The cast fails, you then proceed to use the yellow pin later on, even though it’s not a blueprint.
Does this code come from a YT tuut? I had this exact discussion with someone else last year. They persevered for nearly a year, before realizing you can’t always remove the highlight from objects.
No not by a tutorial, just from me (im a professional programmer but not in blueprints so its VERY astounding that when the cast fails you get a valid object back WTF).
I will later try your aproach (just check if the object implements the interface by using “implements” function, which i did not find before (searching for docs about blueprints is still not that easy, i often dont find what i need, in other langs its easier).
Does this code come from a YT tuut? I had this exact discussion with someone else last year. They persevered for nearly a year, before realizing you can’t always remove the highlight from objects.
I dont quite understand what you mean? In my case i just want to show/hide a text on the object it self if you look at it and allways only one object, to indicate that user can interact with the object.
BUT! its just prototyping phase. The bigger problem was the weird behavior of the casting function.
You’ll find that setting and unsetting a variable is not enough, in the end. Because the player can mash the mouse around quickly and the code won’t have time to catch up.
You’ll find that setting and unsetting a variable is not enough, in the end. Because the player can mash the mouse around quickly and the code won’t have time to catch up.
I doubt that there is a catching up problem, since the code is still should be executed in a deterministic way.
