"Display Text" bugs
rebump
Member Posts: 1,058
I've made sure there is only one of the actor's in the scene but sometime "Display Text" will display what it is supposed to display twice. Basically I using it for a cheapy (i.e. non-custom font) score mechanism. It updates with score increases and decrements with score penalties. However, sometimes it seems to display the number and display it again offset to the right just a little making the numbers unreadable due to the overlap.
Also, if you create a game text/string attribute (say you call it "StringHello") and you leave it or set it to nothing at the manual edit attribute level. If you then use that text/string attribute in a "Display Text" behavior it will do wild things to the display when you preview the scene. In my instance, I was concatenating the text/string attribute to another value. Using the current example the expression to generate the weirdness would be:
game.StringHello.."Bob"
Basically, the preview scene display would fill up with all sorts of bitmap noise or what not.
Both problems are still present after a GS restart and a scene rebuild (although the second issue is a forced issue in that I don't intend to leave "game.StringHello" void of a text/string value).
Also, if you create a game text/string attribute (say you call it "StringHello") and you leave it or set it to nothing at the manual edit attribute level. If you then use that text/string attribute in a "Display Text" behavior it will do wild things to the display when you preview the scene. In my instance, I was concatenating the text/string attribute to another value. Using the current example the expression to generate the weirdness would be:
game.StringHello.."Bob"
Basically, the preview scene display would fill up with all sorts of bitmap noise or what not.
Both problems are still present after a GS restart and a scene rebuild (although the second issue is a forced issue in that I don't intend to leave "game.StringHello" void of a text/string value).
Comments
http://gamesalad.com/forums/topic.php?id=514#post-2711
and the fix, if you want to call it that, is to make sure you always have a value in your text/string attributes. Umm, nice. "What's the red button for?" "Don't push the red button!"
I'm guessing my first issue may be due to the alignment buttons since I read some posts concerning alignment only working for multiline but I will have to play around and see.
In the meantime, these would be nice things to have working correctly/robustly.
Evidentally:
`game.PreScoreText.."000000"`
is somehow different than
`game.PreScoreText.."00000"..game.Score`
when used in a "Display Text" behavior even though "game.Score" had a zero in it during the testing.
I thought I would cover my bases by having an initial test of if "game.Score" is less than or equal to zero display the first version above (i.e. the all zero string "000000" with not trailing concatenation of "game.Score") just in case some penalty somewhere put the score at under zero and I didn't catch it (even though I have some safety logic for that elsewhere that sets "game.Score" to zero if it is less than zero).
When I assumed it would be caught elsewhere by the less than zero check on "game.Score" and I just started my test out if "game.Score" was less than 10, pad it out with zeros (i.e the second version that uses five zeros and concatenates "game.Score" to the end), it never presents two overlayed text strings offset by a minor X difference.
So much for being proactively thorough. :-)
I guess the rule is try to keep the "Display Text" text consistent in how it is put together even though logically two assemblages of it may be equivalent.
Sounds like a bug.
Hopefully if others run into the padding things out, this helps them (assuming they are not converting the number to their respective places (i.e. ones, tens, hundreds, etc.) and displaying custom font number actors. It probably would have taken less time to do that than to fidget around trying to figure out that this was a bug! :-)