Can I batch-modify the paths for fill style bitmaps?
I hadn't revisited my 2mtt test style, pretty much since I posted about it back in November.
Today, however, I installed CC3+ on a new machine and decided to place the "Program Data" files in another drive (D:\
, just like Ralf does :). To verify I hadn't missed anything I opened a few maps, and I noticed my 2mtt maps had an absolute path specified (*sigh*).
I also created a template for each map type, so this error is present in quite a few files. Not only that, but since I wanted all the maps to have all the 2mtt fill styles, most maps/templates have 40+ fill styles.
Basically, I'd like to know if there's a way to batch-replace all paths that start with C:\ProgramData\Profantasy\CC3Plus\Bitmaps
, to @Bitmaps
. (I also have a few raster images placed in @Symbols
, that I use for fill styles as well).
Can this be done?
Best Answers
-
jslayton Moderator, ProFantasy Mapmaker
Start with LISTIMAGENAMESDWG to get a listing of all of the image files used in your current drawing. Then make a backup of your drawing. Then, use REPLACEIMAGENAMESDWG to do the replacement. The backup part is important because there isn't an undo for this one. Again, make sure you have a backup before doing this!
If you leave off the DWG part at the ends of the commands, they will work on a whole directory of fcw files at once. Again, make a backup before doing the replace.
Did I mention to make a backup because there isn't an undo?
-
roflo1 🖼️ 3 images Surveyor
So... I decided I wanted to create a "base test". And I came up with this.
It does use a custom fill, but it's based on an official bitmap.
Steps to reproduce:
- Execute
REPLACEIMAGENAMESDWG
- Set the first parameter to
C:\Program Files\ProFantasy\CC3\Bitmaps
- Set the second parameter to
@Bitmaps
And a few seconds later, CC3+ crashes.
Anyone here willing to try it out to confirm?
- Execute
-
jslayton Moderator, ProFantasy Mapmaker
Thanks for the reproduction case! Yes, I can confirm that it's causing a crash.
The programmer didn't properly terminate the list of fill styles for the case where the list got longer or stayed the same size (the "\CC3\" typo in your case above made this obvious much faster than it might have been otherwise). The programmer also missed an additional problem that usually masked the crash for the case where strings got shorter.
Yeah, that programmer was me.
I'm guessing that the fix for this problem will make it into the next CC3+ update.
Answers
Start with LISTIMAGENAMESDWG to get a listing of all of the image files used in your current drawing. Then make a backup of your drawing. Then, use REPLACEIMAGENAMESDWG to do the replacement. The backup part is important because there isn't an undo for this one. Again, make sure you have a backup before doing this!
If you leave off the DWG part at the ends of the commands, they will work on a whole directory of fcw files at once. Again, make a backup before doing the replace.
Did I mention to make a backup because there isn't an undo?
I need to do this as many of my older maps didn't use standard bitmap fills.
Thanks @jslayton .
I just got around to trying it out (after making a backup), but apparently the command doesn't exist/has a typo:
Luckily, I found this old post and realized it should be
REPLACEIMAGENAMESDWG
, so I gave it a go after making a backup. Sadly, CC3 tends to crash after this and ends up corrupting my map (to the point that even displaying a preview will crash CC3).Good thing you recommended making a backup. Also, making a backup was good advice. ;)
Anyway... I guess I'll try again on the other machine, since it's more poweful (and doesn't use Win8). But any additional pointers are appreciated in the meantime.
Interesting as it worked for me.
Took around 10 or so seconds.
Map still.opened, but note there were no bad paths. I have a huge number of maps with unofficial bitmap fills. I'll try one of those tomorrow.
Command has always worked for me. But there is also an alternate command, FFIX. The downside with that one is that it has to be run BEFORE you move your data directory, as it takes all valid paths and makes then into relative paths, but it don't know what to do with invalid paths, like those pointing to the old location of the data directory would be.
I fixed the initial comment in case anyone happens to stumble upon it. Early versions of the command would behave badly if the replaced name (file name with replacement) was longer than the existing name, but that hasn't been the case for an update or two. It's this bad behavior with old versions of the command that resulted in the strong caution about backups. Make sure that you're running the latest update, if you can.
I tried REPLACEIMAGENAMES and got the two prompts.
I copied and pasted C:\Program Files\ProFantasy\CC3\Bitmaps
And for the second prompt I put @bitmaps
Couldn't save,it dropped back to desktop.
FFIX doesn't fix it as these are unofficial bitmap fills.
Thanks @JimP .
That is consistent with what I experienced. Also with unofficial bitmap fills.
So... I decided I wanted to create a "base test". And I came up with this.
It does use a custom fill, but it's based on an official bitmap.
Steps to reproduce:
REPLACEIMAGENAMESDWG
C:\Program Files\ProFantasy\CC3\Bitmaps
@Bitmaps
And a few seconds later, CC3+ crashes.
Anyone here willing to try it out to confirm?
Thanks for the reproduction case! Yes, I can confirm that it's causing a crash.
The programmer didn't properly terminate the list of fill styles for the case where the list got longer or stayed the same size (the "\CC3\" typo in your case above made this obvious much faster than it might have been otherwise). The programmer also missed an additional problem that usually masked the crash for the case where strings got shorter.
Yeah, that programmer was me.
I'm guessing that the fix for this problem will make it into the next CC3+ update.
Yes, I can confirm that it's causing a crash.
Yay!
I'm glad it's not just me. ;)
the "\CC3\" typo in your case above made this obvious much faster than it might have been otherwise
That was a "happy accident". At the time it was easier to copy/paste from JimP's last post... and I told myself it didn't really matter if the path actually existed or not, as long as the string got replaced.
Anyway, thanks for following up with this.
Hi @jslayton !
I've been meaning to revisit this issue, and I did notice this in the Readme for the last update:
- Fixed crash/corruption with REPLACEIMAGENAMES command.
But theres no mention of the
REPLACEIMAGENAMESDWG
command. I still gave it a try with my previous reproduction case. Sure enough, it managed to crash CC3+.Just to be sure, I checked my CC3+ version before posting:
.. and then to be absolutely sure, I ran the update again and did the test again. But it still crashes. On the upside, the FCW isn't corrupted any more, so that's a win.
To wrap it up, I made a new folder and copied my
CrashTest.FCW
file to a new folder and executedREPLACEIMAGENAMES
on it. And while CC3+ doesn't quite crash, it does hang for many minutes (until my patience gives up and I terminate it by hand - around 15 minutes).Did the fix not make it to Update28?
A change made it into update 28, but it looks like I did it wrong. It worked for the test case I was using at the time, but failed in the general case. Pretty sure this little incident will hit me in the credibility rankings at the next software developer lodge meeting.
I don't have any kind of schedule for when this might get patched, sorry.
I don't have any kind of schedule for when this might get patched, sorry.
That's ok.
If I were in a hurry I could edit them manually. But I'm not in a hurry.