Far as I can tell, it is not present in b45.Hawke wrote:Do we know if this soft-fog-mouseover bug is present in b45?
MapTool 1.3 Development Build 47
Moderators: dorpond, trevor, Azhrei, Craig
BUG: Changing token image
Sometimes (this is intermittent) when I drag an rptok onto the board, I want to change the token image, mix things up etc.
So I double click, then hit the little green + next to the pic and choose a new token.
Sometimes, when I do this... the OK button stops working.
It clicks. It depresses, changes color... but has no effect. Dialog doesn't close, changes are not saved, etc.
I have to Cancel or X out, which loses the change. Re-editing the token, choosing the same pic, will then work.
It mostly seems to happen with one specific token I have... the effect is fairly consistent.
I'm including the rptok here so you can figure out the cause, maybe.
STEPS TO REPRODUCE:
1: Drag token onto map. Can be from file manager or Resource library
2: Double click token
3: Hit green + to change image
4: Choose any other image and hit ok
5: Once back to the basic "Edit Token" window, click OK, nothing happens.
I am able to consistently reproduce the behaviour using this one token, have not yet identified other affected tokens.
The behaviour is campaign-independent. I was able to start a brand new session, on the default grasslands, and reproduce this.
Sometimes (this is intermittent) when I drag an rptok onto the board, I want to change the token image, mix things up etc.
So I double click, then hit the little green + next to the pic and choose a new token.
Sometimes, when I do this... the OK button stops working.
It clicks. It depresses, changes color... but has no effect. Dialog doesn't close, changes are not saved, etc.
I have to Cancel or X out, which loses the change. Re-editing the token, choosing the same pic, will then work.
It mostly seems to happen with one specific token I have... the effect is fairly consistent.
I'm including the rptok here so you can figure out the cause, maybe.
STEPS TO REPRODUCE:
1: Drag token onto map. Can be from file manager or Resource library
2: Double click token
3: Hit green + to change image
4: Choose any other image and hit ok
5: Once back to the basic "Edit Token" window, click OK, nothing happens.
I am able to consistently reproduce the behaviour using this one token, have not yet identified other affected tokens.
The behaviour is campaign-independent. I was able to start a brand new session, on the default grasslands, and reproduce this.
Ran into the mouseover today's game in b45. Funnily enough I didn't mention it in case it was there and quickly one of my players said "There's 5 guys in that room."Rumble wrote:Far as I can tell, it is not present in b45.Hawke wrote:Do we know if this soft-fog-mouseover bug is present in b45?
"How do you know"
"I don't know, I moved my mouse and saw them... sorry... I'll try not to do that again."
----
Also, It'd be nice if the labels/healthbar wouldn't be visible if the token cell wasn't visible. Overall b45 is somewhat stable for my group, eager to try out b48!
Your token has a Macro with an null command. The replaceMacroList() method in Token.java tries to reference the null command and goes boom. (Running MT from a batch file using "java.exe" would have revealed the exception message the first time you hit it.)palmer wrote:BUG: Changing token image
Sometimes (this is intermittent) when I drag an rptok onto the board, I want to change the token image, mix things up etc.
The question that needs to be answered is whether or not a null command string should be considered an error and trapped or left as is.
In any case, took less than a minute to find it in Eclipse and will take about the same to fix it.
That's bizzare, considering I set that macro up using drag-copy from other tokens. I've identified another token which had a null macro and it exhibited the same behaviour. Fixed them now.Phergus wrote:Your token has a Macro with an null command. The replaceMacroList() method in Token.java tries to reference the null command and goes boom. (Running MT from a batch file using "java.exe" would have revealed the exception message the first time you hit it.)
The part I'm curious about is that the first time, the OK button wouldn't work. But if I cancelled and did it again, it would work.
This makes me wonder about that error trapping, as it's not doing it all the time.
This argues strongly for better logging in MT. 
I'm a little familiar with Log4J (and the "official" Java Logging API, since they're the same), but I think that would take a lot of work to log exception output, right? Or is it as easy as opening a file, creating a PrintWriter, and storing that into System.{out,err} ?
It would be great if, at startup, MT could check and if the file already exists and has more than a couple lines in it (to account for the LAF messages) it would rename it to a permanent name that won't be overwritten in the future... And then put a message box on the screen letting the user know there is a log file with crash information in it.
I'm a little familiar with Log4J (and the "official" Java Logging API, since they're the same
), but I think that would take a lot of work to log exception output, right? Or is it as easy as opening a file, creating a PrintWriter, and storing that into System.{out,err} ?It would be great if, at startup, MT could check and if the file already exists and has more than a couple lines in it (to account for the LAF messages) it would rename it to a permanent name that won't be overwritten in the future... And then put a message box on the screen letting the user know there is a log file with crash information in it.
I was -just- looking over the source for my first time...and yeah, I was kinda surprised by all the printStackTrace()'s in there...but, then again, I guess that is why it's _b_47, right? ^.^ Still, it would be nice to have a log somewhere, since I -do- play launched from a script, so stdout/err are gone off to /dev/null. Or, perhaps, have a logging chat tab option eventually.
Then my guess is the drag-copy of macros is probably broken as well.palmer wrote:That's bizzare, considering I set that macro up using drag-copy from other tokens.
The first time through it tries to copy the macros but fails when it gets to the macro with a null command. Any that came before it are preserved. In your example case the first one is null so all are lost. After that it has an empty macro list and doesn't try to copy them them.palmer wrote:The part I'm curious about is that the first time, the OK button wouldn't work. But if I canceled and did it again, it would work.
IRRITATION: Right click delete missing
I can no longer right click a Common Macro and delete it. This is what I would do when I needed to update a macro across the board. Delete them all, add new with update, drag-copy to all.
Pursuant to that, could we just have the ability to edit a Common Macro (which are by definition identical) and have that change propagate to all selected?
I can no longer right click a Common Macro and delete it. This is what I would do when I needed to update a macro across the board. Delete them all, add new with update, drag-copy to all.
Pursuant to that, could we just have the ability to edit a Common Macro (which are by definition identical) and have that change propagate to all selected?
If Lindharin isn't already looking into it, I will, but what you're asking for isn't quite as straightforward as you might think at first blush. I can't guarantee that I would have it ready for b48, but I'll try.palmer wrote:IRRITATION: Right click delete missing
I can no longer right click a Common Macro and delete it. This is what I would do when I needed to update a macro across the board. Delete them all, add new with update, drag-copy to all.
Pursuant to that, could we just have the ability to edit a Common Macro (which are by definition identical) and have that change propagate to all selected?
Speaking of which, do you have a ETA for b48 yet, trevor? (Just so I know how much I would need to rush this for next release.)
"Should" is the biggest word in the English language.
"Just" is the second biggest word in the English language.
What I'm working on
"Just" is the second biggest word in the English language.
What I'm working on
Real life is interfering this week (business travel), so I won't be able to look at that until at least next week. So if you have the chance and the interest to fix that, applekor, feel free!applekor wrote:If Lindharin isn't already looking into it, I will, but what you're asking for isn't quite as straightforward as you might think at first blush. I can't guarantee that I would have it ready for b48, but I'll try.
