The MacroPolicebox: Second Regeneration (D&D 4E Framework)

Framework(s) for D&D 4e, including Veggiesama's.

Moderators: dorpond, trevor, Azhrei, giliath, Gamerdude, jay, Mr.Ice

Xun
Cave Troll
Posts: 29
Joined: Mon Nov 22, 2010 2:11 pm

Re: The MacroPolicebox: Second Regeneration (D&D 4E Framewor

Post by Xun »

ok, this is weird now...
Your Vani gives me the same overflow error.
I now ran Vani under (MT 1.4.8.1/MPB SL159) and it also crashes.
My dnd4e at least finishes the first import step under (MT 1.4.8.1/MPB SL159) but then crashes with overflow near the end of the import power step.

For the crash on F4 under SL181, I put some debug statements into the macros and it seems to get all the way through to the last (long) coding line in the Setup player token F4-macro.

Btw., being somewhat rusty on my posting after my first few - 7 years ago -, I oversaw the warning not allowing dnd4e extension files to be added... :D
Attachments
Dolgar3.zip
(28.46 KiB) Downloaded 22 times

User avatar
StarMan
Dragon
Posts: 939
Joined: Mon Jul 18, 2011 1:10 pm
Location: Toronto

Re: The MacroPolicebox: Second Regeneration (D&D 4E Framewor

Post by StarMan »

OK I was able to download your file and do the import, the results of which are attached. You didn’t supply a JPEG so I chose a dwarf-looking guy from my token collection. As you can see from the chat log, I had to set the “Allow houseruled” option but I kept prompting off. I’m actually on the job now so I shouldn’t be doing things the long way.
Dolgar.zip
The mighty Dolgar is born!!! Let the monster ass-kicking begin!!!
(534.28 KiB) Downloaded 19 times
Speaking of which, you should have generally fewer memory issues with prompting on but I still think this is a Java and/or MT 1.4 problem. There is a precedent in this forum for the MPB failing under 1.4 but succeeding under 1.3 without anything else being changed. You can read all about that here. My first post on that page is still true. I still haven’t tried 1.4 and can assure you I have no intention of releasing a 1.4-certified version if the official story is that 1.3 macros are guaranteed to run under 1.4 unaltered:
Jagged wrote:There shouldn't be any compatibility issues between 1.3b91 and 1.4

If you find any please let us know.

There is one known bug with 1.4.0.1 (with table image size) but that has been corrected.
If I am wrong in that understanding then somebody please post evidence to the contrary. Anyway, pre-1.4.0.3 was admitted to be defective by Craig later down that same page! Maybe latter 1.4 releases aren’t as good at handling stacks.

Again, all I can suggest is you uninstall your JRE and install base Java 8 without any updates. If that doesn’t work then try under MT 1.4.0.5 with the same Java. The idea is to start from scratch (when things were presumably working ok) and then update both until we find the latest working MT/Java combo. I know your contention is that “something happened after SL 156” but if that were true then why are both dnd4e’s working on my iMac and both failing on your system? OK I admit I haven’t tried SL 181 but I started working on 182 yesterday and can assure you the fixes thus far are negligible. The only relevant adjustment is in the Import Magic Item macro and it sounds like you are failing before we get anywhere near that stage.

If you have a spare system kicking around then another idea is to install 1.3 b91 on it with base Java 8. Do all your importing on that box and then send the campaign file to your 1.4 system where you can hopefully run encounters without incident. I am gladdened by the fact you are trying to alter the macros to debug the point at which the crash occurs. I like to put [assert(0, “Hello”)] statements just before the suspected trouble point so I can verify we can at least get to Point X. That way we can isolate the offending statement. By all means keep me posted on your efforts …
StarMan - The MacroPolicebox D&D 4E Framework: Import ANYTHING!

Xun
Cave Troll
Posts: 29
Joined: Mon Nov 22, 2010 2:11 pm

Re: The MacroPolicebox: Second Regeneration (D&D 4E Framewor

Post by Xun »

ok, I took my older PC (32 bit java) and installed
  • MT 1.3.b91
    Java 8.0
I ran your Vani under MPB SL154 and 181 and both failed.
I launched with 1024/1024/6 memory setting.
Then I loaded the SL154(181) campaign file, set PC prompting to off, dragged the Elf from the standard token library to the Map, set it from NPC to PC and ran F4.

I am at a loss here...

Comparing with your former debug pic, the difference being you running MAC on 64-bit with a still older SRE build (1.6.xxx)
Attachments
MT debug.JPG
MT debug.JPG (44.05 KiB) Viewed 1116 times

User avatar
StarMan
Dragon
Posts: 939
Joined: Mon Jul 18, 2011 1:10 pm
Location: Toronto

Re: The MacroPolicebox: Second Regeneration (D&D 4E Framewor

Post by StarMan »

In that case I'm out of ideas. :( If it's a problem with the OS (which is what I'm suspecting since we've eliminated all the other variables) then even going down to Java 7 or up to 9 won't help although it costs you nothing to try those options too. If you have it, you can try installing Win XP in VMWare or VirtualBox but I still say it would be simpler to just keep trying different systems. Yes, my OS X has 1.6 installed at the O/S level but MT itself is pointing to Java 8. This is the string from my MT launcher:
/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java -Xms64M -Xmx1024M -Xss5M -ea -DMAPTOOL_DATADIR=/Users/Dave/.maptool -Xdock:name=MapTool 1.3 -jar maptool-1.3.b91.jar run

XXX-iMac:bin Dave$ pwd
/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin
XXX-iMac:bin Dave$ ./java -version
java version "1.8.0_73"
Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode)

Did you try importing a monster as per my PM? Just curious if that works. Also do download the zip I attached above and see if Dolgar's powers work ok. If none of your friends have any luck either then send me your other dnd4e files and I will be happy to create the tokens for you. I admit that's not a good long term solution but at least it will get you going this time.
StarMan - The MacroPolicebox D&D 4E Framework: Import ANYTHING!

Xun
Cave Troll
Posts: 29
Joined: Mon Nov 22, 2010 2:11 pm

Re: The MacroPolicebox: Second Regeneration (D&D 4E Framewor

Post by Xun »

I will check on the zipped Dolgar later on...
Just tried to import a monster, gave me the same stack overflow error after the second input pop-up...

Thank you for your immediate assistance so far. I will try some more settings and let you know of my findings.

Cheers, Xun

User avatar
StarMan
Dragon
Posts: 939
Joined: Mon Jul 18, 2011 1:10 pm
Location: Toronto

Re: The MacroPolicebox: Second Regeneration (D&D 4E Framewor

Post by StarMan »

Hmmm, I notice you are using a 32-bit JVM. Would it be possible for you to try a 64-bit one like this guy did? You may even want to post your results to that thread to see if those guys (of which Full Bleed is one) can help. The first thing you will want to assure them is that there is nothing wrong with the framework. If there was then I and the rest of my user base would be having difficulty too. Yes I have had other users going through crashes but every single time it was a problem with MT fighting with Java and had nothing to do with anything I did. Failing that, try reading other posts in this search I did.
StarMan - The MacroPolicebox D&D 4E Framework: Import ANYTHING!

Xun
Cave Troll
Posts: 29
Joined: Mon Nov 22, 2010 2:11 pm

Re: The MacroPolicebox: Second Regeneration (D&D 4E Framewor

Post by Xun »

Just noticed something strange while playing around with 'assert'.
When I place an 'assert[0,...]' at the end of the F4 macro, it finishes up to this point and I end up with an 'empty' lib:token. (Not sure, if this should be the case at that point...)
After placing an 'assert[0,...]' at the end of 'edit properties', I then ran a button on the token itself (prompting switched on) and ended up - no stack overflow - with a lib:token with exact the same content as your Dolgar lib:token.

So basically everything runs smoothly, except when 'returning' from macro execution - whatever that tells me...

Btw, I did this with the combination of all the newest releases (JAVA 8 151/MT 1.4.8.1/MPB 181)

User avatar
StarMan
Dragon
Posts: 939
Joined: Mon Jul 18, 2011 1:10 pm
Location: Toronto

Re: The MacroPolicebox: Second Regeneration (D&D 4E Framewor

Post by StarMan »

While I certainly applaud finding alternative ways to de-fur the proverbial feline, I'm afraid this isn't practical as a long-term solution. I'm shocked there was no overflow at the power generation stage as the macros that are used then are definitely larger than Setup Player Token. When you start an actual game session then you will be running Attack Power and Register Effect which are also pretty ginormous in their own right. In all cases, the text for these will need to fit into your stack size. Since you are using a 32-bit JVM, that space will be 1Mb regardless of what you select in the launcher at the beginning. I gleaned that little tidbit from the research mentioned in my last post. If the error rears its ugly head again then read this article on ways to get around it.

The other problem is that you will need to modify Setup Player Token for every SL that I release. Well ... at least the ones you wanna run F4 with anyway. It's OK to delete the code at the end from the [Results=""] line on down because it's just output for the remainder of the macro. Glad to hear you are able to go on and generate the Lib token contents but the danger of getting another overflow during gameplay will be omnipresent as I explain above. Don't get me wrong, I am constantly searching for ways to reduce the size of all my code but the most I can manage each SL are a few bytes. That's meaningless in the grand scheme of things. You won't be able to significantly pare down the operational macros without breaking something so the only answer is to go up to a 64-bit JRE. 64-bit allows enormous stack sizes so you should never have overflow issues again when setting to 5 or 6.

Once again, the important thing is that you are willing to tinker with the code to find a solution which is exactly what I do when I find a bug. Bravo! :) As such, I obviously can't fault you for doing the same thing. If your character macros aren't working quite the way you like I encourage you to go through the Programmers' Reference on the web site as well as the MMHoF Lib token. The latter contains customized common powers and feats. Don't hesitate to let me know if you have any further questions.
StarMan - The MacroPolicebox D&D 4E Framework: Import ANYTHING!

Xun
Cave Troll
Posts: 29
Joined: Mon Nov 22, 2010 2:11 pm

Re: The MacroPolicebox: Second Regeneration (D&D 4E Framewor

Post by Xun »

Well, I continued 'tinkering' a bit to narrow down the issue.
Meanwhile, I think it is not a gradual (linear) problem of assembling stack during runtime but more a general issue somewhere in the code (on whatever layer...). I am also leaning towards the conclusion that me running a German language OS may also contribute to the fact.

Anyhow...
my search led me to one line of coding deep down then path F4->Create button group->Refresh Menu tooltips->update tooltip.
If I delete the line...

Code: Select all

[IF(listContains(Available, Label) || !listContains("maroon,black", color)): PowersList=listAppend(PowersList, Label)]
...I get through the import process w/o overflow - at least for stack size 8 and higher.
As the line as such does not look like being enough to cause a stack overflow (I tracked Powerlist, broadcasting it), it certainly is some kind of trigger for the issue.

I then found a checkbox in the Global toggles (Powerlist in tooltips) and I de-selected it.
This works like a charm now, as I get through the import step w/o error even on such 'low' settings as 1024/1024/4.

Unfortunately, this still does not help me to get through the power import step, so I will continue to tinker there ...

BR,
Xun

User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: The MacroPolicebox: Second Regeneration (D&D 4E Framewor

Post by Full Bleed »

StarMan wrote:Thanks for your responses, Jamz and Full Bleed. I guess I am on the "high end" because I get overflow errors when using a value of 4 in 1.3 b91. Again, in my experience every time somebody gets an overflow not solved by increasing SS then it's because they are using a faulty JRE. For me, everything goes smoothly with 5 as pointed out in the link in my post above.
5 isn't worrisome. Some frameworks need a little more. But 12 is really outside the norm and I've seen numbers like that cause more problems than they fix so I like to warn users who have done that. Before I started messing with stack I'd make sure a player was using 64 bit java and then bump the max mem up to half of their system memory... and only then would I start nudging the stack 1 at a time to find stability.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

User avatar
StarMan
Dragon
Posts: 939
Joined: Mon Jul 18, 2011 1:10 pm
Location: Toronto

Re: The MacroPolicebox: Second Regeneration (D&D 4E Framewor

Post by StarMan »

Xun wrote: Unfortunately, this still does not help me to get through the power import step, so I will continue to tinker there ...
What I wager will help is Full Bleed's wise advice of going up to a 64-bit JRE and then tuning your stack the way he suggests. I am assuming your reluctance to respond on this point is because you have some particular reason for sticking to 32-bit. That's your choice and I respect that if you want to find a way using your current setup. Just keep in mind the article I referenced as a means for fixing your system software. You will then be able to use my framework the way you see me doing in my videos. Having said that, I do pride myself on the fact the MPB has relatively low memory requirements given the broadness of its scope.

I honestly don't know how using German Windows will affect things but I do recall a post explaining what parameter(s) to add at the launcher stage to support non-English characters. I did find it interesting that turning tooltip refreshing off allows things to run more smoothly. If you already know where all the functions are then half the explanations in my Architecture video become moot. The Powerlist variable itself is tiny so I very much doubt that is a large contributing factor. Nevertheless, I am greatly interested in your findings with respect to how certain stretches of code affect memory consumption so I look forward to your results.
Last edited by StarMan on Sat Jan 06, 2018 5:54 am, edited 1 time in total.
StarMan - The MacroPolicebox D&D 4E Framework: Import ANYTHING!

Xun
Cave Troll
Posts: 29
Joined: Mon Nov 22, 2010 2:11 pm

Re: The MacroPolicebox: Second Regeneration (D&D 4E Framewor

Post by Xun »

Ok, I did not mention this explicitly. I only used my 32-bit machine to check on the older Java versions. Now I am already back on my 64-bit computer (where I do all my playing around). I was just reluctant until now to install additional/older Java versions here (which I might do in the end...).

Xun
Cave Troll
Posts: 29
Joined: Mon Nov 22, 2010 2:11 pm

Re: The MacroPolicebox: Second Regeneration (D&D 4E Framewor

Post by Xun »

btw, I already tried a lot changing the memory settings, also what Full Bleed suggested (I ran on Java 64bit with a 8192/4096/4 tuning it up tp 8192/4096/8) I get the overflow in each and every combination.

I also, albeit slowly, trying to wriggle my mind around the macro language. Following on the suggestions in the MP-wiki about stack overflow, I wondered about two of the topics there.

One was the regex topic (this is why I thought of the German setting). I remeber trying to do something with regex in MT in the past, always in parallel checking on the various regex-websites, where you comfortably can check if it works. -> You had always change the expression a bit to work in MT (e.g. adding a '/' here and there.)
So I just wondered, if the macro-code somewhere assembles a lot of memory and - in the end - dumps.
But as I have definitly no technical background, it is just a gut feeling.

Second was the suggestion about having smaller parts of coding. For sure, I do not want to redesign code here, but I took the effort to play around a bit. The macro code as such does not seem excessivly large and I guess it is already strucured very well in terms of hierarchical calling of (other) macros. But I wonder - w/o really understanding how the macro language works - that 'evalmacro' may be some hidden function to inline code at runtime and thus contributing to the memory issue.
Clutching at that particular straw - and if only to improve my understanding of macro coding :D - I replaced most of the evalmacro() functions from the F4-macro by macro() itself. Without having found a better way on short notice, I had to pass along the token-name down the macro chain and 'switchtoken' explicitly everywhere.
=> and as a result, I got rid of the stack overflow during F4 - even at the default low memory settings (1024/64/2)

So summarizing all my admittedly more or less academic approaches until now...
  • 1. I started with deleting one line of code to get rid of the stack issue
    2. Used a global setting, which prevented the execution of the line I deleted in 1.
    3. replaced evalmacro() by macro(), which also affected the code processed in 1. and 2.
Only with step three, I was able to reduce the memory to (1024/64/2) without stack overflow, for options 1 and 2, I still get the overflow with these settings. So 1./2. were maybe only prominent contributers to the issue, but there seem to be others.

The one central question - of course - remains unanswered: why me? :(

I guess my next attempt will be tuning down java-versions on my 64-bit machine (though I hate playing around with those configurations...)

User avatar
StarMan
Dragon
Posts: 939
Joined: Mon Jul 18, 2011 1:10 pm
Location: Toronto

Re: The MacroPolicebox: Second Regeneration (D&D 4E Framewor

Post by StarMan »

Agreed, it sounds like you've explored the full spectrum of memory options. I really am truly sorry you're having so much trouble but I honestly can't be of any more help except to repeat my earlier suggestion that you search for other posts on this forum from those who have had overflow issues. I am already following most of the guidelines at the bottom of the SO article. The only thing I can think of is refactoring the code into smaller chunks ... but I'm not sure about the best way to go about that. Besides, you are kind of doing that with your evalMacro to MACRO conversions so maybe we should compare notes.

As you have noticed by now, the two main reasons I use evalMacro is to get around the curly brace nesting limit and to save output in the Results variable for display at the end of the macros. You may want to assign blocks from Import PC Power, Construct Rumble States and RACK to their own individual macros. Passing the needed variables to these new macros and parsing them from macro.return will be a pain but may be worth the effort in your case. No promises but I will see what I can do on my end for SL 183 which I will be starting work on soon.
StarMan - The MacroPolicebox D&D 4E Framework: Import ANYTHING!

User avatar
StarMan
Dragon
Posts: 939
Joined: Mon Jul 18, 2011 1:10 pm
Location: Toronto

181/182

Post by StarMan »

In all the excitement of the most recent forum activity, I neglected to announce SL 181! 182 is available too so I will do another amalgamated highlight post. Although rare, there are monsters like the Famine Spirit with no Speed spec in their stats block. This results in a blank Notes tab for their powers. :( This has now been corrected as has Import Magic Item missing property and level descriptions. Setup Player Token now outputs power names without "X" words, RACK includes a Banner call for multi-attack powers and Create Effect will no longer delete Duration for CurrHP effects. Most other tweaks are minor efficiency improvements.

During our session this past Tuesday, my brother pointed out a major misconception our group had about OAs. We were under the impression that if you made an OA on a token then you could not take another on that token until after your next turn. Upon rereading the rules we found this is NOT the case. You may take another OA on that token after the current turn regardless of whose turn it is. I don't think this will make much difference during game play as nobody generally provokes more than once during the course of a round but I have adjusted the Opportunity Attack macro accordingly anyway.

The news I am most excited about is that I have finally resolved the problem of using Property=CurrHP effects (like Resist and Vlnrbl) with the Link=Self option. This now works as expected! The way it works is that upon registration a so-called "Removal Pointer" effect gets registered on your token which contains information about when/where your main effect (which will be set to Duration=Encounter) should end. Initial testing has looked very, very good but only time will tell if there are conflicts with other specialized aspects of the framework. Enjoy!
StarMan - The MacroPolicebox D&D 4E Framework: Import ANYTHING!

Post Reply

Return to “D&D 4e Frameworks”