Well, I tested it, and it works, at least the stuff I tested. So functionality here isn't really a problem. However, I think the API could use a cleanup (or maybe a major rework).
First of all, I dont want to type in 10 parameters every time I create a texttag. It's just annoying, and it's easy to forget what those parameters are, so I have to go back and look at the documentation every time. Instead of emulating BJs with their huge parameter lists, you could make a Template struct, for example:
integer red integer green integer blue integer alpha integer size boolean visible boolean permanent real fadepoint real lifespan real xVelocity real yVelocity
function NewTextTag takesreal x, real y, real z, string text, Template template returnstexttag localtexttag tag = CreateTextTag() call SetTextTagPos(tag, x, y, z) call SetTextTagText(tag, text, template.size * 0.023 / 10) call SetTextTagColor(tag, template.red, template.green, template.blue, template.alpha) call SetTextTagVisibility(tag, template.visible) call SetTextTagPermanent(tag, template.permanent) call SetTextTagFadepoint(tag, template.fadepoint) call SetTextTagLifespan(tag, template.lifespan) call SetTextTagVelocity(tag, template.xVelocity, template.yVelocity) return tag endfunction
Some other things:
Your textbar thing shouldn't really need to take in an existing texttag upon creation. The constructor should create its own texttag. Also, by convention the constructor of any struct is .create(), not .Create() (and more generally, all method identifiers should have their first word in all lowercase, and the rest with first letter capitalized: .create(), .destroy(), .doSomething()).
You should use size and not height when determining text size. It's just easier to work with. Size can be thought of as the same thing as font size in word processing programs, while height is just some random real that probably makes no sense to anybody except the people at blizzard who wrote the natives.
Your documentation should specify what it is that some of the parameters do. Some of them are obvious by their names; others are not. It's best to be clear.
You should rename all "transparency" parameters to "alpha", since the way you handle them you are treating them as alpha values (0=transparent, 255=opaque) and not transparency (0%=opaque, 100%=transparent).
I've probably forgotten some other things that I thought of while testing. But this is it for now.
You should use size and not height when determining text size. It's just easier to work with. Size can be thought of as the same thing as font size in word processing programs, while height is just some random real that probably makes no sense to anybody except the people at blizzard who wrote the natives.
I don't see where I have done that?
Other than that, updated. Fixed alot of things you mentioned.
You shouldn't use 'this' as a variable/parameter name unless it's in a completely internal block of code. Doing otherwise makes it more likely for users to get confused.
So every time anyone creates a text-tag it starts a new timer? Why not just have all of these in a stack and then run through the stack every interval (one timer).
I know how such indexing works, but I don't see any particular reason for doing so. It might be neccessary for things which you use often, but I don't think you're going to create 50 attached texttags.
But it doesn't slow anything down, so why would you deliberately use unnecessary resources? Especially in something which would be implementing into someone else' map, you would want it to be as perfected as it can be.
