ID:1740451
 
Not a bug
BYOND Version:507
Operating System:Windows 7 Pro 64-bit
Web Browser:Firefox 34.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:
DM will not save more than 512 icon states in one file.
Numbered Steps to Reproduce Problem:
1. Create .dmi with 513 states.
2. Save .dmi
3. Reopen .dmi

Expected Results:
513 states in the file.
Actual Results:
States past 512 are removed.

Workarounds:
Using third-party tools.

Also see http://www.byond.com/forum/?post=1507331
This is a massive maintainability issue for SS13 projects. It would be a great boon to us if you could fix it.
Nadrew resolved issue (Not a bug)
This is intended, it prevents an overload which causes the IDE to crash, it's better to split files if they become this large to prevent issues further down the road.
Note: one change in this build is that DreamMaker will not load more than 512 states in an icon; this is in the interest of speed. I can't imagine this will mess up any games (you'd have to be referencing a high-number state on the map-editor or wanting to edit it in the icon-editor-- this has no bearing outside of DM); if it does, we can always up that or figure out another system.

we can always up that or figure out another system.

;-;
Why would you want 512 states in an icon anyways?
just curious does this include all the frames in a animation of a icon state? or just the individual icon states?
In response to Mastergamerxxx
Mastergamerxxx wrote:
just curious does this include all the frames in a animation of a icon state? or just the individual icon states?
Just the individual states.

Super Saiyan X wrote:
Why would you want 512 states in an icon anyways?
You wouldn't.

I guess Nadrew's right to close this since at this point nobody's pretending the DreamMaker IDE is going to be maintained past simple band-aid fixes.
I wonder if it would make more sense to support multiple pages of much less than 512 states, for icons with a ton of icon states. If the problem is having a list of more than 512 icon states, then why should it only be the first 512 states rather than 512 latter states?

not that I have any icons with 512+ icon states
lol my god the amount of flickering there would be for 512 icon states would take forever
Can I just ask why you need over 512 icon states?
In response to Lugia319
Lugia319 wrote:
Can I just ask why you need over 512 icon states?

we display the item a player is holding in his/her hand on their mob as a small sprite that is overlaid on the mob. these icons obviously have to be stored somewhere.
In response to Lugia319
Lugia319 wrote:
Can I just ask why you need over 512 icon states?
Let's be honest here, nobody does. SS13's usage (all items have their equipped graphics defined... in the same 2 files, one for right hand, the the other for left) only exists because none of the major projects have gotten around to refactoring it yet.

The only semi-valid potential applications I can think of involve doing hacky things with the RSC and caching very large subsets of high-res bitmap fonts, and I highly doubt anyone's itching to get into those.

But that doesn't make this any less of a bug. As they say, legacy support is like sex: one mistake and you have to support it for the rest of your life ;)
There's no reason you can't split up the icon file into 2 icon files though. It would probably make it easier to edit too. It's not a bug though.
I would say an intentional limitation to get around a crash qualifies as a bug.
Any IDE is going to have an upper limit on something or other. Bear in mind, having more than 512 states (to say nothing of animation!) means the image file is not only gigantic, but costs both DS and the server (when using the webclient) more power when trying to find the right icon state. I've seen much more extreme cases of this for some specialty lighting libs, and DS has to be altered at one point to prevent massive slowdowns from icons that used nearly 7000 states. Both DS and the webclient function a lot better now in that regard.

DM has long used a (subclassed) Windows list control to handle its icon list display. This control is known for some bad behavior when it's overloaded. Even when crashing isn't an issue, in large icons it was common for refreshing the list to cause severe non-responsiveness and flickering.