Is it time for a new PyPRP release?

[Christian Walther]

Next Step: Determining what remains to be done in the code for the release.

Developers, please go to the PyPRP Release Planning wiki page, read the instructions, and add your release-ready modifications that aren't in the trunk yet to the list.

[Robert The Rebuilder]

Thanks again for agreeing to head this effort, Christian!

Regarding the documentation: it would be great if we could group the current Wiki articles into tutorials (i.e. a walkthrough of how to add the given feature to an age, complete with visuals and optionally a sample age) verses reference articles (anything less than the definition of a tutorial, e.g. a list of possible AlcScript parameter values). While reference articles are easier to write, the tutorials are what many of the new users really need.

[Christian Walther]

Robert, you may want to discuss this with Marcello, he's planning to do some work in this direction.

State of affairs from my part:

It seems that compilation of the coding to-do list is nearing completion already. The list will still remain open for editing for the time being.

I have been granted SVN write access and will on Wednesday or Thursday (tentative schedule, no promise), unless I get any vetos by then, start to merge those changes to the trunk that are listed as ready to merge and not needing discussion, contacting developers individually about what exactly to merge. I will review the modifications as far as my limited Plasma knowledge allows, but in general I'm taking your word for it that they are in working condition and uncontroversial.

After that, I will start work on compiling a "what's new" list from the SVN log that will later be fleshed out with descriptions and documentation links in collaboration with the developers.

GPNMilano - about your two additions that you want to discuss: I would suggest that, as part of making them ready for integration, you also write basic documentation about them that allows other developers (or perhaps other PyPRP power users) to test and review them and provide their recommendations. That could happen in a forum thread, on the wiki, or wherever you like. What do you think? As a side effect, that documentation could then serve as a basis for the refined end-user documentation produced in the next step. Is your contrib branch (or will it be) in a state where these features can be tested by simply switching to your branch, or does it contain other, unfinished things that are not ready for testing? In the latter case, you might want to prepare a separate branch with only the features under discussion.

Apart from that, I don't quite understand what you mean by "Estimated time: 2 weeks (but ready to merge)". How can something be ready to merge now and still require 2 weeks of work at the same time?

[GPNMilano]

about your two additions that you want to discuss: I would suggest that, as part of making them ready for integration, you also write basic documentation about them that allows other developers (or perhaps other PyPRP power users) to test and review them and provide their recommendations. That could happen in a forum thread, on the wiki, or wherever you like. What do you think? As a side effect, that documentation could then serve as a basis for the refined end-user documentation produced in the next step. Is your contrib branch (or will it be) in a state where these features can be tested by simply switching to your branch, or does it contain other, unfinished things that are not ready for testing? In the latter case, you might want to prepare a separate branch with only the features under discussion.

My contrib branch is in a state where everything can be tested by simply switching to my branch yes. I'm about to start a thread as you suggested on the changes up for discussion regarding the Mat Classes.

As for the one that says its ready to merge:

It can be merged safely, and the modifier attached to an object and still export correctly. The problem arises in this:

A plEAXListenerMod must be attached directly to the scene object of a soft volume to work. The soft volume code does not allow for logic modifier (which the plEAXListenerMod currently is located under) scripts like

Code: Select all

logic:
    actions:
      - example:
        name:
        example:


so in order to make them work you have to attach it manually via pageeditor. Since this is something we're trying to avoid, the softvolume code either will have to be adapted to either allow for logic scripting, or the code expanded to attach one upon export in the prp_ResManager.py. I'm not familar enough with the soft volume code to do this however, and I don't want to break anything with soft volumes. Thats the only problem with the plEAXListenerMod at this point. It works and it can be merged without issues as it stands, but it the soft volume code needs to be adapted to allow for either automatic exportation of a plEAXListenerMod through alcscripting, or logic scripting functionality being added to the SV code.(ChloesHoodOffice has it there for example)

[Christian Walther]

OK, I understand. I hope you can resolve the plEAXListenerMod/softvolume issue together with Paradox or Nadnerb (or someone else knowledgeable in this direction) - while I have done some bugfixing and research work about softvolumes, I'm utterly clueless about the rest of Plasma (and besides, I don't have EAX capable hardware to test it).

________


Rant - unrelated to the conversation with GPNMilano and not directed at anyone in particular:

Most of those of you who have contrib folders in the PyPRP repository have a peculiar style of working with Subversion that in my opinion doesn't make full use of Subversion's capabilities and needlessly complicates work both for you and in particular for the people who want to merge your work into the trunk or into their own branches. If that's just because you aren't familiar with Subversion, I hope you take this as a friendly hint to learn something from - if it was an informed choice, take it as a surprised observation from an outsider, not as criticism intended to have you change your ways.

Let's say you have modified the file prp_SomeClasses.py and want to commit it to your contrib. You do that by copying the modified file into your working copy of pyprp/contrib/Someone, svn adding it (or the Tortoise equivalent), and committing, say as revision 530. What if later you want to review what you have done in that revision?

Code: Select all

~/pyprp/contrib/Someone$ svn diff -c530

(in TortoiseSVN: Show log, select revision 530 in the upper pane, double-click on prp_SomeClasses.py in the lower pane) doesn't help: it just tells you that the whole file was added in that revision. You need to tediously find the original file before your modification, in the correct revision, in your working copy of the trunk or in the repository, then manually feed it to svn diff or your favorite diff utility together with the modified prp_SomeClasses.py.

What if I want to merge your change into my own branch or the trunk? First, since the SVN log only tells me that you added prp_SomeClasses.py in r530, I need to make a guess as to what the original file was that you modified to arrive at contrib/Someone/prp_SomeClasses.py r530. A reasonable guess is trunk/src/prp_SomeClasses.py r529. If I guess wrong, and it was in fact trunk/src/prp_SomeClasses.py r528, then I will end up reversing the changes (if any) that were made in trunk/src/prp_SomeClasses.py r529. So, to review your changes, I can do

Code: Select all

svn diff http://svn.guildofwriters.com/pyprp/trunk/src/prp_SomeClasses.py@530 http://svn.guildofwriters.com/pyprp/contrib/Someone/prp_SomeClasses.py@530

