For those in the CASE discussion

[thelevitator]

Well, I was actually implying that I feel inferior, but you are right. I really shouldn't feel that way. I've been super lucky to have met some fantastic gamers who have gone way out of their way to help me do the things I've wanted to do with my games.

It's not so much that I'm ashamed to ask for help so much as I get frustrated when I can't just do something for myself. I don't think I'm alone in this either. We are all gamers, and we all know how limited our time is when it comes to this wonderful hobby. And knowing that makes it difficult to constantly bug other gamers to take out time from their own endeavors to help us out.

I should have prefaced my entire statement by pointing out that I don't have the first clue in how to keep MT usable to the majority and not the minority, or if it is even possible based on the newest additions to the program. I don't have any idea of how much of the new features can be streamlined to make them accessible to the average, non-coding user, if at all.

I just wanted to go on the record as speaking for the little guys who wholly appreciate it when others help us, but would prefer to have the means to do things for ourselves as much as possible. I didn't want the developers to get so far ahead in developing new features and additions that we average users never get to play with the new features because they weren't made to be accessible by those of us lacking programming backgrounds. I understand that certain aspects of scripting and coding can only be simplified so far, I am just hoping that in the process of developing MT, the coders and developers can find ways to make things a little easier on those of us who want to do as much as we can for ourselves.

I've been using DM Genie for more than 5 years now I think. I've created some scripts by myself by taking other scripts apart and figuring out how they worked, and then modifying them to create my own scripts. And even after 5 years, I still need help occasionally from the DM Genie pros like Azhrei and Big Mac. But, it means a lot to me that the scripting in GM Genie is simple enough that a non-programmer like me can dissect similar scripts and figure most things out for myself.

What would be really nice is if someone could break the codespeak down for us non-coders every 5 pages or so, so at least we have an idea in the direction things are going and we can do our best to keep up. I was doing pretty good for a while there, but am now completely lost on just what features are being added, which ones are being changed, what protocols are being used, etc. Being able to stay somewhat in the loop at least makes it a bit easier to visualize the direction things are going and allows the rest of us to stay up to date on just what functionalities are being added and modified. Maybe it would be cool to have a separate Macro Room where there can be a current "this is what we've added and this is what we are adding" list in layman's terms so those of us who have trouble following the technical conversations can at least stay up to date on functionalities that we may find useful in our own games.

One other thing to consider is that many of us who use the latest versions of MT aren't using them for the purposes of macros, but for the latest versions of light/vision/initiative/etc. But since they are there, we do our best to try and keep up with all of the latest changes. I also realize that with the rapid development of this program, that it's almost impossible to keep the documentation up to date. I know that once things slow down, we'll eventually have a glossary and basic coding information in the documentation that will make it easier for people to decipher existing scripts and modify them to suit their own purposes. Again, I just wanted to say something now so that these types of things aren't forgotten and people lose interest in using the program because it is evolving faster than they can keep up with it.

I'm hooked on MT, and can't imagine gaming without it, whether online or tabletop. I just don't want it to evolve so quickly or become so complicated that a program I've been using for several years becomes frustrating.

[BigO]

oh.. and Perl!

Ha! It's funny you should mention Perl. I debated with myself quite a bit about weather or not I should include it in the list. I have a foolish fondness for Perl that I can only attribute to nostalgia. And yes, it's DEFINITELY case sensitive.

Microsoft clearly states in all their "best practice" documentation that the first thing you should do in VB is to turn on the option to make it case sensitive.

Not only that, but even when you don't have that turned on the IDE (Visual Studio) will automatically correct the case for you if you don't type it consistently.

[Craig]

With all the calls (in other threads) for implementing a "real" scripting language for macros. you are all aware that all the major options (JavasScript, JPython, JRuby, Groovy, etc) are all case sensitive. So even if you move to case sensitive if a scripting language is introduced for macros you will just be moving back again.

So in that case which is more of a usability issue,
1) X != x
2) Changing X != x to X = x, then later changing it back again to X != x

Edited for clarity

[UntoldGlory]

In this case though, I think trevor, the main developer, has managed to outwit all the other developers, and I'll restate this: If there isn't a GAMING system that NEEDS case sensitivity, it should probably go away BECAUSE it is EASIER (from a psychological standpoint) for users to deal with. This may offend developers sense of style and rightness, and it frankly creeps me out to have "stringA"=="Stringa" return TRUE, but I can see why for non-coders out there it might drive them batty to have those be different.

Quoted for Truth and agreement.

Giliath, I appreciate your action, as it on the surface placates both parties. Question though. If someone just uses "A == a" without using the neqs deal, what will it return? If it does not return TRUE then it will not help non-coders, cause remembering "neqs" is harder than remembering case sensitive.

I would point out that many of these case sensitve languages and whatnot have automaticl color coding and case correction and autocomplete features. MapTools does *not* have that. I would also point out how long it took the world to grasp that original email addresses had to be all lowercase, and that original windows filenames couldn't have spaces.

Also, note that while I just said "windows", you knew I meant "Windows".

Having said that, I would prefer to spend more time troubleshooting my macros to figure out that I accidently typed "Strbonus" than to have people's tempers continue to rise.

[hennebeck]

that original email addresses had to be all lowercase, and that original windows filenames couldn't have spaces.

And, now things have gotten to the point where you can type Upper or lower or even use symbols in Windows file names.

Isn't it now that way because it's easier for end-users?

I've changed my stance. If this was just for coders and those that are inputting features, CaseSensitive.

But if it's something that an end-user is going to input, make it as easy as possible. As it stands right now, I'm making macros for my whole group because they haven't a clue. And I only have a clue because of what I've read here.

