ROM Collection Browser on Kodi 20 Nexus + Launch External Emulator

 

First a little back story:  After a failed Ubuntu update I ended up reworking my HTPC built from junk/cast-off parts.  I think I'm done with Ubuntu though, which is a rant for another day.  I ended up installing Linux Mint on this box again.  I don't know why I even bother trying other distros anymore, I always circle back to Mint.  Though in this case not the current version of Mint, I had to step back a bit because of the ancient Nvidia graphics card in this computer.  The proprietary drivers aren't available on the current version, and I know from messing around with Ubuntu 22.04 that the open-source "Nouveau" drivers aren't stable enough, and you have to extract binaries from the proprietary drivers to get hardware video encoding/decoding to work, except (in my experience) it just froze or crashed the entire computer as soon as I started playing a video.  Which rendered my HTPC useless.  So, anyway, I ended up going with Linux Mint 20.

Unlike under Ubuntu 20.04 I was able to actually install Kodi 20 Nexus.  Okay, so I was able to install it, but it would crash immediately on opening. So I was stuck on Kodi 19 Matrix but couldn't use Retroplayer because of an unmet and uninstallable dependency.  So I ended up having to point Kodi to open every game ROM in external emulators.  Which thankfully isn't that hard with IAGL or Advanced Emulator Launcher.

