I've found several feature requests that relate to this:
http://www.byond.com/members/ DreamMakers?command=view_tracker_issue&tracker_issue=1221
http://www.byond.com/members/ DreamMakers?command=view_tracker_issue&tracker_issue=1713
http://www.byond.com/members/ DreamMakers?command=view_tracker_issue&tracker_issue=1220
But I haven't seen any with a response from the staff.
It would be nice to have a way to get more information about animated icon states at runtime. In particular I'd like to be able to figure out the duration of an animation.
ID:102814
 Oct 3 2010, 8:56 pm
|
|||||||
| |||||||
...You mean something like
Pixel 1: 0 Pixel 2: rgb(0,0,0,0) Pixel 3: rgb(255,0,0,150) Hot Spot: Pixel 1024 ? | |
Getting pixel color information is already doable. Though if it was somehow efficient to do this way then I suppose that would work.
I don't know how you're numbering pixels though... a coordinate system should work compared to whatever you're doing in your example. Hot Spot yes, as well as number of frames, delay on those frames, total duration of the state (though this could be determinable manually with the previous info), if its a movement state or not, if its set to rewind and/or how many times its set to loop, how many directions it has, etc | |
I support this, since 2 of those previous requests were mine =P
| |
Well this has been requested before and I just want to have another crack at it. Just wondering if there could be some way to find out how many frames there are in an icon? I mean something like icon.GetFrames(state) (look familiar?). Probably low priority but just want to at least get it on the list.
| |
Instead of having a proc that returns this information (because, knowing the BYOND staff, the proc would return a text string you'd have to parse to get the information), I'd rather see something like this. The server has this data about icons and animations, we shouldn't have to call proc to get it, there should be built-in objects with vars that expose these properties.
| |
Forum_account wrote:
...the proc would return a text string you'd have to parse to get the information... params2list() | |
I'm well aware that parsing a text string is possible, but consider which is easier:
// this: Having vars for all these things also means that they can be documented in their own reference pages. Instead of one huge page explaining everything that the icon_state_info proc does, you could have separate pages to explain each of the icon's vars that represent the same information. | |
For your method, you would need to define the icon in some special way, so your "easier" example wouldn't work as simply as shown.
Also, I think the format should be icon_state_info(icon,icon_state), as opposed to the format in my original request (as an /icon proc). | |
For my method the icon var is just an instance of the /icon datum, same as in the syntax you initially proposed.
| |
You wouldn't be able to use icon.duration, it would have no information about the desired icon_state, unless you specially created the icon with such information, which would make the feature useless (or just inefficient and over complicated to use) in most cases.
You could do something like icon.state_info["state"]["info"] (as you posted on your blog), but that doesn't seem like it would fit with any of the other built-in BYOND features, or like it would be any more effective than having a proc to retrieve them, though maybe more efficient. | |
An icon datum can represent a set of states, a single state, or a single image of a state (in the case of directional or animated states). You're right that an icon datum representing a set of states wouldn't have duration information, but this is a mess that needs sorting out, not more mess piled on top of it.
| |
Forum_account wrote:
An icon datum can represent a set of states, a single state, or a single image of a state (in the case of directional or animated states). Not really, and there's no reason to degenerify (its a word!) the use of icons, just to accomplish some unrelated goal, a goal which can be better accomplished with a new, easy to use proc. | |
Luckily I don't have to convince you that this all-encompassing info proc is a bad idea, just the staff. It would be nice if they'd weigh in on the issue, it would be nice to be able to control all of the properties that can be set in the icon editor through code too.
| |
Forum_account wrote:
...just the staff. Maybe just them, but you should probably out counterpoint my side if you want to accomplish that =P it would be nice to be able to control all of the properties that can be set in the icon editor through code too. You already can, though you have to remake the icon. And since you can't read them in advance, it makes properly rebuilding the icon somewhat difficult, part of the reason for this request. | |
The problem with many of BYOND's features that are meant to simplify things is that they end up only simplifying the things that would have been easy anyway. The consequence is that other, more complex tasks end up being overly complex or sometimes impossible.
And since you can't read them in advance, it makes properly rebuilding the icon somewhat difficult, part of the reason for this request. Right, and it would be much nicer to be able to say either "icon.duration" to read the value or "icon.duration = 5" to set its value. | |
I doubt changing the duration of a state like that could yield desirable results. And as we went over before, you wouldn't be able to directly reference icon.duration like that =P
| |
A new proc that would return as much available information as possible about a specific icon_state in an icon.