It has bothered me a lot lately that Poser forces files into its given structure. With a handful of files that might be okay.

I like it when the files of a package are all together in one folder. So that when the folder is removed, all files of the package are gone ("uninstall"). Or that a package can simply be moved from one path to another.

So what could be more obvious than building a script that does just that. All files that do not have any of the defined exceptions (images, obj files, morphs, text files, etc.) are examined - and included path/file information is rewritten if necessary. This way an installed Poserpackage should work from any directory.

Before I release the script to the general public, I need to make sure that everything works reliably and that all cases are considered. Therefore first of all here in a really small circle of people who know how to program themselves and can make suggestions for changes if necessary :)

To underline the test status there is no UI yet. There is only a simple choice for a zipfile to locate and the possibility to specify the path where to unpack (I prefere to write the packagename directly in the script until the UI is ready).

And yes, you can also specify a URL from which the zip-packet should be loaded :)

Feel free to comment, look for error, test for completness!

As usual the script can be found on my website (contains characters Rendo can't handle, so I can't post it here).

For the UI:

I think the best thing would be to have a wx.Dialog containing the following controls:

• checklistbox for zipfiles
• dropdownbox for targetpathes
• editable list of keywords to watch for (lines containing pathnames)
• a possibility to create substitutes (string_to_replace|replacement)
• ??? anything else ???

so far, my tests in pp14 and p11 crash poser - after extraction of the files mind. One thought, will you be enabling multi file extraction? There are a great number of products that come with multiple zip files, some that I have in my queue right now have 4 zips - which I manually extract to the resident folder then move to my test runtime,

it would be great an option to uninstall a certain file too

structure posted at 5:24PM Mon, 09 March 2020 - #4382982

so far, my tests in pp14 and p11 crash poser -

Ok, I didn't test it in Poser yet - only standalone. Will see where the trouble is this evening (or did you already find out?)

after extraction of the files mind. One thought, will you be enabling multi file extraction? There are a great number of products that come with multiple zip files, some that I have in my queue right now have 4 zips - which I manually extract to the resident folder then move to my test runtime,

Multi-file is an exelent idea! Will do it!

"Uninstall" is not more then deleting the folder. Or what do I miss?

Multizip: Implemented - can you test it, pretty please?

last version: http://adp.spdns.org/ExtractZip.py

(name stays the same for a while, no versions; so download will be easier)

Looks like the Python 2.7 ZIP-library under Poser is much slower than the one I use under Linux. A package that takes less than 3 seconds to unpack under Linux takes 10 seconds under Poser Python (on the same machine).

Zips in a Zipfile also seems to cause problems with Poser Python. I get the error message:

zipfile.BadZipfile: Bad magic number for central directory

Standalone (without Poser) unpacks the script correctly without grumbling.

And in the end it works out!

Embedded zip files now also work with Poser Python.

FYI: The Problem was Poser-Python's shutils.copyfileobj(). It damaged zip-files for what reason ever.

The script works fine for me on Win10 / Poser 11.3 when the zip is on my own system. I tried to load form my store files in Rendo but that did not work because apparently the zip was not downloaded to the location the script assumes. (or was that not intended?)

I do see the advantage: you can load the content via drag and drop from Explorer, the Runtime needs not be in active in the library.
What is not clear to me though is where the script filters between refenced files that are in the .zp and therefore will be copied to the dstination folder, and referenced files the content needs but that are not in the .zip and for which the referenced address must be kept as they are.

FVerbaas posted at 12:12AM Thu, 12 March 2020 - #4383241

The script works fine for me on Win10 / Poser 11.3 when the zip is on my own system. I tried to load form my store files in Rendo but that did not work because apparently the zip was not downloaded to the location the script assumes. (or was that not intended?)

The download is very simple in this version. Just on call to the library "urllib.urlretrieve(...)". This call should return a filename (path included) where the downloaded file is located. If that is not the case, the script simply aborts. I think the download does not happen because of https. No problem to do, but needs more work on this.

I do see the advantage: you can load the content via drag and drop from Explorer, the Runtime needs not be in active in the library.
What is not clear to me though is where the script filters between refenced files that are in the .zp and therefore will be copied to the dstination folder, and referenced files the content needs but that are not in the .zip and for which the referenced address must be kept as they are.

Good point. For me all files should be extracted, but I see other may have other needs.

