MapTool 1.3 Development Build 38

New build announcements plus site news and changes.

Moderators: dorpond, trevor, Azhrei, Craig

Post Reply
User avatar
trevor
Codeum Arcanum (RPTools Founder)
Posts: 11311
Joined: Mon Jan 09, 2006 4:16 pm
Location: Austin, Tx
Contact:

MapTool 1.3 Development Build 38

Post by 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.
Dreaming of a 1.3 release

n3phrit
Cave Troll
Posts: 84
Joined: Mon Apr 21, 2008 7:30 am

Post by n3phrit »

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

User avatar
Micco
Giant
Posts: 148
Joined: Mon Jun 16, 2008 10:21 pm

Post by 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.
Last edited by Micco on Mon Jul 28, 2008 11:21 am, edited 4 times in total.

User avatar
TK
Giant
Posts: 162
Joined: Fri Jun 27, 2008 12:02 am

Post by TK »

Micco wrote: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.

User avatar
UntoldGlory
Great Wyrm
Posts: 1649
Joined: Sun Mar 16, 2008 8:12 pm

Post by UntoldGlory »

ooooOOOOOOoooooo

Well, time to rewrite all the macros!




Again.





And be happy about it! :P

User avatar
RedDog
Dragon
Posts: 372
Joined: Sat Jan 05, 2008 10:02 pm
Location: Clearwater, FL

Post by RedDog »

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

User avatar
Mathemagician
Dragon
Posts: 666
Joined: Tue May 22, 2007 2:27 pm

Post by Mathemagician »

Fantastic :)
I'm obsolete now 8)

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 :D

User avatar
RPTroll
TheBard
Posts: 3148
Joined: Tue Mar 21, 2006 7:26 pm
Location: Austin, Tx
Contact:

Re: MapTool 1.3 Development Build 38

Post by RPTroll »

trevor wrote: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.

User avatar
Stitched
Dragon
Posts: 274
Joined: Fri Jul 11, 2008 5:56 am
Location: Uppsala, Sweden

Post by Stitched »

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

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

User avatar
simonutp
Giant
Posts: 160
Joined: Wed Jun 06, 2007 10:03 am
Location: Colmar, France

Post by 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?

User avatar
Orchard
Great Wyrm
Posts: 1852
Joined: Fri May 09, 2008 10:45 am
Location: Doylestown PA
Contact:

Post by Orchard »

Mathemagician wrote:Fantastic :)
I'm obsolete now 8)

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 :D


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.
0+0=1, for very unstable CPUs.

User avatar
Micco
Giant
Posts: 148
Joined: Mon Jun 16, 2008 10:21 pm

Post by 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
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Post by Craig »

Micco wrote:
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

User avatar
Orchard
Great Wyrm
Posts: 1852
Joined: Fri May 09, 2008 10:45 am
Location: Doylestown PA
Contact:

What am I doing wrong?

Post by 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.
0+0=1, for very unstable CPUs.

User avatar
Micco
Giant
Posts: 148
Joined: Mon Jun 16, 2008 10:21 pm

Post by 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?) :)

Post Reply

Return to “Announcements”