PyPRP new version downloadable now

[Trylon]

Ok, I want to announce that we finished the rewerite of pyprp to the point of initial release

This is the GoW PyPRP, not to be confused with the alcugs PyPRP

Download it here: http://www.guildofwriters.com/pyprp/pyprp20080112.zip

An example blender file, implementing all new features can be found here: http://ulm.hbyte.net/downloads/FuncChk.zip

Also, to avoid confusion, I must inform you that the GoW pyprp developement team has decided to fork away from Alcugs, and continue GoW developement of PyPRP separate from Alcugs and Almlys. This decision was made because we discovered that the visions Almlys has for PyPRP differ too much from our visions for it to warrant a productive co-operation.

Therefor, please refrain from posting tutorials on this new version on the alcugs wiki, as we are currently working hard to establish a GoW wiki - which would be the best place for such tutorials.

[D'Lanor]

I cannot say I like the direction you are going from the posts I have seen here, but I guess it is natural to dislike drastic changes. I am willing to try the new version and see if the new way is really better.

But what if after that I still prefer the visions of Almlys? Do you know if there is currently any development for that branch?

[Trylon]

By referring to almlys vision for pyprp we are not referring to anything to do with interfaces. Almlys has not noticably contributed to pyprp developement in the last 18 months or more, so any vision on the interfaces has been from other developers - most of whom are in the GoW currently

Almlys visions for the future of pyprp are not in the direction of export to uru, but are focused on his 7D7 project. We believe that we can provide better focus on exporting to uru if we are working separate. As said before, Almlys has not noticably contributed to pyprp developement in the last 18 months or more, so it will not be a change that plugin users will notice in development philosophy.
There is no reason to expect that any continuing pyprp developement on Alcugs will provide any improvement to its support for uru prp export.

[andylegate]

Trylon,

does this version have everything working in it? You mentioned last time that certain things (footstep areas, etc) were broken.

[Trylon]

They are working again.
Also, support for clickables has been re-instated.
The quickscripts that make the footstep areas, clickables, SDL states, and also self-triggered animations (regions that trigger an animation on entering), support both alcscript and logic properties for their activation.

Also, swimregions and camera regions are working again.

The way of operation of these and similar features that you can expect in the future is the following:
- Through alcscript the objects and settings will become fully customizable to the limits of uru
- Before any other processing of the objects, quickscript processors for basic setups, will parse both the logic properties and the object's alcscript settings.
These quickscripts will react to commands in logic properties and/or alcscript, that tell them to make a set of default settings, for e.g. footstep regions.
They will insert (invisible to the user), the advanced required for enabling the stuuff into the objects alcscript, so that it will be parsed in the normal parsing cycle.

Basically, that boils down to:
You will still be able to use logic properties for setting simple operations - the way they are processed just allows for more flexibility and easier implementations in the prprp code itself.
But you will be able to fully customize your objects if you want to.

Currently there are four quickscripts available that operate in this exact way.
- Footstep regions
- self-triggered animation regions - the avatar will use the origin of the triggering region as seekpoint
- Boolean SDL
- Clickable objects

Also, the requirement for clickable objects and camera's to be located inside their activating regions has been removed.

[boblishman]

Will there be a way to export an Age that does NOT compress or change the size of texture files (in the same way that As A Full Age (.age) exports in the stable 0.5 version does not compress or change file sizes) ?

I ask this because (it appears that currently) to be able to use .png transparancy images in Journals (for 'drawn' sketches or diagrams) that they must not be resized to the 128x128 type format or compressed either (if they are resized or compressed, they dissappear from the journal).

Currently, these transparant 'sketches' can be acheived by exporting the age intially as As a Full Age (.age) (which generates the cache files and folder ... you then delete all the files that you DO want to compress (i.e. all the files except the sketches) from the cache folder and re-export the age as Generate Release (.age) ... the result being a mixture of non-resized/non compressed textures and resized/compressed textures)

...or is there a simple way to tell the plugin not to compress or resize a specific texture file?

[Trylon]

I added a download link to the first post.

Here is it again for those who don't want to scroll all the way up: http://www.guildofwriters.com/pyprp/pyprp20080112.zip

[Marcello]

Great Trylon thanx! But...

I'm reading about so many new features and changes that I have no idea how to start working with the new plugin. For instance the changes to materials and the ability to do vertext alpha channels has not been documented in a tutorial somewhere. I understand people are working on this, but aren't there drafts or test blender files we can study?

If not, is there a roadmap for the release of the new wiki?

[Trylon]

I have an example blender file - with associated files here: http://ulm.hbyte.net/downloads/FuncChk.zip

[Marcello]

Cool thnx