I changed the name of the Hair TransMap from "...Hair Displacement Map" to "...Hair TransMap" in order to match your terminolgy.  Yet, for both the first name and second name, VSS selected it  for the Bump Map.

Meanwhile, the actual bump map called, "...Body4Bump" was completely ignored. 

Even more strange, it placed the actual displacement map correctly (veins - although you can't see any in the final render) but that image's name is "...BodyBump0"

I know you love a good challenge.  Here it is.  What happened?

Quote - In case any of you understand Python, I'm just doing os.path.join(vssFolder, 'macro1.py') 

That is the official way to join folder names with file names.

Why is that not producing the desired outcome?

If you inspect "poserStartup.py" (location runtime/python/poserscripts), you may find the reason.
"Buttons" aren't started with Pythons function exec anymore. They are started via Posers build-in "ExecFile". This function accepts only ":" as path-delimeter.

Insteed of writing os.path.join( ... ), write:

path=":".join(("path 1", "path 2", "path 3"))

Thanks for the hint, adp001. I've got it working on my Mac now.

I replaced one line about halfway through the vssui.py script, near the end of "class Wacros(object)":-

this is the old line (commented out):

#call = os.path.join(vssFolder, self.pyfileFmt % (i+1))

this is the replacement:
 

call = ':'.join((':Runtime:Python:vss', self.pyfileFmt % (i+1)))

This uses a literal string for the vss folder. The folder variable vssFolder is no good here because it uses the os path separator ("/" in the case of Mac/Linux/Unix).

I don't know if this is a solution to the problem, or just something that works for Me'n'MyMac.
Hopefully it will help...

Izi

call = ':'.join((':Runtime:Python:vss', self.pyfileFmt.replace("/",":") % (i+1)))

may do the trick.

The second variable in the join is just the script filename. It contains no path separators that would need to be replaced. The script is located directly in the vss folder.

The new line that I gave before works fine, thanks to your previous hint, adp001.
:O)
Izi

Quote - The second variable in the join is just the script filename. It contains no path separators that would need to be replaced. The script is located directly in the vss folder.

The new line that I gave before works fine, thanks to your previous hint, adp001.
:O)
Izi

...then you should be able to put the vssFolder variable back in with:

call = os.path.join(vssFolder.replace("/",":"), self.pyfileFmt % (i+1))

..if I'm not mistaken :).

A good thought, Spanki, but the os.path.join method would insert a "/" before the script filename, and the resulting output would be:-

        :Applications:Poser 7:Runtime:Python:vss/macro1.py

Using the ":".join method together with your replace("/",":") method would give:

        :Applications:Poser 7:Runtime:Python:vss:macro1.py

Not sure if that would work..... in any case, I don't think we really need to use the vssFolder variable at all in this line of code, but bb might be able to clarify that when he is back.

Izipizithepythonprentice
I hate snakes

The rule is: Don't use os.path.join( ... ) when creating pathes for "Poser-Python-Buttons". Buttons are executed via poser.ExecFile( ... ). This functions needs colon-seperated pathes on all plattforms.

os.path.join( .. ) seperates pathes with what is stored in os.sep. This is mostly "/" in newer Python versions, because this Unix like path-seperator is known by allmost any OS.

Ahh - I'm not terribly familiar with Python classes, so that was a guess... but it sounds like this would work then:

call = ':'.join(vssFolder<font face="Courier New">.replace("/",":")</font>,
self.pyfileFmt % (i+1))<br></br>

...in place of the original line:

call = os.path.join(vssFolder, self.pyfileFmt %
(i+1))<br></br>

...I hadn't looked at that code, but I think BB was trying to account for the folder being in various places on some user's system, so the path is built up into that vssFolder variable.

...erm, listen to ADP, not me :).  He's the Python guru here.

In the above picture, I entered a new Displacement Value and image into the VSS prop.

I ran Macro1 and the value got transfer correctly, but it seems because there was already an image map plugged in, it did not replace it with my new desired one. 

I would think the "Control Prop" would take precedence. 

If I don't add a map to the VSS prop, don't touch the one that's already in my figure.  But, if I do add a new map - then replace any that are already there with the new one.

Are there more reasons than not why we wouldn't want this rule?

