MapTool 1.3 Development Build 38
Moderators: dorpond, trevor, Azhrei, Craig
- 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
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.
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
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.
(silly forum parser eats everything between < and > 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.
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.
I believe Trevor meant:&&, and
||, or
>=, ge
<le>, gt
<le>=, ge
Code: Select all
&&, and
||, or
> =, ge
>, gt
<=, le
<, lt
==, eq
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.
Especially if you're writing a page in both ASP (uses "=" for the 'is equal to' operator) and javascript (uses "==")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.
I'm quite excited by these new changes.
- UntoldGlory
- Great Wyrm
- Posts: 1649
- Joined: Sun Mar 16, 2008 8:12 pm
- Mathemagician
- Dragon
- Posts: 666
- Joined: Tue May 22, 2007 2:27 pm
Re: MapTool 1.3 Development Build 38
Orgasmic screams from trollland. IFs!!!!! Thanks the gods of coding and gaming!!!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.
GILIATH FOR PRESIDENT!!
darn, I have to go to work today. Maybe I should call in sick and play.
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?
/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?
Great!Mathemagician wrote: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
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.
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 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?
The expression in the if worksMicco wrote: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 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?
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
What am I doing wrong?
Okay, in playing around with the new codes, I'm very curious...what have I broken? Both of these throw the same error:
This results in:
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.
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)}
The question is: why?Could not execute the command: null
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.
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:
If I put leading and trailing spaces in the property like this:
I get:
If I then assign the value of that property within a macro like this:
{AttackLabel = "Attack1Label"}
I get:
as the parser again ate the leading and trailing spaces. If I put two leading and trailing spaces:
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?)
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
Code: Select all
" Claw "
Code: Select all
Claw
{AttackLabel = "Attack1Label"}
I get:
Code: Select all
la
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?)