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.
Last edited by Trylon on Sat Jan 12, 2008 1:14 pm, edited 4 times in total.
One day I ran through the cleft for the fiftieth time, and found that uru held no peace for me anymore.
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?
"It is in self-limitation that a master first shows himself." - Goethe
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.
One day I ran through the cleft for the fiftieth time, and found that uru held no peace for me anymore.
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.
One day I ran through the cleft for the fiftieth time, and found that uru held no peace for me anymore.
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?
when it comes to Age creation ... "DOH" seems to be my middle name...
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?
