I have used external runtimes on a different hard drive for more than a decade since Poser 6. I do this to save hard drive space and also to protect from hardware failure. I note that with Poser Pro 11.3, there is a Purchased runtime installed for me. It is not desirable for forced content installations into the Purchased runtime, as dictated in this manner.

I agree, but I do not think it will go away.

This purchases folder is useful as a 'sandbox' though. Stuff unpacked there you can inspect and test, correct, combine and when found ok and complete copy it where you want it and flush the folder.

In the PoserPython forum there is a thread about a tool to move content folders around, correcting the file references as needed.

What happens if you delete it? Does it re-spawn?

I don't see any reason why the Purchases folder couldn't be symlinked to a location of your choice, network drive or otherwise. As long as something exists with that name that behaves like a folder, I doubt that Poser will do anything other than assume that it is and act accordingly.

Yes, it does re-spawn. Ugh. I really wish there were a way to remove both the Downloads and the Purchases runtimes from Libraries. If I want to see them, I'll add them.

I have my default runtime on an external drive. It's an option when you install Poser. And as long as the Purchases folder is empty, it doesn't take up much space on your drive.

But I don't like seeing runtimes I didn't add in Poser.

I um...just ignore it? You can install to a runtime you want, manually move things the way you want? Did I miss something? It is a folder I will never use, and so it does not bother me, but like others said, new users may find it useful and some people may use it as a sandbox. I installed content since the upgrade and in no way was I forced to use this runtime?

I agree, it takes up essentially zero space if you don't have any content in it, but for new users it allows them to load content directly from the new purchases tab in the library.

Rhia474 posted at 7:41AM Wed, 01 April 2020 - #4385088

I um...just ignore it? You can install to a runtime you want, manually move things the way you want? Did I miss something?

What annoys me is that it appears on your Libraries palette and can't be removed. Along with Downloads. (Do we really need both of those?) I typically have a couple of dozen runtimes attached, so having two empty "dummy" runtimes that can't be removed is annoying.

It's annoying, especially at the bottom of the library list. That's where I keep my current work-in-progress runtime for quick reference. But at least it doesn't automatically move to the bottom. I manually edited the XML to move it to the top, and it stays there.

But why do they need both Downloads AND Purchases? Downloads was an earlier version of the same nonsense. Now we have two unremovable nonsenses cluttering up the list.

ockham posted at 9:57AM Wed, 01 April 2020 - #4385094

But why do they need both Downloads AND Purchases? Downloads was an earlier version of the same nonsense. Now we have two unremovable nonsenses cluttering up the list.

No idea, but honestly, is it truly that big a deal?

It is good to have at least one standard 'sandbox' library folder for scripting purposes. It allows you to write temp versions of library files without having to ask the user every time where to write them with the risk they give different names or to have to pass path names between scripts. The standard press and temp folders are hidden pretty deep and Poser does not allow you to add folders to the library. A standard scratch/temp/dump space like this is a good alternative.

SeanMartin posted at 10:27AM Wed, 01 April 2020 - #4385096

ockham posted at 9:57AM Wed, 01 April 2020 - #4385094

But why do they need both Downloads AND Purchases? Downloads was an earlier version of the same nonsense. Now we have two unremovable nonsenses cluttering up the list.

No idea, but honestly, is it truly that big a deal?

I really find it aggravating, because I use multiple runtimes, and often find myself with too many to scroll through. I have to go back to the root and find the runtime I want that way. These phantom runtimes would be much less annoying if there weren't that limit on the number you can scroll through.

Not as aggravating as that Content Paradise tab EF installed, which I always ended up accidentally clicking, but at least that could be removed.

See, and I actually liked the CP tab because it allowed to install properly packaged zips faster.

We are a diverse group. I dont think one extra runtime you can use to park things in if you want and leave alone if you dont needs this much attention, but that's just me. I would love to hear a new user's opinion.

I am not a new user, however I have been using the Purchase Tab and folder to see how it works to be able to answer questions from real newbies'. For the most part I like how easy it is to use, enter your user name and password and hit install all and it goes of and does a decent job of getting the content. The biggest issue with it is not the function itself but how the products are packaged in the store. If Bondware wants this to be used they are going to have to step up their requirement that products are packaged in a standard way so that the files are placed where they are suppose to go (at least the way the file structure is laid out now).

The biggest issues I have is Templates are not stored since they have no proper location and that several of the products have very vague names, so can't be placed into a common templates folder.

When it errors when not being able to store a file it has a RED message with the error, however I don't see a way to make the message go away.

And as I said above the content really needs to be properly stored to make it go into the proper categories. Right now I have files at the Runtime level because they have an extra folder where the Runtime is located and that is not good.

While I'm not so concerned about another runtime folder, I hesitate to install the update because I've just returned to Poser, recently purchased 11 pro, and am just starting to rebuild and organize my various runtimes. I've installed python scripts in the Main Poser folder (program files) and I'm worried that they will "poof". Between work, organizing content, etc etc I have very little time for art making... Are my fears unwarranted?