Make it easy if it's end-user input. That's my take now.

[Azhrei]

And, now things have gotten to the point where you can type Upper or lower or even use symbols in Windows file names.

Isn't it now that way because it's easier for end-users?

Probably. But let me tell you it's a major PITA when your fileserver is Unix/Linux and you have to write backup scripts for Windows files! (My wife just loves to put semicolons and such into filenames and piping the output from find(1) into xargs(1) no longer works now. Sigh.)

Make it easy if it's end-user input. That's my take now.

Aye, but there's the rub. What's easy for me is not so easy for you. Over the last ... hm, 30 years? ... I've written code in five versions of assembler, six versions of BASIC, and four versions of FORTRAN. I've used BLISS, CORAL, SNOBOL, and StarTek (yeah, a silly name for a custom language used by a DOD contractor). I have experience with most of the current crop of whizbang languages, including some that probably don't qualify as languages per se (Ops5 or Oberon, anyone?).

Easy is in the eye of the beholder.

Easy should be solving a problem with the least amount of effort by the end user. Easy should be a tool that helps the user do what they want to do. Easy should be a program that precisely identifies any errors that the user may make and provides suggestions for how to correct the error.

MapTool will get there. It just takes time. "Rome wasn't built in a day."

[Phergus]

In this case though, I think trevor, the main developer, has managed to outwit all the other developers, and I'll restate this: If there isn't a GAMING system that NEEDS case sensitivity, it should probably go away BECAUSE it is EASIER (from a psychological standpoint) for users to deal with.

End of discussion as far as I am concerned.

[UntoldGlory]

Wow, I agree with Phergus on something!


I guess it was bound to happen eventually, 10k monkey's at typewriters and all that.

[Brigand]

I disagree, it is not the end of the discussion. Case sensitivity is very important when creating scripts. Macro's are basically weird donkey scripts with funky brackets and braces, which are actually somewhat harder to read than well written code.

Code: Select all

if (x == 1) {
  DoThisStuff;
  }
else if (x == 2) {
  DoThisStuffInstead;
  }

Anyone can learn that. In my opinion, that is easier than learning:

[if(x==1, True, False)]

In addition, the true scripting allows for more interesting "macros" that do more, more easily. Nested if/elses in the current macros are a nightmare to figure out. They're harder than learning scripting, imo.

[Full Bleed]

Code: Select all

if (x == 1) {
  DoThisStuff;
  }
else if (x == 2) {
  DoThisStuffInstead;
  }

I think you should have to capitalize the "I" in your "if" statement. It's creeping me out that the beginning of a line like that isn't capitalized. It simply does not jive with basic latin-based language rules.

if you know what I mean.

[Brigand]

Coding doesn't care about language rules. Coding creates it's own rules!

[giliath]

Giliath, I appreciate your action, as it on the surface placates both parties. Question though. If someone just uses "A == a" without using the neqs deal, what will it return? If it does not return TRUE then it will not help non-coders, cause remembering "neqs" is harder than remembering case sensitive.

The new functions are for strict matching of "strings" only. This way, if someone does come up with that 1 case where they need strict string matching they have a way of doing it.

Code: Select all

"FOO" == "foo" // returns true
eqs("FOO", "foo") // returns false

The "A == a" case is different than the string comparison in that it is about variable resolution. "A == a" will also return true, regardless of the values of A because it will resolve to the same variable.

We haven't fully worked out how the JavaScript will integrate, but I imagine it will look something like this:

Code: Select all

var token = TokenManager.getCurrentToken();

var str = token.getProperty("Strength");

var roll = Math.ceil(20*Math.random()) + str;

// Do more with the roll

or something like this to depend on existing expression evaluation

Code: Select all

var roll = Expression.evaluate("d20 + Strength");

// Do more with the roll

[BigO]

var roll = Math.ceil(20*Math.random()) + str;

Ack! No way. I realize why it might be complicated to give us direct access to the normal dice rolling stuff, but at the very least there should be something like a roll() method always in scope to use instead.

[giliath]

Ack! No way. I realize why it might be complicated to give us direct access to the normal dice rolling stuff, but at the very least there should be something like a roll() method always in scope to use instead.

LOL... Great suggestion, although the code was more to suggest how the expressions and javascript might integrate and how the case insensitivity discussions would not really have some of the cross over problems previously suggested.

[osman]

Wow. Went away for a week, and all hell broke loose. Anyways, as someone that programs for a living (in multiple case-sensitive languages), I'll throw in my 2 cents...

Absolutely everything in MT should be case insensitive. Period. Case sensitivity is feel-good crap that we all think we need, because that's what every other language does. It doesn't actually provide any tangible benefit at all.

More importantly, claiming that things should be case sensitive because that's how other language (C++, Java, VB, C#, whatever...) do it is (IMHO) fatally flawed in one major respect. If I'm writing code in any of those languages, I'm using an IDE (or at least VIM with a tags file). In that situation, I have the immense benefit of context-sensitive assistance that takes out all of the guesswork in remembering the exact naming of identifiers. Even if my IDE can't do that for me, and I know that I need a function or variable that has to do with "shirt color", I can do some kind of grep/find-in-files/regex to trawl through my code and scan for likely candidates.

Even if you're coding in a case-sensitive language, you're constantly using other tools and processes to help eliminate the handicap that the case sensitivity adds in the first place. Without ANY of those tools (certainly, none of the things I've described are possible in MT right now), removing case sensitivity levels the playing field a bit. It's one less fragment of information cluttering your head, as you won't be able to (easily) rely on your IDE and other tools to do it for you.