marktb1961 wrote:I imagine this is some sort of issue with Apple, and in fact I already have an issue that I don't seem to be able to resolve easily (.DSstore file being in the image list).
Overall, it would be nice if the Editor allowed replacement of files (images, sounds) directly, so this external tinkering was not necessary. e.g. a tick-box on file-loading functions to force replacement of the file.
JoelCFC25 wrote:I want to make sure I'm following on this section of your post. You are getting the hidden .DSstore file included in your module's images folder when zipping up on MacOS?
The Editor already allows loading in replacement images--if the image being loaded in precisely matches the filename of the already existing image, the new will overwrite the existing. If the filename differs, the image will be loaded in and the existing image will linger on unused inside the ZIP archive. If you mean something else by replacement, can you describe what that is and what "external tinkering" it would obviate?
JoelCFC25 wrote:The Editor already allows loading in replacement images--if the image being loaded in precisely matches the filename of the already existing image, the new will overwrite the existing. If the filename differs, the image will be loaded in and the existing image will linger on unused inside the ZIP archive. If you mean something else by replacement, can you describe what that is and what "external tinkering" it would obviate?
uckelman wrote:I'd like to see an example of a module where this problem happens involving accented characters.
jrwatts wrote:This was not my experience with 3.4.5 (on Linux, Java 11.0.8 ) last week; I was replacing 5 images with new versions, and when I tried to do it with the editor, the old images stayed in place. I had to use an external archive program to replace the images.
dotnet ReadZipHeader.dll /Users/bdegroot/Downloads/CCNapoleonics3_42.vmod.zip
S111 - Ocaña_Cavalry.vsav
0x53 0x31 0x31 0x31 0x20 0x2D 0x20 0x4F 0x63 0x61 0xF1 0x61 0x5F 0x43 0x61 0x76 0x61 0x6C 0x72 0x79 0x2E 0x76 0x73 0x61 0x76
dotnet ReadZipHeader.dll /Users/bdegroot/Downloads/CCNapoleonics3_42\ re-zipped\ on\ Mac.vmod.zip
S111 - Ocaña_Cavalry.vsav
0x53 0x31 0x31 0x31 0x20 0x2D 0x20 0x4F 0x63 0x61 0x6E 0x303 0x61 0x5F 0x43 0x61 0x76 0x61 0x6C 0x72 0x79 0x2E 0x76 0x73 0x61 0x76
uckelman wrote:Also, do I remember correctly that one of you reporting this is using a Mac with a Retina display? If so, there's a second thing I'd appreciate it if you'd check in this build. I suspect that in 3.3 and previous 3.4 builds, the image you were seeing
when dragging pieces was half-size, and in this build that should be back to normal. Is it?
)
uckelman wrote:I looked into this a bit more. It turns out there is something fairly low-impact we can do to mitigate this (though it is still completely bonkers that HFS+ was designed this way). Try VASSAL-3.4.7-SNAPSHOT-bug13525-95b51620d, available here:
http://www.vassalengine.org/~uckelman/tmp/
Does that solve the problem for you?
...
(NB: When I said UTF-8 above, it should have been UTF-16, but that makes no difference otherwise.)
Return to Technical Support & Bugs
Users browsing this forum: No registered users and 7 guests