Something else the Store and the Purchase function need to work on is making a way for the program to download only Poser Content Zips. As it is now the Templates download and are left in the Download folder (which is a good thing) so that they can be placed later, however some products have a DS portion and that is thrown all over the place since they don't follow the Poser Runtime paradigm. Those Daz Files don't need to b downloaded or in a couple of cases I have training videos that have a large number of errors because they can't be placed.

One other issue is that when the files are extracted they get a created date of when the function runs and not keeping what is in the Zip file. This needs to be fixed so that when I try to combine folders (such as with Dreamlands city blocks) I will be able to tell which is the newest file when there are several that are the same name just different sizes, or even if the same size and date they could be skipped over.

EldritchCellar posted at 8:15PM Wed, 01 April 2020 - #4385148

While I'm not so concerned about another runtime folder, I hesitate to install the update because I've just returned to Poser, recently purchased 11 pro, and am just starting to rebuild and organize my various runtimes. I've installed python scripts in the Main Poser folder (program files) and I'm worried that they will "poof". Between work, organizing content, etc etc I have very little time for art making... Are my fears unwarranted?

You shouldn't if you don't uninstall first, but some people are having an issue where poser seems to be doing that automatically instead of asking. You might want to make a backup.

Anything that is manually installed will not be uninstalled, which includes Python Scripts. I have not lost a single script during several of my uninstalls/installs.

I didn't lose Wardrobe Wizard, but all the data files went away. (Luckily, I had backups.)

WW was one of those scripts that took a direct hit, both from Bondware support and PhilC backing away from the app. I still have mine from Poser 2014, so I won't have problems porting that over. It's just too bad we won't see any more figure modules but you'll still be able to use the features.

That’s funny! I didn’t even notice it since I always ignore downloads just above it.

hborre posted at 1:50PM Thu, 02 April 2020 - #4385224

WW was one of those scripts that took a direct hit, both from Bondware support and PhilC backing away from the app. I still have mine from Poser 2014, so I won't have problems porting that over. It's just too bad we won't see any more figure modules but you'll still be able to use the features.

I had ported it over, but Poser updated itself and nuked all my preferences (just before the 11.3 update). It didn't delete WW, but it deleted the data file with all the figure modules.

It sounds like the decision to exclude WW was Bondware's not PhilC's. Philc is still selling modules at his web site, and he's denied the claim that he's retired and no longer supporting WW. So there might be more figure modules in the future. Though maybe not LF or LH. :-/

One of the goals for Poser 12 is upgrading to Python 3.x. With that, the hope is we can find a way to secure Python apps & lock them to a Poser license. This would allow Python apps like WW to be sold without vendor concerns about piracy.

Just updated without uninstall and all of my python scripts are still in place, as are my prefs. So far pretty painless...

tim posted at 2:38PM Fri, 03 April 2020 - #4385243

One of the goals for Poser 12 is upgrading to Python 3.x.

That would be very good news, but it would break all existing compliled scripts and require editing of the ones available in plain code.

We're aware it's a heavy lift, but probably worth it if it opens up a viable, third-party market for python apps. This was also part of the thinking with new Purchases tab as it will provide a structured way to install and protect such apps.

If it breaks all existing purchased Pythons. I would be very unhappy. Most of us aren't coders and please don't assume we can just hop in and edit python code.

I think there would be many unhappy members if the next update broke the current scripts. There are some that are almost essencial and the creators are no longer around to fix them.

tim posted at 1:06PM Fri, 03 April 2020 - #4385243

One of the goals for Poser 12 is upgrading to Python 3.x. With that, the hope is we can find a way to secure Python apps & lock them to a Poser license. This would allow Python apps like WW to be sold without vendor concerns about piracy.

