GoW PyPRP 1.6.0 Beta 2 released

[D'Lanor]

kk, I've noticed another difference with 1.6.0 with the visregions:

Prior to your new release, pyprp didn't care what page the visregion was on to affect the objects for it. NOW it does. The visregion that affects Object X, must be on the same page_num as Object X, else it won't work correctly.

I've changed the Vis Regions tutorial over at the GoMa Age Creation Tutorials section. I looked, but I'm not finding a Vis Regions tutorial on the GoW's Wiki, only the Soft Volumes explination (which needs to be edited now).

The Soft Volumes wiki has a visregions section, which has already been updated for inverted visregions.

At least that is what it says under the history tab.

[Christian Walther]

Just a suggestion, as it's been suggested before, but you need to get people's attention a bit better on how 1.6 installs different than the previous versions of pyprp. I suggest editing your very first post, and use large, bold sentence at the beginning...

Sigh... I hate screaming at people, but if you insist...

Also, make sure everyone knows that if they install the new version of Blender, they will have to make sure they install Python 2.6.2 (Blender got upset with me about that).

Another thing that would seem self-evident to me. There's even a bold note about it on the install page. Would adding the following sentence be sufficient clarification?
PyPRP 1.6 also works with some older versions of Blender (before 2.49a) and Python (before 2.6), but make sure that your Blender, Python, PyYAML, and PIL match!

Now I've got to go in and change ALL of my scripting for visregions now.....sigh.

Sorry about that, but the previous behavior (automatically setting the kIsNot flag everywhere) was just broken, and we preferred to fix it as long as you are the only one who uses visregions . If it's too much work for you and you don't need it fixed immediately, you may want to wait until you manage to talk one of us into providing a way to specify visregion flags explicitly so that you could put the kIsNot flag back.

kk, I've noticed another difference with 1.6.0 with the visregions:

Prior to your new release, pyprp didn't care what page the visregion was on to affect the objects for it. NOW it does. The visregion that affects Object X, must be on the same page_num as Object X, else it won't work correctly.

I am not aware of any such change. Will have to investigate.

I looked, but I'm not finding a Vis Regions tutorial on the GoW's Wiki, only the Soft Volumes explination.

That is correct, as far as I'm aware. There is no tutorial, only a reference (that D'Lanor links to).

[andylegate]

Another thing that would seem self-evident to me. There's even a bold note about it on the install page. Would adding the following sentence be sufficient clarification?
PyPRP 1.6 also works with some older versions of Blender (before 2.49a) and Python (before 2.6), but make sure that your Blender, Python, PyYAML, and PIL match!

Just keep in mind that when something might seem self-evident to you, does not mean it will always be self-evident to others. Up until today, I've been using Blender 2.48 with the old 1.5.0 plugin. When I downloaded the new plugin, I didn't bother to read any instructions. Why bother? It's just going to be like all the other plugins since 0.5, right?

But of course it wasn't, it was different this time (and makes more since to have it's own folder too, good job!), but it has been the same way for so long that people (like me) just got used to it and assumed. I quickly figured it out, but others might end up tearing their hair out trying to figure out what's wrong.

