RPTools.net

Daeger wrote:Not to mention the fact it doesn't even work at all for some of us.

And I have no clue why that would be. I was hoping some of the Windows gurus here could try it and investigate the issue more. Since there's nothing in the log and nothing is displayed on the console, someone with some knowledge of how Java runs on the platform is going to need to take a look. Maybe perusing the ChangeLog would give a clue as to what the issue might be...

With Java 7 I had the colour picker ArrayIndexOutOfBounds exception. Then I rolled back to Java 6.31 and b88 worked fine. Windows 7 here.

Jox wrote:With Java 7 I had the colour picker ArrayIndexOutOfBounds exception. Then I rolled back to Java 6.31 and b88 worked fine. Windows 7 here.

I admit that I have submitted the patch that causes this aggrevation. To my defense I must say that this is a very curious situation. You may try the work-around you describe (roll back Java), use the old rplib.jar or apply the patch included (if you know how to do that). There are several guesses as to why this happens: Java 7 changed the look&feel compared to Java 6. The people experiencing the problem have changed their look&feel themselves. Or TinyLAF (a quite old library in MT) finally gives up. The patch provided implements a workaround. I would be interested in a screenshot of the PaintChooser from the people that have this problem, either when using the old rplib or Java 6.

I'm sorry but this effect of the patch included in b88 could not be conjectured. To be honest, I would like to debug this more closely, but I can't reproduce this. Some technical notes follow for those with a knack for diving into code, because I will not have time for this during the next three weeks:

Spoiler

Look into the PaintChooser.java from rplib. The ArrayIndexOutOfBounds happens, because the method createHueColorChooser returns a colorchooser with no (sub-chooser) panels. That can only happen if javax.swing.colorchooser.DefaultHSBChooserPanel was not instantiated. This in turn means that (a) Java decided to kick this class, (b) The LAF decided to kick it, (c) the user (inadvertently) decided to kick it. I have also found some notes on changes from Java 6 to Java 7 concerning the color choosers here: http://docs.oracle.com/javase/tutorial/ ... ooserpanel => "Creating a Custom Chooser Panel", which might explain this problem. That wouldn't justify incompatible changes on Oracle's side though. (But the MT code is quite strange at that point and needs to stretch "compatibility" quite a bit.)

aliasmask wrote:b88 and b87 seem pretty compatible for saving and loading, so I've been doing my map editing in b87 but game playing in b88 because of the frame popup fix.

You can even connect with a b86 as GM to a b88 running. This way you can circumvent the problem that objects on the background cannot be sized in b88. Not that this is a comfortable solution.

username wrote:

aliasmask wrote:b88 and b87 seem pretty compatible for saving and loading, so I've been doing my map editing in b87 but game playing in b88 because of the frame popup fix.

You can even connect with a b86 as GM to a b88 running. This way you can circumvent the problem that objects on the background cannot be sized in b88. Not that this is a comfortable solution.

Are you saying I can run a game with b88 and run an instance of b86 (b87?) and connect to b88 game and not have to worry about resize and drop problem through b86 instance?

Can we pull out this patch and release a b89?

aliasmask wrote:

username wrote:

aliasmask wrote:b88 and b87 seem pretty compatible for saving and loading, so I've been doing my map editing in b87 but game playing in b88 because of the frame popup fix.

You can even connect with a b86 as GM to a b88 running. This way you can circumvent the problem that objects on the background cannot be sized in b88. Not that this is a comfortable solution.

Are you saying I can run a game with b88 and run an instance of b86 (b87?) and connect to b88 game and not have to worry about resize and drop problem through b86 instance?

You can resize/rotate in the b86(b87 should work as well) instance. That gets propagated to the b88. (Needs a redraw nudge once in a while.) Whether this has anything to do with the drop issue I don't know, meaning I haven't reproduced the problem yet.

Here's a patch for people eager to test. It resolves (or rather should resolve) the issue that you can't drop a second token. Problem is that during subsequent drag-n-drop an unmodifiable list was cleared. This caused all drag-n-drops from then on to fail when the drop occured and later stages would just assume the activity happend on the previous item.

(Side note: this is the announcement forum. Maybe it is not appropriate to post patches to the "general public", but the issue was brought up here and may be urgent enough for some people to try out patches. Where else should this go? CC'd to Azhrei anyway.)

username wrote:Here's a patch for people eager to test. It resolves (or rather should resolve) the issue that you can't drop a second token. Problem is that during subsequent drag-n-drop an unmodifiable list was cleared. This caused all drag-n-drops from then on to fail when the drop occured and later stages would just assume the activity happend on the previous item.

(Side note: this is the announcement forum. Maybe it is not appropriate to post patches to the "general public", but the issue was brought up here and may be urgent enough for some people to try out patches. Where else should this go? CC'd to Azhrei anyway.)

Testers Forum...

So, should us users apply this patch or wait till b89?

ziltmilt wrote:So, should us users apply this patch or wait till b89?

Unless you want to compile the code yourself, you'll need to wait for b89

I don't want to produce another build until we have this working -- we're getting too close to a three-digit build and I don't know if that's going to screw things up but I don't want to risk it.

So when the Testers forum has had a couple people try it out, then I'll do the build. I have some time at the end of the week to do another build if we get some confirmation on this.

Is the resize issue resolved already, or is this inherent to the other issue?

wolph42 wrote:Is the resize issue resolved already, or is this inherent to the other issue?

Resize issue has a patch out in the testers' forum since... like two minutes. It's unrelated to both startup-crash and drop-token issues.

Is there a workaround for this bug because it just hit me out of nowhere and no matter what I do I cant defeat the token replace bug!