Is it time for a new PyPRP release?

[GPNMilano]

My branch of PyPRP, is much more screwy then Paradox in some ways. I have a few half finished classes and thats why a lot of my stuff isn't in my contrib. I can tell you what is in my branch though. As I Hoikas pointed out, I have PMed him about merging the trunks and getting a new release of PyPRP out to the masses. I don't have write permission to the trunk, just to my contrib, so there's very little I can do as far as putting my stuff in the contrib and letting others sort out the mess, but to roll down the list of what IS finished and working in my branch:

GUIs - Still buttonless, but part of the contrib (this was Dox' work I just merged his stuff with mine for it)
Exclude Regions-Working, but really can't test them as its mainly for multiplayer stuff.
MultiStageBehmods-Working fine and in each Devs Contribs I believe
MaintainersMarkerModifier-Working, and in by contrib.
SeekPointMods-Working but not in my contrib
ResponderEnableMsg-Working, not in my contrib though

Those are the the working ones, unfortunately some of those are mixed in with half cobbled together stuff thats not working.

Expanded on stuff

Sound classes were expanded on with a few extra new scripting options for a few of the variables in them. Mat classes is the biggest thing that got any real work put into it, a ton of stuff was rewritten and moved around so that just about every flag that could be used could be implemented within blender, along with Ambient color and opacity layer animation support, but this was, unfortunately a age breaking implementation, as the ambient color was mapped to the Mir color in blender, and Mir is automatically set to white by Blender, which is the highest setting that it can be set to in Plasma, so if this is implemented within the trunk EVERY one of the materials thats in an age will have to have their mir color adjusted to black so that its set to 0 in Plasma. In other words, you have to go through each of your materials in an age and set the mir color to black for each one that WONT be using the ambient color. So that would have to be noted in the release notes so people know to change their materials.

The added bonus of all these material changes is so that more advanced things like SDL Layer animations can be made possible. I did this so that rather than the old way (whereas every layer on a material got the same layer animation for its color) now its on a perlayer basis.

Bob: When I get some free time I'll see about making up some tutorials for libPlasma so that first time users can figure out how to make some of the things that are necessary right now to use libPlasma for. Maybe a set of tutorials similar to blender's getting started wiki tutorials or something. When i start this I'll PM you, and if you have the time you can be my beta tester for them. I just need to set aside some time for this.

[Trylon]

Core to getting things runnign again is getting the developers motivated. I usually found myself motivated when there was clear need for a certain part, and if it was a decent puzzle/challenge (not too easy, and not too hard either). E.g. swimregions, camera support, rewriting the drawable export, were such challenges for me.

How about this for a plan of action:

1) We compile a list of features currently lacking in the trunk Pyprp, sorted by priority
2) Developers who have done some work in those parts, indicate so in that same list
3) Developers claim a single subproject (preferably what they were working on before, if motivated enough), and start working on implementing it in the trunk.
4) We determine which parts need to be done for a new release.
5) Documenters sign up with the developer of a subproject for testing and documentation.

Thoughts?

[boblishman]

Bob: When I get some free time I'll see about making up some tutorials for libPlasma so that first time users can figure out how to make some of the things that are necessary right now to use libPlasma for. Maybe a set of tutorials similar to blender's getting started wiki tutorials or something. When i start this I'll PM you, and if you have the time you can be my beta tester for them. I just need to set aside some time for this.

I am VERY VERY happy to do this ... (and yes, I understand the time factor) ... just pm me when you are ready ...

[GPNMilano]

Core to getting things runnign again is getting the developers motivated. I usually found myself motivated when there was clear need for a certain part, and if it was a decent puzzle/challenge (not too easy, and not too hard either). E.g. swimregions, camera support, rewriting the drawable export, were such challenges for me.

How about this for a plan of action:

1) We compile a list of features currently lacking in the trunk Pyprp, sorted by priority
2) Developers who have done some work in those parts, indicate so in that same list
3) Developers claim a single subproject (preferably what they were working on before, if motivated enough), and start working on implementing it in the trunk.
4) We determine which parts need to be done for a new release.
5) Documenters sign up with the developer of a subproject for testing and documentation.

Thoughts?

