I am modifying a former module I made about Napoleon’s Leipzig Battle.
I am working with the more updated version: Vassal 3.7.18
Now I have a problem: whenever I try to reposition an At-Start Stack the Vassal freezes completely. I cannot even close it. I need to press Ctrl-Alt-Del to close the program.
I’ve searched over older topics and there is one about the same thing from 2020 but it doesn’t solve the issue. I’ve already went to the preferences at Vassal and disabled DirectX D3D pipeline - it doesn’t work either.
The graphics from the pieces and the map of my game are heavy, but my computer is only 1 year old and I doubt that this will be the problem.
My main suspicion is that the problem has something to do with the rotate traits and their order.
I have a lot of At-Start-Stacks; when I open the game the army pieces start on the map with specific facings.
Now, each piece relates to a prototype where I have the following traits (from top to bottom):
Trigger Action
Send to location
Does not stack
Place marker Hit
Place maker form square
Replace with other
Can rotate (arbitrary rotations)
Border Outline
Movement Trail
Then each piece have the following traits
Basic piece
Place Marker (Corpses)
Trigger action
Prototype (as above)
Replace with other
Can rotate (CW and CCW, 12 facings)
Global Key Command (just with text for piece identification)
The main reason that I have at the prototype the free rotation and at each piece the Can rotate trait (Cw and CCW) is that I only found this solution to orient each piece at the proper direction at the At-Start-Stack (free rotation at the prototype wouldn’t allow me to orient the piece at the start).
It used to work this way but now, as I told you, the Vassal just freezes when I try to reorient a piece in an At-Start Stack…
try to reposition a stack - i.e., place the stack somewhere else on a board?, or
when you try to modify the initial facing of pieces in the stacks - i.e., change a trait on a piece?
The circumstances are very different, so it is kinda important.
I think the best chance of someone figuring out the problem, is if you can post your module somewhere, for example at Google Drive, DropBox, OneDrive, or similar. Off-hand, I cannot tell what the problem might be.
If you do share your module somewhere, please also detail what you do to provoke the problem.
Remember that pieces are rendered (drawn) starting the closest to the BasicTrait. That probably implies that the border trait should go lower in the list than any rotate trait.
But, you have two rotate traits. Perhaps that could be a problem.
Uh!? Wouldn’t a Mark trait be a better option for this? Global Key Command is meant to for sending commands to other pieces, while it seems like you want an identifier for this piece.
Just to satisfy my curiosity, I would like you to try something. When Vassal locks up, switch your computer to a different window that has nothing to do with Vassal. Say, a browser. Your browser should be atop all other windows. Read it if you like. Now switch back to the locked Vassal window. Is it still frozen, or has that condition gone away like magic?
I have tried Shilinski’s advice,. It doesn’t work.
The program freezes when I try to reposition the stack; it moves then it freezes.
The reason that I have two rotate traits is because with the free rotate trait at the prototype I cannot reorient the pieces at the At-Start stacks; but it works if I add the rotate trait with Clockwise/ Counterclockwise option to each piece.
The reason that I use the Global Key Command just to write the information about the piece is because I want to right-click on the piece and see that information right away at the top (because it’s the bottom trait). I haven’t found any better way to do it. I don’t want the information to hang around on the map, just when I right-click the pieces. I have tried to add the marker trait, but that asks me for a property name and a Property value which, I think, is not the thing I am driving at.
I have tried to send the module to Christian via a personal message, but I don’t know if it worked. Please be so kind to inform me and, if that didn´t work out please instruct me how to use Google Drive to send it.
For any file or folder you have in Google Drive, right-click it, look in the Share menu, and choose “Copy link”. Paste that link into a message or a post. At most you would have to manage the access of the item so that anyone with the link can view/download the file.
First of all, there’s a couple of things I would recommend you to do
Open the module in the Vassal editor and select Tools→Remove unused images. That will remove all the images in your module that are not referenced anywhere in the module. That will slim the module to a little more than half its size (86MB→45MB).
Secondly, many of the charts are not readable. Consider to put them in maps so that users can zoom in.
The resolution of the background map is rather poor, while the resolution of the units is way to high. I would shrink the pieces down by at least 50% and similar for the map to match the resolution of the pieces. There’s really no reason for your graphics to be of such high resolution.
For example, the unit B9a’s image is 406×179 pixels, which could easily be scaled down by a factor of 1/4 to roughly 200×90 pixels without a lot loss of information
Your map image is 13932 × 14174 pixels - which is very big, and it seems to be an enlargement of a much smaller image, which means its very gritty. It seems the original image was 3483 × 3544 pixels - which be quite adequate.
I tried to reproduce the problem you reported above - i.e., that Vassal freeze up when you try to reposition a piece. I cannot reproduce the problem (note, I’m using Vassal on Linux). What I do see, is some lack in rendering the background when repositioning a piece. This could be what causes your problem. and that would surely be remedied if you reduce the resolution of the graphics and if you remove superfluous image files.
As for your use of Global Key Command to provide information on the pieces: Instead, I would make a Trigger Action trait - say
Trigger Action Trait
name: B69.Grodno Hussar Regiment. Russian Cavalry Corps
key: Ctrl-P
Report Trait
keys: Ctrl-P
report format: {"B69.Grodno Hussar Regiment. Russian Cavalry Corps @ "+CurrentX+","+CurrentY}
which will give you the menu entry you want to see which unit you have, and the possibility execute that menu entry to print - in the chat - the name of the unit.
Note, you can set the name of a piece to practically anything, so you could change the name of the piece B69a to B69.Grodno Hussar Regiment. Russian Cavalry Corps, and then the Report trait could have
and it could be put into a prototype so you do not need to do this in all pieces. You can even define Mark Trait that sets a “pretty name” or something like that.
1.Great tip about the Tools to remove unused images. The way I used to do it (I don’t remember where I have learned it) was to make a zip file of the module and then open it and remove manually duplicated images. This new way you taught me is far, far more simple. I learned also, when I was replacing old images, to give exactly the same name to the new ones to overwrite the old ones- it still works, right?
So the main problem about the module freezing, according to you would be its size. 3 years ago, when I have created the first version I had similar problems with the module; at that time it wasn’t when replacing At-Start stacks, it crashed in the middle of the game. I have, at that time reduced all the pieces to 30% of its original resolution and it solved the problem. But I must confess I love the pieces that I have drawn myself with that high resolution and I was hoping that, 3 years later, with a more powerful computer and new Vassal versions that wouldn´t happen. Well, I was wrong…
Would you think that the problem might be solved instead using a computer with more power on graphics?
Also a message appeared stating that I hadn’t enough memory and I should rise the heap values at Vassal, but it doesn’t gave a hint to what values I should write. I have opened the preferences at vassal and placed under the converter folder, JVM maximum heap (in MB) to 1024 and then at the tiler folder set the JVM maximum heap (in MB) to 20000. Does this values make sense? Anyway it didn´t solve the problem.
About the advices you give about not using the Global Key Command to provide information on the pieces. I haven’t tried yet your solution. But, in your example, I guess that I would need to press Ctrl-P to get the information (isn’t it?), while with my akward way of using Global Key Commands I can simply right-click on the piece. Ok, it is not the right way but would you think that that would give trouble within the module? Because I have made now about 5 different modules and always used that solution without any problems. My idea is, that it is working, and to change to your correct way would give me a lot of extra work and I would need to press Ctrl-P to get the information of each piece - or not?
Now my module was reduced, according to your precious instructions, to 49Mb, keeping the high resolution pieces and even introducing a compressed map with higher quality (25,9Mb). I think I will try to play it this way to see how it goes. Anyway the problem of repositioning At-Start Stacks only appears during the designing phase and I had already positioned most of them before
Thank you very much for all your trouble and hints.
If your new image file’s names are the same as before, then that should work.
One caveat, which I’m not sure will affect your module, is if you change the dimensions of your image. Then things like grid coordinates and settings might need adjusting. However, in your module you do not define a grid, so that shouldn’t be an issue.
If you do reduce the resolution of the images - say by a factor of 2, then you’d need to change the location of the start-up stacks. One way to do that, is to unpack the module and then open the buildFile.xml in an editor and replace the coordinates of your At-Start Stacks. In a good editor (e.g., Emacs) you can do that with regular expressions and computations.
There’s no reason why you couldn’t keep those images at high resolution separate from your module, so that you may edit them more easily. However, consider your 13932 × 14174 map. On a 1900 × 1200 screen, you would need to zoom in to show roughly 13% of the map to see the image at a 1:1 resolution. If you zoom into show 4% of the map, you will still be at a 1:4 resolution which still looks fine with PNGs. The point is, you loose very little by downscaling your graphics, and it makes your module far easier to handle - even if you have a slightly older machine.
No. Vassal, or rather Java, does not really benefit a lot from powerful graphics cards. A lot of the rendering is still done in the CPU rather than in the GPU. Secondly, since Vassal only uses 2D graphics, there’s not much benefit from a GPU 3D acceleration.
As Joel said, not very likely to help. Take him up on his offer and post the errorLog and I’m sure Joel will give you a good explanation why not.
No, in my suggestion, you would still see the name as part of the context menu (right-mouse click or Mouse-2). The major difference is that if you select that menu item, you will get a print in the chat and not some useless command sent to all pieces on the board
You could also have
Text label trait
Text: `{ShowName ? PrettyName : “”}
Dynamic property trait
Commands
text: Toggle name
key: Ctrl-P
type: Set directly
expression: {!ShowName}
Value: false
Numeric: true
Mark trait
Name: PrettyName
Value: the name of the piece
(the first 2 traits could go in a prototype, the third is piece specific).
Then, you can toggle the display of the name by selecting Toggle name from the context menu (or press Ctrl-P) and the names will persist until you toggle the display off. In that way, a user may toggle on the display of multiple pieces to get an overview or move specific pieces, and then toggle them off when they are no longer needed. It all depends on the usage patterns of your module.
Yes, because your a issuing commands that go no where. In principle, the commands will be sent to all pieces on the board, but no piece does anything in response. Potentially, that could cause a lot of overhead.
Compression of images is only a boon for storage. At run-time, the image has to be decompressed and will take up the full size in memory (bar tiling).
Another thing I noticed: It seems like you let units go from line to column by using Replace by trait, which means you double the number of pieces you need to define.
Another way to approach this would be
In the BasicTrait do not define an image for the piece
Add a LayerTrait with
Always active: true
Loop: false
Increase: Form column
Decrease: Form line
Layer images:
the line image
the column image
Layer names:
+ in line
+ in column
Now changing form line to column formation, and vice versa, is captured by changing the active layer, and all the rest of the traits need not be duplicated across pieces.
Perhaps, you should also consider to make the background of the piece images (semi)-transparent - I think that may actually look better on the map and give more of an illusion of miniatures.
Ok, I will remake the module according to your instructions.
About the column / line layers I remember, 3 years ago I tried the layers but, as the images are perpendicular, in column it showed below the image in line and vice versa, and I couldn’t discover a way of hiding the layer below, that’s why I have adopted the solution to replace the pieces instead. Or is there a solution for that?
Christian’s first step should resolve what you are talking about. The double image is caused when the Basic Trait image conflicts with the layer image(s)
Sounds great. BTW, another point: Your unit pieces should probably contain a Mat trait, and your Hit and To Square markers have a Mat Cargo trait, so that hits and square placed on the units stick with them. As it is now, if you move the unit, the hit or square marker doesn’t follow along. Note that the Mat trait automatically makes the units non-stackable, so you won’t need the Does not stack trait in the markers (another simplification).
I noticed, that the initial unit pieces have two Can Rotate traits (one from the piece itself, and one from the prototype), but once you go through a Column→Line→Column cycle, the resulting piece only has one such trait. Now, I understand that you want the Can Rotate in the individual pieces so that you may set up an initial rotation in the pieces in their At-Start Stack. You will probably need to have that Can Rotate in the individual pieces to accomplish that, but I would remove the similar trait in the prototypes.
