Not sure if this is the right place, but:
When an atom is displayed in a stat panel, how does the BYOND software know exactly what to put in the stat panel i.e. Why Does one see an icon, and then the name of the atom
ID:135033
 Apr 30 2005, 8:25 am
|
|
|
Apr 30 2005, 1:22 pm
|
|
PirateHead
 |
This is the only behaviour BYOND supports. It displays the icon, then the name, then the suffix. BYOND is inflexable in many such ways. The Stat() procedure, for example, is called every .8 seconds, whether you like it or not, with no flexability. Hopefully updates will quickly fix bugs like these.
|
PirateHead wrote:
The Stat() procedure, for example, is called every .8 seconds, whether you like it or not, with no flexability. Not true. You can delay it as long as you like (http://www.byondscape.com/ascape.dmb/ Shadowdarke.2003-0322/##stttim). You just can't speed it up so easily. | |
PirateHead wrote:
The Stat() procedure, for example, is called every .8 seconds, whether you like it or not, with no flexability. Actually, you can override client/Stat() to slow it down, and lower world/tick_lag to speed it up. =) | |
PirateHead wrote:
This is the only behaviour BYOND supports. It displays the icon, then the name, then the suffix. BYOND is inflexable in many such ways. The Stat() procedure, for example, is called every .8 seconds, whether you like it or not, with no flexability. Hopefully updates will quickly fix bugs like these. Despite the fact that I hate posts of this nature -- "insulting" or being seemingly derrogative against the BYOND system, this does bring up a valid point regarding Stat(). It would be nice if the internal timing was either easily (one variable) customizable or a easier to control value. Updating every second, versus every .8 second would make it easier to control exactly how long. I would be able to set tick_lag to 0.1 and know that stat panels update 10 times a second now. ~Polatrite~ | |
Polatrite wrote:
"Despite the fact that I hate posts of this nature -- "insulting" or being seemingly derrogative against the BYOND system," Oh man! Dream Maker might get upset! Don't puncture Seeker's ego... :p | |
Well, derogatory is a little harsh. I'd use the word sarcastic - the lack of flexability in things such as GUI features and that Stat() proc might be regarded as bugs, but since they've apparently been around for a good while and never been looked into my comment was a bit tongue-in-cheek.
No more tomfoolery. Here's my guff. I have two problems with the Stat() proc. First of all, in a perfect world, I would never call it unless I wanted it. I would have a procedure that called it every time stats were updated, such as during battle or after a new player joined. Furthermore, I would not call the whole Stat() procedure, but rather just update one statpanel or one element of one statpanel. This issue is connected to the problem that all statpanels have to be re-calculated every time Stat() is called. I wrote a system for my latest project whereby a player can choose to have his statpanel output display one of four ways. However, because the statpanel() and stat() procedures can be called only from within the Stat procedure, the code turned out to be very long and tedious since I could not break it into many procedures. This also makes recursive processes impractical, since you probably only want to recurse one part of the procedure. The only workaround is using a spaghetti-esque goto structure which is not only confusing but also, unless BYOND is built to handle goto statments well, inefficient. The solution to this problem is to allow statpanel() and stat() to be called outside of the Stat() procedure, thereby allowing updates of single statpanels or stat objects within the stat panel rather than an update of the entire Stat object. My second problem with Stat() is that its contents are inflexable. You cannot change the spacing of elements, the color of text, the displayed stat icon, or any other parameter. While the default behaviour works well enough for many applications and saves time and stress in writing a GUI interface, there is no reason it couldn't be customizable or even rebuildable interface. The solution to this problem is as simple as better, more effective features for the statpanel display. If you view this post as derogatory, censor me - but if I were developing BYOND, I'd really want to know what improvements people wanted to see. My intention is not to deride BYOND and my intention is not to portray BYOND in a bad light. Hopefully you can see past sacastic comments and realize that when the diaper (or display panel) smells funny, it's time to change it. | |
There are better means of handling interface work than anything built-in, and they are already accessable. Get creative! But I do agree, stat could use a number of improvements -- and I believe they are scheduled for version 400.
| |
PirateHead wrote:
Well, derogatory is a little harsh. I'd use the word sarcastic - the lack of flexability in things such as GUI features and that Stat() proc might be regarded as bugs So Winamp is buggy because it doesn't browse RSS feeds? And Calculator is buggy because it doesn't do integral calculus? ;-) That said, everyone would certainly like to see extra GUI features (note that I said "features", not "bugs" =)) added. BYOND 4.0 (which is not necessarily version 400, Polatrite) will greatly enhance BYOND's GUI functionality when it comes out a few years ago. ;-) | |
Crispy wrote:
(which is not necessarily version 400, Polatrite) The current version is 341.877, so it would seem to follow. I might have a slightly out-of-date copy, maybe I should upgrade. ~Polatrite~ | |
PirateHead wrote:
My second problem with Stat() is that its contents are inflexable. You cannot change the spacing of elements, the color of text, the displayed stat icon, or any other parameter.
| |