Remaining issues for 3.3.0

[uckelman]

Remaining 3.3.0 issues in the bug tracker

What's there presently is:

* 12825: Investigate connection loss
* 12824: Improved max heap heuristic for image tiler
* 12817: Right-clicking on unexpanded stacks no longer selects top piece
* 12816: Splitter between chat and map panes starts with map completely obscured

Current status:

* 12825: I have a collection of emails and suggested patches. I intend to produce some test builds in the coming week.
* 12824: I've collected some data for Java 14. I made a test build weeks ago, but I haven't heard from anyone about it. I'll make current test build once again, but this issue won't get any further attention unless someone who is actually having tiling problems tries a test build and reports back.
* 12817: I'm investigating this now.
*12816: We get questions weekly from confused users about why they can't seen the map. This problem might be the single most asked-about one we have. Someone please volunteer to work on this.

All of these should be fixed for 3.3.0-beta4.

[Cattlesquat]

12816 --

Code: Select all

final ComponentSplitter splitter = new ComponentSplitter();           
ComponentSplitter.SplitPane pane;
pane = (SplitPane) splitter.getSplitAncestor(GameModule.getGameModule().getControlPanel(), -1);
pane.setDividerLocation(160);

Put it after the map is loaded into a scenario.

[uckelman]

3.3.0-svn9400 has fixes for:

* 12861: Improved behavior of Zone editor (thanks to Michael Kiefte)
* 12817: Right-clicking on unexpanded stacks no longer selects top piece

http://www.vassalengine.org/~uckelman/tmp/

[JoelCFC25]

* 12861: Improved behavior of Zone editor (thanks to Michael Kiefte)

Huzzah!

[uckelman]

I believe I have a fix for 12816 (Splitter between chat and map panes starts with map completely obscured) in 3.3.0-svn9410:

http://www.vassalengine.org/~uckelman/tmp/

If you were having a problem with the splitter between the chat pane and map being all the way at the bottom of the window when starting a game, please check 3.3.0-svn9410 and let us know whether that still happens.

[marktb1961]

I believe I have a fix for 12816 (Splitter between chat and map panes starts with map completely obscured) in 3.3.0-svn9410:

http://www.vassalengine.org/~uckelman/tmp/

If you were having a problem with the splitter between the chat pane and map being all the way at the bottom of the window when starting a game, please check 3.3.0-svn9410 and let us know whether that still happens.

Did a quick test with .vlog files from the Commands and Colors modules. Where I am used to seeing this problem more or less all the time, every file opened up with the map visible.

[uckelman]

3.3.0-svn9410 seems to have solved the divider issue for some people, but not everyone, which is aggravating.

3.3.0-svn9451-connection_test has a potential fix for Bug 12825, which sends out a keep-alive whenever there's been no traffic for two minutes.

[marktb1961]

3.3.0-svn9410 seems to have solved the divider issue for some people, but not everyone, which is aggravating.

3.3.0-svn9451-connection_test has a potential fix for Bug 12825, which sends out a keep-alive whenever there's been no traffic for two minutes.

Sorry to hear the 9410 hasn't worked for all. So far for me it is a major improvement, no blank screens in any of my pbem games. Just now, I opened a .vlog and instantly started trying to get the slider to scroll up the window and then realised the map was already displayed. This confirmed in my mind that the issue was happening all the time for me before. I look forward to kicking that habit soon.

I've installed 9451, one 3 hour online game played so far with some long pauses but without disconnects. Early days but I do experience the issue from time to time, as do my regular opponents. I also experience another one that might be related, or maybe not; a sudden pause, where my opponents actions don't appear on my screen until after a 30-90 second delay. Some of us suspect an occasional sync problem that exhibits as duplication of a game piece or cards (maybe two types of this problem), but that would be way out of scope of this issue, I guess.

[stew-rt]

So I've got a semi-working Gradle build going
https://github.com/Stew-rt/vassal

It builds 3.3.0 fairly happily for Linux.. and got a preliminary launch4j going...

still working on trying to get it to set "-Guser.dir" dynamically though...

[Flint1b]

So I've got a semi-working Gradle build going
https://github.com/Stew-rt/vassal

It builds 3.3.0 fairly happily for Linux.. and got a preliminary launch4j going...

still working on trying to get it to set "-Guser.dir" dynamically though...

Probably off-topic here but sounds good, where is the Gradle file though? I'd like to see and maybe even use it myself! I only see the fork of the master branch, and a branch with a bugfix in your repo.

I've also seen a branch where a guy tried to make a maven build, don't know how that ended but maybe it helps with the gradle setup, maven and gradle are very similar after all: https://github.com/CliffAllisterMcLane/ ... se-maven-3

[Flint1b]

Also, which bugs are still open and unassigned? I would like to fix another one, preferably one of those very difficult ones that need a lot of analysis and many hours of tracing through the code, those are my favorite.

[Cattlesquat]

I would love if 12551 (move trails) could get unlocked and taken-a-look at. Although my original writeup's theory about what was causing the behavior was not quite right, I have since added an entry supplying a fix I think would at least be minimally sufficient to the core problem.

I *ALSO* have a further fix I could supply which would allow the Trails flag for a piece to be forced to a known state (i.e. force trails on, force trails off, rather than only being able to toggle). But I realize this could be edging into borderline new feature territory.

[Flint1b]

I would love if 12551 (move trails) could get unlocked and taken-a-look at.

I don't see that one, the bug tracker says I am not authorized.

[Brent Easton]

I can't see it either

You might be interested in looking at Bug 12850 which is a good follow on from the PieceMover issue. It is specifically about GamePieces being created in At-Start stacks, but assigned to different Game Piece Layers and what happens when you start trying to move them.

This is directly related to another issue (no bug report) that you are supposed to be able to get pieces to change from one layer to another by changing the value of their layer property. This results in the same problem.

Unit in different layers are supposed to stored in separate stacks in separate PieceCollections, one for each layer. If unit does change layer, I don't think there is any need to instantly move it to it's new Stack and PieceCollection, just handle it the next time it is moved.

Regards.

[Cattlesquat]

I think 12551 is still waiting to be cleared through moderation?