BB, where are you?  Hope all is well.  And if so, I need you.  I have many items for you to look at .

Sorry - I'm around, just really busy at work. :)

I read the recent posts. Very interesting about the path separator. I'm trying to understand what I really should do about it. I don't want to use a "poser" style portable path, since that only works if the item is in your runtime. The whole point of what I was trying to do was that you don't have to put my scripts in any runtime whatsoever, let alone the main runtime.

With regard to the replaced displacement map:

My intention was that if the target shader already had a map, it should use that one. The idea that the template shader actually has maps in it that should take precedence seems slightly wrong to me. Here's why. We have a template for all skin in Template Skin. That includes face skin, lip skin, etc. How can you put a body displacement map into the Template shader and expect it to be used correctly for the face? It would not. The target shader is supposed to supply all the maps.

However, I have included in the design of VSS that there are distinct map templates, for the different UV zones. I have not shown anybody how to use these, but the feature exists. So the idea is, the Template Shaders define the shaders - skin, eyewhite, cornea, etc. These are the various material models. The maps that control them, such as diffuse color, specular amount, displacement, bump, etc. are coming from your target figure at the moment. However, if we enable the Map templates in the prop, then the target figure does not define anything at all. VSS would then combine a set of shader nodes, and a UV area specific set of image maps, to build each particular target shader.

This way, you can use the prop to control both the shader model, and the control maps if you want. For the time being, I was only showing everybody the easy one-click solution. The assumption in this case is you pre-load the target figure with colors and bumps using existing mat-pose files or whatever, and then VSS rewrites the shaders.

For tricky complicated maps, such as a vein displacement map, and a hair map, and a suntan map, which may all need to be used at the same time, we'd want to use the Map template scheme.

Does that make sense?

What are your new questions?

Forgot to mention, looking at the last posted screen shots, somehow the color map got mixed into the displacement logic. I don't know how that happened, unless you pre-loaded the figure with a shader that was using the color map as a displacement map. That is a bad idea, if it was the case, as it confuses VSS very badly as to what the heck that map is for.

Quote - A good thought, Spanki, but the os.path.join method would insert a "/" before the script filename, and the resulting output would be:-

        :Applications:Poser 7:Runtime:Python:vss/macro1.py

Using the ":".join method together with your replace("/",":") method would give:

        :Applications:Poser 7:Runtime:Python:vss:macro1.py

Not sure if that would work..... in any case, I don't think we really need to use the vssFolder variable at all in this line of code, but bb might be able to clarify that when he is back.

Izipizithepythonprentice
I hate snakes

I'm still reading through all this very carefully.

However, we do need to use the vssFolder variable, unless we are willing to give up arbitrary location compatibility. My goal was that I should not care whether the vssFolder is actually in your main runtime, some external runtime, or not a runtime at all. That's the goal, anyway. On PC it works perfectly. On MAC Poser 6 it works perfectly.

It is only Mac Poser 7 that does not. I'm not sure I fully understand why not, but it looks like a Poser bug in my opinion. The documentation does not claim anything that requires we place python scripts in the runtime, right? It doesn't claim that we must NOT use our OS-specific path naming format, does it?

Another thought I have is to give up the Poser Python and Wacro buttons altogether, and use something else. If Poser had a decent GUI API, I'd be there already. I've had a couple conversations with SM:Poser guys about this. I love those guys - very open to my opinions. But they are actually a pretty small group of engineers, and there's soooo much to do. They can't get around to all the stuff I want.

I've made the suggestion several times that I'd be interested in fixing some of these issues FOR FREE, if only they'd give me the source code. They haven't taken me up on it.

I posted a note about this, then I had a re-read and a re-think and deleted it.
Still thinking, bear with me. I may have to do some testing over the next day or two....
:O)

RE: replacing displacement maps.  2 kinds: Head & body

Dang!  That's actually a good reason for not having the option of replacing what's in the control prop with what already exists.

Although, most models have separate head and body maps.  Would it be possible to add an extra option to ask whether "head",  "Body" or "All" when changing out maps?  (I know nothing of python - just throwing things at the wall to see if anything sticks)  It would certainly make your VSS even MORE versatile!

As far as having a Texture Map hooked up for Displacement, I didn't check to see if the pre-existing character was set up that way.  I'll check it out tonight when I get home.