Can be resolved if first all filenames in the package are collected. Then only those filenames are replaced.

sorry - my wife has been ill - I have not been here for a couple of days. downloading multi-zip now

so far I have been unable to select multiple files - or a folder, but poser no longer crashes !

structure posted at 6:41PM Fri, 13 March 2020 - #4383418

so far I have been unable to select multiple files - or a folder, but poser no longer crashes !

Allowing multiple file select should find support in the UI. The UI is only a simple file selection yet. Looking for someone able/willing to make a UI, supporting all the features (multiple replacements, replace certain files by just one (can be useful for textures), remove parts, rewrite version-number, etc.), because I'm not good with designing userinterfaces (mainly lack of interest :) ).

structure posted at 6:49PM Fri, 13 March 2020 - #4383415

sorry - my wife has been ill - I have not been here for a couple of days.

I'm sorry to hear that. I wish your wife all the best.

adp001 posted at 8:37PM Fri, 13 March 2020 - #4383446

structure posted at 6:49PM Fri, 13 March 2020 - #4383415

sorry - my wife has been ill - I have not been here for a couple of days.

I'm sorry to hear that. I wish your wife all the best.

Thank you and, I am starting work on a UI - should have a prototype ready in a day or 3

Ups! Weekend work! :)

I don't know if I do mutch Python for the next few days. One of my 3D-Printers died. I have to find out why and what is broken. My second one isn't able to print soft materials and I have to print out something for a friend of mine.

Work has taken over from what I have time to do, it is going to take a little longer than I thought.

adp001 posted at 2:56PM Tue, 17 March 2020 - #4383002

"Uninstall" is not more then deleting the folder. Or what do I miss?

Uninstall a file is not deleting the folder, but only the list of files included in the zip file.

We basically need to know the files Included in the zip

Thought about it. It's not difficult.The directory of the files exists in the corresponding ZIP-file.

But what if one of the extracted original files was changed?

In my case, I extract the files exactly once from the original ZIP (at least usually). Then the main folder into which they were extracted is moved to the backup when they are no longer needed.

Somehow I don't see the sense in deleting the files extracted from the ZIP and keeping only newly created files. Because obviously the newly created files belong to the installed ones. So what do you do with them if the original files are no longer available?

Wouldn't it make more sense to have a function that packs a new ZIP from the directory instead?

I must mention at this point that I am not necessarily the typical Poser user and use Poser only for special purposes. It would be great if you could describe a typical use case to me. Then I would know more exactly how such a delete function should work.

adp001 posted at 10:59PM Tue, 17 March 2020 - #4383867

I must mention at this point that I am not necessarily the typical Poser user and use Poser only for special purposes. It would be great if you could describe a typical use case to me. Then I would know more exactly how such a delete function should work.

You can compare the date of the files to verify if they were modified, it would be great to give the user the option to backup only the modified files, zipped and move them to a backup folder so they don't get in the way

So it would probably make more sense to create a specific file in the destination folder that gets all file names and paths from the zip. And to delete only what is in that file on request.

Then you don't have to dig out the source zip file from any backup (of which you might not even remember its name).

adp001 posted at 8:55AM Wed, 18 March 2020 - #4383901

So it would probably make more sense to create a specific file in the destination folder that gets all file names and paths from the zip. And to delete only what is in that file on request.

Then you don't have to dig out the source zip file from any backup (of which you might not even remember its name).

Maybe we could have both options, some files have the list of files included in the readme files, the problem is finding the right readme file and getting the file list

Begins to look like a sort of vaulting. A database with the files extracted, from which product it was extracted, and which files call which resources, so you know what you can delete and what to keep. Calling files can have direct path.

FVerbaas posted at 7:56PM Wed, 18 March 2020 - #4383927

Begins to look like a sort of vaulting. A database with the files extracted, from which product it was extracted, and which files call which resources, so you know what you can delete and what to keep. Calling files can have direct path.

You are right. I had the same idea, as I started to script a delete-function.

One of the problems: The script, while unpacking a ZIP, may: rename files, store them in other places, change content, skip extracting them, etc. A simple and useful "delete" function isn't possible.

For me it seams easier to have a central "database" knowing what is going on.

Right now I prefer the following idea:

First installation of a package: Parsing the package, adjusting (or removing) paths, correcting versions, and more. The (possibly corrected) pathnames/filenames are moved into the database (under the package-name). The original package goes into the backup, the modified package into the backstore.

