Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
This can happen if you have tooltips turned on and your mouse ends up over a widget that has a tooltip. Turn off tooltips to stop this behavior. It is, yet again, a part of the focus issues that I talked about earlier. Once the tooltip is triggered focus will not return to the entry widget and it must be clicked on again.
Kendall
Cheers Kendall
Sounds like the same behaviour, but "focus will not return to the entry widget and it must be clicked on again." - when this occurs for me, the numeric entry widget is either totally unresponsive to clicks or clicks actually zero the contents of the field.
I'll give your suggestion a try and turn off tooltips and see if the behaviour re-occurs at any point.
Thanks again.
Gaff
Since it's working only for linux right now, I'll leave it here for the moment.
https://pastebin.com/ntrgBqP4
It's a PHP (CLI) script to convert all G3 poses to G8. Please use at own risk! Read the instructions below!
Usage:
php convertPoses.php <PATH_TO_SOURCE_DAZ_LIBRARY> <PATH_TO_TARGET_DAZ_LIBRARY>
Should be pretty self explaining, you run the script and provide it the source library and the target library as a parameter.
You can use the same path for both, then it will directly write to your G8 Poses folder.
Or use a temporary directory as the second parameter, so you can first test if everything works okay for you, before you go for your real library - I recommend that!
It will ask for every pose, if it should convert it, giving you some options.
You can also create a sub-folder within your G8 poses folder, so you can separate the converted ones from the original G8 poses. Also recommended!
You need to have installed:
Have fun!
Edit: Updated instructions
Maybe better to have a different variable library_path_out configured along with library_path ? You are setting up an 'out_path' twice that I can see under 'Define some Folders' and again under 'Create Folders for G8'...
- I'd be disinclined to even let the user specify the same output as the input - it's all very well saying 'use at own risk' but I prefer to minimise what the idiot user can do to themselves.
- Or you could set arguments to be passed in when running the script - which is my usual choice for run once ocassionally scripts like this with one input path and one output path.
"if you have multiple libraries, you need to edit this and run the script multiple times for now."
- I can't see how you are going to avoid having to do this from a per library basis - You could run a standard directory-walk from a user specified start_point looking for People/Genesis 3 Female/Poses/ and process everything in there - (if you could be sure someone hasn't dropped expressions under poses) - that would take care of multiple libraries in one run if they are all stored in the one location given in start_point (i.e $HOME/Documents/DAZ 3D/Studio/ )
- Another option is a config or feed file containg all the full paths of all the users library locations and just run through each one and leap straight to People/Geneis 3 Female/Poses each time and process all files/folders from there. i.e.
/home/user/Documents/DAZ 3D/My Library......../media/external_drive1/Daz/My Library 7...Just a few observations...
Again, Kudos....
Ah yes, it's very quick and dirty, did it at work when I had some free minutes. ;-)
I strongly advise to change the output path to a temporary directory, because you likely need to clean up some things.
At work I had limited content, so limited test cases, but at home I noticed some quirks, of which some I've fixed already.
There is one annoying thing left for sure:
It won't copy poses to directories deeper than 1:
Genesis 3/Poses/ConvertedFromG2/Aiko6/01
will be copied to
Genesis 8/Poses/Aiko06/01
Gonna have to fix this, it really messes things up.
As for the multiple libraries I had the idea that maybe I can parse the DAZ config - DAZ itself needs to know where the content is and that needs to be stored somewhere, right? :)
Parse Daz config? Do you mean the Smart Content db? No?
I suppose the Content Library locations need to be stored somewhere - whether it's worth it if they are stored in some odd file config is debatable - and you need to be able to find and query that file in the filesytem too. But if you can, it would allow you to run with a little less user input - although you'd still need to query for a save location.
If It's a script people are going to run once in a while - I'm not sure it's worth making it too automated.
- You are going to want to run it once for all your G3 poses to date most likely
- Then you may want to think about a smaller scale version so people can convert a new pose set they've just bought from G3 to G8.
Look to the Zev / Draagonstorm Pose converters* - they run from the given point in the filesystem down giving you the option of converting the entire Pose dir or only one or part of a Pose Set.
* (I don't know about you, but on 'Linux those take an age to load - and the 32bit one is sooo slowwww).
I'll have to study your conversion code closely - I really want every pose set I have to be usable by every figure - so I've been pondering a script that will take e.g a G3F pose set and convert it to Genesis2. Genesis, Gen-4 and Mil-3 ('cause I still use them ocassionally) - but I know nothing of figure rigging.
If you are aiming as close to Daz as possible, I think the dream goal should be giving the user the ability to highlight an entire pose set/dir or multiple and getting it to kick off the conversion right there to a selected location and a selection of figures (with probably adding the new files to the product entry and amending the supported figures and whatnot - if not creating an entire new entry - I dunno I don't use Smart Content much yet).
As to the deeper than lv 1 issue - I usually find Rosetta Code a good start point site for example based help - should be a directory walk example for most know languages, including php in there, I used the ruby version recently.
I updated the script and made it a class. Problem is, I can't get Connect to work at home, so I can't test it with Connect content yet.
Should be pretty self explaining, you run the script and provide it the source library and the target library as a parameter.
You can use the same path for both, then it will directly write to your G8 Poses folder.
Or use a temporary directory as the second parameter, so you can first test if everything works okay for you, before you go for your real library.
It will ask for every pose, if it should convert it, giving you some options.
You can also create a sub-folder within your G8 poses folder, so you can separate the converted ones from the original G8 poses.
Works for me, hope it does for you. :)
As for the conversion: It's nothing big, I only apply the changes I've read on these forums, like 45 degree bend on arms and 6 degree side2side on thighs.
Since DUF files can be compressed, there is some extra code to uncompress the file, before it can be edited. Then some regex magic to find the values, change them, then save.
That works for G3->G8, but anything else is way out of scope, because it needs more than simple shift from T to A pose. Okay, it would work for G8->G3 too, if you flip the values. :)
As for the DAZ config: could not find it at the first glance, so go the manual way: user has to provide the path.
Don't want to make anything big out of it, I just thought I might share my tool with the community. I created it for me in the first place. ;)
But if there are problems, let me know and I'll see if I can sort it out.
I've connect and Smart Content working on the 32bit version of Daz, but the 64bit version is still a problem - Amy Aimeis how to on DA is first class. I'm not sure why it's not working on 64bit, but preferences won't accept a change of port from default and changing port on the other side doesn't help either.
"Don't want to make anything big out of it, I just thought I might share my tool with the community. I created it for me in the first place. ;)
But if there are problems, let me know and I'll see if I can sort it out."
- That's fine - I was mostly brainstorming - these little tool-ets sometimes have a way of snowballing though...
I did a little script lately to make use of the custom folder icon setting abilities of Dolphin, the KDE File Manager - it snowballed into not only doing CD covers for my music collection folders to Videos and books and other folder icons and now creates the icons on the fly using imagemagick rather than pre-created icons.
- it started as a simple little script to apply changes to every directory in a given path passed by argument, now it;s starting to become an entire subsystem with a config file.
The conversion for V4 to Genesis seems to be mostly adjustments of a foot joint offset (from watching Pose Converter in action) - I'm sure there are others, but those are the most notable - (they don't really help on some freebie V4 poses though) - I'm just keen to try to get poses converted back to V4 then to V3 to widen my choice baseline. I'm also interested in smoothing out some of the female poses for use on the male figures - all the male poses are almost agressively hard and seriously overpumped on narcisistic borderline testosterone overload - younger (and most normal men) don't stand like that - I'm wondering if there might not be a softening formula I could come up with....
"It will ask for every pose, if it should convert it, giving you some options"
- Given, I've not yet had an opportunity to check out your changes yet... That could get tiresome - Beets is a great program to adjust and catalogue your music collection against the online Musicbrainz reference library (might also be on Windows, but it's definetly on Linux) - it queries you for every album under a specified match criteria - it gets really tiresome - especially with my mostly anime music collection which mostly confounds it...
I got Connect to work at home as well (Xubuntu xenial 64-bit). I think the problem was that my Postgresql version was too high (9.5) whereas DAZ uses 9.3.4
I also had 9.5 and 9.4 running in parallel - I made the wrong assumption that the old version gets replaced, like in MySQL, but that's not true.
When removing old versions, be careful, it will erase your databases without any hesitation.
Then, for some reason, 9.5 was listening on the wrong port (probably because 5432 was already in use by 9.4).
I removed both version, then fetched 9.3.4 sources, compiled and installed it, set up environment paths.
It's a little bit messy right now, because there is no service installed to start it up yet, but it now does work.
I used this guide to fetch, compile and setup the 9.3.4:
http://www.davidgis.fr/blog/index.php?2017/03/19/1185--wine-staging-23-daz-studion-and-postgresql-cms-on-linux
I followed the first part, how to compile and install it, then skipped the configuration part, but did that part with the setup:
"Create a temporary file with the following content "
and
"Apply it. Using psql its output should be similar to below output"
The second part is required, because by default I did not seem to have a user with the database and therefore could not connect.
Also, I explicitely needed to use the psql binary in the /opt/PostgreSQL/9.3.4/bin/ folder when testing, otherwise I was told I need to install a client first - gotta fix that.
My wineprefix is set to WindowsXP, not sure if that makes a difference.
I set my Wine prefix to Windows7 in order to get Reality to install on 32bit version - haven't tackled the 64bit version for Reality yet - it's still set to XP.
It complains a bit, but still connects to CMS on 32bit - Aimei reported the prefix needed to be set to XP otherwise it wouldn't work - I had mine set to XP initially, then changed it as Reality won't run the installer on less than Win7 - so no issues whatsoever with CMS on Dazs latest 32bit build - it's the 64bit version which is playin silly buggers...
I'm not certain the Postgresql version should matter if it's working on the 32bit version of Daz like it is - and I have version 9.6.3-2 (wine 2.10) currently. I'm on Archlinux, the bleeding edge rolling distro - I've had CMS working on 32bit since January, and Arch updates a lot and regularly...
- There's been effort since version 8.0 of postgresql to try to ensure different versions of client and server do not cause undue issues.
- I'm not discounting it, it just seems unlikely...that the 32bit version would be oblivious to the version of postgresql talking to it and the 64bit version sensitive like a gregarious girl at a party who'll flirt with anyone vs. her shy and prim and proper friend who only talk to people of the right age bracket and social background.
I think it was working on 64bit on the first run back when 64bit was not that stable on my Wine version back in January, then I had to redo the 64bit prefix and it's not been right since - maybe I'll have to redo my Wine prefix for 64bit Daz from scratch.
I have to install the new version of 64bit for V8 anyway - it loads V8, but complains that it can't load it then it does...
Reality does work on 64 bit, but I found rendering with the windows version to be pretty unstable. So I usually only export the scene with Reality, then edit the exported files (change Paths from Windows to Linux) and exchange the part that tells it to render with CPU to GPU (Reality does not recognize my GPU, hence does not offer me to render with GPU). Then import in linux version of Luxrender and render. Not ideal, but it works more or less. I think I ended up with compiling my own version of Luxrender, because they very rarely release a linux preview version.
The problem with DAZ@32bit is, you don't have IRay, right? And large scene would be a problem too, that's why I needed 64 bit in the first place.
The CMS definitely works on Arch, I have Manjaro at work and it was much easier to get it to work than at home, don't know why. But I know it works, because I did it (this week). ;)
As for DAZ complaining when loading V8 - check the error message, mine complained that I did not upgrade to 4.9.4, but did load it anyway too.
Edit:
For rendering I'm currently re-testing Blenders Cycles, so far I'm very impressed, quality and speed wise. But the shaders could need a lot of fine-tuning to make the best out of it and sometimes GPU rendering is not playing nice. Got to test that more, maybe I can extend mcjs TeleBlender to setup the shaders for me or create my own script for blender. But when it works, it's a much faster render engine for me than IRay (I have AMD).
Has anyone else upgraded to DS 4.9.4.117 yet? I know I read that @mork did. Anyone else?
I installed it last night and so far so good. I even have some slightly faster load times than I did with DS 4.0.3.155 which is nice. I like the new Power Pose templates and it seems to work fine in Linux. I had a blast playing with the expressions on the head template. I put the upgrade in its own bottle. I was not about to mess with what was already working so I don't know how upgrading directly onto the older version would go. Of course, it was easier to install because I already had everything all set with the database and I just copied over the same cms file that I had already done from the older DS install.
'Reality is unstable'
Probably not that much more so than the render plugins for 3DL and Iray through Wine...but I bought it with the intent of exporting and running it on the native render engine - which is how I work in 3DL all the time - I never run the Windows 3DL renderer - I always export to rib - i-render is nicer than the Daz plugin and Daz Studio is not locked up while I render.
Yeah, Iray is lacking in 32bit, but I've not had too much dificulty in large scenes in 3DL in 32bit (proly 'cause I use .rib), but of course the 64bit is preferable as the option to Iray is there, and it even runs a little smoother than the 32bit version - all I'm lacking is CMS - I'll create a new Wine prefix from scratch when I install DS 4.9.4.117 - see if that sorts out the problem.
'I ended up with compiling my own version of Luxrender, because they very rarely release a linux preview version.'
Luxrender development is on mercurial - it's not that they don't release often to linux but that the Linux distros don't refresh their package version that often probably - if they carry it at all in their repo - it's not a core package or something the majority of users would need - if a stable release comes after a distro release or after the freeze prior to release, you are stuck with the old version until next release of the distro or until a point release between times happens to update.
It's in the Arch Comunity repo - so obviously it got enough votes to get out of AUR - 3Delight is available in the AUR - it's prettty simple to pull in a package from the AUR, and it's always freshly compiled for your machine - compiling from scratch is a hell of a lot more pleasant than dealing with a windows installer....
The Arch base is bleeding edge - always the freshest packages straight from upstream - no distro specific quirks or out of date packages - perhaps that was what made it easier. It's another reason I'm not keen to fall back to an old postrgresql version - although I have nothing else on my system depending on postrgresql that an old version might 'cause issues with, it's not a habit I want to get into if I can avoid it.
'I usually only export the scene with Reality, then edit the exported files (change Paths from Windows to Linux) and exchange the part that tells it to render with CPU to GPU'
I threw a 3Delight scene out to Lux with reality after 3Delight came back with 'unexpected end of rib' error on render - a sure sign I've maxxed my limits - I never get another valid render after that with a scene - it was too big for Iray already - even if I had been on the 64bit version - so I thought 'what the hell, I've nothing to lose' exported it and ran it on luxrender from the CLI - now on Hour 50 of the render - I'm not expecting it to work, I did no optimisation beyond what Reality automatically does to a Daz scene - and it's still really spanking my four CPUs....I've screenshots on my DA page of it's 'progress' ....wish I'd known about GPU switching...and I probably should have read the manual more thoroughly first.
- What is this about path changing ? I treated it like I do 3Delight renders, export to .rib and then run "renderdl -id renderfile.rib" from inside the render directory. I just ran "luxrender reality_scene.lxs"...
The content locations are stored in the windows registry. "COMPUTER/HKEY_LOCAL_MACHINE/SOFTWARE/DAZ/Studio/ContentDir0" ".../ContentDir1" ".../ContentDir2" etc
Kendall
Wait... the sliders too? Or still the same behavior?
Ah, no, unfortunately, there is still the same issue with the sliders. However, I do have slightly faster load times and haven't had anything not work yet. Admittedly, I've only done one render so far and played around with the new Power Pose template for V8's face. So far, so good, though.
Just an update
I'm having issues with Wine 2.17 on Archlinux (kernel 4.12.13-1 )(I know most of you will be quite a few Wine releases behind, so FYI).
Up to recently, I've had little issue with wine versions and Daz. I'm getting threads blocked on startup on 64bit versions of Daz. At some point, be it a kernel update or Wine upgrade (over the weekend), this crept in....
<code>err:ntdll:RtlpWaitForCriticalSection section 0x7f0c766e8200 "../../../wine/dlls/gdi32/freetype.c: freetype_cs" wait timed out in thread 00c0, blocked by 002c, retrying (60 sec)
err:ntdll:RtlpWaitForCriticalSection section 0x7f0c766e8200 "../../../wine/dlls/gdi32/freetype.c: freetype_cs" wait timed out in thread 00c0, blocked by 002c, retrying (60 sec)</code>
ad nauseuem...
Tried an older Wine versions with a more complex version of my usual 2-line launch script:
<code>#!/bin/bash
WINEPREFIX=$HOME/.PlayOnLinux/wineprefix/Daz64
WINESERVER=$HOME/.PlayOnLinux/wine/linux-amd64/2.5/bin/wineserver
WINELOADER=$HOME/.PlayOnLinux/wine/linux-amd64/2.5/bin/wine
WINEDLLPATH=$HOME/.PlayOnLinux/wine/linux-amd64/2.5/lib64/wine
wine $HOME/Wine/Daz64/drive_c/"Program Files"/"DAZ 3D"/DAZStudio4/DAZStudio.exe </code>
No difference from the system version (2.17) - also with wine version 2.12 & 2.15 so maybe it's not the Wine version alone.
32 bit version is unaffected.
Still working on the issue.....
Update
There was an issue with PlayOnLinux wine versions prior to 2.8 (apparently) (on Archlinux at least) which results in similar malfunctions - tracked to incompatible versions of lib32-libpng - but not a solution to my problem (I tried the fix anyway) as I was using the system version of Wine not one of the POL versions.
Update 03 Oct
Now seems to be working again after updates to linux kernel to 4.13, wine to 2.18 and a libpng update (1.6.32>1.6.34) - fairly sure it was libpng issue - too similar to other earlier Wine problems tracked to lib32-libpng and some other wine programs were not affected.
+1
Okay, I updated to v4.10.0.101 and so far this version also seems to work well in Wine (PlayOnLinux) BUT to my surprise dForce does not work. It says it does not find a valid OpenCL device which is strange because Iray works just fine with CUDA and therefore theoretically OpenCL should also work fine. Display drivers are also up to date.
Kind of a bummer since I was really keen on giving that feature a try but I still hope that there might be a fix some day.
I think I saw a Linux CPU driver for OpenCL on the Intel page linked from the Start here thread - have you tried that? OpenCL, OpenGL, and CUDA are not tied together so one working doesn't guarantee that the others are supported by the driver.
Yes...
CUDA was already installed from the first time I ran Studio and after that didn't work out, I tried the Intel drivers to at least get it running that way somehow but that doesn't show up either while both drivers are apparently running:
I know Studio isn't supposed to run under Linux and of course I can't expect this this to work but I'm still hoping. I mean, a couple months ago Iray didn't run under Wine and now it does almost flawlessly :) ... So yeah, I hope a little miracle happens, lol. All in all I'm still surprised how well it runs even with bigger szene files.
Oh, forgot to mention that I gave it a quick try in my old W7 installation and there the Intel OpenCL driver shows up but my Geforce 750Ti does not. But there I also have the latest Nvidia drivers and those should have the OpenCL drivers in it I think. And of course Iray works fine with the 750Ti in Windows too, it just doesn't show up for dForce.
The reason I stopped purchasing products from Daz is their lack of support for linux. I stopped using windows a few years back and only checkin on Daz once in a while to see if they have linux support.
Odd, I have an nVidia 750Ti too and it works as an OpenCL device (in Windows 10).
...now that would really be a "knock our socks off" move if Daz suported Linux nateively.
Oooh, I'd love that...
I'll not hold my breath wating though...'Linux market share would need to be significantly higher than Macos to seem an attractive prospect for software companies.
I'd settle for Daz Studio running a little more smooth in Wine.
Anyone who got OpenCL to work within WINE? I tried several times throughout the last months, but never got it to work. :(
It works perfectly for me within linux itself, but not in WINE.
Maybe it's a W7 specific problem or it's because of my 2x750Ti setup. Got a second one from a friend months ago and use one of them for display and the other one combined with the first one to compute CUDA stuff in Blender and also works fine in Studio. Didn't get to take one out and test. But then again I'm just glad CUDA and most of Studio work damn fine so I rather not tinker with the system at the moment.
That would be beautiful but as Gaff said, it's highly unlikely, sadly. I also would love to see Affinity Photo natively for Linux but there they officially said they can't afford the development for such a version for such a tiny market share.
I have the same problem, buddy. OpenCL doesn't seem to work under Wine (I use PlayOnLinux) while CUDA does. But as I said before, there's still hope since the development of Wine seems to go really nicely.
Update:
Just found out that by copying some OpenCL libraries from my old W7 System32 to the Wine System32 got at least the Intel OpenCL support to run! Of course fairly slow on my old i3 but at least that is running and I can test the dForce feature finally!
Happy Halloween lol
I somehow managed to get CPU OpenCL to work within Wine and DAZ Studio \o/
I try to explain how I think I did it.
This is my system:
Xubuntu 16.04
GPU: Radeon R290X
GPU Driver: MESA padoka stable repo
CPU: AMD FX(tm)-8350 Eight-Core Processor
It's important to understand that things will greatly vary depending on your CPU manufacturer and GPU driver. This guide will work for the system listed above, your mileage may vary.
Prerequisites:
Install clinfo, if not already installed:
This helps you to check which OpenCL devices the system knows about.
So, since I'm on MESA, I cannot install the AMD GPU Driver package, which should also install OpenCL drivers.
Check your current installed OpenCL drivers:
It probably only lists the MESA GPU OpenCL driver. This driver causes some problems, e.g. I cannot get blender to work with this GPU OpenCL at all. It works pretty good when using the AMD proprietary driver though. So GPU OpenCL is out, we need the CPU driver for OpenCL.
1. Install CPU OpenCL (Linux)
NOTE:
If you already have OpenCL up and running within linux, please skip this step and proceed to step 2.
Also, chances are high that you don't need this step at all, you can try with doing step 2 only and if that fails, come back to step 1.
But if you are on MESA as well, you might want to have a working OpenCL setup, albeit it's for CPU only. Your choice. :)
Go here and download the latest SDK for Linux: http://developer.amd.com/amd-accelerated-parallel-processing-app-sdk/
Right now it is this file: AMD-APP-SDKInstaller-v3.0.130.136-GA-linux64.tar.bz2
Note: The following commands are for the version listed, it might be different when AMD updates the package or you download a newer version
Download the file, extract it and run the installer, preferably with root permissions:
Install to default location, which is /opt/AMDAPPSDK-3.0
Check that amdocl64.icd is installed in /etc/OpenCL/vendors:
There should be 2 .icd files:
mesa.icd
amdocl64.icd
If the amdocl64.icd is missing for whatever reason, you can create it yourself:
If the amdocl64.icd does exist, open it in an editor (with sudo) and replace the contents with this:
For example:
sudo vim /etc/OpenCL/vendors/amdocl64.icd
<press Insert>
<Remove contents with DEL>
<add> /opt/AMDAPPSDK-3.0/lib/x86_64/sdk/libamdocl64.so
<press ESC>
<type :wq and hit enter>
At this point, clinfo should recognize the CPU for OpenCL. Check that, because if it does not, I don't think the following steps will end up in a working OpenCL within Wine - I'm not 100% sure in that, but I'm sure that CPU OpenCL won't work in linux when using it in e.g. blender.
2. Install CPU OpenCL within Wine (Windows)
Until know, OpenCL CPU should work in Linux, but Wine still does not recognize the CPU OpenCL driver.
So again download the AMD SDK, this time for Windows:
http://developer.amd.com/amd-accelerated-parallel-processing-app-sdk/
At time of writing, this is the file you're looking for:
AMD-SDK-InstallManager-v1.4.87 (1).exe
Copy the file to your wineprefix (e.g. in drive_c) and run the installer:
Note that you need to change the paths to match yours.
Install the thing, it should work without problems.
3. Start DAZ Studio 4.10 and test
At this point, WINE should recognize the CPU OpenCL driver.
Start up DAZ 4.10 in wine and hopefuly you'll presented with a OpenCL device, instead of the "No device found".
Good luck! :)
Doing this can seriously damage your install. If you need 3rd party libs in your libs folders, use symlinks -- don't copy them. 'man ln' is your friend (you're looking for 'ln -s' BTW)
Kendall
Generally speaking you're probably right, one shouldn't blindly copy libs to /usr/lib, but in this case I think it's an okay solution, though not ideal, I agree.
Thing is, in the SDK lib folder there's a dead symlink linking to /usr/lib. One either fixes the symlink or copies the missing lib to /usr/lib - thinking of it, I think I did copy only the missing lib.
Will investigate when at home. Probably fixing the symlink and adding the SDK lib folder to LD_LIBRARY_PATH, if isn't already, does the trick as well, it's just a little bit more work.
So far it works "okay" for me, the speed is awful, it takes ages to cancel a simulation, but it's a start. :)
Edit:
I updated the guide. I realized that it does not matter where the library is located at all, all you need is to provide the full path to it in the vendors file.