Is it time for a new PyPRP release?

[Paradox]

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).

Nadnerb and I were under the impression that they would control whether a sprite (such as a lamp flare) was visible when its centre of rotation was occluded by another object. This would prevent lamp flares from being visible if the lamp itself isn't. My tests indicate that they work, but might not be as useful as we imagined (since the centre of the flare is almost always inside the lamp, and thus occluded).

The class you're describing sounds like plDistOpacityMod? IIRC it was used for things like the GZ Markers to make them become more opaque as you approached them.

[Nadnerb]

Lon is wrong, Dox is right. Currently the only thing I've seen FadeOpacityMods do is fade out an object when it's object center is occluded by other visual geometry. DistOpacityMods handle distance-fading, and I don't believe they're implemented. (FadeOpacityMods are now implemented and working in Dox's contrib, I was hoping to merge that to the trunk, but it's proven to be a little annoying due to the extreme differences between Dox's contrib and anything else in the pyprp svn)

It just might be possible to get flares on lamps to work by parenting the flare itself to an object at the center of the lamp with the ViewFaceModifier applied to it, so that the object center of the flare would remain outside the lamp.. I've yet to test this, and it's a bit convoluted, even if it works.. >.>

[Christian Walther]

I assume you've checked how Cyan does it - do they not use it at all? My first guess would be that there is some flag that you can set on the lamp to stop it from occluding the flare.

[Nadnerb]

That would be logical, unfortunately, I've only found one case of it's use in all of Uru. That would be in Eder Tsogal, where it is used for the sun. At first I thought maybe the LOS wouldn't be broken by a non-physical object, but it seems that any visible geometry will occlude it. So if there is such a flag, I doubt we'll be able to find it by looking for a Cyan example.

This may in fact be why we don't see it used much in Uru. However, it wouldn't be the first time we've done something with plasma that Cyan didn't seem to have thought of.

The reason I originally thought of using this modifier was that all of the lamp flares in realMyst seem to use it, (or it's plasma 1 equivalent) and I noticed that the flare effect in general looked a lot better in realMyst.

[Jojon]

I suppose the "2BlendSpans" thing, whatever that is, that shows up when clicking Tsogal "SunBack" and "SunLOS" in prpshop, wouldn't have anything to do with it?

[D'Lanor]

Note to developers: When documenting new features which are not yet in the trunk, please do not add links to the main wiki page.

I have been getting PMs from people wondering why their EAXListenerMod was not working.

[Christian Walther]

Documentation volunteers needed

A few of the new features and changes implemented by Nadnerb since the last release are not documented adequately yet, and it would be appreciated if some people would volunteer to work on this and update the What's New list on the release planning page with their results. Nadnerb is available for answering questions.

Revision 314 - Put layers that are flagged as lightmaps using the "Amb" button in the material "Map To" panel into the "piggybacks" list.

Code: Select all

svn diff -c314 http://svn.guildofwriters.com/pyprp/trunk/src/prp_MatClasses.py

I have added a preliminary explanation given by Nadnerb under Lightmaps. It would be nice if someone could play around with this, find what the exact effect of the change is, judge if it is invasive enough to warrant a "changes existing age" warning in the release notes, if the previous behavior can be restored, and if the documentation on the Lightmapping page or elsewhere is still accurate and sufficient.
Volunteer: Christian

Revision 344 - New message: plEventCallbackMsg, proper support for plMessageWithCallbacks.

Code: Select all

svn diff -c344 http://svn.guildofwriters.com/pyprp/trunk/src/prp_LogicClasses.py http://svn.guildofwriters.com/pyprp/trunk/src/prp_Messages.py

This allows responders to wait for an object animation to finish or reach a marker before continuing, and has been discussed in this forum thread. That discussion needs to be distilled into documentation, perhaps on the Animations page. Ideal candidates would be people with some experience with animations and logic scripting.
Volunteer: D'Lanor

Revision 382 & 383 - Allow setting of visual.icicle AlcScript flags by name.

Code: Select all

svn diff -r381:383 http://svn.guildofwriters.com/pyprp/trunk/src/prp_GeomClasses.py http://svn.guildofwriters.com/pyprp/trunk/src/prp_DrawClasses.py

A list of these flags somewhere on the wiki is needed (can be taken directly from the code), with descriptions of what they mean, where known. I will start this with the raw list and the few things I know, others are invited to expand it with their knowledge. Edit: that list is here now.
Volunteer: Christian

Please let me know (on IRC or here) if you would like to tackle any of these points, and I'll update the list. If you are unfamiliar with getting specific revisions from Subversion for testing the first (or the current trunk for the other), I can provide pre-packaged versions.

[Jojon]

Revision 344 - New message: plEventCallbackMsg, proper support for plMessageWithCallbacks.

Code: Select all

svn diff -c344 http://svn.guildofwriters.com/pyprp/trunk/src/prp_LogicClasses.py http://svn.guildofwriters.com/pyprp/trunk/src/prp_Messages.py

This allows responders to wait for an object animation to finish or reach a marker before continuing, and has been discussed in this forum thread. That discussion needs to be distilled into documentation, perhaps on the Animations page. Ideal candidates would be people with some experience with animations and logic scripting.
Volunteer: vacant

I'm not really volunteering, I'm afraid. I'd just like to mention that in the case I was struggling with, I never got this to work for more than one single event within in a responder and wound up using timer events instead.

If I manage to find out what I've been doing wrong; THEN I'll volunteer. :7

[Christian Walther]

I'm not really volunteering, I'm afraid.

I had hoped to get you interested, obviously - but it's your choice, of course, and I'm fine with that.

I'd just like to mention that in the case I was struggling with, I never got this to work for more than one single event within in a responder and wound up using timer events instead.

Hmm, too bad. Is it intended to work with more than one event? (This question coming from someone who to date has no idea what responders, messages, and other Plasma logic critters are, mind you. )

[Jojon]

Hmm, too bad. Is it intended to work with more than one event? (This question coming from someone who to date has no idea what responders, messages, and other Plasma logic critters are, mind you. :))

Neither do I, which is why I'm not volunteering - I'd like to contribute but has nothing to show for myself. :P

I'm *guessing* you should be able to have any number of these events, just giving them each an ID of their own and assinging them to a waiton key, near the end of the state listening for it, so that you could have a Rube Goldberg machine sort of string of animations triggering in turn, as the one before it finishes or reaches a marker (..which we can't add yet) on a frame within it. :7