MapTool 1.3 Development Build 38

[trevor]

The "Overdue critical fix for parsing bug .... with a little bit extra" build

Build 38 (7/28/08)
* Fix bug: expression parser is breaking on recursive calls
* Fix bug: NullPointerException with light in some circumstances
* Fix bug: attempt to restructure startup sequence slightly to reduce flashing of main window during construction
* Fix bug: non visible tokens still show their light

Contributed by giliath
* Parser now supports:
&&, and
||, or
>=, ge
<le>, gt
<, le
==, eq
if(condition, true, false)

Hopefully this will be a sufficiently stable build to use in games.

[n3phrit]

IFs FINALLY!! (dropped off). NICE JOB TREVOR!!

[Micco]

Woot! Thanks Trevor and Giliath!

For those of you wondering, the syntax works like this (on the IF statements)

{HP = HP - if(HP > 0, 1, 0)} to subtract one from HP when it is greater than zero.

As far as I can tell, you can't put executable statements (like assignments) in the "True" and "False" results. (EDIT: Craig says assignments and other executions should work withing the IF statement, but there is a bug in the parser right now that causes it to work only sporadically.) So stay tuned...

So instead of:

if(HP <= Bloodied, state.Bloodied = true, state.Bloodied = false)

you should use

state.Bloodied = if(HP <= Bloodied, 1, 0}

Just thought I'd share my learning so far. I haven't opened the code yet to see how this works, but that's what it looks like with my playing around.

&&, and
||, or
>=, ge
<le>, gt
<le>=, ge

I believe Trevor meant:

Code: Select all

&&, and
||, or
> =, ge
>, gt
<=, le
<, lt
==, eq

(silly forum parser eats everything between &lt and &gt symbols even if it is in a "code" section)

Oh, and if you can't get something working, make sure you are using the Boolean equality test "==", not the assignment operator "=". I've been doing a bit of programming for a lot of years and that one still bites me from time to time. It might be smarter to use "eq" to avoid that common issue.

[TK]

Oh, and if you can't get something working, make sure you are using the Boolean equality test "==", not the assignment operator "=". I've been doing a bit of programming for a lot of years and that one still bites me from time to time. It might be smarter to use "eq" to avoid that common issue.

Especially if you're writing a page in both ASP (uses "=" for the 'is equal to' operator) and javascript (uses "==")

I'm quite excited by these new changes.

[UntoldGlory]

ooooOOOOOOoooooo

Well, time to rewrite all the macros!




Again.





And be happy about it!

[RedDog]

More great new features! Thanks for all the hard work trevor!!!

[Mathemagician]

Fantastic
I'm obsolete now

Though, just to look a gift horse in the mouth, I never did like the (one line) ternary operator notation for conditionals, but as a first implementation, I'll take what I can get

[RPTroll]

The "Overdue critical fix for parsing bug .... with a little bit extra" build

Build 38 (7/28/08)
* Fix bug: expression parser is breaking on recursive calls
* Fix bug: NullPointerException with light in some circumstances
* Fix bug: attempt to restructure startup sequence slightly to reduce flashing of main window during construction
* Fix bug: non visible tokens still show their light

Contributed by giliath
* Parser now supports:
&&, and
||, or
>=, ge
<le>, gt
<, le
==, eq
if(condition, true, false)

Hopefully this will be a sufficiently stable build to use in games.

Orgasmic screams from trollland. IFs!!!!! Thanks the gods of coding and gaming!!!

GILIATH FOR PRESIDENT!!

darn, I have to go to work today. Maybe I should call in sick and play.

[Stitched]

What, no " != " (not equal)?

I kid, I kid. This is all very great (except the rewriting macros part).

[simonutp]

The following token macro :

/stp [MaxPV=MaxPV]
[PV = min(PV - Damage,MaxPV)]
[state.Mort = max(0, min(1, PV)) *-1 + 1]
[Ratio=round(round(PV/MaxPV,2)*100,0)+"%"]
[token.halo=if(((PV/MaxPV)>0.25),"Yellow","Red")]

gives :

Error Evaluating Expression: Invalid Halo Color (ello)

When PV/maxPV is > 0.25

and

Error Evaluating Expression: Invalid Halo Color (e)

When PV/maxPV is < 0.25

What am I doing wrong?

[Orchard]

Fantastic
I'm obsolete now

Though, just to look a gift horse in the mouth, I never did like the (one line) ternary operator notation for conditionals, but as a first implementation, I'll take what I can get

Great!

So I spend all that time working on the min/max stuff and now I get if/then!?

Sheesh.

Of course, I wouldn't have done it without Mathemagician's help, and with this out, I wouldn't have needed his help.

