Is it time for a new PyPRP release?

[Christian Walther]

Feature freeze in two weeks

GPNMilano has informed me that she probably won't be able to complete work on her pending features anytime soon, so I have decided to conclude the "code" track of the release preparation process and declare feature freeze on Sunday 2009-07-12 0:00 UTC. Any new feature or other non-trivial/non-bugfix change that is not in a mergeable state (and, if controversial, discussed) by then will not make it into the release. Not part of the freeze are conversion scripts to update old Blender files for the new PyPRP, where necessary - these will be integrated in a later step. It doesn't hurt if their basic workings are ready by then, though.

For a while it seemed sensible to me to leave the "code" track of the process running along in parallel to the "documentation" track as long as work on it was announced and no other part of the process depended on its completion. The "documentation" track is still in progress and will not be done in two weeks, but now that the announced work has been postponed, I think the time of the "code" track is up, it has been running for way too long already, and it seems better to put a definite end to it than risk letting it use up more energy or prolong the other one even more.

As to progress on the "documentation" track - there has been none in recent weeks as far as I can see. I'm planning to start work on the orphaned piggyback lightmaps point as soon as I get around to it, completing it will probably take me a few weeks, and if I have to do the event callback one myself as well, that will take even longer. Other pending points are drawable criteria by Paradox and kickable collision by Robert the Rebuilder.

[Robert The Rebuilder]

I've added documentation for the user-define kickable colliders and updated your chart.

[D'Lanor]

:arrow: Documentation volunteers needed

Revision 344 - New message: plEventCallbackMsg, proper support for plMessageWithCallbacks.

Code: Select all

svn diff -c344 http://svn.guildofwriters.com/pyprp/trunk/src/prp_LogicClasses.py http://svn.guildofwriters.com/pyprp/trunk/src/prp_Messages.py

This allows responders to wait for an object animation to finish or reach a marker before continuing, and has been discussed in this forum thread. That discussion needs to be distilled into documentation, perhaps on the Animations page. Ideal candidates would be people with some experience with animations and logic scripting.
Volunteer: vacant

Recently I have been playing with event callbacks and by studying Cyan's files I believe I have them figured out. There is something odd going on with key 0 which cannot be assigned to an animcmdmsg. It only seems to work for the oneshotmsg or timercallbackmsg. I also found out how to set numcallbacks and that Cyan assigns msg in the waittocmd table to the actual message/command which adds the callback (and not the same number as the key).

Anyway, I think I should be able to document this. Now to find the time to do it...

[Christian Walther]

Thank you D'Lanor!

[D'Lanor]

I will be documenting plMessageWithCallbacks this weekend (last weekend the wiki was being migrated).

On a different note, with the upcoming feature freeze tomorrow... do we still want the basic pfGUIDialogMod implemented in the next release? I discovered that it works without pfGUIButtonMod (although somewhat less user friendly). No libPlasma hacking required. See here.

I have a version in my contrib folder that is mergeable with the current trunk without breaking anything.

[diafero]

I would vote for "yes", GUIs are a long-standing feature request.

[Christian Walther]

Apologies for my sudden disappearance - my main computer has broken down earlier this week and will be in repairs for another week or so. I have its hard drive here, as well as a few older computers, so I'm not completely put out of action, but still somewhat handicapped. I'll try to increase my presence on IRC and on the forum again and I will see if I can set up an age/PyPRP development environment and continue work on PyPRP as planned.

The plan would be the following:
On the code front, putting the feature freeze into action:

• Merge tikibear's texture ofs/size fix.
• Merge D'Lanor's GUI additions - I assume you're talking about the four files added in r421, and I assume they are derived from trunk r420?
• Merge (or re-enact) my "single-package distribution" reorganization.
• Then would be the time to create the release branch so that development can continue in the trunk unhindered. However, since we don't know yet how the release is going to be named, I'd like to defer that step until it's needed, if you all don't mind. If anyone wants to continue development in the trunk, please let me know and I'll make the release branch immediately (we can always rename it).

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. I am in the middle of my research on the lightmap change, and depending on my success with getting Blender, PyPRP, and Uru running on my old computers, I may or may not manage to complete it this weekend. D'Lanor, your entry on revision 325 (319), QuickScript_SimpleClickable, is still marked as "documenting", is that a relic or are you still working on that?

When that is done, the next step will be deciding whether to call the release 1.6 or 2.0, based on the collected information on how it affects existing ages. I will also transform the list of changes into an end-user-ready "What's New" document, and spend some thought on how to make a compatibility report/conversion script for those aspects that can be checked or converted automatically.

[D'Lanor]

Merge D'Lanor's GUI additions - I assume you're talking about the four files added in r421, and I assume they are derived from trunk r420?

Yes, that is correct. Sorry, I was in a hurry and used the "known method" of adding to my contrib instead of studying the "unfamiliar" method you proposed somewhere earlier in this topic. And to give credit where credit is due: these are not my GUI additions but those of Paradox and GPNMilano. I merely stripped their files of all the other stuff which might break something.

D'Lanor, your entry on revision 325 (319), QuickScript_SimpleClickable, is still marked as "documenting", is that a relic or are you still working on that?

I have put that on the back burner for now. This still needs reworking but I have pointed it to the existing documentation which is not incorrect as such (just a little messy). The "breaking" change has been documented in the release planning article though.
The callback documentation and now also the GUI documentation have my priority at the moment.

[Lontahv]

I think it should be called 1.6. From 0.* to 1.* was a pretty large leap IIRC. This isn't a leap at all. Really, just some more features and fixes. There are other plans for PyPRP 2.*. These currently include using Python 3, PyPlasma and Blender 2.5. Based on what I've seen so far of Blender 2.5, I think I can say with almost certainty that the current PyPRP will not work with Blender 2.5 without rewriting large sections of the code.

We should save PyPRP 2.* for a larger change (for example the rewrite needed to make it work with Blender 2.5 and Python 3).

Also, calling this release PyPRP 2.0 would disrupt current preliminary work on a next generation of PyPRP (which is currently called 2.0).

[Christian Walther]

Yes, that is correct. Sorry, I was in a hurry and used the "known method" of adding to my contrib instead of studying the "unfamiliar" method you proposed somewhere earlier in this topic. And to give credit where credit is due: these are not my GUI additions but those of Paradox and GPNMilano. I merely stripped their files of all the other stuff which might break something.

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?
• 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.

I have put that on the back burner for now. This still needs reworking but I have pointed it to the existing documentation which is not incorrect as such (just a little messy). The "breaking" change has been documented in the release planning article though.

OK, I think we'll consider it "done" for the purpose of the release in that case.

In other news, I probably won't get much more done today. I've only just gotten PyPRP to export working ages on my PowerBook (see r422).