I had no idea that I would have to download and reinstall everything again this time around, as I just quickly grabbed things and tried to get going (as you may have guessed, I'm one of those people that grab something out of the box, and through the manual over my shoulder and just start plugging in wires and pushing buttons, hehe.....then start digging for the manual when things go wrong.).

Serene exported just fine with the new plugin, and once I changed the other visregion and give it the same page number as the objects it was affecting, everything went back to normal. As far as having to change all the alcscripting for the visregion, no biggy, I just pasted it into my word program, and had it replace all the text for me, then copied it back into Blender, took less than 2 minutes.

[D'Lanor]

You are right Andy. It is not self evident at all. Blender's own release management made a mess of the Python versions. Beats me why they went from Python 2.5 in 2.49 to Python 2.6 in 2.49a. Especially since Blender 2.5 is already in the works and will be based on Python 3.0.

When I updated the PyPRP installation page on the wiki from Blender 2.48a I deliberately pointed everything to Blender 2.49 and Python 2.5.4. There are AFAIK no fixes that we need in 2.49a so I figured it would only cause confusion. But then Robert updated the links to Blender 2.49a and Python 2.6.2. IMO this was not necessary but hey, it's a wiki. Everyone here can do with it as they see fit.

[Jojon]

Humm... kind of odd.. Here, I had to keep visregions on the same page as the objects they affect (couldn't even make a cross-page reference), with the old plugin as well... Of course, only place I had used them at the time was Ahra Pahts, which may mean some special situation... :7

[Christian Walther]

Just keep in mind that when something might seem self-evident to you, does not mean it will always be self-evident to others.

I know, but I'm kinda helpless about what to do about it...

(as you may have guessed, I'm one of those people that grab something out of the box, and through the manual over my shoulder and just start plugging in wires and pushing buttons, hehe.....then start digging for the manual when things go wrong.)

Nothing wrong with that attitude, as long as you do use the manual when things go wrong, rather than complaining to the manufacturer. The problem are the people who think they know what they're doing, but get it wrong, and then come and complain. That is what's hard to prevent. The easiest way out is to say it's their own fault and ignore them, but that's not a very satisfying solution.

Since you just quoted my question but didn't answer it, I have just gone ahead and added the proposed sentence to the install page. Feel free to edit, anyone, if you have any clarifications or think it creates even more confusion.

Prior to your new release, pyprp didn't care what page the visregion was on to affect the objects for it. NOW it does. The visregion that affects Object X, must be on the same page_num as Object X, else it won't work correctly.

I am not aware of any such change. Will have to investigate.

OK, we indeed had a whole bunch of bugs in that department. For one of them, we have even talked about the fix before. I have committed some fixes (r440-442), if you'd like to test them, get
http://svn.guildofwriters.com/pyprp/branches/1.6/PyPRP/prp_RefParser.py
http://svn.guildofwriters.com/pyprp/branches/1.6/PyPRP/prp_Export.py
http://svn.guildofwriters.com/pyprp/branches/1.6/PyPRP/prp_ResManager.py
http://svn.guildofwriters.com/pyprp/branches/1.6/PyPRP/prp_Classes.py
and substitute them for the existing files.

Unless anyone finds any serious problems with these commits, I'm still planning to package up the final release tomorrow.

However, as far as I can see, these bugs have been there since the beginning of time, so I don't understand why this would have worked in 1.5 (as Jojon mentions). Perhaps your situation is a completely different one than the one I fixed? On what page is your object, on what page your softvolume, and what do their AlcScripts look like? My test case (that works now, but didn't before) has

Code: Select all

SoftVolTest1:
    type: softvolume
    softvolume:
      - type: convex
        softdist: 10
        instrength: 0.1
        outstrength: 1.0

SVTestOcta:
    visual:
        visregions:
          - softvolume:SoftVolTest1@Other

where SoftVolTest1 is on page 1 ("Other"), and SVTestOcta is on page 0 ("mainRoom").

[D'Lanor]

Unless anyone finds any serious problems with these commits, I'm still planning to package up the final release tomorrow.

• No problem with those but can you merge my prp_SndClasses.py fix from rev. 439 into the final? See description here.
  
• I am not sure about the modification of the waveset geostate defaults in that same revision yet. We have had 3 testers so far but I suspect that they all used the default texstate setting. So basically that still counts as one result. I guess this one has to wait. Although it is a big issue for some people.

[Christian Walther]

I am not sure about the modification of the waveset geostate defaults in that same revision yet. We have had 3 testers so far but I suspect that they all used the default texstate setting. So basically that still counts as one result. I guess this one has to wait. Although it is a big issue for some people.

I'd vote for leaving that out of the 1.6.0 release too. There are some other open issues like the sphere bounds, so we can probably do a 1.6.1 release containing these things relatively soon.

[dendwaler]

Its well known that every object must have a material assigned before exporting.

...... even when exporting an empty mesh!

Should this not be an exception?

[Lontahv]

Why export empty meshes? Why not use Empty objects?