All that said, I'm VERY glad to see to this in some ways, and a bit frightened by it in others. We are developing an ad-hoc scripting language here, and it has very poor documentation and some strange formatting requirements. I suspect it's going to be as buggy as hell if things don't get tightened up a lot before too long. I would much rather see a plugin with javascript (or another scripting language--python, lolcode, brainf*ck, perl, visualbasic, or anything else that already has a free java library already written) used than too much more functionality built into the macros.

I've said in other places, and I'll emphasize it again here. While I personally care more about the functionality than how we get there, I really care about it being truly functional, and not buggy, and I'm afraid of bugginess in the current system. The inability to include newlines in macros without the parser going haywire makes it harder to debug them, and THAT means you are more likely to make mistakes as you code increasingly more complex macros.

Thinking about the Wall of Code that Craig was doing for displaying health bars in b37 with conditional formatting (see thread here: http://forums.rptools.net/viewtopic.php?p=53941#53941), and the trouble I was having in debugging the rather simple (and it is simple, really) macro to auto calculate damage based on hitting a possible crit and all that across 6 attacks for a given AC, and then trying to figure out why the parser was adding extra columns to my table, I can only imagine what is now possible with the new features (actually nothing new is possible--just more concise), and how difficult this may be to debug on a single line.

Being able to plug in a javascript or other script, and then have the macro call that would be much more useful. Giving the GM access to that script for verification is going to be the truly tricky part. GM's will essentially have to either say that they trust the player, take the time to vet the script, OR disallow the script. Which means that a script could never be introduced on game night--but that is a social problem, not a technical one, and MapTool should NOT be trying to solve social problems with technical barriers. That's never a good idea because it is doomed to failure from the outset.

[Micco]

The following token macro :

/stp [MaxPV=MaxPV]
[PV = min(PV - Damage,MaxPV)]
[state.Mort = max(0, min(1, PV)) *-1 + 1]
[Ratio=round(round(PV/MaxPV,2)*100,0)+"%"]
[token.halo=if(((PV/MaxPV)>0.25),"Yellow","Red")]

gives :

Error Evaluating Expression: Invalid Halo Color (ello)

When PV/maxPV is > 0.25

and

Error Evaluating Expression: Invalid Halo Color (e)

When PV/maxPV is < 0.25

What am I doing wrong?

You can only evaluate values within the IF statement, you can't execute operations. So, your "PV/maxPV" must be done outside of the IF statement and then that variable evaluated. I didn't test it, but that's was my learning from this morning.

[Craig]

The following token macro :

/stp [MaxPV=MaxPV]
[PV = min(PV - Damage,MaxPV)]
[state.Mort = max(0, min(1, PV)) *-1 + 1]
[Ratio=round(round(PV/MaxPV,2)*100,0)+"%"]
[token.halo=if(((PV/MaxPV)>0.25),"Yellow","Red")]

gives :

Error Evaluating Expression: Invalid Halo Color (ello)

When PV/maxPV is > 0.25

and

Error Evaluating Expression: Invalid Halo Color (e)

When PV/maxPV is < 0.25

What am I doing wrong?

You can only evaluate values within the IF statement, you can't execute operations. So, your "PV/maxPV" must be done outside of the IF statement and then that variable evaluated. I didn't test it, but that's was my learning from this morning.

The expression in the if works
Its a parser bug that is striping parts of the string weird (first and last character). but its not doing it everywhere just some places, wierd

[Orchard]

Okay, in playing around with the new codes, I'm very curious...what have I broken? Both of these throw the same error:

Code: Select all

Roll {R=1d20}
Hit {RHit=if(R>=EnemyAC || R==20 ,1,0)}

Code: Select all

Roll {R=1d20}
Hit {RHit=if((R>=EnemyAC || R==20),1,0)}

This results in:

Could not execute the command: null

The question is: why?
It should be possible to say, logicallly IF R is equal to or greater than EnemyAC OR if R equals 20, then set RHit to 1, otherwise set RHit to 0. That's what I'm saying in the code, I think, but the parser disagrees and I'm not sure why.

Now, before I added the " || R==20" bit, things were moving along quite nicely, and I'm pleased with the new functionality. Muito bem.

[Micco]

Interesting Craig...I was just about to post about that bug. Here's my observations on it (I'll name it "The Bug That Ate Characters")

The parser "eats" the first and last characters of a string that is passed out of a property.

For example, if I have "Claw" in a token property called Attack1Label and then reference that property like this:

{Attack1Label}

I get output in my string like this:

Code: Select all

la

If I put leading and trailing spaces in the property like this:

Code: Select all

" Claw "

I get:

Code: Select all

Claw

If I then assign the value of that property within a macro like this:

{AttackLabel = "Attack1Label"}

I get:

Code: Select all

la

as the parser again ate the leading and trailing spaces. If I put two leading and trailing spaces:

Code: Select all

"  Claw  "

it gives the right output again.

It's been around a couple of builds. I think I mentioned it in B36 (which was, what, less than a week ago?)