Also, pre-existing characters with AMUCFS loaded don't fall into the correct positions once VSS is applied.  I post examples later tonight when I get home.

AMUCFS is way too complicated. It has two color maps loaded for skin, and four color maps loaded for eyes. Such multiple color maps cannot be assumed are just for ethnic blending, as I've done in AMUCFS. Plus it has the hair map. A hair map is not something I can automatically detect, with regard to its purpose.

See, the way VSS detects what a map is for, is to look at what it ultimately plugs into. For example, its a good bet that the Diffuse Color Map is eventually plugged into Diffuse_Color, or into a Diffuse type of node in its color parameter.

Similarly, a map plugged eventually into the Bump channel must be a bump map.

But when a map is, for example, plugged into the Blending value of a Blender node - I have no idea what it's for. Building artificial intelligence into VSS to fully diagnose the purpose served by your various control maps is pretty much impossible. How would you tell, for example, that such a map, controlling a Blender, is which of the following (since they all are used this way)

Suntan map (defines tan lines from a bathing suit)
Lip gloss map (defines where lip gloss effect goes on a face)
Eyeshadow map (defines where eye shadow goes on eyelids on a face)
Blush map (defines where blush goes on cheeks)
Freckle map (defines the strength or size of freckles on face or body)
Hair map (defines where small hairs are, such as eyebrows, or arm hair, or chest hair)
Stocking map (defines where to apply a second-skin stocking effect to legs)
Tatoo map (defines where a tatoo is applied)

See what I mean? These all look the same, from the point of view of analyzing what is plugged into what.

So to handle any kind of non-standard maps, we are going to have to use Map templates. We'll get there. You are a pretty advanced user, and will find the power of the full VSS to be very helpful. In the short term, though, I'm just trying to get the basics going for your average Poser user.

I hope to eliminate all evidence of plastic skin and nostril glow from the Poserverse.

I can't tell you how many product promos I look at, and I'm just embarrassed for the author. It's terrible what people publish and think it's good stuff.

Quote -
Another thought I have is to give up the Poser Python and Wacro buttons altogether, and use something else. If Poser had a decent GUI API, I'd be there already.

It's possible to use a GUI of your choice if you use IPC (Inter Process Communication). Up to a Javascript scriptable Webpage ("Ajax"). I've done this allready years ago. In my version IPC works in "non-blocking" mode. Means, IPC-communication works in background (with all Poser versions >= 5). Even other Python scripts may be started as usual without breaking IPC.

Quote -
It is only Mac Poser 7 that does not. I'm not sure I fully understand why not, but it looks like a Poser bug in my opinion.

Versions before 7 are using Pythons standard ExecFile() to execute buttons and things.
Version 7 and up uses poser.ExecFile()

ADP:

What you've said is very interesting to me. I've already developed a number of web-based scripts for Poser, using a server I wrote (similar to yours) and using Ajax on the client side. It works very nicely and is extremely easy to program.

My question (and problem) is the "blocking" aspect. In particular, while my server script is running, Poser won't run any other scripts. How did you get it to be 100% in the background?

I did have some success setting it up as another thread. However, the server-side could not do any Poser scene calls then, because they are not thread safe. When I tried it, Poser crashed.

I also tried setting the server side up so that it uses the background scene callback. I registered a callback and Poser calls it like 10 times a second, which is good enough to respond to Ajax requests, and does not cause threading issues. However, when the Poser application does not have the focus, it no longer calls the background scene callback. Thus, the server becomes dead if another application has the focus. In particular, if the browser has the focus, then Poser won't answer the browser Ajax requests.

I've also tried putting up a Tk dialog and using Tk's background callback, but that seems really ugly. I want the server to run forever, not just while some bogus dialog is up.

How the heck did you set up the background service that let's Poser think there's no longer a script running, and still calls your code frequently enough to service the Ajax requests?

Quote - > Quote -

It is only Mac Poser 7 that does not. I'm not sure I fully understand why not, but it looks like a Poser bug in my opinion.

Versions before 7 are using Pythons standard ExecFile() to execute buttons and things.
Version 7 and up uses poser.ExecFile()

Certainly, but that does not explain why slashes are OK in Windows, but not in Macintosh.

