I came a bit strong.. I pointed out something that I clearly tested and that we pointed out I did.. YOU are the one worried about it being completely functional.. Sorry about m wording. I still pointed out something you all have went great lengths to make in to a greater issue. FFS.
'son'
Its WILD that this topic went this way. Homie, he was linked to the ref. The ref explains that images do not have mouse procs called. You came in, were an ass, had to be shown that what you were fighting for never worked in the first place, and now you're browbeating everyone else? This is ridiculous. You get a compiler error now telling you that you just wrote nonfunctional code. Why do you want the compiler to not tell you about nonfunctional code? | |
I have responded to him multiple times...
| |
Yes. You ignored that he DID have an error that presented to him that DIDNT before.. by saying he shouldn't have been able to in the first place... Why are you attempting so hard to be an ass?
| |
Shadowkaroth wrote:
The attitude to even have to have a conversation about his is again, wild. There wasn't really a conversation until you made your comment about testing the code ourselves though. OP made a bug report, someone else cited the ref that it was intended behaviour, happens all the time. Unfortunate that it was undocumented, yeah, but if this is the hill that everyone wants to fight for, I'll make myself a charcuterie board and put my pants on. The movie I was watching sucked anyway | |
Shadowkaroth wrote:
Yes. You ignored that he DID have an error that presented to him that DIDNT before.. by saying he shouldn't have been able to in the first place... Why are you attempting so hard to be an ass? OP didn't originally specify that issue was not present in earlier versions | |
I'm gonna step away from this, but like, this whole thing is monumentally stupid. This wasn't a bug. Mouse procs on images never worked by design, which is documented, and them compiling in the first place was probably a mistake.
ShadowKaroth wrote: YOU are the one worried about it being completely functional. I guess I confess having a hard time explaining why someone who has been using the engine, and helping other people develop games as long as you have, would advise a user to report a bug about code that won't compile, and is documented as not functioning by design... And then not care that the code wouldn't run even if it did compile after smugly lashing out at people who, you know, took the time to do the research you accused them of not doing. The only rational explanation I have is just that you're having an extremely hard time with either self awareness or humility. Both of the latter explanations track, frankly. | |
Ok great. So we all agree that this is a pointless conversation at this point and can leave it up to lumbum to review after the weekend.
Close the Blast Doors! | |
So it looks like I'm late to this party, but to add clarification, Spevacus described this change correctly.
This produces an error now when it didn't before. From my understanding the compiler generally seems to pick up on some things it didn't used to. I believe this is ideal since this was never intended to be supported. It is jarring for those who "relied" upon undefined behavior, though, I guess? I can't imagine an override for image/Click() would ever execute any code though. The compiler's understanding about what is and isn't available was refined in an undocumented change. Previously the compiler would allow that without raising an error, but that was incorrect behavior. The reason this happened was that when looking up whether a "hard proc" existed, the compiler was basically treating /image as /obj for that purpose. I believe this changed when I also removed access to vis_flags, which /image doesn't have either. | |
The attitude to even have to have a conversation about his is again, wild.
Shade deserved the respect of a better response. Its WILD that this topic went this way..