1) For some reason, the Maptools Launcher doesn't actually work to launch maptools. It will give me the pop-up asking for memory allocation just fine, but after I click 'okay', I get an error that it is unable to access the jarfile and Maptools doesn't launch.
2) I can use the jarfile directly to launch Maptools, but it doesn't seem to recognize the memory allocation settings I might enter in the launcher. I can use the Launcher, change Stack from 2 to 200, get the error, then start Maptools from the Jarfile and I still get a stack overflow from what I consider to be pretty short and simple macros. This leads me to believe that the launcher isn't properly setting the memory due to the inaccessible jarfile error.
3) I've tried editing the .SH file to reflect my preferred stack size, bumping it from 2 to 200. This still causes me to get a stack overflow error on these short macros, which means it's either not actually changing my stack size, or these macros are somehow causing an absolutely massive overflow.
I'm not extremely well-versed (I can barely understand http://www.lmwcs.com/rptools/wiki/Avoid ... k_Overflow) but I know enough to think it's extremely odd that something this simple is throwing me a stack overflow. Here's the first macro I'm using, "Scratch":
Code: Select all
[h: x=input("Dbase|2|Damage base")]
[MACRO("GetDamroll@Lib:Common"):Dbase]
[h: ret=macro.return]
[h: numDice = getStrProp(ret,"num")]
[r: numDice]I've written it very simply as an initial test. GetDamroll actually returns three values, but I'm only using numDice for right now to make sure it's returning them properly (it is). Now, here's GetDamroll:
Code: Select all
[h: damBase = json.get( macro.args, 0 )]
[h,switch(damBase), code:
case 1: {[h: numDice=1] [h:numSides=6] [h:bonus=1]};
case 2: {[h: numDice=1] [h:numSides=6] [h:bonus=3]};
case 3: {[h: numDice=1] [h:numSides=6] [h:bonus=5]};
case 4: {[h: numDice=1] [h:numSides=8] [h:bonus=6]};
case 5: {[h: numDice=1] [h:numSides=8] [h:bonus=8]};
case 6: {[h: numDice=2] [h:numSides=6] [h:bonus=8]};
case 7: {[h: numDice=2] [h:numSides=6] [h:bonus=10]};
case 8: {[h: numDice=2] [h:numSides=8] [h:bonus=10]};
case 9: {[h: numDice=2] [h:numSides=10] [h:bonus=10]};
case 10: {[h: numDice=3] [h:numSides=8] [h:bonus=10]};
case 11: {[h: numDice=3] [h:numSides=10] [h:bonus=10]};
case 12: {[h: numDice=3] [h:numSides=12] [h:bonus=10]};
case 13: {[h: numDice=4] [h:numSides=10] [h:bonus=10]};
case 14: {[h: numDice=4] [h:numSides=10] [h:bonus=15]};
case 15: {[h: numDice=4] [h:numSides=10] [h:bonus=20]};
case 16: {[h: numDice=5] [h:numSides=10] [h:bonus=20]};
case 17: {[h: numDice=5] [h:numSides=12] [h:bonus=25]};
case 18: {[h: numDice=6] [h:numSides=12] [h:bonus=25]};
case 19: {[h: numDice=6] [h:numSides=12] [h:bonus=30]};
case 20: {[h: numDice=6] [h:numSides=12] [h:bonus=35]};
case 21: {[h: numDice=6] [h:numSides=12] [h:bonus=40]};
case 22: {[h: numDice=6] [h:numSides=12] [h:bonus=45]};
case 23: {[h: numDice=6] [h:numSides=12] [h:bonus=50]};
case 24: {[h: numDice=6] [h:numSides=12] [h:bonus=55]};
case 25: {[h: numDice=6] [h:numSides=12] [h:bonus=60]};
case 26: {[h: numDice=7] [h:numSides=12] [h:bonus=65]};
case 27: {[h: numDice=8] [h:numSides=12] [h:bonus=70]};
case 28: {[h: numDice=8] [h:numSides=12] [h:bonus=80]};
default: {[h: numDice=1] [h:numSides=1] [h:bonus=0]}]
[h:returnData=setStrProp(returnData,"num",numDice)]
[h:returnData=setStrProp(returnData,"sides",numSides)]
[h:returnData=setStrProp(returnData,"plus",bonus)]
[h:macro.return=returnData]This is what's causing my stack overflow. When I cut it down to only having "Case 2," which is the argument I'm using for testing, it works perfectly fine. However, I need it to be able to handle one through twenty-eight, and having that many if cases causes an overflow! HALP!
