For those in the CASE discussion

[Big_Mac]

Yeah, but X does not equal x.

only when viewed as ASCII

to Humans they have the same value just a slightly different font

X = 6
x = 6

so

X=x

[emirikol]

I'm not a programmer..What I'm not comfortable with is the seemingly increasingly separatist attitude that is making people like me feel like idiots for not being programmers. I'm starting to get the message that only the elite coders of the world will be able to use this program, and that people like me will be groveling at their feet for help on getting the functionality we want and have access to all of the goodies. ..What I don't care for is my personal sense that MT is turning into a 2 class program; where the elites get to use all of the goodies and us average users are stuck begging for scraps from the big table... as one of those "average" users, don't want to get lost in the shuffle.

I'm glad you came out and said it I think that's why it's our job to keep bringing fort "playability" issues..that's our contribution.

jh

[RPTroll]

I apologize ahead of time for anyone this might offended.

I'm not a programmer, but I think I am one of the original 50 members of this forum.

Lev, I agree. I've made several pleas for usability vs. coding purism. There is a reason we have business analyst decide what programs should do and coders figuring out implementation. This is discussion is a classic, in the bits, opinion spewing example of why BAs tell coders what to code without telling them how to code it.

I hate to use the term drivel but that's what this topic feels like. In the end it just doesn't matter if things are case sensitive not. It affects usability not one whit and the only impact is some possible macro rewrites.

My only really argument on this subject is that MT should be as consistent as possible.

My hope is that the non-coders will be able to find a macro/properties set they like, rip it off and run with it. You don't have to know the formula behind it you only have to know it works.

So while the bit heads argue ad nauseum about how 'A' should or should not equal 'a' please keep posting concerns like this so MT doesn't go too far into the weeds.

At the same time, I'm very excited about macros and scripting and the huge leap forward in functionality and ease of play.

That said, I'm done with this topic.

[BigO]

What I don't care for is my personal sense that MT is turning into a 2 class program; where the elites get to use all of the goodies and us average users are stuck begging for scraps from the big table

I think this is a very valid point for the dev team to keep in mind as they continue to add features. However, I have somewhat of a different perspective on what's been happening.

I'll try to explain it this way. I don't care at all about lighting in MapTool. I'm not calling it a useless feature, or trying to invalidate the people who DO like it and use it, but to me personally, it's pointless eyecandy that bloats the software and distracts from the core of the game. So if b41 comes out and has a major new feature relating to lighting, I'm going to pay very very little attention to the discussion that ensues.

Now lets say several builds go by and everything is lighting related. New lighting toolbar tools, fancy 3d effects, shadows, whatever. After a while I'm going to get anxious for them to turn their attention again to the things that I care about, but I'm not going to feel left out or slighted.

I realize that this is being developed for free by people in their spare time and if I want them to focus on something different I can donate and bump my favorite feature up on the wall of requests.

I agree that it's important for the dev team to not forget the average non-coding user, to keep it accessible for everyone, and to avoid a 2 class system, but from my perspective this isn't what's happening here. We're just in the natural process of fleshing out a new feature that has just been added. A lot of the minutia of syntax discussion that his occurring here are pre-requisites of accomplishing the goal of making it easier.

And to support that statement, consider this: I have a macro that I wrote for my attack roll that use the images from the D20 dice table and has a number of conditionals for things like critical hits, if I can use my sneak attack, and other things. In b38 this macro was about 300 lines of code. In b39 I cut that down to around 150 to accomplish the same thing. I'm not done adjusting it for b40 yet but I expect it to now be around 75 lines.

The code discussions we are having ARE making it easier to use. You just have to be patient and give it time to mature.

[Orchard]

I'm not a programmer, but I think I am one of the original 50 members of this forum. I've been using this program since at least 1.1, maybe even before. I have to say that I'm a bit wary of how MT has been evolving over the last 6 months. It feels like the program is starting to be developed on the assumption that people have to be programmers to enjoy the full features of the program. It's starting to make this long-time user and idea contributor feel pretty left out.

I'm all for the development of new features and the evolution of this program. What I'm not comfortable with is the seemingly increasingly separatist attitude that is making people like me feel like idiots for not being programmers. I'm starting to get the message that only the elite coders of the world will be able to use this program, and that people like me will be groveling at their feet for help on getting the functionality we want and have access to all of the goodies. I understand that in the development phase, that certain protocol must be followed for consistency, and that things will usually start out more complex to then be refined and streamlined for us "average" users.

What I don't care for is my personal sense that MT is turning into a 2 class program; where the elites get to use all of the goodies and us average users are stuck begging for scraps from the big table.

My ultimate hope is that once everyone agrees on the structure, that some effort will be made to make the program accessible to non-programmers who don't want to have to depend on programmers to enjoy the program. So I'm thrilled at the rapid evolution of MT, it's just that I, as one of those "average" users, don't want to get lost in the shuffle.

I absolutely agree with this.

I consider myself as an intermediate user. Someone who is fully capable of programming, but won't ever particularly get into some of the complexities of it for a variety of reasons that have nothing to do with ability.