Why not have an option to encrypt the scripts, with the decrypt key (and the purchaser's billing name / addy as part of said decrypt key) being the license, and it only gets decrypted within the runtime memory space?

Certainly not perfect (there are still semi-exotic means to still get the script itself shaken mostly-intact out of memory in spite of OS memory randomization), but perfect is the enemy of good, and at least it'll keep the casual pirates away. You'd see a touch of initial lag in performance, but with the right means, only when it gets called the first time.

PS: You can run multiple python versions on the same box, and supply a stupid little script for users to run which would re-write script headers so that "/usr/bin/python" becomes "/usr/bin/python2.3" or suchlike (and 'make altinstall', at least on MacOS, would prevent overwriting anything.)

Well destroying all older Poser 11.1 working pytons sure makes sense as for most great Pyton creators are buried ! It is the best way to fight Piracy LOL !!! Hit that selfdistruct Button !!! I was really hoping that there would be a fix to make the Pytons work back again like they were, but the future seems to be the allot of Skin Packages will stop working if you make that change. you will have to do a really deep cleanup in the store with all the sold Packs that contain these Pyton Extension !

Creators also depend on these little apps to make great models but well keep on fighting Piracy and make a full lock and control Programm that is the best way for a good future and if it could be pirated then Destroy !

Well simple thinking where there is nothing there will be nothing to Pirate but there will also be allot of restrictions for good creations, unless you want to jump back to a Poser 4 and start all over again.

Most of the current Python scripts were written for Poser 10 and have NO clue about the new Render engine. When Poser 12 comes out there will be 2 types of users 1: will be those of us that already have Poser and therefore will be able to run the current python 2.7 scripts and 2: Users who have never had Poser and therefore won't know about all the OLD scripts. Personally I have Poser 5-11 still running on several computers and if I really need to use an old script just fire up the proper version and have at it. There is no requirement that says you can only have 1 version on your computer.

At some point Poser is going to have to move forward and leave teh past behind. In some respects poser 11 does that since a poser 11 scene can not be used in Poser 1 if it has any of the new features used such as SuperFly.

You know, I am not asking for all python scripts to be useable since Poser 1, you are moving goalposts. All I'm saying is that please don't break that worked in Poser 10 further, or 11, like Snarly's stuff, a lot of the scripts that build shaders and are used in commercial products that are still useable as of today. Is that so hard to understand?

tim posted at 7:17AM Sun, 05 April 2020 - #4385316

We're aware it's a heavy lift, but probably worth it if it opens up a viable, third-party market for python apps.

To open up this market the Python3 implementation must be a complete re-implementation with all bugs fixed and with the additions we have been asking for for so long.

This was also part of the thinking with new Purchases tab as it will provide a structured way to install and protect such apps.

Not really sure how these two would be connected other than using a similar callbackhome mechanism on installation. I can imagine an 'IsThisLegalUse()' Python method, querying some user-specific keys stored in preferences and obtained from Bondware if not found. I do hope these scripts will not be limited to act on stuff in the purchases folder only.

In fact, every script that would try to "phone home" would be nuked and deleted.

And I would notice because my Poser machine isn't connected to the Interwebs at all.

This is both because of security reason (ransomware!) and also because of those phone home "features".

IF some content won't work without an internet connection - so phft! I'll give it a miss and delete it. Must I emphasise that I wouldn't EVER buy stuff from that particular vendor again, and he'll be blacklisted?

His stuff will be available in a matter of weeks on the pirate sites anyway, and then without the phone home "feature".

K

The issue lies not there. Calling would not be necessary when proper install was carried out, and fixing a modified install on user's request by a call to Bondware servers for 99% of users will be preferred over the hassle of sending emails with system info and license code files. Knowing the sensitivity of the topic that 'manual' method would need to be there but relative to total may not see much use.

More fundamental: Python by design is notoriously open and code is difficult to protect to begin with. On top of that, unless Rendo takes care of and responsibility for the protection, everybody is 'in the development house' so the procedures and calls to use will be in the manual. This only then relates to protection of intellectual property. Piracy was also mentioned and that is yet another story.

It is a noble objective though. I wish Tim and his team a lot of success with undertaking this.

There is no Python that cannot be reversed back to source code. Even when Dropbox hacked their version of Python engine to use obfuscated op codes and decryption of the app itself in memory using "secret" information, the source for the entire application was revealed by hackers in days.

In case you fail to see why that matters, once the source is revealed it is easy to make a revision to remove phone home, decryption, password protection, anything at all pretty much. People used to pay me to do this to games and those were binary executables with no way to see the source. Doing this for Python apps is absolutely no trouble.

Link to paper describing how Dropbox Python was reverse engineered

Exactly.. I've said too much already

Are addons considered scripts? That’s what I’m mostly concerned about.

To be honest, I feel that the addon folder is just a redundant location for spillover scripts. There are scripts that simply need to be recompiled but who has the time, skill, and software to do that.

false1 posted at 5:06PM Mon, 06 April 2020 - #4385570

Are addons considered scripts? That’s what I’m mostly concerned about.

Yes. Yes they are.

hborre posted at 5:06PM Mon, 06 April 2020 - #4385578

To be honest, I feel that the addon folder is just a redundant location for spillover scripts. There are scripts that simply need to be recompiled but who has the time, skill, and software to do that.

I don't think you know what Poser addons are…

I don't, just my opinion. But if you could elaborate on its purpose, I'm all ears.

hborre posted at 6:10PM Mon, 06 April 2020 - #4385587

I don't, just my opinion. But if you could elaborate on its purpose, I'm all ears.

Fair enough. A Poser addon is a Python script, and as such is subject to the same considerations as any other script with regard to the move to Python 3.

By virtue of its location in the special addons folder (and its adherence to certain conventions) it benefits from (a) automatically loading when Poser starts, (b) its user interface being managed by Poser, including its docked status and its location in each room and (c) access to parts of the Poser python API not readily available to regular scripts

It's certainly not perfect (addons can interfere with each other far too easily), but it's still a neat feature that I use a lot.

This is EZScene, the Poser addon I've been developing recently.

I can assure you it is neither redundant or merely a spillover script :)

Ah! So, as I understand, it will automatically load scripts without any intervention from the user. That is a convenient feature. It might explain some issues that I experience when resaving a scene from Poser. The script error window I get seems to flag scripts, particularly yours, installed in another Poser version I still use once in a while. I need to look into this further.