Ah, great, good catch.
Would it be possible to add a warning to the parser?
- 29 January 2023, 05:39
- Welcome, Guest
News:
The new forum is online, hope you enjoy it!
|
11
on: 17 December 2022, 08:12
|
||
| Started by newuzer - Last post by newuzer | ||
|
12
on: 16 December 2022, 09:31
|
||
| Started by newuzer - Last post by Roman | ||
|
Ok, I had a closer look.
If you have a datfile with "bla\ blabla", the space gets already trimmed when the datfile is loaded/parsed. |
||
|
13
on: 15 December 2022, 14:35
|
||
| Started by newuzer - Last post by newuzer | ||
|
Everything default, no 7z involved, just zip.
Yes, the OS kills the leading space. |
||
|
14
on: 15 December 2022, 13:54
|
||
| Started by newuzer - Last post by Roman | ||
|
Well, most likely the archive operation (where maybe a file unpack to disk is involved) kills the space since I assume that 7z / zip unpack will create the file on disk without the leading space....and then the file is repacked to the destination. Maybe even the OS itself kills the space, too.
So...what are your rebuilder settings, if 7z is involved, the files will definetly be unpacked first and recompressed via 7z.exe from your disk.... |
||
|
15
on: 15 December 2022, 13:20
|
||
| Started by newuzer - Last post by newuzer | ||
|
The ROM entries in the generated (not with CMP but with SabreTools) datfiles are 1-on-1 copies of the original raw XML file entries.
Hence the reference to the commit that fixes the original XML, which contained the leading space in the first place. After rebuilding with CMP, the filename in the zipfile does not have the leading space. Apparently with RomVault it does. So somewhere in the process, the leading space is lost. |
||
|
16
on: 15 December 2022, 10:36
|
||
| Started by newuzer - Last post by Roman | ||
|
Erm..no, cmpro does not change anything!
If the dat holds the "\ ", then it's taken over. So again: how was the dat being generated? If you've exported it with cmpro, then the original dat (before merge) holds the " " or you have a space in your naming patter (profiler settings: %f\%1 -> %f\ %1) |
||
|
17
on: 15 December 2022, 10:27
|
||
| Started by newuzer - Last post by newuzer | ||
|
No, it's something clrmamepro changes from source to end result, so the warning should be there IMO.
The generated entry (filename) is the same as the RAW source XML. |
||
|
18
on: 15 December 2022, 10:20
|
||
| Started by newuzer - Last post by Roman | ||
|
But wouldn't it then be a job for the generator to trim?
|
||
|
19
on: 15 December 2022, 10:07
|
||
| Started by newuzer - Last post by newuzer | ||
|
It was an entry from a generated merged XML, not the raw XML
 |
||
|
20
on: 15 December 2022, 09:33
|
||
| Started by newuzer - Last post by Roman | ||
|
Erm...since when does MAME use subfolders in its xmls?
Anyhow, cmpro does support them but for cmpro the rom name is the full (relative) path, including "dogfights\"...so a space in the middle somewhere is not checked at all since normally it's valid. I think I do trim the complete entry though (left/right)...but definetly not checking anything inside. I take a note, but don't expect anything anytime soon. |
||