Native filespecs still work on Windows. Why not on Mac?

BB, that MAT set-up that used the body map as a displacement map was Jepe's Dick AM VI - one of his older products. 

Luckily, we already know all Jepe's future products will most likely be VSS compatible.

VSS put the second skin map into the diffuse node. 

It grabbed the "Hair TransMap" and placed it in the Bump Map.

It got the Displacement Map correct.

It ignored the Bump Map and the second Displacement Map - not sure what that one's about.

Before reading your recent posts about how the VSS looks and sees what is plugged into where, I assumed that it looked for map names and placed them accordingly. 

I thought you were on the brink of standardizing the whole Poser system of naming conventions for MAT products.

Alas, I guess not.

First image is AMUCFS 1 click with RT&AO (although, I think you mentioned somewhere in this 25 page long thread that you had turned off the AO?)

Second image is 1 click VSS.  As shown in the post above, the "HairTransMap" was used as a Bump Map.  You can see in the second image, the "bump" of hairs on his skin.

Last image is VSS adjusted.  The "Bump Map" was added in correctly (manually to all body skin material zones) then I used the VSS Control Prop to Increase the bump to .004 and displacement to .03

I know you're working on the basics, but if you find the time to show how to hook up a HairTransMap....

Quote - Regarding switching AMUCFS to VSS:

VSS put the second skin map into the diffuse node. 

...

My bad!  You can't add a map to this node. 

The original map is now shaded differently.

bb - can you confirm that the value given to the variable 'vssFolder' on a PC Poser 7 install is the full path (i.e. beginning with the drive root, such as C:) and uses "/" as the path delimiter? Thanks.

adp001 - if my assumption above is correct, do you have any thoughts why the VSS buttons work with Poser 7 on a PC, when they have paths that use "/" as a path delimiter? This would seem to conflict with the Poser ExecFile function only accepting ":" as a path delimiter. Or is it possible that a Poser 7 install on a PC does NOT use the built-in Poser ExecFile, while on a Mac it does. Thank you.

I'll get to the bottom of this if it k

(edit) oops, I missed bb's last one...

Quote -

Certainly, but that does not explain why slashes are OK in Windows, but not in Macintosh.

Native filespecs still work on Windows. Why not on Mac?

Because S+M programmed something wrong in this method? The basic Python libs are very well tested in the meantime and work on Mac (yes, you said allready it must be an error in Poser-Python).

Quote -

I did have some success setting it up as another thread. However, the server-side could not do any Poser scene calls then, because they are not thread safe. When I tried it, Poser crashed.

Threading with Poser-Python < version 7?

Quote -
I've also tried putting up a Tk dialog and using Tk's background callback, but that seems really ugly. I want the server to run forever, not just while some bogus dialog is up.

Even in version 7, threading is broken. Look into the threading module. It's not original (not in Windows, don't know for Macs). The whole implemented Python isn't original. Some libs simply won't work, other may or may not. Mostly those libs where threads are required.

On the other side, any usermade python script is executed in the same "frame". Means also, all variables are left for the next script. The interpreter isn't reset. That's bad for standard things, but fine if you want to do some tricks :)

The good news: Threading isn't required to serve a few calls from the outside world. Use a three-thier model (GUI to Interact with user - server in the middle as consumer - Poser as factory). So Poser needs only a small communication part and a small resolver. The rest can be done inside the server - in any programming language (even on another machine if RPC is implemented on top of IPC).

For the script running in Poser, don't use the higher level Python libs for IPC and keep it small and simple. This script has only 2 things to do: waiting for questions/commands from the server and respond with a result or errormessage.

The trick with the eventloop is: Think the other way around.
The normal way: Poser calls your script (Poser does nothing until your script returns), then your script waits for Poser to get some processing-time again (via TK or an poserevent).

My way: As soon as my script is called the first time, it enters an endless "blocking-loop". Inside this loop the incomming/outgoing ports are scanned, than Poser is called.

while True : if shouldstop: break # incomming data has higher priority if checkIPCinWaiting() : processIncommingData() elif checkIPCoutWaiting() : processOutgoingData() poser.ProcessSomeEvents(10) time.wait(0.001)

