Yea, I fixed the problem, was in the wrong folder.
The adequate folder is essential, as noted in the txt file (relevant for both, Linux and Windows). The pm2ubcd script uses similar concepts or conditions that are already in use in other scripts included in UBCD (not necessarily with the same type of code).
I'm glad you solved that issue.
It boots just fine after merge, cleanup, then running the ubcd2iso to compile the iso. Only thing I noticed was that the Pmagic Version number menu item in UBCD didn't match the Parted Magic version that was detected with your script. Would be awesome if that was fixed
Also mentioned in the txt file
The version of PMagic included in the official releases of PMagic is included by Victor (manually, I would guess). If a user manually updates any tool in UBCD, the version needs to be manually corrected too, and this is also valid for PMagic.
In the particular case of PMagic in UBCD, the version number that is displayed in the initial boot menu comes from "main.cfg" (for the default Syslinux menu). As mentioned in the pm2ubcd.txt file, only the relevant files inside "/pmagic/" are touched, which leaves out "main.cfg".
There is a reason for this limitation: customizations. If the script would edit main.cfg with the new version of PMagic, the only way to be sure about the result would be to apply the script to the original official UBCD. So for each time you would want to use pm2ubcd, you would need to start over, from scratch.
If a user has additional customizations, specially if they are part of "main.cfg", how the script would correctly identify what exactly to change and what exactly *not* to modify? The reason pm2ubcd can do what it does is because the basic structure and the expected patterns of both, PMagic and UBCD, are known. The script can handle many variations of PMagic, and it won't touch any personalized file nor any PMagic's module (such as those included in UBCD, for example). But, for that logic to work as expected (and remember, we have no control about future versions of PMagic, and yet, the script will mostly keep handling it OK), we avoid touching anything else that the user might (or might not) have customized.
Giving that the correct version number is included in the boot menu of PMagic itself (just select PMagic from UBCD and the default menu entry shows the version number in the lower part of the screen), my suggestion would be to avoid specifying any version number of PMagic in "main.cfg". Of course, this is up to Victor.
The current possibility, for the final user that executes pm2ubcd, is to either "leave it as is" (since PMagic will work correctly anyway and the actual version is mentioned in its own menu), or to edit main.cfg manually (which is exactly the same as with any other customized tool or manual update in UBCD).
Curious, why not just have one script connect to the other script? So after merge, have option to choose one of the other commandline/shell scripts to, for instance, run ubcd2iso with the parameters that were added?
The goal of the pm2ubcd script is just to make it easier for users, since PMagic is generally updated more frequently than UBCD (even Victor could use it as part of the building procedures of future releases of UBCD, if he wants). It is not meant to be an "all-in-one" solution (for example, it doesn't include a "directory=" boot parameter), and it is certainly not a replacement for "laziness"
(to be absolutely clear, I'm not implying anything about anyone; I'm just stating that those two situations are not included in the objectives of pm2ubcd).
It is not so simple to always find an adequate balance between needed features, usefulness, ease of use, and flexibility.
For customizations, I would suggest using the scripts (probably to be executed in this order): pm2ubcd, antivirus updates, syslinux2grub4dos, ubcd2iso, ubcd2usb; each with the adequate parameters (sometimes the same value needs to be used in more than one script).