ID:2963265
 
Not a bug
BYOND Version:516.1655
Operating System:Windows 11 Home 64-bit
Web Browser:Chrome 132.0.0.0
Applies to:Dream Maker
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:

You get an undefined proc error when calling Click() on /image.

Numbered Steps to Reproduce Problem:

Go in a project and attempt to use the Click() function on an /image object.

Code Snippet (if applicable) to Reproduce Problem:
/image/Click()


Expected Results:

For the object to be clicked.

Actual Results:

Undefined proc error.

Does the problem occur:
Every time? Or how often?
Yes
In other games?
In other user accounts?

Kozuma3 encountered this error: (override_before_def): Click: procedure override precedes definition

On other computers?

When does the problem NOT occur?

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

Workarounds:

No Workarounds.
From the ref:
The /image type contains data used to create a virtual image. Unlike other atomic objects, this object is a purely visual effect. It always appears attached to some other object and it behaves in every way as though it were part of that object (e.g. if the user clicks on it, this counts as a click on the atomic object, not the image).

Images do not have mouse procs by design.
I told Karoth but he didn't believe me
Spevacus resolved issue (Not a bug)
It do be like that sometimes.
In response to Spevacus
Wild that Click() works on /images in previous versions. It's like no one did any research to confirm this bug report.
I downgraded to 515-1636 and it was possible to use mouse procs on /image.
In response to Shadowkaroth
Shadowkaroth wrote:
Wild that Click() works on /images in previous versions. It's like no one did any research to confirm this bug report.

The bug report section does contain a section to mention the last version that this worked on, which wasn't filled out for this report. There's no need to get salty about it., especially since the documentation says that this is intended behaviour.
I just tested this in 515.1647, and I get a compiler error with
image/Click()

which would indicate that it hasn't functioned since before the last major version change.
In response to Shadowkaroth
Shadowkaroth wrote:
Wild that Click() works on /images in previous versions. It's like no one did any research to confirm this bug report.

Bug reports are meant to be self-contained and supply the necessary details to reproduce the problem. I operated based on what I had.

If you have more proper reproduction steps, I'll happily reopen, or otherwise advise to file a different post.
Ah, hm, now I kinda grok the situation.

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.
Tests:

/*
These are simple defaults for your project.
*/


world
fps = 25 // 25 frames per second
icon_size = 32 // 32x32 icon size by default

view = 6 // show up to 6 tiles outward from center (13x13 view)

maxx = 100
maxy = 100
maxz = 1


// Make objects move 8 pixels per tick when walking

mob
icon = 'world.dmi'

Login()
..()
var/image/i = new/image/sometype()
i.loc = src
client << i

Click()
world.log << "mob"

image/sometype
icon = 'test.dmi'

Click()
world.log << "Image"













Version: Compiles: Output:
510 Yes "mob"
511 Yes "mob"
512 Yes "mob"
513 Yes "mob"
514 Yes "mob"
515.1590 Yes "mob"
515.1637 Yes "mob"
515.1638 No N/A
515.1647 No N/A


I found no version where the undefined behavior of mouse procs on images functioned, and I don't particularly feel like digging back to a version old enough to be potty trained.

Defining mouse procs on image types was always undefined behavior. At best, it does absolutely nothing. It looks like this functionality was lost in 515.1638.

ShadowKaroth wrote:
Wild that Click() works on /images in previous versions.

When you say works, do you mean it COMPILES, but leaves broken code in your project that will never be called, or do you mean... Actually calls Click() on an /image instance? Because if you have a version number I'm interested. If that's been the case, Dan, Tom, Lummox, everyone else in the community, and I have been teaching this concept wrong since forever.
It looks like it's just an undocumented change to the compiler that wasn't listed in release notes, which there have been a few that I've seen over the last few months.

I went back and tested 1637 as well and it compiles there, so somewhere between then and 1647 was the change.

According to the ref, though, it's intended, so I'd still put my money on "Not a Bug".
In response to Ter13
As F0lak said, at least up till then Click() is fully functional on images.
I said that it compiled, not that it was functional.
Ter's report is the one that mentions what it output.
In response to Shadowkaroth
Shadowkaroth wrote:
As F0lak said, at least up till then Click() is fully functional on images.

Click was NEVER fully functional on images.

You're complaining about a runtime existing that tells you that you are writing broken code. Well no shit. The docs tell you right there that it doesn't work.
In response to Ter13
You all seem wildly enraged with this. I said it was wild that something that I pointed out wasn't done wasn't done..

As Shade posted he was Correct. He was able to define Click() I only confirmed what he posted... He asked me first and I sent him here.

You can all go on with the energy though.
I'm not enraged, and I don't know where you're drawing that conclusion. I've only pointed out that the report wasn't properly filled out, and that it's a bit salty for you to call anyone else other than OP (or lummox, but it's saturdude) out for not looking into the details of the report.
In response to Shadowkaroth
Shadowkaroth wrote:
You all seem wildly enraged with this. I said it was wild that something that I pointed out wasn't done wasn't done..

As Shade posted he was Correct. He was able to define Click() I only confirmed what he posted... He asked me first and I sent him here.

You can all go on with the energy though.

Okay. Let's take it a step back; Did you ever confirm that the code that compiled was even capable of running in any prior version before you accused everyone in this thread of not doing their research?

You came on a bit strong, son. Then acted like nobody knew what they were talking about, and then wasted everyone's time.
In response to Ter13
Ter13 wrote:
Tests:

> /*
> These are simple defaults for your project.
> */

>
> world
> fps = 25 // 25 frames per second
> icon_size = 32 // 32x32 icon size by default
>
> view = 6 // show up to 6 tiles outward from center (13x13 view)
>
> maxx = 100
> maxy = 100
> maxz = 1
>
>
> // Make objects move 8 pixels per tick when walking
>
> mob
> icon = 'world.dmi'
>
> Login()
> ..()
> var/image/i = new/image/sometype()
> i.loc = src
> client << i
>
> Click()
> world.log << "mob"
>
> image/sometype
> icon = 'test.dmi'
>
> Click()
> world.log << "Image"
>













Version: Compiles: Output:
510 Yes "mob"
511 Yes "mob"
512 Yes "mob"
513 Yes "mob"
514 Yes "mob"
515.1590 Yes "mob"
515.1637 Yes "mob"
515.1638 No N/A
515.1647 No N/A


I found no version where the undefined behavior of mouse procs on images functioned, and I don't particularly feel like digging back to a version old enough to be potty trained.

Defining mouse procs on image types was always undefined behavior. At best, it does absolutely nothing. It looks like this functionality was lost in 515.1638.

ShadowKaroth wrote:
Wild that Click() works on /images in previous versions.

When you say works, do you mean it COMPILES, but leaves broken code in your project that will never be called, or do you mean... Actually calls Click() on an /image instance? Because if you have a version number I'm interested. If that's been the case, Dan, Tom, Lummox, everyone else in the community, and I have been teaching this concept wrong since forever.

FYI, since you seem to have Ter blocked. Click() on images is intended to pass to the atom that its attached to, an image not attached to an atom should not work with Click(). You might have a feature request youd like, but its not a bug.
Page: 1 2