Guild of Writers

*pokes Tahgtahv* :ph34r:

It works! Just not the way I was expecting :blink:

I apparently hadn't saved the CoordinateInterface changes that I had made, so the object didn't have a Position.

So I linked back in and it wasn't rotating. I walked around a bit, and look what I saw:



So apparently I messed one of the settings up because it's rotating on the wrong axis.

For those familiar with Blender's axes: It's rotating around the X axis, not the Z axis.

I'll do a bit more playing around with settings and see if I can get it working the way I want it to, but hey, it's a start

Great news, Paradox! Now it should be a matter of trial and error before you get the right axis.

Aloys - I think you can stop poking Tahgtahv now.

Cool, you're making some nice progress.

As soon as that works out (and if we figured out the current transparency issue we have) I'll add sprites to the lampposts in Ahra Pahts.

Robert The Rebuilder wrote: My personal lists...

........

Lower priority classes - Needed info for refactoring

.........

plSwimRegionInterface (self)
plSwimCircularCurrentRegion (self)
plSwimStraightCurrentRegion (self)

We have Swim Region and Swim Current Region classes already.

Or do you mean that they should be refactored? if so, why is that?

Trylon:

You're right - these classes do exist.

The reasons for refactoring any of the PRP Blender Plugin classes are the following:
- Use the inheritance tree to eliminate duplicate code (e.g. of reading/writing/initializing member variables)
- Change variable names and types to match the more up-to-date information we have
- Utilize the hsStream class for file IO to improve readability
- Utilize the hsTArray class for better maintenance of UruObjectRefs

Although we had proclaimed the plugin refactoring "done" back in August, that was based on the information we had at the time - only 1/3 of the existing classes in the plugin ended up getting refactored. Since then, we've learned more, and consequently the need for refactoring the plugin classes has returned.

Hope this clears things up.

Aloys wrote: As soon as that works out (and if we figured out the current transparency issue we have) I'll add sprites to the lampposts in Ahra Pahts.

Aloys: the transparency issue has been fixed in the latest plugin release; see this post at Alcugs:

http://alcugs.almlys.org/forum/viewtopic.php?t=215

I recently updated my version of the prp plugin, and, after working through all the immediate problems with the new regions, things work properly again. But this version seems to have introduced some problems that I can't fix.

first, all my vertex colors are massively desaturated when viewed in uru, and second, the exporter totally ignores any changes I make to the normals in blender, so objects which I have had to invert the normals to display properly still have inverted faces in uru.

here is a picture showing the desaturated colors problem. note that this makes the avatar seem washed out by comparison. Also, deleting faces from a mesh in blender removes the graphic object in uru, but the collsion remains. To fix that, I have to modify the vertexes surrounding the face. (i.e. delete them and make new ones, replacing the surrounding faces in the process.)

(it's been several versions since I last updated, so I don't know how long these problems might have existed)

hmm, the inverted normals problem is just plain weird - can't recall seeing that anywhere....

Did you by any chance import your age sometime, and forgor to delete the [your-agename] folder? That might account for some problems.....

The saturation problem is actually a feature.... it's because blenders defautl material settings have Ambient at 0.5. This value is used to determine the ambient color of textures and such, in relation to the fully-lit variant.

To get full saturation again - set the ambient slider to 1.0

thanks for the reply. my colors are all fixed now. I've never imported my age. (very bad, causes loss of data. something which ought to be on the long term feature list for the plugin. (is there a way to implement new classes so that they are used for both import and export?)) and the only similarly named file is the TexCache file. (which is a really cool feature, by the way. exports are much faster now )

anyway, it turns out that the normals on the object I mentioned are not ignored, just inverted in the export. :blink: Which is weird, since it only affects some objects.