In legal parlance, they say "This discussion is allowed because the prosecution opened the door to it..."
Well, since Tom opened the door on icon enhancements, here are a couple of thoughts from my recent icon usage:
In general it would be good to have icons be inspectable. That is, I would like to be able to query an icon to find out:
- What states it has
- More importantly, whether it has a particular state
- How long a particular animation state takes to run
Testing for the existance of an icon state is important for allowing the game to adapt to the situation. For example, let's say that a Bobfish has managed to pick up the Flaming Sword of Death.
Now, you never anticipated a fish engaging in sword combat, so you didn't provide Bobfish with a "swinging" attack animation. So when the Bobfish swings the sword, you try to flick() the "swinging" icon state animation, and nothing happens. Bobfish sits there like a dead fish, but the other player is getting hit and they may not even know why or how. However, if the game could test for existance of the state then it could compromise by switching to the standard Bobfish attack animation "tail smack".
This particular one could actually be handled by having flick() return a binary value indicating success or failure in finding the state, but other cases would require something else (testing for the existance of a "drunk" state, for example). Games need to be able to query important objects for their statistics, and things like animation length should haven't to be programmed in manually.
At the next stage of request is the ability to change attributes in game (which this release provided a wonderful start on!):
- animation speed
I was also thinking possibly manipulation of states, but I can only make up reasons at the moment. It's not one I've actually needed, while everything else here is.
Some of this applies to sound too (especially finding out sound length), but Tom didn't open the door on that one!
ID:138423
 Aug 27 2000, 7:13 am
|
|
On 8/28/00 12:08 am Tom H. wrote:
On 8/27/00 11:13 am Deadron wrote: I totally sympathize. At least you can be comforted to know that the requests will stop at some point. Oh I really crack myself up. Anyway, what about adding things in a purely additive manner? For example, I'd be really happy if the current icon and sound stuff were left as is, but if we got new icon and sound objects that were wrappers around them which also provided some of this extra info. Same is possible for a string object. In fact, many object-oriented systems have both primitives and object wrappers for things like strings. | |
On 8/28/00 12:18 am Deadron wrote:
For example, I'd be really happy if the current icon and sound stuff were left as is, but if we got new icon and sound objects that were wrappers around them which also provided some of this extra info. Do you have ESP? Or are our intentions that transparent? The new minor notation of which I've spoken is essentially that which you've proposed (damn, do I have to put (Deadron) in the notes now?) We have been babbling about just having the wrapper classes: /text, /num, /file, /sound, /icon, etc, merely to placehold some functions. You wouldn't have to use them (backwards compatibility is essential at this point, because of the fairly large number of demos and the now complete documentation) It only came up because we have a few icon functions with funny names that would probably get misinterpreted if not associated with the /icon "class". Anyway, I'll hush up about this. Dan has deemed this to be a fairly easy adjustment, but I think he is sore at me for tredging up new developments in the midst of our so-called stability package. And we don't really want to outdate the book before we even sell a copy, so all changes are, like you said, additive. | |
And we don't really want to outdate the book before we even sell a copy, so all changes are, like you said, additive. You could always ask the publisher to print stickers saying "This book is out of date" and put it on the cover of each. Then you could force people to buy a completely new copy in a week. =) | |
These are all fairly trivial items to deduce, and should be accessible if and when we get the minor notational addition in place. I say "if" because right now we have regressed into coding mode and that has us both a little worried. Dan may hold a pre-emptive strike, as I did the last time this fiasco came about. Numerous copies of the new manual will make the current notation essentially set in stone as of this week, so we have to be extra careful, especially since we are bordering on some sort of public release once the server is stable. On the flip side, we want to have only the best notation available for the future audience of BYOND gurus!