(Tortoise: open the repo browser in r530, choose Mark for comparison on the contrib/Someone folder, then Compare URLs on trunk/src). (Trunk r530 is the same as trunk r529 since you didn't change the trunk in that revision.) To merge, I svn update (backdate) my working copy of the trunk to r530, replace trunk/src/prp_SomeClasses.py by contrib/Someone/prp_SomeClasses.py, svn diff to check, svn update to HEAD again to let Subversion merge in the trunk changes since r530, diff again to check, and commit.

That was the complicated workflow as it exists today. What about the easy one?

Here you are again with your freshly modified prp_SomeClasses.py, and a working copy of trunk and contrib/Someone (not containing prp_SomeClasses.py yet) in r529. Now you do

Code: Select all

~/pyprp$ svn copy trunk/src/prp_SomeClasses.py contrib/Someone/

(Tortoise: right-drag the prp_SomeClasses.py file from trunk to contrib/Someone and select SVN Copy versioned item(s) here from the context menu). You can do that before you even start modifying, and then do the modifications directly in the copied file, or if you already have the modified file elsewhere (e.g. in .blender/scripts), replace the SVN-copied file in contrib/Someone by your modified one (using normal, non-SVN file copying/movement). The important thing is to have used an SVN copy operation once to create the file in contrib/Someone initially, not just a normal file copy/move. When you commit now, Subversion knows that your new file is a modified version of trunk/src/prp_SomeClasses.py r529, and the output of svn log -v -r530 or the TortoiseSVN Show log dialog will reflect that. As a side effect, this uses less disk space on the server, since the repository knows what the original file was and only needs to store your modifications, while it would store the whole file if you had just added it as a new file.

Reviewing your modifications now is as easy as

Code: Select all

~/pyprp/contrib/Someone$ svn diff -c530

or Tortoise Show log - the diff will only show your changes. Merging them to the trunk is as easy as

Code: Select all

~/pyprp/trunk/src$ svn merge -c530 ../../contrib/Someone

, which has the additional benefit that Subversion will record the merge so that it will not attempt to merge the same revision again later. In TortoiseSVN: Right-click on trunk/src, Merge > Merge a range of revisions > ...

Even more convenient would be, IMHO, if you wouldn't just store individual modified files in your contrib folders, but make them real branches, i.e. full SVN copies of trunk (or trunk/src) (like contrib/CWalther/experimental and contrib/CWalther/stable). That does not use significantly more space on the server - copies are cheap in Subversion, the repository only stores references to the original files, not full copies of their contents (plus the modifications you make to them). For one thing, that would make it easier to switch from trunk to branch to branch without having to mix and match individual files and risking version conflicts between them. In addition, you could easily merge changes from the trunk (or other branches) from time to time to make sure your branch stays up to date and compatible with the trunk, increasing the chance that your contributions will merge into the trunk successfully when they're ready for that.

[Christian Walther]

While work is still going on in deciding what contributions to include in the release and merging them to the trunk, we're getting ready to proceed with the

Next Step: Completing the What's New list and writing documentation

Developers, please to to the Compiling a What's New List and Documentation section of the PyPRP Release Planning wiki page, read the instructions, flesh out the descriptions of your changes, and tackle the biggest chunk of work in this endeavour: documentation!

[Christian Walther]

State of affairs:

Progress has been a bit slower than I had hoped lately. D'Lanor and GPNMilano have been productive in documenting their contributions - thanks! -, others less so, but neither has anyone declined to do it or asked for assistance. I have now contacted some developers individually about reviewing their What's New list entries and documenting their changes. The biggest problem I see right now is getting Nadnerb's changes documented (where necessary), since he hasn't offered to do it himself. It's quite a bunch. At a glance, I may be able to do it on my own for some, others look harder. I'll have a closer look and try to get it organized. Apart from that, I'm still waiting for mergeable code from GPNMilano, and there is still the discussion about her MatClasses changes that seems to have come to a halt. As I see it, we have not reached a conclusion yet, and personally I haven't formed a definitive opinion yet because I've held off some examinations until I have the updated code.

[Paradox]

This might not be the best place to discuss this, but I don't see any other place...

I have an issue with the way EAX settings are handled in AlcScript (as per GPN's tutorial http://guildofwriters.com/wiki/Adding_echos_to_sounds). They are in a logic block, which should be reserved for scripting that requires a logic modifier. I believe it would be better to place this in a namespace of sounds, under an 'eaxlistener' name. This code would ideally be attached to a softvolume region, which would be used to handle the EAX volume.

Code: Select all

[objectname]:
    sound:
        eaxlistener:
            #settings

I believe Nadnerb merged by DrawInterface AlcScript changes to trunk a while back, but I have since added more script to control the Drawable Criteria more accurately. I will merge this to trunk within the next few days and begin documenting the flags on the wiki.

Nadnerb had mentioned wanting to add plFadeOpacityMods to PyPRP. I will try to put these into my contrib, and then potentially merge these if they are done before the release. This should not be considered a blocker.

[Christian Walther]

I have an issue with the way EAX settings are handled in AlcScript (as per GPN's tutorial http://guildofwriters.com/wiki/Adding_echos_to_sounds). They are in a logic block, which should be reserved for scripting that requires a logic modifier. I believe it would be better to place this in a namespace of sounds, under an 'eaxlistener' name. This code would ideally be attached to a softvolume region, which would be used to handle the EAX volume.

Code: Select all

[objectname]:
    sound:
        eaxlistener:
            #settings

OK with me. I'll leave it to you to discuss that with GPNMilano once she's back.

I believe Nadnerb merged by DrawInterface AlcScript changes to trunk a while back, but I have since added more script to control the Drawable Criteria more accurately. I will merge this to trunk within the next few days and begin documenting the flags on the wiki.

Great, that would be nice.

Nadnerb had mentioned wanting to add plFadeOpacityMods to PyPRP. I will try to put these into my contrib, and then potentially merge these if they are done before the release. This should not be considered a blocker.

I have no idea what a plFadeOpacityMod is, but it sounds good . I'm open to adding new features to the release until all the ones from the to do list are in and we declare feature freeze (which could take another month or so, depending mainly on GPNMilano's availability) - as long as they are finished, reasonably stable, and come with documentation.

In that connection - if you or anyone else wants to continue development in the trunk without affecting the release, let me know and I'll move the release process to its own branch. It is not my intention to hijack the trunk and block all development there while the release is being prepared. The release will eventually get its own branch anyway, but I'm not branching off sooner than necessary to minimize the work of backporting release branch fixes to the trunk (in particular the single-folder installation thing that I plan to commit as the last thing after all other features are in).

[Lontahv]

plFadeOpacityMods make objects get more opaque the farther you are away from them (I forget if you can invert the effect). A good example is a black plane in the doorway of the library on Myst island (and I think the tree-detail-levels on Myst island in realMyst as well... I'd have to look). They were used a lot in realMyst and the black-fading doorway one is still used on Myst island in MystV.

If I've messed up this class for a different one please correct my with all haste (I may have made a mistake since I'm somewhat rusty at this).