Your suggestion would pointlessly over-complicate and confuse the language, without providing any additional functionality.
Associative lists could be implemented to allow both reading and writing of icon related variables, without needing to pointlessly change how icons are already handled.
You'd think that having separate objects to represent icons and icon states would complicate things, but it would simplify them. It's a little counterintuitive, but adding more objects and variables means more reference pages and cleaner documentation. It also means there's less guesswork on the developer's part because the objects more accurately resemble the entities you're dealing with.
Suppose a proc is passed an /icon datum and wants to create a new icon with the north and south states swapped. I'm not sure it's possible now, but with more fully fleshed out objects to represent icons and icon states it would be easily possible. I don't expect the staff will implement either of our solutions. Mine is too much work and yours doesn't seem to fit with the existing icon object. What seems most likely is that icon procs will be added to expose whatever properties are currently not available - an icon.Duration() proc similar to the existing Width() and Height() procs. I'm pretty sure it's possible to check if an icon state is a movement state though it's cumbersome, so that'd be a nice proc to have too. | |
An icon having a single state is pretty rare, and even more so a single frame.
How would an icon_state object (or whatever you're requesting) be put to practical use? I don't see how it would make swapping north and south animations any easier. And, from the sound of it, I would have to pointlessly swap out icon objects a lot more often. Creating an actual /icon object is already a pointlessly overcomplicated waste of resources, and required in places without notice. Your suggestion sounds like it would make things even worse, and doesn't even seem like it would address the original request here... or anything else for that matter. Your strongest argument for it seems to be more documentation, which is mostly irrelevant, and not even entirely true. A proc that returned all of this information at once would list all the information that could be returned, and what each of them represents, and it would have it all listed in a single place, instead of being spread across multiple reference pages. Similar to browse()'s entry; There are better examples, but I can't think of them off the top of my head... EDIT: Also, the information should be in some "readable" format, so that it can be dynamically looped through. Having a separate proc for each value would be tedious to work with, and would be much less effective in general. | |
An icon having a single state is pretty rare, and even more so a single frame. How else would you read or modify the duration of a single frame of an animation? You might think that certain cases are rare, but this is what I meant when I said that simplifying things often makes the easy case easier and the harder case even harder. I don't see how it would make swapping north and south animations any easier You could do something like this: var/temp = state.frame[NORTH] Swapping frames is just like swapping anything. You don't have to know too much about icons to figure this out. | |
I doubt that frame swapping could be possible, though I don't know much about how icon tags actually work.
To read the duration of a single frame of an animation, you could do something like icon.state_info["Walking"][NORTH][3]["frame_delay"], and to set it, just throw an =# on the end. I still don't see how you expect to be putting a /state object to practical use in a game. If swapping frames was actually that easy, then I see no reason why it couldn't be applied to the current /icon object. And I don't see how forcing your icons to be a single /state would be beneficial. | |
The duration property would only be used when the /icon datum represents a single state (or a frame of a state), not a collection of states. This is a messy situation because of the ambiguity of what an /icon datum can represent, but your suggestion only adds to the mess. I realize it's not likely to happen, but it needs fixing at a deeper level.