ID:1027734
 
BYOND Version:497
Operating System:Windows 8 Professional
Web Browser:Internet Explorer 10.0
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:

Numbered Steps to Reproduce Problem:
Create a new project with the code from the code snippet.

Code Snippet (if applicable) to Reproduce Problem:
/*
These are simple defaults for your project.
*/


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

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


// Make objects move 8 pixels per tick when walking

mob
// step_size = 8
Logout()
..()
del src
verb
Transform()
var/icon/a=input("Choose an icon from your system","Your Icon")as null|icon
if(!a)
world<<"For some reason we didn't see that you picked an icon file...weird I know..."
return
a=new(a)
if((input("Do you want to resize this icon to 96*96?","Resize Icon") as null|anything in list("Yes","No"))=="Yes")
a.Scale(96,96)
src.icon=a
var/sj=input("Type an icon state from that file.","Your Icon State")as null|text
if(sj)
src.icon_state=sj
//obj
// step_size = 8


Expected Results:
It would set your icon to any icon you want.

Actual Results:
90% of the time it fails, but it only happens on specific icons...

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

When does the problem NOT occur?
Not sure

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.)
I didn't download every version, but it's interesting to note it has been broken for a very long time....

It worked in 465 & broken again by 468...so it was somewhere around there...and i'm using 497, so that was quite a while ago...

It's interesting to note theres no problem if I create in 465 & run the project using 497, at that point everything works as expected, but if I compile with 497 it fails, as well as compiling with 468 makes it fail.

Even if I do clean compile with 497 & include new features it doesn't seem to fail as long as I had 465 to originally compile it once...

I don't have a specific version, I just know it's around 465-468, 465 works, 468 fails, I don't know about in-between.

It was interesting to note it said it was compiled for 468 or later though when I first tried to run it with 465, but i'm not using any features exclusive to 468 & compiling pre-468 it actually WORKS as expected.

Workarounds:
Compile any new projects using an early byond version, in my case byond versions below 468 seem to do the trick...

---As for icons to test with I was simply trying to set a placeholder icon from RoH.

http://www.byond.com/developer/hub/Xerse/RiseofHeroesSource

That's the link, it seems enemies.dmi will work, I click the icon, no error message about me "not having selected an icon" BUT when I select uniques.dmi it does give me the message.

It seems to be only certain icon files that produce a problem, and it's most of them...

I have a mix of icons that are 3.5 & 4.0 icons still, so i'm not sure if any of that plays a role or not & i'm pretty sure that I didn't upgrade any of the source icons to 4.0 from the RoH source, so it doesn't explain why some work & others don't.

However it seems that enemies.dmi is a large icon(many states) and all the others ive been trying are comparatively small & always fail, maybe it has to do with size of the icon, amount of states in the icon, or something like that...

------Hopefully it can be fixed, it's pretty annoying...I couldn't figure out why it wouldn't work, since the code looked solid & worked on other games I've been working on, but never worked in my new project.
I didn't think "as icon" gave you an icon object, but a file. Either way, it's safer to put the result in an icon() call. Try that.
Kaiochao, I did all that as well, it fails regardless, it's working in the byond version mentioned(pretty much anything below 468).

If you have done actual testing & have gotten something to work...it must be a clean project, compiled only with byond versions over byond 468 - then I will accept any working code you give me & test it...

But I have done extensive testing, lots of code, and it fails regardless of what I do...

Also tell me the byond version you have that it's working so I can do testing with that one, because no matter what I do it fails, like I said.
I can confirm that input() returns null on perfectly valid files sometimes.
A couple of things to note:

Corrupted icons (icons opened as an environment in Dream Maker, etc) will not register if you select them, and icons currently used in memory (such as if you have two servers open, and you've already used the icon on the first server by selecting it) will also not work.
In response to LordAndrew
LordAndrew wrote:
A couple of things to note:

Corrupted icons (icons opened as an environment in Dream Maker, etc) will not register if you select them, and icons currently used in memory (such as if you have two servers open, and you've already used the icon on the first server by selecting it) will also not work.

I was actually aware of this and made sure I was not running any DM instances or seeker / etc. It would still return null on valid files. But I have yet to try restarting my computer and seeing if there's some weird ghost hook somewhere holding on.

Edit: When you say "corrupted icons (opened as an environment in Dream Maker)", do you mean those icons are now forever unable to be opened by input() or that they're just not while they are open in another application process on the current operating system session.
In response to FIREking
In Dream Maker under File, there's an option called "Open Environment..." that can be used to open .dme files. Problem is, it works on any type of file and doesn't assert what you're opening is a .dme file. If you open a .dmi using this option, it damages the headers of the file that tell DM it's an icon file, making it no longer register as a valid icon.

See also: [Link]
In response to LordAndrew
LordAndrew wrote:
In Dream Maker under File, there's an option called "Open Environment..." that can be used to open .dme files. Problem is, it works on any type of file and doesn't assert what you're opening is a .dme file. If you open a .dmi using this option, it damages the headers of the file that tell DM it's an icon file, making it no longer register as a valid icon.

See also: [Link]

Ok, so this does not apply to my tests because I have not done that.

Edit: Ok, there's something to this. I wasn't aware that double clicking on a file in windows explorer was actually attempting to open the file as a DME in DM. So this means that quite A LOT of icon files on my computer are actually corrupted! How can we fix this, and how can we prevent this type of damage from happening in group projects (aside from informing everyone in the group not to do it).
So yeah, this bug can be closed. Icons that are doubled clicked in windows are automatically opened by Dream Maker as a DME which modifies the file's headers. Even though the file will continue to work in your games and development environments, it is not technically a valid DMI file until a change is made to the icon itself and then re-saved by Dream Maker (which will cause a new header to be written).
FIREking wrote:
So yeah, this bug can be closed. Icons that are doubled clicked in windows are automatically opened by Dream Maker as a DME which modifies the file's headers. Even though the file will continue to work in your games and development environments, it is not technically a valid DMI file until a change is made to the icon itself and then re-saved by Dream Maker (which will cause a new header to be written).


double clicking in Explorer does no such thing. Have you tried clearing your cache? or caught any resource errors.

if you enable debug mode, you will see such errors and notifications about resources. (.configure debug on) in the command prompt for seeker.
FIREking, I have re-saved files of my own, etc...and double-clicked them & checked headers myself, for the bug reported, my icon files are perfectly fine, but aren't working, if your files aren't correct in some way & re-saving is working for you, that's fine, but it's not working for me, considering the header isn't messed up to begin with.
In response to FIREking
I use the following code & I get the message when selecting perfectly fine files, hell no matter what the file is, an icon with a bad header, an icon not working for as icon() it should still load in, but i'm having problems selecting the same files using the code below that I have with using as icon...

mob
verb
Transform()
var/a=input("Choose an icon from your system","Your Icon")as file
if(!a)
world<<"For some reason we didn't see that you picked an icon file...weird I know..."


Now the better question is why is it not seeing the file, all it's supposed to be is a string of the location of the selected file or an internal reference for the file & it's data, depending on how it works...

So why are certain files, in this case i'm only having problems with icon files, I tested lots of regular files & they work...just failing to admit that I selected them?
...Have you cleared your cache?
In response to Super Saiyan X
I have myself plenty of times, doesn't do anything as I figured it wouldn't...don't know about fireking.
did you activate debug mode as my previous post suggested?
In response to Super Saiyan X
Using that suggestion nothing at all pops up anywhere, no other messages...nothing...it just shows the same message as per the code, as if no file was selected, in a statement for as file & not as file|null it's supposed to be impossible to get the message even, especially with no other errors, so i'm not sure why it's even broken.
The messages should appear in Options and Messages, in an orange text.
Super Saiyan X, there are no such messages when picking the file(in options & messages), nor to the default output pane(it's using the default interface), so it's not seeing that something is selected & for some reason doesn't have one of the things that will usually error at...

It's just failing...
Double clicking on an DMI file in windows explorer does indeed open it with dream maker. Not sure if dream maker corrupts the header or not, just saying what happens on my machine.

I opened every icon file on my computer last night, added a blank icon state, resaved the icon, NEVER opened the icon again by double clicking in windows explorer, and then every single file I did that to started to load with input().
In response to Super Saiyan X
Super Saiyan X wrote:
FIREking wrote:
So yeah, this bug can be closed. Icons that are doubled clicked in windows are automatically opened by Dream Maker as a DME which modifies the file's headers. Even though the file will continue to work in your games and development environments, it is not technically a valid DMI file until a change is made to the icon itself and then re-saved by Dream Maker (which will cause a new header to be written).


double clicking in Explorer does no such thing. Have you tried clearing your cache? or caught any resource errors.

if you enable debug mode, you will see such errors and notifications about resources. (.configure debug on) in the command prompt for seeker.

I haven't tried clearing my cache but I don't think the cache would apply when you're loading an external file with input() from a completely unrelated folder to the project.

There are no resource errors, and I always compile with debug mode on.
Page: 1 2