This simple loop makes sure Poser runs as usual but the script doesn't loose control. There may be delays, especially if Poser renders. But this is something you can't avoid anyway. The middle part (the server) should handle such issues. Anytime the script has to wait for in- or output (while receiving or sending), Poser should be called via ProcessSomeEvents() to let Poser run as smoothly as possibe.

checkIPCinWaiting and checkIPCoutWaiting must use low-level network calls to avoid the script is blocked until a network-timeout occures (Poser 5 is the biggest problem here).

By the way: time.wait() is used to give other apps more time to run (even the GUI and the serverpart).

It's possible to use UDP insteed of TCP for communication between server and Poser. The needed overhead for the required protocol is small, because the Poser script acts synchron-seriell (first-in, first-out)

bb - I gather from what adp001 says (Jul 8 8:07pm) that we can't do anything about the Mac/Poser 7 buttons problem. So I'll just try out VSS with my own fix for the buttons. I'd like to do the same with Matmatic (which is where I started with all this), but one thing at a time...

All the other deep stuff here is of no use/interest to a Poser noob like me, so I'll drop this thread now. :O)

If you would like me to try anything else on my system, please IM me - I'd be glad to help if I can.

Izi

Quote - Comparison of AMUCFS to VSS.

First image is AMUCFS 1 click with RT&AO (although, I think you mentioned somewhere in this 25 page long thread that you had turned off the AO?)

Second image is 1 click VSS.  As shown in the post above, the "HairTransMap" was used as a Bump Map.  You can see in the second image, the "bump" of hairs on his skin.

Last image is VSS adjusted.  The "Bump Map" was added in correctly (manually to all body skin material zones) then I used the VSS Control Prop to Increase the bump to .004 and displacement to .03

I know you're working on the basics, but if you find the time to show how to hook up a HairTransMap....

is this apollo maximus? the body looks different

adp:

Thank you for taking the time to explain how to write the server, but as I've said, I already implemented a server and had no trouble with that. What I wrote is sort of like a Java servlet engine, but the servlets are written in Python. I call it PASer (Poser Application Server). I have already written a dozen servlets for various purposes. The most used one is a light panel that puts together a nice web page GUI to control all the light parameters and shadow settings. I know how to do network I/O in a non-blocking way, and how to write client/server software, or browser/appserver software. I do all these things for a living.

What I was asking about was the blocking aspect of your service loop.

Earlier you wrote:

"In my version IPC works in "non-blocking" mode. Means, IPC-communication works in background (with all Poser versions >= 5). Even other Python scripts may be started as usual without breaking IPC."

but then later you wrote:

"As soon as my script is called the first time, it enters an endless "blocking-loop"."

That is the contradiction and the specific issue I'm struggling with. As I wrote earlier, I tried several techniques for getting control and servicing my browser requests. The only one that worked well is the blocking-loop, precisely what you showed in your last post.

But that is very much NOT going to let other Python scripts be started by Poser. Poser (rightly) believes that my main Paser script is still running, and refuses to launch any other Python scripts. Users will find this not very friendly and will get confused. In fact, I've seen this confusion recently. Look at this thread:

http://www.renderosity.com/mod/forumpro/showthread.php?message_id=3263103

Mathman was complaining that a wacro didn't do anything for him. It took him quite a while to realize it had nothing to do with the wacro. The problem was he had a PRPC daemon running and had forgotten about it. The PRPC daemon uses the same "blocking" loop strategy, which prevents Poser from running any other scripts. When you push a script button or menu item, Poser doesn't tell you why it is refusing - it simply doesn't do anything.

One solution I had to this was to add the ability to run scripts from within Paser. This means the user can still run scripts - but cannot run them from the Poser GUI. They must be invoked from the Paser script browser pages. This is OK I guess. But consider this:

Suppose the user is already running Paser, which is uses a blocking loop as above. Now this user runs YOUR server daemon, which goes into its own blocking loop. My loop is now halted, until your loop exits!

This would be a terribly complicated and confusing situation. The user will not understand why Paser pages (serviced by my loop) stop working while your server is running.

This is the reason I asked you how the heck you made it non-blocking. But then your answer was that you actually made it blocking. I'm not following that.

What we really should do is establish a standard, whereby we all share a common service loop that we agree to install and run exactly once. Then all of us write our little background activities and servlets under the assumption that we can all share the same blocking loop.

