Is it time for a new PyPRP release?

[D'Lanor]

OK, I've had a look at it and will merge it. Random observations:

• Code: Select all

  --- prp_RefParser.py    (.../trunk/src/prp_RefParser.py)        (revision 420)
+++ prp_RefParser.py    (.../contrib/D'Lanor/prp_RefParser.py)  (revision 421)
@@ -161,7 +163,7 @@
  #                       print "Error decoding keytype:",type_id
                         return None
 
-                    return { 'type': keytype, "name": name,"pagename": None }
+                    return { 'type': keytype, "name": name,"pagename": pagename }
 
                 else:
                     return None


  
  This change looks unrelated to my untrained eye (I haven't checked what it actually does). It's from /contrib/Dox/prp_RefParser.py r337, probably a bugfix. Is it intended, and safe?
  

That one must have slipped through. Studying the code it looks like a fix to resolve a referenced (external) page. If the page is not found it defaults back to the current page, which it always did with that hardcoded None. So it looks safe to me. For our purpose it is probably not needed though.

prp_GuiClasses.py:51, in plPostEffectMod.__init__():

Code: Select all

        self.fFOVX = 45.00
        self.fFOVY = 33.75

Assuming these numbers are the field of view in degrees, they give you an aspect ratio of 1.37 = 4.10:3 (tan(45°/2)/tan(33.75°/2)). If they are half the field of view in degrees, it's 1.50 = 4.49:3. Is that what you want?

prp_GuiClasses.py:69, in plPostEffectMod.read():

Code: Select all

        self.fHither = stream.ReadFloat()
        self.fYon - stream.ReadFloat()
        self.fFOVX = stream.ReadFloat()

Looks like a typo on the fYon line.

All I know is that the resulting GUI camera view is fine.

[diafero]

Well, it will read a float and not save it. I doubt that is wanted. Is that code even executed when exporting? It looks more like importing code for me. So to verify the best should be to compare with the exporting code of the same class.

[Christian Walther]

That one must have slipped through. Studying the code it looks like a fix to resolve a referenced (external) page. If the page is not found it defaults back to the current page, which it always did with that hardcoded None. So it looks safe to me. For our purpose it is probably not needed though.

I left it out of the merge commit (r424) to keep the history tidy, but we can commit it separately if it's considered useful.

All I know is that the resulting GUI camera view is fine.

All I know is that Cyan has trouble getting their aspect ratios right (at least in MOUL), so these numbers caught my attention . Perhaps GUIs use an orthographic camera and the numbers are not angles, or these numbers are not used at all (is the projection contained in the matrices?), or something.

Well, it will read a float and not save it. I doubt that is wanted. Is that code even executed when exporting? It looks more like importing code for me. So to verify the best should be to compare with the exporting code of the same class.

Yes, that is import code. I haven't tested it but it seems pretty obvious, also in comparison to the export code, so I changed it.

[Christian Walther]

On the documentation front:
I am pleased to see that we're nearing completion here, with the last pieces being worked on by D'Lanor and me.

OK, that wasn't completely correct - I neglected that the list wasn't complete yet. I have added the (hopefully) last entries now.

• Tikibear, are you around? If you have time, could you make sure that the Animating Textures page is up to date with respect to your changes (adding something about the scale animation that's now possible, at least)? If not, I'll have a go at it when I'm done with the other stuff I'm supposed to be doing.
• D'Lanor, can you have a look at the entry about GUI dialogs and mark it as done if it looks OK to you and you consider your documentation page complete?

[andylegate]

'Tis too cool! Been waiting for a new plugin version for a long time now. Thank's all for so much hard work!

[Christian Walther]

Hi Andy, nice to see you here again! If we managed to drag you back, that's already half the mission accomplished!

What's New document is here - Next step: deciding on the version number

With all documentation done, and my computer repaired, I have now compiled the collected list of changes into a What's New page. Please have a look at this, see if it makes sense to you as an end-user-readable document, and apply corrections if needed. (One detail: D'Lanor, your "multiple footstep sounds not appended conform specs" explanation feels a bit out of place on the Miscellaneous New Features page, but I wasn't sure what to do with it. Should it be left there, or removed altogether, or moved somewhere else?)

Now, with all the age-breaking changes gathered in a convenient list, the basis is laid for the decision of what to call the release: 1.6 or 2.0? I personally tend towards 1.6, but there have been some compatibility-breaking changes (most severe, I guess, inverted visregions and texture animations/offsets), and according to the explanation of the version numbering scheme earlier in this thread, they might justify a jump to 2.0. What do the creators of that versioning scheme think? (Trylon, or whoever?) Lontahv has already given his opinion here.

(You may notice that I wrote "1.6" in all wiki pages. That is just my guess as to what the outcome of the discussion will be and is not to be construed as exertion of influence. I had to write something, and if I'm lucky it's going to save me some page renames.)

[Tsar Hoikas]

1.6

From 0.5 -> 1.0 we saw a res manager rewrite and the deprecation of most text properties. Nothing on such a large scale has happened since... *Decides not to drone forever on the subject*

[Nadnerb]

Definitely 1.6

Nothing has been done to merit a major version change, and the designation 2.0 is already reserved by some other project, I think.

[Christian Walther]

That looks like a pretty clear vote so far, but if there are other opinions, keep them coming. I am not declaring the question decided yet because I will be away for the rest of the week - I'm going to spend a few days in the mountains, first on my own, then with some other Uru fans at the Uru RealLife Community Gathering.

Next up on my to-do list is the compatibility report/conversion script. In case anyone wants to have a go at this while I'm away, here's roughly what I have in mind:

The PyPRP Wizards menu is extended to something like this:

Code: Select all

.----------------------------.
| Wizards: PyPRP Wizards     |
|----------------------------|---------------------------.
| PyPRP 1.5 to 1.6 Upgrade > | Compatibility Report...   |
| ...                        | Convert Texture Transform |
'----------------------------| ...                       |
                             '---------------------------'

Choosing Compatibility Report prints something like the following, perhaps directly in the script window if that's possible, or in a text editor window, but does not modify the file:

Code: Select all

The following objects have modifiers. PyPRP will export the modified mesh. If that's not what you want, remove the modifiers.
    WallN - EdgeSplit
    Ground - Decimate

The following texture layers have static or animated offsets or scales. They can be converted using the "Convert Texture Transform" option.
    WallTex1

The following texture layers have offsets or scales that cannot be converted because they exceed the range supported by Blender. You will have to use a separate UV layer instead to retain their effect.
    Flower3
    Flower8

The Convert... options then do the actual conversion and print another summary of what they did.

[andylegate]

Hi Andy, nice to see you here again! If we managed to drag you back, that's already half the mission accomplished!

Aw shucks!

Seriously though, I've got people on FB saying the same thing......I'm just this guy that wrote a few Ages is all........there a people with far better work out there.....

Oh and I vote for this one being called 1.6 also. Makes sense as 2.0 has had planning/work for it done already. To me jumping to 2.0 would be like if the plugin was re-written with a GUI, or included several major changes.



EEEEEEKKKK! No! No Hoikas! Don't step on meeeeeeeeee!

(eheh, Adam looks just like my younger step-bro, Ron)