Guild of Writers

Correct me if I'm wrong, but won't a new version of PyPRP have to be created, to be able to create ages that are compatible with MORE, since it is a different plasma version? The PRP structure of MOUL is similar but there are minute differences. This is just my personal opinion, and I'm putting it out there for the devs as a suggestion, that maybe the 2.0 series should be saved for a new version of PyPRP that will be compatible with MORE. While the 1 series be soley for CC. This way it avoids confusion for any new writers who come along that want to make ages for both CC and MORE.

I wouldn't be surprised if they had already been planning that.

I was thinking along the lines of a PyPRP-M or MPyPRP for the MORE version. A slightly more ambitious version might combine CC/MORE methods and allow the creator to choose the version at export time. Just some thoughts.

MORE support is planned for PyPRP 2.0. We're going to have to rewrite a few things (Layer Animations, anyone?) first though. MORE is a way off anyhow, so let's not push too hard.

Anyway, first we have to hammer out issues with 1.5

Tsar Hoikas wrote:MORE support is planned for PyPRP 2.0. We're going to have to rewrite a few things (Layer Animations, anyone?) first though. MORE is a way off anyhow, so let's not push too hard.

Anyway, first we have to hammer out issues with 1.5

The only reason I asked is because of the confusion new people might have when the 2.0 series comes. Having two versions of PyPRP within the same series, someone is bound to incorrectly install the wrong one thinking it will work with MORE or vice versa. I brought it up because the thread for 1.5 suggested it would be the last in the 1.x series before 2.0 came out. Separating the two into separate series (CC in the 1.x series, and MORE in the 2.x) seemed like the best way to avoid such a complication in the future.

The only other way that I thought it may work would be to have one plugin for both, with an option in the wizards to convert the age to MORE, similar to what was done from the old plugin to the new one.

But I'm just rambling off things I think would be good. I leave it up to the Devs to figure out the best solution to the problem.

Present and past versions of pyprp have a variable to set the version of prp they export. (currently [uu/live] and [tpots])I assume future versions will stay the same, though the default version may change. Once again though, this is far off, and we'll cross that bridge when we get there.

I disagree with that approach. I do not want to maintain multiple codebases. It's as silly as Cyan is for maintaining two separate branches of Plasma.

I think that we should just start to work on this and add stuff to the present version and then just keep it out of sight for most people with a conf-enabled thing.

Tsar Hoikas wrote:I disagree with that approach. I do not want to maintain multiple codebases. It's as silly as Cyan is for maintaining two separate branches of Plasma.

I assumed that the majority of the Developers would also feel this way, as two plugins can also cause problems. Which is why I suggested the second option of a conversion wizard set into PyPRP that would change the variables for export of the PRP. This way people can choose which version they wish to export (TPOTS or MORE), and would save you guys the hassle of juggling the development of two plugins. But I don't know how much coding would be involved in the creation of a wizard that chooses the type of export you want.

An abstraction layer in the plugin would be more useful.