But one of the hats I wear occasionally is that of usability thinking. I am a psychologist by training, and I absolutely shudder when I see anything headed away from that. Right now maptool is very usable. We need to maintain that, and increase it. Anything that moves that direction is to be applauded and anything that does not is to be deplored.

The REAL problem is this: what is usable for developers is NOT always usable for non-developers. If I were setting up a usability study and allowing voting on features, I would rank votes based on relevance: if it was something that only a developer would need, then fine, developers get double votes. But if its something that everyone needs (and lets face it, macros should be accessible to everyone) then developers get a portion of votes such that their votes cannot outweigh everyone elses!

Why? Because developers are inherently out of touch with what non-developers do with software. It comes from being so familiar with coding practices and how software 'thinks' etc, that it is almost impossible for a developer to 'think' like a non-developer.

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.

Will there always be crazy people doing things with maptool that I simply don't have time/inclination to accomplish? Sure. Is that necessary? Not at all. As long as it is always easy to do the basic things that I need it to do, I'm happy. The more we can make complicated actions accessible to non-technical users, the better.

[dorpond]

One of the focuses of 1.4 will be making MT prettier and easier. That being said, I would have to guess that all of this, along with all the rest, will get a nice face lift.

But I totally agree - make it easier. My friends will be a great benchmark - if they can do it, anyone can do it and they just cannot do it now for sure.

[Brigand]

I completely disagree about the coders and not-coders bullcrap. I scripted for NWN and NWN2 for years and many people who could not script were overjoyed when I and other coders in the scripting community produced easy to use script packages that were fully integrated with each other, thoroughly bug tested, and not bloated. They were also very well commented so even non-coders who wanted to dabble, could figure some simple things out.

I never felt superior over those people. I was glad they enjoyed the scripts. I was glad to be of service. It's no different than the complex macro's being posted here. Some people will never be able to figure out how to make their own complex macros and will rely on others to provide packages of macros for those people.

If you feel like you're superior for being able to write a macro someone else can't... that's not a problem with MapTool usability.

[giliath]

Wow, this has almost turned to a religious debate. Kinda scary.

The macros and expressions are intended to be the easier form of what is eventually coming. Full script integration. With the full script integration, you are going to probably be able to use JavaScript or some other scripting language to do many of the things you can do today. Trevor and I debated for a while whether this change made sense, and when we couldn't come up with any reason other than "it doesn't feel right" we went ahead and added it. I completely respect and agree with everyone who said it doesn't feel right and that other programming languages don't do this. However, the macros and expressions are eventually only going to be the easy way to do some things and you will have the full power of something like JavaScript for the rest.

That being said, I went ahead and added a strict string equals and string not equals function that does not trim and does a case sensitive compare. I did not add operators for this at this time.

eqs, strEquals, equalsStrict
You can call eqs("FOO", "foo") and it will return false.

neqs, strNotEquals, notEqualsStrict
You can call neqs("FOO", "foo") and it will return true.

Also, in the next build of MapTool it will support case insensitive functions and some case insensitive variables. The reason I say "some" is that token properties and states are a little harder than regular x=10 variables, so that might miss the b41 release.

Thanks

[BigO]

I went ahead and added a strict string equals and string not equals function that does not trim and does a case sensitive compare. I did not add operators for this at this time.

eqs, strEquals, equalsStrict
You can call eqs("FOO", "foo") and it will return false.

neqs, strNotEquals, notEqualsStrict
You can call neqs("FOO", "foo") and it will return true.

Huh. Well, not exactly the solution I was expecting, but that works for me.

[Brigand]

I honestly think we should make macros as close to scripting, while still being easier to use... so that when someone does decide to go from making macros to coding scripts, it's not so much relearning.

Macros and the scripting capabilities that may someday be a part of MapTool, should share basic operators and case sensitivity simply to keep them similar.

[thelevitator]

I completely disagree about the coders and not-coders bullcrap. I scripted for NWN and NWN2 for years and many people who could not script were overjoyed when I and other coders in the scripting community produced easy to use script packages that were fully integrated with each other, thoroughly bug tested, and not bloated. They were also very well commented so even non-coders who wanted to dabble, could figure some simple things out.

I never felt superior over those people. I was glad they enjoyed the scripts. I was glad to be of service. It's no different than the complex macro's being posted here. Some people will never be able to figure out how to make their own complex macros and will rely on others to provide packages of macros for those people.

If you feel like you're superior for being able to write a macro someone else can't... that's not a problem with MapTool usability.

Feel free to call it bullcrap, but I think it's a bit shortsighted to not notice a pretty clear division in the users of this program between those that can code and manipulate it and those that can't.

I don't know where you got the whole superiority thing, as I never said it in my post. In fact, my perspective is more from the the angle of feeling inferior, not inferring that those that can program are superior. What I was trying to say is that I'm starting to be intimidated by a program that I've been using almost as long as it's been available, and that bums me out. I fully understand that this is a developmental process. It's just my hope that non-coders aren't left out in the cold and reliant upon coders to get the functionality they want out of a program.

