Hero Lab scripting 201: Location, Location, Location

[liz]

Originally Posted by Exmortis

That's too bad, I do understand his frustration.

Yeah. We're also frustrated that we don't have as much time as we'd like to update our documentation. As TheIronGolem alluded to, good documentation takes time. Given our small team, we have a lot of things competing for our time. Sometime things have to be put on hold. Unfortunately, updating our documentation has been one of those things.

[ProphetPX]

Originally Posted by chimeforest

I agree with Exmortis =]
Best to just be chill, angry coding never works out.. though I do understand ProphetPX's frustration. For pretty much every other scripting/programming you can find a unified and complete syntax, but not for Hero Lab.
Still, it's pretty cool that Hero Lab is so customizable ^^

THANK YOU for finally being someone who is understanding of where i am coming from!!!!!!!

[ProphetPX]

This ... seriously made me laugh and give up a bit of my own grief in doing so ... YOU UNDERSTAND!!!! YOU KNOW!!!

FINALLY!!!!!

Originally Posted by TheIronGolem

I sympathize as well. I would push a busload of nuns off of a cliff just to have a "tag dictionary" that lays out all of the Pathfinder tags, what uses each one, and the effects of applying them. If it was searchable, I would pick a cliff that was directly above a burning orphanage. And if I told you what I would do for a complete reference on the scripting language, the CIA would drone-strike my house, on the off-chance that I meant a word of it.

That said, I know from painful experience that software developers are often too close to the product to be able to write clear documentation on it, and technical writing is a whole different skillset that LWD may not have in-house. That means any "O'Reilly's for Hero Lab" project would likely require an outside contractor, and that means spending money that otherwise could be spent on adding more features and data packages to Hero Lab. Not necessarily a good ROI, given that us modders are a rather small part of their overall customer base.

Finally, ProphetPX, have you looked at the wiki? It's far from comprehensive, and it isn't the easiest thing to navigate, but it is handy for looking up functions and what methods and transitions are available from a particular context. It's the closest thing to what you're asking for that currently exists. I frequently refer to the Language Intrinsics and Pick Context pages in my own work.

These forums are an excellent resource, too. I've said it before, but for every time I've had to post a question here, there have been 10 or so times that I haven't needed to post one because I found what I needed by searching older threads.

THANK YOU for finally being someone who is understanding of where i am coming from!!!!!!!

And yes i have looked at all of that stuff
sigh

words cannot express how i relate to you right now. they just can't.

THANK YOU for saying what you did!

[Azhrei]

I'm one of the lead developers on RPTools (or used to be; I haven't written a lick of code in a long time ) and we have a problem with documentation on all of our tools and our scripting language for MapTool, MTscript.

It is difficult for the development team to keep the docs up to date as most users want the developers to be, you know... "developing". One of our team members put up a wiki that the users now keep up to date. It isn't perfect, but it lets the users share their knowledge -- and their experience -- with other users.

I'm just learning the scripting language that HL uses. I see it has some of the same issues that MTscript has: a wimpy editor (no "intellisense" or syntax highlighting); the editor UI is cluttered; the tooltips are not particularly helpful; and as Prophet says, there doesn't seem to be any kind of aggregation of globals lists (I posted on this in another thread this morning and then subscribed to this forum, just so I'd get to see the answer if/when it's posted!).

One thing that would go a long way in HL scripting is for the compiling process of HL data files to spew out a list of all tags for all components into a log file. Maybe this would only be turned on when "Show Debug Output" is turned on, so that 99% of users wouldn't see that disk space taken up, but it would sure be handy for developers! Granted, there could be runtime tags added, but if you're developing new code you know what your own tags are -- it's the ones you don't know that are the bottleneck, and most of them are going to be static.

In our own project, RPTools is transitioning to the latest version of Java and JavaFX and they include a lot of new features that we expect will magically fix some of our problems (we're switching to JavaScript and dumping our custom and proprietary language, for example, and a lot of IDEs support JavaScript), but it's a long journey and we're just volunteers working on a labor of love. HL can't easily do this anyway as it's not as simple for them as just upgrading the runtime environment.

Anyway, I want to say to Prophet, "I feel your pain." And to the HL developers and support staff here, I would say, "I know your pain."