Workspace installation: The database is used to determine which files are required for a complete installation and these are installed in the workspace.If files already exist in a different directory, the Poser files are adjusted during the installation (but only for the files that are in the database).

Each database entry that refers to a file also holds a counter that is incremented for each installation. If different packages point to the same file, that file will not be removed from the workspace until the last package pointing to it is removed.

Also important:

1. A function to turn an installed package into a ZIP file to be installed normally.
2. A function to update a package in the database (include newly created or changed files/directories).

At the end the question: Where do I take the time to realize all this? Besides everything else I already have in work.

Translated with www.DeepL.com/Translator (free version)

By the way, I would also suggest to split the whole script into individually runnable/usable dialogs. So that you can use critical parts completely outside (or even without) Poser (and thus also libs that are not available under Poser). Another advantage: Splitting work/coding.

For the communication between the parts I would suggest a simple network communication.

Last information: Poser-Python will be updated to 2.17 (last release). But I think it will still be impossible to simply install not standard-libs. So I still prefer external coding for bigger tools with IPC-Communication* to Poser-Python. Beside this, there are plenty P10 users out there with no plans to upgrade.

• IPC = Inter Process Communication; based on Network, file or memory-blocks (easy to implement with Python; even in older installations).

adp001 posted at 8:52AM Thu, 19 March 2020 - #4383936

At the end the question: Where do I take the time to realize all this? Besides everything else I already have in work.

That is where I was also. Too big a project for a single person in spare hours after day work, and when completed still quite fragile if not supported by software maker.

That makes it more safe to speculate about possibilities though. LOL.

I was considering not to unpack at all. Just parse the zip and fill database with pointers and pull from zip when needed what is needed and amend as needed. Changes are automated anyway. On project wrapup delete all files from project runtime that have not changed during the project and replace them with pointers. New files and changed files registered in the central database so they are available for other use. (VenturaProjectLFFaceTextureWithBeard.jpg)

Just my two cents ... some years ago I was nearly ready with such a unpacking/installing/databased archiv. It was a hobby project besides my full cash projects with similar goals. So it was done with VB5/6 and Access-MDB as base and third-party libraries for packing/unpacking (zip,rar,gz,arj,...) like also a FTP-libary not needed for this. Sadly the Poser-stuff hangs at around 70-80% ... the old damned time problem. But now I'm nearly on the way to start again (depending on time) cause all that fine freestuff and also commercial stuff is to much to install all and even keep in view.

But ... there are problems ...

1. exactly the harddisk with the project stand ready up to now is the only one not responding in any way, why ever.

2. Surely I have a rather actual backup. I only have to identify which backup software I used. With look to the readable Windows start menu I guess it was Paragon Backup. I got the newest version and have now to install and to hope that the version will read the old backup structure.

3. MS Office is no longer my first choice, specialy Access ... new version = new DB structure. So I tend to use a SQL-DB instead. Times ago I would have taken MySQL but cause this is now Oracle (no need to change MS with Oracle) I look more to SQLite 3 or MariaDB. First more simle, second full size and somewhat a fork of MySQL if I see right. At the moment I have to migrate my relatively fat video-DB from Access to some other DB. First approach was to use the Libre Office Base cause LOB can work with Access-DB via ADO/ODBC and also with SQLite -DB but up to now Libre will not work with Access-DB on Linux. So I have to install on Windows where the ADO/ODBC-stuff is up-to-date and try again. If that is done I guess a little bit GUI and reporting for the SQL is needed. That was a fine easy stuff with Access ... so what. But therefor I need a little bit more practice with Python and its libraries. Maria-DB looks for that a bit more complete than SQLite.

But in all I'm more with ADP, better programming such as stand-alone than as a Poser-inside solution. Stand-alone even Python 3 could be a advantage. But first I need my backup read to find again all my ideas and also the DB-structure for that. Was relational with some tables fully pointered with search key and such stuff. Not my first SQL-DB ... I'm traditional fan of DB's and not Excel (Schlabber-Stuff).

But one idea here regarding the updating practice ... how about CRC or such to identify the single files and their version. With first read-in of a pack these CRC's could be calculated and stored in the DB. Ok, nowadays a lot vendors are having megabyte heavy packs so calculating CRC's could last a little bit time. But its the only safe method to know if something is updated or not. That even something I deeply miss with the now permanent Poser-Updates ... only a date is a little bit less ...