I'm a big fan of trying to do things on my own before asking for help. DM Genie is a great example of this. Over time, I eventually figured a lot of things out for myself, and for the things I couldn't figure out, I was lucky enough to get help from guys like Ahzrei and Big Mac. While someone like me may appreciate the ability to go to a forum or group page somewhere and just download scripts, believe it or not, some of us do try to learn on our own and really appreciate a program that makes that process a bit easier.

Just because starving people are grateful to those who provide them food doesn't automatically mean that those same people wouldn't prefer to get their food on their own. So just because people are grateful when coders create scripts for communities doesn't automatically mean that they all prefer handouts over the ability to do things for themselves.

All I am saying is that I am hopeful that, as MT continues to evolve, the coders and developers can find a way to make things as easy as possible for non-coders to be able to do things for themselves and not have to rely on others for their games.

[Brigand]

No one is implying inferiority either. No one should feel inferior just because they can't write scripts or code. Not everyone gets it. It took me months of dinking around with scripting in NWN1 before I felt comfortable even releasing a single script to the wild.

I'd rather have a small, dedicated group that fully understands how to create interesting and useful scripts/macros that anyone can use, than to be shackled with easy to create macros that anyone can make, but don't provide a lot of cool stuff.

If I had the same scripting support in MapTool, that I do in NWN... I could create some wild stuff. Entire game systems where all the numbers run in the background and provide health bars / prosaic text to describe attacks and such. I could automate combat to the point where it's perceptibly no different than free-form roleplaying. I bet we could even create campaigns that players could run through as a group, without a DM.

Of course, a lot of that would require heavily modifier chat windows, to allow groups to be formed with private channels and more. That would be my dream tool. ^_^ I guess what I'm saying is that you shouldn't be ashamed of asking for help. There are plenty of people who enjoy providing that help. Especially when they know it greatly aids someone else with running their games.

[jfrazierjr]

C#(C Sharp) is so far the only noted language that is Case sensitive.

Let's look at it this way. What are the most common programming languages in use today? For Windows it's C++, C#, VB.NET, or Java. For Mac it's C++, Java, or objective C. For *NIX it's C, C++, or Java. For the web it's JavaScript, and server-side stuff based on Java, C#, PHP, or VB.NET.

oh.. and Perl!

If I counted right, that list contained 8 different languages. Of those 8, ONLY ONE is not case sensitive, that being VB.

Exactly, and whats more is that 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.

Now, having said that, do I think that this is how MT macro syntax should be? Not really. I'd like to be able to choose to compare strings in a case sensitive or in-sensitive way, and I just want the variable name usage to be consistent, weather that be case sensitive or not.

What he said..... consistency is the key.

[jfrazierjr]

I'm not a programmer, but I think I am one of the original 50 members of this forum. I've been using this program since at least 1.1, maybe even before. I have to say that I'm a bit wary of how MT has been evolving over the last 6 months. It feels like the program is starting to be developed on the assumption that people have to be programmers to enjoy the full features of the program. It's starting to make this long-time user and idea contributor feel pretty left out.

I'm all for the development of new features and the evolution of this program. What I'm not comfortable with is the seemingly increasingly separatist attitude that is making people like me feel like idiots for not being programmers. I'm starting to get the message that only the elite coders of the world will be able to use this program, and that people like me will be groveling at their feet for help on getting the functionality we want and have access to all of the goodies. I understand that in the development phase, that certain protocol must be followed for consistency, and that things will usually start out more complex to then be refined and streamlined for us "average" users.

What I don't care for is my personal sense that MT is turning into a 2 class program; where the elites get to use all of the goodies and us average users are stuck begging for scraps from the big table.

My ultimate hope is that once everyone agrees on the structure, that some effort will be made to make the program accessible to non-programmers who don't want to have to depend on programmers to enjoy the program. So I'm thrilled at the rapid evolution of MT, it's just that I, as one of those "average" users, don't want to get lost in the shuffle.

I R != L337!!

[jfrazierjr]

I apologize ahead of time for anyone this might offended.

I'm not a programmer, but I think I am one of the original 50 members of this forum.

Lev, I agree. I've made several pleas for usability vs. coding purism. There is a reason we have business analyst decide what programs should do and coders figuring out implementation. This is discussion is a classic, in the bits, opinion spewing example of why BAs tell coders what to code without telling them how to code it.

I hate to use the term drivel but that's what this topic feels like. In the end it just doesn't matter if things are case sensitive not. It affects usability not one whit and the only impact is some possible macro rewrites.

My only really argument on this subject is that MT should be as consistent as possible.

Agreed. All or nothing case insensitive, all in one shot. Either change it all at one time or never change any of it.

My hope is that the non-coders will be able to find a macro/properties set they like, rip it off and run with it. You don't have to know the formula behind it you only have to know it works.

Right, and thats why, even as a coder, I made the default properties patch. As a coder and as a person before I was a coder, I HATE to repeat myself, so I added the default properties.