IsaoShi:

In answer to your recent question about the vssFolder value...

Last week I asked you to show me all the output. You said there wasn't anything before the button info. I don't understand that, because I print out several lines of path info at the top.

Here's what I see from VSS on Poser Pro on my laptop:

appLocation C:Program FilesSmith MicroPoser ProPoserPro.exe
appFolder C:Program FilesSmith MicroPoser Pro
scriptLocation C:Documents and SettingsbagginsDesktopMyPoserStuffvssRuntimePythonvssvssMainButtons.py
mainPython C:Program FilesSmith MicroPoser ProRuntimePython
vssFolder C:Documents and SettingsbagginsDesktopMyPoserStuffvssRuntimePythonvss

script button 1: 'Synchronize'
       invokes: 'C:Documents and SettingsbagginsDesktopMyPoserStuffvssRuntimePythonvssmacro1.py'
script button 2: 'Render'
       invokes: 'C:Documents and SettingsbagginsDesktopMyPoserStuffvssRuntimePythonvssmacro2.py'
script button 3: 'Designer...'
       invokes: 'C:Documents and SettingsbagginsDesktopMyPoserStuffvssRuntimePythonvssmacro3.py'
script button 4: 'Parmatic...'
       invokes: 'C:Documents and SettingsbagginsDesktopMyPoserStuffvssRuntimePythonvssmacro4.py'
script button 10: 'Poser Main Buttons'
       invokes: ':Runtime:Python:poserscripts:mainButtons.py'
 

I have a desktop folder called MyPoserStuff. I keep my own code and data there for handy access right from my desktop. Inside that, is an external runtime for vss. As you can see, Poser is quite happy with this arrangement, and all of the paths are real Windows paths. I got those paths by asking Poser where I'm running from. That's what the variables appLocation, appFolder, scriptLocation, mainPython, and vssFolder are showing. These are all the important pieces of information necessary to assemble correct paths.

Quote - Before reading your recent posts about how the VSS looks and sees what is plugged into where, I assumed that it looked for map names and placed them accordingly. 

I thought you were on the brink of standardizing the whole Poser system of naming conventions for MAT products.

Alas, I guess not.

 
Actually I am trying to standardize the names. The what-is-plugged-into-what strategy is only for the case that we are using VSS in the one-click way. This situation demands that I analyze the target figure's existing shaders, and deduce the purpose of each image map.

On the other hand, when we switch to using map templates, the purpose of each will be explicitly and exactly based on the standardized names. You will not have to connect the maps to anything to set up a map template. You will simply identify the files you want to use.

The reason I did not offer this yet, is related to all this other talk about the buttons not working, and about how to do a nice and sophisticated graphical user interface. I do not want you to have to faff about manually adding image map nodes and setting the names.

Here is my plan:

You load a control prop that has various more complicated shaders.

Some of these shaders are partial shaders. They add on to other shaders. For example, we can have one that does body hair, and this partial shader is written by itself as a template. It does not get mixed into the skin shader by you. That mixing and assembling will be done by VSS, where you get to load a skin shader, a hair shader, and suntan lines shader, a tatoo shader, etc.

VSS will scan all these shader templates and figure out what control map image files you'll need.

You tell VSS you want to fill in the control map files. It builds you a nice GUI, tailored to the actual shaders you have loaded.

You then use the GUI to assign images to each named map, once per UV zone. For example, for a James or Jessi, there are only two UV zones - head and body. So you would fill in two maps for each effect. On the other hand, V4 has 7 UV zones. You would fill in up to 7 maps for each effect. However, V4 eye shaders probably won't need a hair map. (LOL) So VSS would know that, and not even ask you what hair map you want for the eyes.

After you fill in all the map file names (using browse buttons of course), then VSS will store all that information in the control prop, inside the special materials whose purpose is to keep track of the map templates.

Once you have such a control prop set up for a particular figure, you can save it. For example, you'd save one for Apollo, that includes all the pre-defined map assignments based on all the effects you've chosen to use as well as all the files you've already selected.

In the future, you could load the prop, and then if you wanted to just change the hair map, you'd bring up the GUI again, and select new files for hair maps, leaving all the others alone.