@JoEtzold Interested in working on this? I tend to quit Poser, but this would be an interesting project to do.

Instead of a relational DB I would take something more flexible. Like CouchDB: https://docs.couchdb.org/en/stable/intro/index.html

JoEtzold posted at 7:30PM Sun, 22 March 2020 - #4384010

But one idea here regarding the updating practice ... how about CRC or such to identify the single files and their version. With first read-in of a pack these CRC's could be calculated and stored in the DB.

Not sure if this CRC is required. Each file has a timestamp. And according to my plan, each original ZIP Package is stored untouched somewhere. So it should be easy to manage updates.

adp001 posted at 9:24PM Mon, 23 March 2020 - #4384218

@JoEtzold Interested in working on this? I tend to quit Poser, but this would be an interesting project to do.

@ADP That's a not so bad idea cause as noted a bit before this could be a bigger project. But at the moment I see no chance in starting this cause as earliest in one month I will find time for this again. At the moment I'm changing a lot from sold software like MS-Office to public licence software like Libre-Office, equal Photoshop to Gimp, C4D to Blender, etc.. So a lot of learning and building up experience. In parallel I want to reduce my PC's from 3 to 2 plus a Raspberry as a small NAS means a lot of hardware reconfiguration incl. Linux move and upgrade to 64 bit. And than it's time to become familiar with Python ... ok, a programming language like others but also a little bit other. Even to have correct leading spaces not to disturbe loops and such stuff will be a new experience (who had that damned idea... :-( what was sooo bad on while-wend, if-endif ... ) ... ok, I ever have written good readable code with spaces and line breaks and such but now it's essential and needs to be checked with errors. And a lot of functions have slightly or total other names means a lot of searching and looking into help files.

At the moment I'm on the way to bring Libre Base to fly with the Access-Video-MDB and to get hand on the old stuff via Paragon-Backup (again). If that will work I could make a short overview about my ideas in that stuff as far as done in VB or foreseen like even a first concept of the foreseen database structure. By the way I will stay with a relational SQL-based database like SQLite or MariaDB which even can be nativly read and worked by Libre-Base ... a great advantage to have a GUI incl. report building. My first approach with that stuff is even to have all that packages for Poser or even only 3D-formats sorted correct into a database. And than looking what comes next, unzipping, sorting on harddisk or even changes in single files.

I had a first look to the couchDB and if building some web-stuff it is a interesting approach (ok, "interesting" a bit like used by TV-cookies for taste ... ) but I see here no need for web-basing or browser-using and than json like xml is not very handsome ... my opinion ... Even the concept to omit locking is not what I tend to find good especialy cause for our purpose I see more or less a one user database without locking problems.

Ok, timestamp at a file in my experience is the worst method to decide if modified or not. That can be seen with the Poser files by bondware at the moment. I'm just downloading the complete stuff again cause dates are changed but by quick check most are identical in size so big question if something has changed. And on Windows the timestamp consistency is not really a safe point. So I only know two safe methods version numbers in filename (depends on the file creator) or CRC. So I guess this could or should be a theme. And storing a original package parallel to a actualized package could end up in a big storage waste and more trouble to have things sorted ... ok, disk capacity has become cheaper by the time but never-the-less no need to waste. I for example have more than 20.000 files only from freeware and there is no sense to conserve the originals if reworked to a directly unzipable file. One of the needs to have first a well-done and safe database to catalogue and refind stuff ...

About timestamp: I mean the timestamps inside the ZIP package. That should never change as long as the owner of this specific package (the user) does not add, change or delete content inside the package. You can rename the ZIP file, copy it around and have other timestamps for the package itself, but the files inside the package will stay untouched.

CouchDB in't a "web-db". You can use simply a browser to administrate the DB, but you need that web-admin-interface. Probably the same as other web-tools for relational DBs like mysql.

CouchDB is a so called "Document-oriented-DB". Perfect for Poser, because Poser files are documents! Start with storing the documents as a whole and later on each figure, each actor, each material described in those documents can become a (retrivable) part (record) of the database! In contrast to a relational database the structure is not fixed.

I saw too mutch relational databases eat up the content in a crash. So maybe it is not a good idea to store files (of any sort) without backup into a relational DB. They are not made for this. Users will crucify the programmers if they loose paid content because of a DB crash. I would left it to the user to take care of the original files.

By the way: It is dead easy to link several CouchDBs with free content :) The name "Couch" says it all: It is an acronym for "cluster of unreliable commodity hardware".