Sounds reasonable to me. I know there's a few things that are currently implemented in both the trunk and contrib that need additional stuff to get full functionality going. Example: MultiStageBehMods work, PythonFileMods work, Responders work, we're just a single step away from being able to use all of these together to create the linking effects that Cyan use for their linking system which is the LinkToAgeMsg. I started some work on this but its a very complicated system, but once its implemented, we will be able to simplify our methods of linking by making the responders rather than the python scripts activate the linking.

EDIT: Another Example is the plNotifyMsg. Its implemented in PyPRP but the remainder of the stuff that it is supposed to be able to call is not. EventData functions are necessary for more complex python stuff involving puzzles and multiple animations. I've fooled around a bit with this in some of my ages, but had to use libPlasma again to make the necessary responders that use these functions. But by doing so more complex stuff can be made, xNewHighLevelStarTrekDoor as well as the other cyan python scripts for doors can be used once this is enabled in PyPRP.

[diafero]

making the responders rather than the python scripts activate the linking.

Which will introduce a lot of new problems... the Python scripts which do the linking currently (usually D'Lanor's book template) at least have some sanity checks and can easily be replaced by scripts which verify all linking data (like my xLinkMgr). For responders one would have to manually check the prp files. And there's a lot of stuff people can do wrong when adding a link...

Aside this, I'm afraid I'm not experienced enough in Blender to actually help merging. My impression why there was no release is that those who usually did the release either didn't have enough time to merge things or didn't see the need as everything worked for them. It's great to see something is finally happening, perhaps I can soon stop suggesting people to use nightly versions
I could help doing some "stupid" documentation work like writing the changelog from the SVN commit messages, but I don't know Blender so I hardly can do more.

[GPNMilano]

making the responders rather than the python scripts activate the linking.

Which will introduce a lot of new problems... the Python scripts which do the linking currently (usually D'Lanor's book template) at least have some sanity checks and can easily be replaced by scripts which verify all linking data (like my xLinkMgr). For responders one would have to manually check the prp files. And there's a lot of stuff people can do wrong when adding a link....

I was thinking more along the lines of enabling the use of linking with a responder so that the global linking book pop up can be used by everyone. So that if they want to use a Cyan book like a Nexus terminal (similar to what I have on Eder Licinius) they can do so. I think if we get more people using the global python scripts it would save hassle down the line of having one to many pak files for the offline install.

D'Lanors template can than be adapted so that it works in a similar method that it does now, but with the added bonus that it also activates the multistagebehmod and oneshotmod prior to linking.

