Game Piece sizing option

Basically want to resize the BasicPiece according to HexGrid size. How do I get the current instance of the HexGrid from Board? How to get instance of Board? Some basic debugging lead me to OpCache. How do I get an instance of that?

Thinking to put an checkbox option in preferences “Fit game piece to grid”.

Still learning the architecture.

What’s the reason for not sizing the piece images correctly? That would let you avoid all of this.

You can get a MapGrid from Board.getGrid(). There’s no guarantee that the MapGrid you get is a HexGrid. It could also be a RegionGrid, SquareGrid, or ZonedGrid. How you get a Board depends on where you’re doing it from. You should never get an instance of OpCache. If you need to scale an ImageOp, you do that via Op.scale().

1 Like

User wants a very large map to play, we are using open source terrain data with topography that can’t be scaled, or difficult to scale to a larger resolution.

There are small maps and large maps, and many piece images. Thought this would be easier.

How do I get a Board? Or does that statically work.

There will be a straightforward way to rescale image assets in V4.

For V3, it will be less work to scale them to the desired size outside of Vassal first. While you could do that with custom Java code, it’s going to be a nontrivial amount of work.

That depends on where you are and what you have when you’re trying to get the Board. Where will that be?

Oh thought i’d kick it off from an boolean in Preferences, the preferences class doesn’t seem to map to File → Preferences - Post Module and extensions loaded, lets say. After the map is chosen and board is drawn.

There’s no Preferences class in Vassal 3.6.5 that I know of. If you want to add a checkbox preference, you’d use VASSAL.preferences.BooleanPreference for that.

Boolean Preference has no constructor - how do it get it? oh getPreferenceConfigurer seems like the place to start

Oh, never mind. I always forget that the *Preferences classes under VASASL.preferences aren’t for this—they’re for adding global options in the editor.

What you want is BooleanConfigurer. Look in the code for one of the places that’s used.

Nonetheless, I suggest resizing the images instead.

If you want to resize all pieces uniformly, you could possibly do that by subclassing Map and overriding drawPieces(); that’s going to be inflexible and extremely fiddly to get right. Alternatively, you’d need to have a piece trait specifically for resizing a piece, and you’d have to ensure that is the outermost trait on every piece you want to resize this way. That’s going to be a lot of work and also affect how you construct your pieces.

Thanks, I tried changing the scale in a redraw in Map, which worked, However I have to only redraw this specific scale for specific maps, (small pieces for the large map, and regular piece images for the other maps) so hardcoding the map names seems like a hack, but easiest temporary solution. Also, there are two “pieces” that seems to be drawn the piece after placement, and the “piece” that can be selected. After successful redraw with a different scale, the final result was great on the board, however, the box to select the piece for movement and right clicking was still the large original size.

If you’re subclassing Map, it shouldn’t be necessary to hardcode any map names. What you should be doing instead is using your subclass only for the maps which require it, and using Map for the ones which don’t. (That is, in the Editor, add the maps needing the subclass using that subclass. Don’t select the normal Map for those.)

If you’re drawing the pieces at a different scale, you also need to adjust the size of the selection outline. The selection outline is unlikely to be the only other thing which depends on pieces being drawn at the same scale as the map. You’re likely to find several more such problems.

If you’re subclassing Map , it shouldn’t be necessary to hardcode any map names. What you should be doing instead is using your subclass only for the maps which require it, and using Map for the ones which don’t. (This is, in the Editor, add the maps needing the subclass using that subclass . Don’t select the normal Map for those.)

Wow alright, the power of subclass. I will go about subclassing. Will give it a shot, thank you!

Status Update - VASSAL.tools.DataArchive cannot find class.

This is right click from Editor on the specific map, Add Imported class, perhaps need to add the new class to a file.

New class is VASSAL.build.module.MapResizePiece

You need to copy the class file(s) into the module first, so that the Editor can find them. That’s a thing you have to do manually, using something that can read and write ZIP archives.

You should not put custom classes in our namespace. That causes problems which are difficult to troubleshoot. (Consider what would happen to your module if we later introduced a class called VASSAL.build.module.MapResizePiece.) Put your subclass outside of VASSAL.*, in a namespace you define.

Sure, I’ll make an ext path outside of VASSAL. Seems gotta run make from vassal-master, my setup is standalone. My machine is off the network, make is looking for maven. Just gonna connect it.

I recommend using the module template:

There’s no need to build Vassal itself, only the custom code you’re writing.

2 Likes

So what I should do is get the module code and add the new code to that.

Yes, you’d put the custom code you’re writing in the module template. It’s already set up to build (using mvnw) against Vassal 3.6.5.

If you look under src/main/java, you’ll see an example class, which you can delete, but it indicates where you own code should go.

1 Like