That's the plan. But until I get the GUI crap worked out, the only way to use the UV map template features would be for you to tediously create a map zone for each of the UV sections, and then manually populate them with Image_Map nodes, rename them by hand, and then load the desired image into each. This would be a very lengthy and error-prone process that I really don't want to advocate or support. I'd rather have VSS take care of it all behind the scenes, and just give you a nice clean GUI to fill out.

It works if you wrap anything into a class.

import poser
import time

class test(object):
    def __init__(self):
        pass
    def main(self):
        t=time.time()
        while 1:
            poser.Scene().ProcessSomeEvents(10)
            if t +10 > time.time() :
                t=time.time()
                print t
        
t=test()
t.main()

Here is the output. I started "Inventory". As you can see, Iventory does it's job and the output continues.

1215613654.8
1215613655.39
1215613655.65
1215613655.88
1215613656.39
.RuntimePythonposerScriptsMaterialModsset_mats.py was successfully created.
Open it to view material inventory.  Modify and run it to set materials.

1215613657.63
1215613657.86

Thanks bb. As I said before, I did exactly as you asked and showed you all the output that I received when I ran the mainButton script. I took lots of time about it and was very careful to describe in this thread every step of what I did, and every output from it. I'm sorry if you don't understand that, but it's the truth. :O)

It may be because the current location of my vss folder (in the appFolder/Runtime/Python folder) means that it is skipping the part of the code that contains the variable print statements. I'm at work now and I don't have the code in front of me, but I seem to remember that the print statements were in the 'hackpath' section of the code. I'll check that later at home. I'll try the vss folder in a different location away from the Poser 7 folder, to see what happens then.

During testing (after my initial report) I inserted variable print statements into the mainButtons script, immediately after the hackpath section. I can send you that output too, if you want, although it doesn't tell us anything that we don't already know.

(edit) It's occurred to me that the download I got was only the vssui.py script, not the mainButtons script. Where are those variable print statements located in your version?