But on my new Linux Mint 20 installation I've run into various issues.  First of all many of the Libretro cores for Retroplayer are still unavailable because they fail to build.  Secondly, Advanced Emulator Launcher hasn't been updated for Kodi 20 Nexus so I had to try the development version, with which I ran into other problems. So I tried the Advanced Kodi Launcher forked from it, which is under more active development. But ran into issues with that as well (namely that some browse dialogs weren't working for me). I also didn't like how AKL clutters up my "Games" section with all it's add-on modules. I mean, I get why it's modular, but it's a shame there's no way to hide all of its modules from showing up in the Games Add-ons list, and with the same icon as AKL itself.

Honestly, what I *wanted* to use was Emulation Station Desktop Edition for a retro gaming library, but I can't get it to run on my Linux Mint 20 system.  It crashes on open because it can't find OpenGL.  I don't know if that's because it requires Wayland instead of X or something?  I didn't look into it.  But I can't use Wayland on this system because of the old Nvidia graphics card.  I tried the regular Emulation Station as well and hit the same problem.  I didn't bother trying to build it from source myself, I decided to just focus on using Kodi for my retro gaming library UI.

ROM COLLECTION BROWSER for KODI NEXUS

Which led me to try the "ROM Collection Browser" (RCB) which I've never used before. It's the closest out of the box to Emulation Station, and unlike AKL which requires you to switch your entire Kodi skin to get the cool UI options, RCB lets you access the cool UI layouts without switching your Kodi skin at all.  

However, RCB also has not been updated yet for Kodi 20 Nexus, but someone did fork it for that purpose.  You can find it here:

https://github.com/Trihy/romcollectionbrowser

I needed to download the Master not one of the releases because only the Master branch had been updated to look for Python 3.  You also need to install the RCB Service add-on for Matrix or it won't work. I get a moment of graphics glitches whenever I first open it, but it doesn't affect using it.

Keep in mind that RCB is intended to be navigated with a game controller not a mouse.  It is virtually unusable with a mouse.  D-Pad Up will get you the left-hand menu, D-Pad Down will get the right-hand menu.

However, and this isn't anything wrong with RCB, but too many of the Retroplayer cores are missing or broken to run some ROMs in Retroplayer at all.  

BROKEN/MISSING RETROPLAYER CORES

If you go look at the Team XBMC PPA you'll see that many of the Libretro cores fail to build on various Ubuntu versions and so are not available to install via APT.  You could try to build them yourself from source, but they may just fail for you too.

For example, on my HTPC system there are dozens of Retroplayer cores that are not installable via APT. I can download the package and try to install them manually, but they usually have some unmet dependency I can't satisfy either.

"Zach Morris" who makes the excellent Internet Archive Game Library (IAGL) plugin also maintains a Libretro Buildbox that generates Retroplayer cores.  However as THIS PAGE shows, not all of them work as intended, and I can tell you from personal experience that even some with the status "Works" my not necessarily work for you.

POINTING RCB TO EXTERNAL EMULATORS

For any Retroplayer cores you can't get to work you'll need to launch those games in an external emulator.  But I had difficulty finding instructions on exactly how to DO that in RCB.  So I'm documenting it here, if only for my future self who will likely have forgotten how to do it.

First you need to get to the left-hand menu and select "Edit Collections"

That pops up the dialog box. On that you need to go down the buttons on the left to "Launchers" 

 

 
...and at the top select the specific Collection you need to set a launcher for.

 

At the bottom you need to turn OFF the switch for "Use Retroplayer" because, well, we're not using Retroplayer. That will enable all the dimmed out option in the middle.

I'm going to assume you have a working installation of Retroarch on the same system, but this method should work with any external emulator so long as you get the path and parameters right.

Select "Emulator Cmd" which won't let you just type it in, it makes you browse for the binary to execute:

 

 

 

Note that the path to the binary will be different if you're using a Snap or Flatpack version of Retroarch and obviously will be different if you're pointing to a different emulator.  Now we need to send the right "Emulator Params" to actually launch the game:

 

In my case these was the magic parameters to enter:

-L /home/htpc/.config/retroarch/cores/bluemsx_libretro.so "%rom%"

Obviously you'd need to make sure the username is yours. I'm using "htpc" because that's what this box is for.  For each game platform you need to launch externally in Retroarch you'd need to change the core *.so file it is invoking.  So, for example, an NES game to use the Mesen emulator core would be:

-L /home/htpc/.config/retroarch/cores/mesen-s_libretro.so "%rom%" 

I think you get the idea.

Side note: I couldn't get the Retroplayer BlueMSX core to work even with the extracted "Machines" and "Databases" placed in:

~/.kodi/userdata/addon_data/game.libretro.bluemsx_libretro_buildbot/resources/system/

But they work fine inside ~/.config/retroarch/system/

Which is why I'm launching those games in Retroarch instead of Retroplayer.

(If you don't know what extracted files I'm talking about see the BlueMSX core instructions here: https://docs.libretro.com/library/bluemsx/).

YMMV.

Fixing An Ancient Racing Wheel Controller

 I recently built up another Home Theater PC with some retro-gaming apps on it.  One of the games I wanted to play was an old one I think is one of the best racing games of all time called "Breakneck 2" originally from 1998 (I wrote about it on this blog about a decade ago, it's from Germany and was originally released as "N.I.C.E.2 Excessive Speed" in Europe).  This game is the only reason I even own a racing wheel game controller.

Notice the "Windows 98" compatibility!

 

But the wheel is 24 years old and over the years it has been stored in basements and attics and garages, not to mention the actual use (abuse?). So I'm not surprised it broke inside almost immediately after I started using it this time.

The shattered plastic "yoke" from inside wheel

But the part that broke is a textbook case for using a 3D printer: to reproduce a plastic part that is unavailable.  And I happen to have a 3D printer.

Granted the 3D printer is not a good one.  It's garbage.  LITERALLY.  It was intercepted on its way to a dumpster.  It's a "Tiko" delta printer that was part of a Kickstarter campaign.  On the plus side, unlike a lot of crowdfunded tech projects, they actually DID deliver some units.  But they bankrupted themselves in the process and went out of business.

The biggest issue with this printer is that the built-in "slicer" software is terrible.  But if you use some other program to slice your models and feed the printer raw "gcode" files it works a LOT better!  But you are still limited by the actual capabilities of the printer, and if you need precision parts that will fit together?  Not gonna happen.  Not without doing some filing and shaping, and even then the still may not fit together.

Anyway, the tldr; is after a number of false starts and failures I FINALLY got a 3D printed replacement part to work and got the wheel working again.  Below is my frustrating journey to once again drive some windy old virtual roads at insane speeds.

Plan A: Fix The Original Part

 

original part glued back together

My first thought was just to try and fix the broken part.  Using some superglue I was able to reassemble it.  But this is a part that has a lot of torsional pressure and other forces acting on it.  I thought it would probably just break into pieces again, so at this point I took as accurate measurements off of it as I could.  I thought maybe if I just clad it with some 3D printed pieces to strengthen it then it might work.  So I made a model in SketchUp 2017, exported it as an STL file, generated a gcode file, and printed it:

Printing the part

In case you're wondering, this printer doesn't have a heated bed.  After many frustrating attempt to print things I discovered that putting a piece of printer paper over the bed was the perfect thing for PLA plastic adhesion.  My models no longer break away from the bed and get dragged around by the print head.  You have to tear the part off the paper, but you can simply use water to get all the paper off.

So I made flat pieces for both sides of the Yoke and superglued them to it, then filled in the gaps with expanding Gorilla Glue.  There are rollers that are supposed to go on those pegs.  The rollers ride against a piece of bungee cord to create resistance (this is not a force-feedback wheel). The rollers were only held on by a tiny peg, one of which was broken and even if could find the piece it would never hold.  So I drilled out the pegs and held the rollers with screws and washers:

I have no idea if this glued-together part would've worked because I could NOT get it reinstalled.  The steering shaft is knurled and you could see the imprint of the knurling inside the "tower" on the Yoke, but I couldn't actually get the part to go back down over the shaft.  I suspect it may have been pressed into place at the factory or heated and pushed on, gripping itself as it cooled and contracted.  I couldn't hammer it down onto the shaft because I was sure THAT would just break it into a million pieces again.

 

Okay, so on to Plan B!

Plan B: 3D Print A Replacement Part

My first thought was, since the original piece is very dense, heavy plastic, and has a lot of forces acting on it, I should try and print my replacement part with 100% density too.  Which would take forever, but it would be literally solid plastic.  But I had to quickly abandon that plan because at that density the little Tiko printer starts experiencing pronounced layer shifting:

That meant I had to rework my model a bit to create some interior structure so I could hopefully stop the layers shifting on me.

But there was still some layer shifting, especially when it got to printing the "tower" that goes around the knurled shaft.  Also, because of the limitations of the printer's precision (or severe lack of it) I could NOT get the inside diameter of that tower correct.  I ended up printing a whole bunch of revisions:

 And STILL couldn't get it right.  The inside diameter of the tower not only has to fit over the knurled shaft the outside diameter has to fit inside the "resistance arch" with the bungee cord.  So on that last one on the right I tried to slowly, and carefully hone out the interior large enough to install it.  Which resulted in it eventually breaking off entirely:

DOH!

 

This project went through MANY revisions on the fly:

The many revisions of the Yoke

 

These were all done in SketchUp 2017 which is the only 3D modeling software I really know how to use.  I've tried to build things in Blender, Cheetah3D, and FreeCad with great difficulty.  At least with SketchUp I know I can slam together something really fast.

So in that last revision I decided to approach this a different way.  Since I absolutely could NOT get that inside diameter right I figured I'd design a multi-part model that could CLAMP around the knurled shaft.  That led to this:

The "tower" is printed separately and superglued to the base parts.

With some screws I found in the kitchen junk drawer. 
No idea what they're from, but they went through the holes and were long enough.

Okay, so another problem you run into with 3D printing (and not just with my literally garbage printer) is prints that curl up on the ends as the part cools.  It's more of a problem with ABS plastic than PLA but can happen with either, especially on a printer without a heated bed.

So, to get the parts to match up and be flat I had to heat up a cup of water in the microwave.  For PLA you need it about 150 degrees.  Dip the part in the hot water for a few seconds until it just become pliable enough to reshape it.  If you leave it in too long or the water is too hot, though, you're part will become TOO pliable and will also shrink.  See how the top piece in that photo is a little narrower than the bottom piece?  It shrank a bit.  See that little dip in the top edge next to the longer screw?  My thumb made that.

Reassembly

Now that I had a part that would actually FIT the time came to put everything back together.

When I was trying to get the other attempted Yokes on I had to cut the wires to the buttons in the middle of the steering wheel.  Ironically with the two-piece clamp Yoke I wouldn't have needed to do that.  But what's done is done.  You may have noticed in that disassembled photo up above that there's a part labeled "Weird Dummy Board."  The wires from the steering wheel buttons went to this board that doesn't seem to DO anything:

The wires just connect to one side and there are circuit traces that just go straight across to wires of the same colors.  Why?  Perhaps there was some other model of this wheel with a different board there for some other features this one doesn't have?  No idea.
 

The stupid "Dummy Board"

 

The advantage of getting rid of this useless board was the wires I'd snipped were long enough to reach the ultimate board connector without my needing to solder pigtails onto them.  So, goodbye Dummy Board!

Once I clamped the Yoke on the knurled shaft I had to reinstall the resistance arch over it.  That was secured with four weak little screws from the front panel.  I drilled everything out a little larger and put in some beefier bolts.  Found these Allen-head ones in a box of junk that dressed it up nicely.

Resistance Arch and Clamp Yoke installed

The Clamp Yoke's bolts sticking out aren't a problem, and give enough extra for some lock-nuts.

Next up is reinstalling the gear-driven potentiometer that actually tracks the position of the wheel.  The trick with this is to make sure the wheel is in the center position and the potentiometer is in the middle position and drop everything into place and screw it down.  If you get this wrong your steering wheel will be off-center when you're driving straight.

With everything back in place it's time to reconnect those steering wheel button wires to the connector (sans the "Dummy Board"):

 

Wires bundled and everything is reconnected to the main circuit board!

I did ultimately have to partially disassemble this again because on my first test with it the steering shaft knurling just ground out the inside of the Clamp Yoke tower.  PLA plastic is pretty soft and the forces acting on it just turned the knurling into a file.  My solution to that problem was to permanently GLUE the clamp onto the shaft with two-part epoxy.  It means I will NEVER be able to get this apart again, but once the epoxy resin hardened that clamp isn't going anywhere.

Another issue was that, after 24 years, all the grease had basically gone away.  The only grease I had on hand was some plumber's faucet grease.  I put that on the outside of the tower and on the steering gears.  The only downside to that is the wheel works VERY easily and smoothly.  Though, I'm not sure if maybe that's what it was like when it was new?  I can't remember.  Maybe I just got used to the way it felt without any grease left in it.  Of course, that probably played a role in why the original yoke broke.

Anyway, everything fixed in place again and reassembled it was time to CALIBRATE it!

Calibrating it on Linux with QJoyPad utility

And last, but not least, taking it for a test run around the Breakneck 2 Corsica track:

If, by chance, you have one of these old Thrustmaster racing wheels that has also broken the Yoke here are the STL files of my final revision:

Thrustmaster_Yoke_Rev9.zip

Of course I make no guarantees for how long it will last.  So far mine hasn't broken again, but I've also been careful not to crank on it too hard.

XP-PEN Display Tablet Express Keys "fix" for M1 Mac

UPDATE 7 FEBRUARY 2023
A macOS update apparently made the version 2.0 drivers stop working.  I also ran into an issue where, because I'm using custom display profile overrides the tablet settings app cannot find the names of my displays nor could it tell there were two of them (it sees both displays as one ultrawide).  After some playing around with both newer and older drivers I am now recommending you use the version 2.1.6 driver.  It does have a bug that causes it to sometimes lose all your custom settings (like hotkey assignments), which you can mitigate by locking the actual settings file so it's "read only."  (You can find it at ~/Library/Preferences/com.ugee.pentabletsetting.plist and lock it by right+clicking and select "Get Info" then in that dialog tick the "Lock" box)  But don't do that until after you've finished getting everything set up the way you like.  Also, some apps simply won't accept your custom settings from this driver.  For example, even with the default button assignments on my tablet where K1 = increase brush size, K2 = decrease brush size, CSP sees the first one correctly - but inconsistently - and the second one as "eye dropper."  Even if I assign those to "]" and "[" it shows at the bottom of the display that the tablet IS using the configured keyboard character, but CSP ignores it.  In Affinity Photo, though, it all works as intended.  So this comes with a heavy dose of YMMV.  You can still try the version 2.0 drivers and see if they work for you, but otherwise:

DOWNLOAD THE XP-PEN 2.1.6 DRIVERS FOR macOS

The 2.1.6 drivers *should* automatically create entries for the macOS Privacy settings as shown below in the original post, but you'll want to make sure they are checked, and your tablet will not work until you restart your Mac.  On restart you'll likely see a bunch of privacy/security pop-ups and you need to authorize all of them.

------------ original post follows --------------

Both I and one of my friends own the same model XP-PEN Artist 15.6 display tablet and M1 Macs.  It's a nice tablet for the money but the support for Mac users is terrible, especially since the M1 "Apple Silicon" chip was introduced.  The tablet itself is actually made by Ugee and I think XP-PEN is just one of many "brands" the same tablets are sold under (their websites have the same layout, the driver files are the same versions, the interface for their preferences app is the same, they just swap out some images).

So, anyway, the "New UI" version 3.x drivers are garbage.  They absolutely do NOT work.  Version 3.0.5 would at least detect the tablet if you unplugged it and plugged it back in, though you couldn't configure the pen or the Express Keys as none of the sections would appear in the left-hand column of the preferences app.  The versions after that won't detect the tablet at all. 

I'm using the USB-C to USB-A + HDMI cable that came with my tablet because I'm mirroring my primary display to the tablet through an HDMI splitter.  I haven't tried connecting my display tablet with a USB-C cable, but from what I've read on their forums and Reddit, it doesn't sound like that would make any difference.

The (as of this writing) current 2.1.8.2 drivers are listed as the "Official" ones on XP-PEN's website, and if you have an M1 Mac they will get you up and running, but you won't be able to assign your Express Keys.  There's a bug in those drivers that won't let you reassign them properly and I doubt they'll ever fix it because they've moved on to developing their worthless 3.x drivers.

The Express Keys bug was also present in 2.1.7 version of the drivers and a different bug was present in the 2.1.6 drivers.  The 2.1.6 will let you reassign the functions of the keys, but they were inconsistent in actually working.  When yo press one it displays a message across the bottom of the screen confirming not only that the button was pushed by tells you in bright green lettering what it's supposed to do.  Except on a M1 Mac it wouldn't always actually do it (the drivers seem to work fine on my Intel Mac).

XP-PEN frustratingly does not provide an archive of older versions of their drivers.  And, no, you can't get them through the Internet Archive Wayback Machine either.  Thankfully between three computers I had installers for several different older versions.

After installing and testing and uninstalling ALL of them on my M1 Mac I finally found ONE that actually works the way it's supposed to!

The Version 2.0 drivers that ACTUALLY WORK are, ironically, the oldest ones I have.  The ones I downloaded when I bought my tablet.

You can get them from my Google Drive but installing them in Big Sur is not exactly straight forward.

1. UNINSTALL your current XP-PEN drivers!  Use the "Uninstall" app in the same folder as the Settings app.

2. RESTART your computer to make sure it's gone.

3. Download the installer ZIP from that link in the line above.

4. Unzip it and inside there should be one file: XP-Pen Mac(20180425).pkg 

5. Right+Click on that file so the context menu shows up.

6. Press the OPTION key on your keyboard and then select "Open" from the context menu.

7. The macOS Gatekeeper will warn you about opening it, go ahead and do it anyway.

8. Run the installer and wait for it to finish.

9. It will finish saying "Installation Failed!" but it's a liar, the installation worked just fine. Close the installer.

10. Go to Applications --> PenTablet --> PenTabletSetting.app and open it.

11.  Authorize the app in any macOS security and privacy pop-ups you see.

12. Open System Preferences and go to Security & Privacy

13. Click the padlock icon in the lower left and  enter your login password to unlock it.

14. Scroll the left column down to "Accessibility"

15. Click the [+] button under the list on the right and navigate to:
Applications --> PenTablet --> PenTabletSetting.app

16. Click the [+] button again and this time navigate to:
Macintosh HD --> Library --> Application Support --> PenTablet --> PenTabletDriver.app

17. Now scroll the list on the left to "Input Monitoring" (and we're going to do the same...)

18. Click the [+] button under the list on the right and navigate to:
Applications --> PenTablet --> PenTabletSetting.app

19. Click the [+] button again and this time navigate to:
Macintosh HD --> Library --> Application Support --> PenTablet --> PenTabletDriver.app

20. Restart your M1 Mac.

21. Plug in your XP-PEN display tablet.

22. Go to Applications --> PenTablet --> PenTabletSetting.app and you should be able to set your preferences for pen buttons, pressure, display mapping, and Express Key assignment.

23. EXIT the settings app.

Your settings should now be usable with your tablet.  When you press one of the Express Keys on the tablet you should see a gray bar across the bottom of the screen with text telling you what action is assigned to that button.

When you re-open the settings app be aware you may need to select your tablet from the drop-down list at the top before it will actually load your custom settings.  I had made my pen pressure softer but when I reopened the settings app it wasn't showing the curve I'd set for the pen, but after selecting "Artist 15.6" from the list at the top it loaded my settings.  They seem to be persistent after that, but if they revert to showing defaults I'd try selecting the tablet in the drop-down first, just to see if your custom settings load.

This WILL fix your issue assigning the Express Keys custom functions.  Whether using these old drivers ends up causing you other problems I can't say.

Running Clip Studio Paint in Wine on Linux

I would love it if Celsys released a Linux version of their Clip Studio apps, but I highly doubt that will ever happen.  Though if it did it would go a long way toward me being able to ditch both macOS and Windows (at least for my personal projects).  So, without a native Linux version what to do?  Try to run it in Wine (read more about Wine here).  Emphasis on the word "try" because it can be rather difficult to get programs to actually work in Wine.  They have an App Database which can often help you decide if it's even worth the trouble, which it often is not.

Well, with that stellar sales pitch I'll tell you that Clip Studio Paint 1.9.7 and Clip Studio Modeler 1.9.1 both worked for me in Wine 3.0.1 and Wine 4.0.3 on Kubuntu Linux 18.04 LTS.  You should see similar results with just about any Linux distribution, especially the Debian-based ones like Ubuntu and its derivatives.  I only installed the "trial" versions, but I tested as much as I could and everything I tested seemed to work just like it does on my Windows 10 machine.

Clip Studio Paint 1.9.7 running in Kubuntu Linux 18.04.  As you can see the 3D features also work.

However, I would strongly recommend if you have an actual Windows machine, or if you have a copy of Windows you can install on a partition on your machine and dual boot, that would be the preferable solution.  But let's say you don't have a copy of Windows, or you hate it with passion, or you're not sure you'll use Clip Studio often enough to dedicate a drive partition to it.  Ok then, let's install Wine and configure it for running the Clip Studio apps...

Install WINE

1. Open whatever package manager your distribution uses and search for "Wine" and mark it for installation along with whatever dependencies it needs.  

Sometimes the version available in your distro's repo is really old, in which case you'll want to add the Wine repository as a new source and pull it directly from there.  I'm using Wine 3.0.1 (the latest in my Kubuntu LTS repo), though 4.0.3 is the latest stable release available from Wine HQ.  

However, having the latest release isn't always an advantage with Wine, you'll want to check the app database to see if your particular application(s) are listed and what success or problems others have reported.

Note that you can also install the Wine HQ Release Key and Repository source using the Terminal (this would be for my Kubuntu 18.04 LTS install, but any Debian-based distro would be similar):

wget -nc https://dl.winehq.org/wine-builds/winehq.key

sudo apt-key add winehq.key

sudo apt-add-repository 'deb https://dl.winehq.org/wine-builds/ubuntu/ bionic main'

sudo apt-get update

sudo apt-get install —install-reccommends winehq-staging

This will allow you to easily install the latest stable or development releases, as well as force previous versions if that's what you need.

Another reason you may want to use the official Wine HQ repo is for reasons I don't know some of the ones in the Ubuntu repos were missing the Wine Gecko and Wine Mono components, which I had to download separately and manually install.  The one from the official Wine repo was complete.

As I said in the intro, I did test this with both Wine 3.0.1 and 4.0.3 and it worked in both of them, and should presumably also work in all the versions in between.

Install WineTricks

2. Install WineTricks from your package manager, along with whatever dependencies it has.

3. Make sure "cabextract" is installed.  If it's not, install it with your package manager.

Install DLLs Clip Studio Needs

4. Run WineTricks and make sure the radio button for Default Wine Prefix is selected and click OK.

5. Select "Install a Windows DLL or component" and click OK.

6. One by one, in the order they are listed install:

vcrun2005

vcrun2008

vcrun2010

vcrun2012

vcrun2013

vcrun2015 or vcrun2017 (you can't have both, I'd recommend 2017)

vcrun6

vcrun6sp6

msxml4

msxml6

mfc40

mfc42

I honestly don't know if all of those are actually necessary but they were the ones listed in the Linux Mint forum post I found that pointed me in the right direction and it shouldn't hurt anything to install all of them.  If any of them do conflict with your running some other software in Wine you can always use Wine Config to create a custom profile just for that app that excludes the problematic one(s).

Install the Clip Studio App(s)

7. Download and run the Windows installer for Clip Studio Paint.  Note that the shortcut icons on your desktop may show the Wine icon instead of the app.  This is because it actually has to run Wine first.  You can edit the shortcut and assign the correct icon to it under the right+click context menu —> Properties though it may correct itself after a reboot.

8. (optional) Download and run the Windows installer for Clip Studio Modeler if you want to set up 3D objects and characters.  This download will also install the Clip Studio materials management app, which does NOT completely work (see below).

9. Try to open and run each of the Clip Studio apps to make sure they actually work.  If the desktop icons placed during installation don't work use Wine's file "Explorer" to navigate to your fake "C:" drive and drill down to the:

"Program Files (x86)" folder → CELSYS → CLIP STUDIO 1.5 → CLIP STUDIO PAINT → CLIPStudioPaint.exe  

Wine has a file Explorer like old-school Windows

If it crashes or freezes instead of running you probably need to change the Windows version in the Wine Config to Windows XP.

Clip Studio Modeler 1.9.1 running in Kubuntu Linux 18.04.  As you can see the 3D setup functions appear to work.

Configure Your Tablet

10. If you have a Wacom tablet and are using KDE as your desktop environment, they have a Wacom Tablet preference panel you can install from Discover (it's sort of like KDE's App Store), but no guarantees it actually works.  If you have some other kind of graphics tablet and it doesn't have a Linux driver (since most don't) you can try installing the generic "Graphics Tablet" app for system settings.  Again, no guarantees it will work.  Getting your graphics table to work, and particularly trying to get pressure sensitivity to work, can be a real bear on Linux.  For example, XP-Pen graphics and display tablets actually do have a native Linux driver available, but you have to run it with "sudo" from a terminal and keep the control panel open in the background (it doesn't appear to be persistent).  YMMV.

Problems Encountered

1. The desktop shortcuts created by Wine don't always open the apps or take such a long time to open them you think it didn't work.  They're far more likely to work if you already have something open in Wine (like the Config utility or Explorer).  Similarly, the links in the Clip Studio app sidebar don't always work for launching Paint and Modeler either.  Sometimes they do, sometimes there's a lag in Wine and they fail to open.  It's far more reliable to navigate with Wine's Explorer app and open the EXE files directly.

2. If you are using Wine 3.x you MUST set Wine Config to "Windows XP" which will trigger an "unsupported OS" warning when you open the Clip Studio apps, but they will work anyway.  If you select any Windows version later than XP you will have problems.  For example, on my system Windows 7, 8, or 8.1 would let the program run, but the canvas would be blank instead of white.  Window 10 would cause a page fault on startup and crash the program.  In Wine 4.x you can set it to Windows XP, 7, 8, or 8.1 but it will page fault if you set it to Windows 10.

3. The CLIP Studio management app does not work properly.  It relies heavily on loading HTML content both from remote servers and a local folder.  The web code uses CSS3 querySelectorAll and the Wine implementation of the mshtml.dll is too old to support it, so the web content fails to load (which is most of the app).  If you have a CLIP account, you should manage it through your web browser instead because you can't do it from this app.  So what does work?  Well, you can use it for maintenance on your Materials and Work folders.  In fact, because the interface is broken, the ONLY way you can get to the management sections for Work or Materials is to first do a Gear → Maintenance → Organize Work Tags / Organize Materials Folders.  At the end of those relatively fast operations it will take you to the management subsections.  You can also use the app to download the large package of Materials when you first run it.

The Clip Studio Assets Management app running in Kubuntu Linux 18.04 (Notice that a LOT of it does NOT load!)

4. Be wary of updates!  An update to the Clip Studio apps, an update to Wine, or an update to any shared Linux library could break the whole thing.  Running apps in Wine is often a fragile balancing act.  When a new update comes along for the Clip Apps you should RENAME your existing "CLIP STUDIO 1.5" folder to something else, like maybe the actual version number (in my case "CLIP STUDIO 1.9") and then install the update, which will create a NEW "CLIP STUDIO 1.5" folder.  That way if the new version doesn't work under Wine you can simply run the previous version without having to reinstall it.

5. Pressure sensitivity can be difficult if not impossible to get working in Wine.  Odds are you will not get it to work, so you'll have to live with fixed pen and brush sizes.  If you don't usually use variable line widths anyway this won't be a problem, but in Wine most graphics tablets only work in "mouse mode."  Also, even if you get pressure sensitivity to work in one program in Wine that doesn't mean it will work in another program.  Recent releases of Wine are supposed to have improved graphics tablet detection, but it's still pretty buggy.

6. It should probably also go without saying, but I'll say it anyway: don't expect any technical support from Celsys if you're running their software in Wine.  For any problems you encounter you're far more likely to find your answers in a Wine or Linux forum anyway.

If you can't live with all this uncertainty then you should probably run Clip Studio in a Virtual Machine running actual Windows (though if you have a copy of Windows you'd be even better off just running a dual-boot set-up to run Clip Studio in Windows directly on your actual hardware).

Google Chrome "Managed by your organization" when you don't have an organization?

Starting with Chrome 73 when one or more policies are set in the Chrome Browser you'll see "Managed by your organization" at the bottom of the 3-dots menu and at the top of your Chrome Settings screen.   I'm posting this because, first of all I posted it as an answer on Googles support forums and it's pretty clear from the many confused, freaked out, wrong answer posts after that nobody there actually read it; and  Google's official answer isn't terribly useful.  For starters they don't tell you how to clear it.  The links in their answer also aren't helpful if you're a HOME USER who isn't using a Chromebook or your company's G Suite or an organization's computer.  I'm going to tell you below how to get rid of this notice and take control of your browser.

This notice is normal if you're in an enterprise setting like a business or a school where the IT Department is managing the browser capabilities or if you use G Suite for business and you're logged into an account associated with G Suite.

However it's disturbing to suddenly see it when you're using your private computer at home with your personal account!  If you're using Chrome on your personal computer and saw this "Managed by your organization" appear don't worry, it *probably* doesn't mean anyone hijacked control of your browser.

I say "probably" because there are malware and malicious extensions out there that can reset your home page and/or search engine and they do this by creating Chrome Policies, which will trigger the "Managed by your organization" notice. Allowing an extension to run in or even trying to print from "Incognito Mode" can potentially trigger this, but will persist even when you're back in a normal browsing window.

Deleting accounts or profiles or creating new ones won't get rid of it.   Uninstalling and reinstalling Chrome doesn't work.  It might initially seem like it got rid of it, only to have it show up again.  You may have read somewhere that chrome://flags/#show-managed-ui  will fix it.  That just HIDES the notice, it doesn't change any of the managed policies.

Policies apply to ALL users and are set in the operating system not the browser. Unless you're using a Chromebook, then it's managed in the Google Admin Console and applied through your Chrome Profile.  This image explains how it works (image is a link to the Google page about it):

First see what policies are being set and by what by typing in:

chrome://policy

At the top are the "Chrome Policies" set administratively. If under "Applies to" it says "Machine" and the "Source" says "Platform" those are policies that were set ON your computer, they are NOT being managed remotely by Google or nefarious parties unknown.

If there are any extensions setting policies you can simply remove the extensions. Though some extensions NEED to set policies in order to work, for example password managers. That's why it's important to learn what policies they're setting and why.

MAC

On Mac this is pretty easy. You don't even need an Administrative level account.

1. Write down each "Policy name" (they're case-sensitive)
2. Quit out of Chrome entirely
3. Got to Applications → Utilities → Terminal
4. In the terminal type the following for each Policy Name (example is "HomepageLocation"):

defaults delete com.google.Chrome HomepageLocation
Hit enter. Do this for each Policy Name until they've all been deleted.

5. Restart Chrome. If you did it right the "Managed by your organization" at the bottom of the 3-dots menu should be gone. You can double-check by going back to chrome://policy which should be empty of policies now.

Note that if you miss or leave even ONE you will continue to see the "Managed by" notice.

WINDOWS

Windows has tools you can download a fixer app:

Chrome Policy Remover: https://drive.google.com/uc?export=download&id=0B5uG-tHNHBj5XzNJbzlsd0NONnc

You can also do the fix manually by deleting a registry entry:

\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome
or
\HKEY_CURRENT_USER\SOFTWARE\Policies\Google\Chrome

Then run the Chrome Cleanup Tool:
1. Open Chrome
2. Go to the 3-dot menu and "Settings"
3. Click "Advanced" at the bottom of the Settings page.
4. Under "Reset and clean up" click "Clean up computer"
5. Click "Find"
6. If you're asked to remove unwanted software click "Remove"

Linux

It uses a JSON file to set user, rather than group, policies for the browser.  It's rather complicated.  Here's the Chromium Project page explaining it: http://dev.chromium.org/developers/how-tos/enterprise/adding-new-policies

Ultimately if you know they're being set at the operating system level (and if you're not on a Chromebook they will be) and you have administrative privileges on the computer (which you probably do if you own it) then YOU are the "organization" that is managing these policies.

Character Model Reference Sizes

If you're trying to make 3D character models from scratch it is helpful to know the actual dimensions of real humans.  One of the best resources for this information that I've found are the dimensions for the Alvanon Forms.

Alvanon is a company that makes and sells dress forms (aka "dressmaker's dummies") for the fashion and apparel industries.  They also do extensive research on the dimensions of actual human beings, both adults and children, all around the world.  They do sell 3D model services, but they are very expensive and geared exclusively toward their target industries.  In other words, you can't buy one of their standard male or female models to use as a posing dummy in Clip Studio Paint or as a base in your 3D modeling software.

But they do have a massive amount of data on human dimensions you can use as a starting point.  On their website there are PDF product data sheets for each of their many dress forms:

https://alvanon.com/resources/alvaform-manual/

If you go to the last page of each of those product data sheets you'll find all the dimensions for the dress forms in both inches and centimeters in a chart like this:

You can glean the dimensions you need from there.  In this sample it is for six men's UK clothing sizes, but what are useful are measurements such as the Total Height, Inseam, Across Shoulder, etc.

Of course it's helpful to know how they arrive at those measurements so you'll also want to check out the Measurement Specifications documents:

https://alvanon.com/resources/alvaform-measurements-specs/

Which have useful charts like this inside:

Universities are also doing this kind of work for other industries.  For example, here is a 2018 survey published by the University of Malaysia Engineering Department which gathered anthropometric data on Malaysian, Thai, Filipino, and Indonesian men and women:

https://www.ias.ac.in/article/fulltext/sadh/043/01/0010 (PDF file)

I took a bunch of data from various sources (including the CDC, EU, the Malaysian survey mentioned above, an architectural design website, etc.) and put it all in a spreadsheet to get these "Average Human" dimensions:

           AVERAGE HUMAN DIMENSIONS
================================================
                   MALE     FEMALE    AVERAGE

HEIGHT             1715mm   1588mm    1651mm
EYE HEIGHT         1599mm   1478mm    1538mm
SHOULDER HEIGHT    1411mm   1302mm    1357mm
SHOULDER BREADTH    418mm    382mm     400mm
ELBOW HEIGHT       1072mm    991mm    1032mm
HAND LENGTH         189mm    174mm     181mm
HAND BREADTH         77mm     76mm      76mm
REACH UPWARDS      1724mm   1540mm    1632mm
LOW HIP WIDTH       376mm    382mm     379mm
WEIGHT               77kg   62.5kg    69.7kg
------------------------------------------------

The data sets were based on the geographic location of wherever the particular study was being done, with no break-down by race or ethnicity, just male and female.  So it's probably not as globally encompassing as it could be.

In addition to the apparel and fashion industries, knowing these numbers could be useful to engineers, architects, furniture designers, industrial designers, and probably video game, 3D animation, and other artists who work with or from 3D character models.