If I can help with Linux, Raspi's etc, send me a PM. I use different ARM computers for several years now (Odroid, BananPi, Raspberry Pi).

JoEtzold posted at 11:28PM Mon, 23 March 2020 - #4384337

ok, a programming language like others but also a little bit other. Even to have correct leading spaces not to disturbe loops and such stuff will be a new experience (who had that damned idea... :-( what was sooo bad on while-wend, if-endif ... )

Editors made for Python can handle this for you. I'm used to write C/C++ code too, but with the right editor there is no big difference (PyCharm and VS-code are my favorites – in that order).

But something is different: A Python script must not only be written differently, but should also thought differently. Start with Pythons prime rule: Anything is an object...

Thanks for help with Linux or Raspi's but I have Linux Ubuntu and now Mint since some years and two more Raspi's for Radio/CD-Player and a TV streaming/saving nice films. The idea was to do a mediacenter with Kodi. But Kodi in my view is rubbish ... ok, coming from the playstation and that all to be said.

Ok, that the timestamp inside a package stays intact is surely right and so usable if safed to the database. But I would make a CRC of the complete package as a first indicator.

Ok, your toughts are much more forward if you want to store the poser files as such (cr2, pz2, ...) in database. These indeed are documents in that sense. But that was/is not my intention. Only the names, types and such should go to DB not the file itself. And so the document approach is far more as what I need. And therefor a crash of the DB (even not such often) will destroy absolutely nothing than information.

For me also I never contemplated storing the actual content files in a database, but just pointers to the content files, where they come from, which other files they call and where to find relevant help info.

For consistency it would be good to protect the storage folder from direct user intervention.

The database preferably would support compatibility info on a system level. Conforming potential, of course, but also say for a texture file: uv_layouttype: 'V4' and 'body', for a geomentry file: uv_layouttype: 'LaFemme'. For poses with interface to props a pointer to the related prop, say the chair to sit on.

FVerbaas posted at 5:44PM Tue, 24 March 2020 - #4384402

The database preferably would support compatibility info on a system level. Conforming potential, of course, but also say for a texture file: uv_layouttype: 'V4' and 'body', for a geomentry file: uv_layouttype: 'LaFemme'. For poses with interface to props a pointer to the related prop, say the chair to sit on.

I like that :)