Ok, won't work with P7.
I wrote this some years ago for P5/P6. Seems that P7 has more differences in Python than I thought :((

Quote - Thanks bb. As I said before, I did exactly as you asked and showed you all the output that I received when I ran the mainButton script.
....
(edit) It's occurred to me that the download I got was only the vssui.py script, not the mainButtons script. Where are those variable print statements located in your version?

Bingo. Sorry, sorry! I'm an idiot.

Those things are set and printed in mainButtons. I have a modified copy that I didn't give you. You are totally correct. My bad.

Here is the change, if you want to see those variables like I see them. I've included a small bit of before and after, and the changes are in bold.

if mainPython not in sys.path:
 sys.path.insert(0, mainPython) if vssFolder not in sys.path:
 sys.path.insert(0, vssFolder)

print 'appLocation',appLocation
print 'appFolder',appFolder
print 'scriptLocation',scriptLocation
print 'mainPython',mainPython
print 'vssFolder',vssFolder
print

import vss
vss.appLocation = appLocation
vss.appFolder = appFolder
vss.scriptLocation = scriptLocation
vss.mainPython = mainPython
vss.vssFolder = vssFolder
reload(vss)
import vssui
reload(vssui)
vssui.macros.show()

Quote - Ok, won't work with P7.
I wrote this some years ago for P5/P6. Seems that P7 has more differences in Python than I thought :((

Yay, thanks for checking that ADP. I thought I was losing my mind.

Quote - > Quote - Comparison of AMUCFS to VSS.....

is this apollo maximus? the body looks different

Yes, I originally used Jepe's DICK AM VI cr2 to open Apollo.  The I added the AMUCFS MAT afterwords.  The Texture maps were replaced but the morphs remained.

Quote - Actually I am trying to standardize the names...when we switch to using map templates, the purpose of each will be explicitly and exactly based on the standardized names.

You will not have to connect the maps to anything to set up a map template. You will simply identify the files you want to use.

... VSS (will) take care of it all behind the scenes, and just give you a nice clean GUI to fill out.

Fantastic!  Can I have this NOW!

Seriously, you're throwing around a $20 price but I'm telling you I'd paid more.

You know I was blown away by your AMUCFS and always hoped one day I would be able to figure out how to adapt it to other models.  VSS is the answer to my prayers!

Now if you guys can just get all this Python crap worked out - my head is spinning trying to understand what the heck you're all talking about.

Poser is replacing the "/" delimiters in the path that we assigned to the button with colons. You said "(I don't want to use a "poser" style portable path), since that only works if the item is in your runtime." There we have it, I think.  

I presume that the Windows "" path-delimiter does not get replaced in this way, which is why it works on PCs.

The next step is to determine at what point this is being done... when the path is assigned to the button, or when the button is clicked. but I'm not sure how to go about doing this. In any case, it's a Poser Python bug for sure.

Uhhh, wait. If you clicked the Synchronize button and it ran it, isn't that because you hacked your copy to use colons? You're saying in your last post that Poser changed the slashes to colons, but didn't you do that to your copy of vss?

I should have made it clear that I was testing your original code again, to give the output that you first expected. The Synchronise/Render/Designer buttons do not run anything, they only change the text in the title bar on the output window when pressed.

Fascinating! Sorry I did not understand before.

So pushing the button loads what Poser thinks is the configured path into the title bar. And we see colons, even though we used slashes. Now I think I understand the bug.

In slash notation, a leading slash indicates an absolute path.

In colon notation, a leading colon indicates a relative path.

When Poser changed the slashes to colons, it completely changed the interpretation of the path! In converting to colon format, it should have REMOVED the leading colon. This is a bad bug.

Now - what do I do about it? Try this as a test.

In your copy, change the code so that the path you stick into the button has the first character removed.  Open up vssui.py. Locate the class Wacros. Look in the show method. At the end of the os.path.join(vssFolder line, put [1:]

It should look like this - with the addition in bold below

 def show(self):
  for i in xrange(10):
   text = self.text[i]
   if text is None:
    text = self.emptyText
   call = self.functions[i]
   if call is None:
    call = ''
   elif not isinstance(call, basestring):
    call = os.path.join(vssFolder, self.pyfileFmt % (i+1))[1:]
   self.applyToPoser(i+1, call, text)

Then see if the buttons work.

You said that using the colon separator would only work for things in your Poser Runtime - in which case this result is just what we would expect.

That's not your main runtime?

Okay, bb, I got to the bottom of the problem and I have it working using the vssFolder variable. The following line of code works on my Mac (but it won't work on a PC):

call = os.path.join(vssFolder, self.pyfileFmt % (i+1)).replace("/",":")[1:]

On a Mac, it is necessary to use ":" as the path delimiter for defining buttons - we can't use "/". It is true that Poser 7 converts any "/" it finds into ":", but then it expects to find a file by that name including the ":" characters - i.e. it treats each "/" that it has converted into a ":" as part of the filename, instead of a path delimiter. Crazy.

Clearly the above code won't work on a PC because I am dropping the first character in order to convert it to an absolute path using the ":" delimiter. We could insert an if-else condition: if the first character of vssFolder is "/" use the above line of code, otherwise use the original line...  but I can't think any more about it right now as it's past 2am here and I have to get up at 7.

Fantastic script and renders 

I try the VSS Script with the German Poser Version and have an error. Have the Script a problem with the German Poser? Sorry for my bad english.

bb - the following code in vssui.py works on Mac / Poser 7 and should still work on PC (any Poser version). The first line is the commented-out original:

#call = os.path.join(vssFolder, self.pyfileFmt % (i+1))
call = os.path.join(vssFolder, self.pyfileFmt % (i+1)).replace("/",":")

if call[:1] == ':' : call = call[1:]

I've tested this with the vss folder in another location (outside of any Runtime) and it works fine.

Someone will need to test that this still works okay on Mac / Poser 5/6.

Quote - I try the VSS Script with the German Poser Version and have an error. Have the Script a problem with the German Poser?

 
Hi Soni.

I am surprised yet again. Apparently, actor names can be translated by Poser. I learned also a while back that material zone names are translated.

This is a mystery to me. You do not have a special German version of Victoria4, right? Which means that Poser has decided to translate "Body" into some German word. If it didn't, I would expect that MAT pose files, material collections, etc. would not work for you.

So why does Poser tell VSS there is no actor named Body? Clearly there is, because you have the same figure that I have. Hmmm.

I'll have to look into the Python interface again. There may be a way to locate the actor by internal name.