[D'Lanor]

I too prefer Cyan's link responder. My Python script was meant to patch the hole until its implementation into PyPRP. There is however one case of linking that to my knowledge cannot be done that way: public ages. Special Python functions must be used to fetch age info of (for example) public Neighborhoods from the public age table. This method is used in the Nexus and during MOUL several new public ages were added.

Public age linking is not implemented into my Python script btw (but it can be added if the need arises).

Edit: Even if we add that link responder the use of Cyan's Python scripts (xLinkingBookGUIPopup.py and xLinkingBookDefs.py) is still not an option for our ages because in spite of their "x" they are not truly global: They require a modification in xLinkingBookDefs.py for each new age.

[Lontahv]

For me to use I feel like for now it's done. I have the tools I need (PyPRP is advanced enough to export a decent age and libPlasma is great for if you want "that little rare feature" for your age).

Sure, PyPRP has room for improvement and PyPRP2 needs much more work. There's just not the urgency of before. Now, there's a way to do almost everything (either with PyPRP or libPlasma) without having to count bytes. All you need to battle now are the UI's for various tools. IMO, in most cases, even this is a lot easier than hex editing Plasma-objects (however complex the interface may prove ).

That accurately sums up the current stalemate. For you as a developer there is no urgency anymore but most writers have absolutely no use for libPlasma. And they too would like to be able to use new features. And rare features? I don't know. Particles for example are IMO essential.
Keep in mind that libPlasma only makes sense to those who have a basic knowledge of the Plasma engine. Many people are at a stage where they just about manage to copy/paste/change names in Alcscript without understanding the logic of it in terms of Plasma.

You've also developed for PyPRP. Ideally, AlcScript or XML wouldn't even need to be touched by beginners. I also don't see how _this_ stalemate has anything to do with releasing a new version of PyPRP. Actually, I think some of the stuff in the branches could actually make it harder for beginners to use PyPRP.

[Marcello]

I volunteer to help out with some tutorials, like I did for swim regions and stencilling. It was fun writing those while Trylon implemented them. However I don't have time to figure out the workings of features from scratch. With Trylon we went head to head, making it easier for both I think.

So if someone has implemented a feature and wants a tutorials contact me and we can figure out how to share info.

Edit: most importantly.... these tutorials should be very visual. I know some features are documented, but without screenshots of settings, results, test ages etc. I suggest we do more of the illustrated tutorials.

[Christian Walther]

Woo, now we're taking off!

It may be worth noting, that only a short while before the creation of this thread, Trylon himself did a little shoutout to the other devs, regarding an updated release.

When and where did that happen? I must haved missed that. I can't find anything here on this forum.

Documentation is the grisliest bit, I think, though. It can be hard for people in the know, to fully empathise with those not yet initiated, especially when there may be need for prerequisite specialist skills, where the experts will often go "Huh, doesn't EVERYONE know that?!". :7

Definitely. But having the "expert" documentation is a start, and that's the point where the help offered by people like ardent red or Marcello enters the picture. We don't need to get this perfect, but it would be nice to have at least something.

CW, if you seriously do want to take on the responsibility of preparing releases, I suggest you talk to Nadnerb and Paradox. The best way to hammer that out would be over IRC (irc.justirc.net port 6667, channel #PyPRP) as they're really the developers at this point.

I was hoping they would notice this topic and chime in with their opinion on their own - they have both been around, as far as I see. Obviously I haven't been screaming their names loud enough, or their ears aren't as sensitive as yours . I'll try to catch them on IRC.

Core to getting things runnign again is getting the developers motivated. I usually found myself motivated when there was clear need for a certain part, and if it was a decent puzzle/challenge (not too easy, and not too hard either). E.g. swimregions, camera support, rewriting the drawable export, were such challenges for me.

Agreed, and for this project I can't offer the strong motivation of challenges, but only the lesser one of seeing one's work being used. That's why I am trying to estimate support beforehand instead of just going ahead and seeing if people would follow (apart from the "stepping on toes" point and avoiding duplication of work).

How about this for a plan of action:

1) We compile a list of features currently lacking in the trunk Pyprp, sorted by priority
2) Developers who have done some work in those parts, indicate so in that same list
3) Developers claim a single subproject (preferably what they were working on before, if motivated enough), and start working on implementing it in the trunk.
4) We determine which parts need to be done for a new release.
5) Documenters sign up with the developer of a subproject for testing and documentation.

That plan seems a bit more ambitious than what I had in mind - but if we can pull it off without getting stuck midway, all the better.

Here's the rough plan I would have suggested (written from the perspective of the manager):

1. Gather all interested developers by PM to make sure we're not leaving anyone out just because real life has kept them away from the forum for a while.
2. Compile a list of things that we want to complete in the code before the release - finished features from branches that only need to be merged to the trunk, small clean-up work, perhaps backing out unfinished features that nobody is willing to finish or that would take too long, that sort of thing. Not things that haven't even been started yet, that are considered experimental, or that would take a lot of development effort. This is not a wish list, an entry is only made by the person that is willing and able to complete it in the course of a few weeks. The list should turn out fairly short, because most things waiting to be released are in the trunk already. To say it again, my goal is not to advance development of PyPRP, but to get what we have right now out to the people.
3. While the work from the list is being done, compile a skeleton What's New list (change log) from the SVN log, then work with the developers to flesh it out. Ask the developer responsible for each entry to write a short description of the feature for the list, and, if deemed useful, documentation on the wiki, a link to which is added to the list. Whether to write the documentation on their own or enlist the help of volunteers is at the discretion of each developer. Entries that the developer deems not newsworthy may be dropped from the list at this time.
4. Package up a beta release and ask age writers to test it for a month or so.
5. Ensure that issues found in testing are resolved.
6. Package up the final release and announce it to the world.