WACUP
Preview Build Discussion => Preview Build Discussion => Resolved Issues => Topic started by: Resident_Stevil on June 16, 2025, 11:45:41 PM
-
I'm trying to set my skin for WACUP to the CPro MMD3 skin, but for some reason when I do the window disappears and then the program locks up. I have to delete the skin file to reset to the default skin in order to get WACUP to work normally again. Does anybody have a fix for this?
(https://winaero.com/blog/wp-content/uploads/e107_images/winamp/221721.png)
-
Can you provide a link / copy of the skin trying to be used please.
-
I found a copy of the skin & it's getting stuck during skin loading due to patch I'd applied some time back to try to avoid some other modern skins causing crashes on loading so I'll need to refine that for the next build to keep everything else happy whilst allowing this one to load.
-
Sorry I didn't reply sooner. https://winampheritage.com/skin/cpro-mmd/221721 (https://winampheritage.com/skin/cpro-mmd/221721) That's the skin I'm referring to. I appreciate your help.
-
The cPro MMD skin loads and works fine for me with dev build 21946 (x86). It refused to load and caused issues with prior WACUP builds, so I didn't try to use it. I don't particularly care for SUI skins, so it wasn't a problem for me. Never the less, I'm glad it is no longer being blocked.
There is another modern skin called MMD3 developed by Sven Kistner that looks very similar to this skin. It has always worked with WACUP. It is easy to confuse these skins for each other.
-
At least I'd checked the same copy of the skin (once that site provided a valid download for it) so it working from my tests & aminifu's confirmation bodes well for when the next build is made available.
-
One last thing. The code in WACUP that lists skins in 3 groups; classic, modern and cPro does put cPro MMD in the cPro group. But I have another cPro skin called cPro Insomnis v1.03 by Zarko Jovic that is listed with my modern skins. I'm wondering if there is anything I can do to get it listed properly.
-
Having "cpro" or "cpro2" at the start of the filename is what I'm looking for since that seemed to be what they were all doing (dunno about ones that came from other sites / hosting vs skinconsortium) whereas any pre-extracted ones don't matter since the handling is looking for a ClassicPro.xml file within the skin folder.
-
The file was named "cPro - Insomnis.wal". I deleted the spaces in the filename and in the studio.xnf values. The skin is still listed with the modern skins. Maybe the code doesn't like the hyphen. The other skin is named "cPro_MMD.wal".
-
The check looks at the immediate start of the filename so the hyphen isn't something that'd be looked at. Renaming the copy of the skin to what you've quoted works for me unless there's maybe a space at the front of it that's not obvious which would be able to break it. Otherwise I don't see why it wouldn't be working.
[edit]
I've made a change for the next build which will try to ignore spaces at the start of the string as that's the only thing I can think might be doing it though the check is never going to be 100% if someone messes with the name vs the contents inside as that's generally not viable to re-inspect the skin archive contents to figure it out all of the time vs the OS not liking slow to display menus.
-
Having "cpro" or "cpro2" at the start of the filename is what I'm looking for since that seemed to be what they were all doing (dunno about ones that came from other sites / hosting vs skinconsortium) whereas any pre-extracted ones don't matter since the handling is looking for a ClassicPro.xml file within the skin folder.
The filename doesn't start with a space. So you don't need to add anything to look for one. But I guess it won't hurt. I tried replacing the hyphen with an underscore and nothing changed.
I re-read the reply quoted above and even though the skin isn't pre-extracted, I decided to look for a ClassicPro.xml file in the skin's archive file. The cPro_MMD.wal had one and the cPro_Insomnis.wal didn't. I copied the file to the cPro_Insomnis.wal file and now it is listed in the cPro group.
-
I copied the file to the cPro_Insomnis.wal file and now it is listed in the cPro group.
I don't think that file is used by all of the cpro skins & neither of the insomnis skins I got from winaero site had that file in them & I'd strongly suspect you've got the 'ignore the information' option on the skin -> manager settings prefs page as that's the only way I can replicate a bunch of the cpro skins not appearing under there as that will ignore aspects of the filename in the checking being attempted.
With that option enabled I'll need to do some additional checking of the skin.xml to figure out if it's cpro related or not.
Am also now aware that the prefs option mentioned isn't fitting on the same line & is wrapping making it look odd which'll be fixed.
-
Yes, you are correct. The ClassicPro.xml file supports a feature (custom beat vis) that the cPro_Insomnis skin does not have. So I when back to the original archive file.
The real reason the skin wasn't listed in the cPro group was that option in the skin - manager settings preferences.
-
The new beta that just went up should resolve problems with that option being enabled. The fix is based on looking at the skin.xml which also caught one cpro skin for me that didn't have the cpro prefix along with showing that the Skins page list wasn't working correctly with it also enabled. With the option off then it's just going to be looking at the file / folder name & files it can see if not already extracted.
-
In beta build #21962 (x86), the listing of cPro skins (in the main context menu sub-menu) is now working as expected whether that skin - manager settings preferences option is enabled or not. I had enabled that option because I wanted to use it's sub-option to not show empty/invalid skins. Thank you for the fix.
-
The new beta that just went up should resolve problems with that option being enabled. The fix is based on looking at the skin.xml which also caught one cpro skin for me that didn't have the cpro prefix along with showing that the Skins page list wasn't working correctly with it also enabled. With the option off then it's just going to be looking at the file / folder name & files it can see if not already extracted.
So this fix will come with the next public release? I don't have access to beta versions.
-
The loading failure & skin type detection fixes will be in the next preview build once other beta build issues have been resolved (no eta other than when it's done).
-
Still not 100% perfect but at least it's not freezing anymore.(http://)
-
What's wrong with it? If you want the tab labels to be spelled all the way out, make the skin a little wider. Point to the bottom right corner and when the mouse pointer turns into a double headed arrow, click and drag to the right.
I suggest you turn on a custom beat vis. Right-click on the Cpro label at the top, select the show beat vis command at top of the dialog that opens and select one of the beat vis listed. I like the dancing queens.
-
It'll be the 2 elements that are bright pink as part of the player control section. I can't get my 5.666 install to complete loading with the skin but for the brief time where I'm seeing the main window it doesn't seem to have those elements messing up so most likely there's something going on with the images involved that aren't handled the same as what 5.666 was doing (i.e. due to almost a decade of libpng related changes since then based on some problems that have been seen when trying to use modern skins in wacup).
-
It'll be the 2 elements that are bright pink as part of the player control section. ...
Oh that. They won't be as bright when choosing a different color theme. One of our Skinner members can probably provide a better solution.
-
Its something that's wrong my handling to try to fudge gen_ff to work outside of winamp due to there not being a 'color' value specified in the skin for the "$solid" part used to generate the background of those led elements. Afaict that's meant to be treated as color="0,0,0" & adding that into the appropriate line in the groups.xml file in the skin seems to fix it (the pink seems like it might be an error colour to help identify possible problems but gen_ff seemed to gracefully handle this). There'll be change in the next build which should do all of that without having to edit the skin which isn't imho the right fix even it's the quick way to do it.
-
Hi dro,
IMO, it is mighty big of you to have your code turn those leds on/off for that 1 skin, since it is popular. Thank you!
-
It's not a skin specific fix & is a flaw with my handling around getting gen_ff to work outside of winamp. I'd seen it from the first test once I got the skin loading but didn't know if that was correct or not since I'm not going to mess around with trying to get the 5.666 test install loading cpro skins (I want to uninstall it but keeping it for the odd bit of comparison testing still makes sense for now) but thankfully it was simpler to fix purely due to seeing what the related element in the skin related to which is often not the case with other skin rendering issues.
-
It'll be the 2 elements that are bright pink as part of the player control section. ...
That is fixed in build #22186 (x86). Thank you dro.