Nice thing on CouchDB (and similar DB's, there are more of that type) is: you can add additional information/links at anytime. Without limitations. For single entries or for all.

Seems that the NodeJS lib for CouchDB is also usable now (but still beta).

Such cross pointering was what I had in mind. Not neccessarily done by program but edited by hand where senseful. And may be as the only file into the database a .png (small) to have a better idea what stuff is defined.

But at the moment I'm more or less stinky ... I need no corona virus ... I have Microsoft ... :-( . Transfer of the video-access.mdb is a little more difficult. Libre Office in 64 bit version is having trouble reading access. I guess a mismatch between 32 and 64 bit. Although they say its done in 6.3 ... it doesn't do it. But exporting with Access into a Excel-Sheet and reading that into Libre-Base is working ... not such elegant ...

But the restore of the backup from my crashed drive with all the nice VB sources has also crashed. Its a Paragon backup but actual Paragon version don't recognize it. What are these developers if their security software isn't able to read a little bit older backups ????? The 64 bit software installed well (incl. MS C++ Library ---- the roundabout dozends one on my PC ... that library indeed has some viral character) but doesn't read the backup. Thought may be also 32-64 bit mismatch, deinstalled it and installed the 32 bit version ... what a joke ... progress bar is running until 97% and then going straight backwards to 0 %. Such I have never seen before .... and got the comment "Sorry some problem installing ..." . Ok, so I searched the DVD's for the old Paragon version (no. 6 - actual 17), found it and installed. Absolut no problem but running it missed wnaspi32.dll. Okkkk, I got the dll twice from internet and lastly the correct one from the old c:-drive which run with Paragon 6. But Paragon 6 is sure with itself that this is not a correct windows version ... a bit stupid ... ok, it's Windows 7 and not NT4 or XP but indeed I'm absolutly sure IT IS Windows.

Ok, so once in time in this galaxy I have a complete backup and nothing will help me to read it ... there is the difference between such a backup and no backup ... right A WASTE of time and drive space ...

But the problem is that this way at the moment I see no way, have no idea how to come to my done database work ... and my intension to start all again from scratch is definitly very low at the moment. I long time was not sure why I was not unhappy as IBM closed my company two years before my 25. year ... but now again I found the reason for my happyness - no trouble with problems to solve by IT which without IT don't exist ... have to think if I find a idea to crack that damned backup ...

Or maybe I settle down on couch ... without DB at the end ...

Sorry to hear about your problems. I hope you get them sorted. Sometimes of course it is better to start from white canvas again.

That extra information I think is where the benefit of a database would be over the current system. Some of it, like which file calls on which, can be generated or is simply known, like which product the file came with. I would not go into guessing which UV layout a geometry has but for example the xyz location of a hip actor may give a good hint which figure a conformer was made for. Adding to the defaults would to the user.

Most likely futile and a waste of time but have you considered using VirtualBox to create an old Windows XP machine for restore purposes - never tried it but example https://helpdeskgeek.com/virtualization/how-to-set-up-a-windows-xp-virtual-machine-for-free/. Re programming languages have you looked at C#

No need for virtual experiments, ok, for this, but may be for some nice old computer games ... I got the restore managed. Paragon's newest version is not able to read their old stuff directly cause they have changed something for better whatever. But in the outlast corner there are 3 points ... and clicking on that they offer to work with "old PBF files". That someone should know and find ... though for all endusers to which the community edition is adressed even better cause its a most dangerous function. Choice a PBF and a harddisk with enough room and they write back to stuff ... as first deleting and reformating the HD complete. Was good that I had two empty partitions, one to be rebuild and one to get than manually copied the needed stuff. So I have all got back and rebuild the used partition again to normal state.

Wow, it's interesting and a little sad how much or better less is remaining from more than 25 years of day-by-day hard programming ...

But now I know again why I had stopped working on this theme. I had not unzipped and cataloged the original packages but run over installed content to catalog and find/build relations. So I found dozends of paths e.g. c:programsposer... or d:curioslabs... or e:myposerstuff... in obj-references or texture-references. Ok, a lot of this can be reworked by a intelligent automatic although special in textures these paths are seldom consistent used in one file. But much more worse are duplicate names, e.g. black.jpg. In around 100 test cases I found 14 references to that file. But its not everytime the same file, would be to easy, and therefor this is not solvable by program. If even a user is in doubt what belonges to what then you can not build any algorithem to solve this by program. A problem what even Poser itself has. If you have textures and also objects with identical names it often happens that Poser makes a decision what is not what you expect or want. And this can even happen cross runtimes ... :-(

So that was the point I stopped that project years ago cause I had no (save) ideas how to overcome such problems. Ok, there is a lot a user can estimate and solve but without being involved in the Poser program details there is much, much you can be right or not. And therefor a post a bit back from FVerbaas is absolutely correct ... it is a big project AND the most work will/must be done in maintenance cause that is the time things become clear ... a typical banana software - green on delivery and mature by user input.

So for me working on file internal references makes not much sense cause I have Dimension3D's fantastic runtime organizer and poser editor both doing a superb job. Only to run over complete downloaded packages to catalog what all is living on the harddisk would be a nice thing. Also unpacking I will do by hand cause I do it into a empty work directory and afterwards arrange the stuff into my runtimes depending on my choice and thats seldom identical with what the creator has packed. So for example all those licence and readme files are subject to the rubbish box and all those long pathnames with creators name is wasted space and scheme. Good for the creators absolute no discussion but for the usage of a runtime not very neccessary.

Good to hear you found it back.

Multiple files with the same name are an issue. If you have deep library search enabled Poser tends to take the first occurrence of a file with the name it finds in the Runtimes. No prob if the references are correct but a headache when they are sloppy.

The name of the creator in the path can be useful if you want to restore links manually.

Made an update to the script. It can now handle compressed files in a zip-package. I don't mean included zips (I added that earlier), but those Poser files ending with "z", zlib-compressed files.

Now all compressed files are analyzed and containing file-references are modified.

Direct download: https://adp.spdns.org/ExtractZip2.py

Result from a test run:

Done in 6.13 Seconds.
383.45 Megabytes written to 317 files.

I almost forgot to mention it: Of course, the script also runs outside of Poser.