Superbike32 wrote:
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. Try making a change to the file (add a blank icon state). I also noticed that icons with just one single icon_state would not load on input(). | |
At this point in time I can only confirm that it hates DMI V3 icons where the icon state of the first or last icon is blank. This is what it looks like the problem is at least in some cases, there may be more cases, as more seemed to have been broken before, but these are what's not working right now...
| |
Superbike32 wrote:
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... Then you didn't turn it on correctly. If you did, the moment you connected/started a world, you'd get 3 lines of orange text in Ops/Messages. FIREking wrote: Super Saiyan X wrote: Different debug mode. This is a client-side debug. You have to run .configure debug on in "Options & Messages -> Client -> Command..." | |
I have re-tested, after configuring the setting initially, no messages, that is consistent, considering I didn't re-start it after modifying the option...
Anyways after re-starting & testing it states, BUG: Removing corrupt rsc entry 'overlay.dmi' Now the problem with this I don't know, the header is correct, it's showing as a BYOND V3 icon file header(.dmi), identical to all the other working BYOND V3 ones..this one doesn't have a blank empty state first or last like some of the other non-working ones... Anyways, regardless of what it states it doesn't matter unless there's an actual fix so reading off what it says is meaningless really...that's probably the only message it can show besides maybe security & if it was a security error, I wouldn't be stupid trying to select it... Also with an as file basis, it should have no sense of corruption regardless because you haven't done anything with it, you haven't told it what it is, making it assume it's an image & try to load it as one & seeing it's "corrupt" & not allowing it seems unusually stupid behavior, if you try & cast it as an image or set as an image initially, then yes, corruption messages if there's actual corruption should show up, but these "corrupted" files where the headers are perfectly fine even, it worked on versions below 468... If I compile my project in say 465 then update my code in the latest version, there's no bug either...which is very odd because it's the same code, same file...so apparentally there is a condition set somewhere like the compile version or something which is being set allowing it to work like it's supposed to when compiled FIRST by <468 - new projects this version is the cut-off point to be able to run newer games even though they don't use new features, so I am thinking that plays a large role in this, running different code based off compile version which makes this actually work correctly with icons that are V3 which are the ones i'm having trouble with, certain V3 icons. | |
Actually as before, stating compiling with 465 & it works in the later version is false, apparentally it's storing it in .dyn.rsc, knowing it has it, and the later version is loading it from the resource without problem, I assume...since it always says in debug mode it already had 1 of 1 resources even when there is no .dyn.rsc & you never selected the file via input() before, in any project.
Also it starts failing again when removing the .dyn.rsc file. They are valid files, I made sure of that much, as lots of old games icons do it, their headers are correct & they've worked in byond versions below 468. Any speculation on the actual problem is still unknown, but a problem like this HAS been fixed before, I just don't know the version, the bug-fix said something like... Certain icon files failed to load under certain conditions even though they were valid icon files. This bug may have been a long time ago though as I can't find the version it was bugged in or the bug report. When upgrading the icons to V4 they seem to work fine it seems but considering compatibility even with old icon files should be supported by newer versions...and not seemingly randomly declining some old icon files, this needs to be run through the debugger & seeing where it's marking the icon file as corrupted... Like I said the header seems fine though, but maybe it's not, I can only see so much without BYOND telling me what information they include in the header, how to read it & what valid headers are for V3 & V4 icons. | |
Would be more helpful if input could give us more reasons why null was returned.
| |
That would be helpful to notify the user what to do, but the files shouldn't be not working to begin with, however...if you could notify users that there is a problem with it, if the file is actually one that shouldn't work or maybe not an icon file at all, or something like that, you can notify them of what happened...
| |
If I wanted to write a game where users can upload their own player icons, I'd have to write a page long manual about how to "prep" your icon to work with the game in addition to explain that only certain version will work and how to check file headers to make sure they're valid, haha. Even then, input() wouldn't be able to guarantee us a reason of failure if there was one, and we'd be stuck dealing with the issue outside of the game and outside of the code. It's not ideal.
| |
Anyways yes, it opens with dream maker(to edit the icon, it doesn't corrupt the header...) this is intended behavior.