I just tried this and came to the following conclusions:
- Static case: I agree that the previous behavior is incorrect and the new behavior is correct.
- Animated case: I see no difference at all, and in fact I don't expect any since you didn't modify the plLayerAnimation export. Care to explain?
As to whether the fix should be incorporated - I vote for at least keeping the possibility open. There are other potentially compatibility-breaking features
under discussion, and if we decide on including those, I think we might just as well include this one, under two prerequisites:
- There must be a script to convert existing ages. Can you provide such a script, tikibear? I imagine it should be quite trivial.
- Behavior in the static and animated case must match (as far as both are implemented, i.e. for the offset), i.e. you need to fix plLayerAnimation too.
D'Lanor wrote:Even with this patch there are still hundreds of properties that a Blender render will show differently than they will end up in Uru. So my question is: why fix only this visual issue and leave the other inconsistencies?
Well, by that argument we'd never get anything fixed. I agree that there is a lot of mismatch in the way PyPRP tries to plumb together Blender and Plasma, most of it by necessity, but I consider that a major source of difficulty in our current age writing process and I think that where the two
can be made to match effortlessly, they should.
boblishman wrote:... and, lets be honest, with the (wonderful) tex_cache, exporting an age can sometimes take less time than a Blender render ! (and at least you can see exactly how it appears in game).
For me, export time isn't the problem, but restarting Uru is. I hope we can get that fixed quickly once we have the source.
boblishman wrote:PLease, I beg of you Christian, only "break" my Ages with the next release if you really have to (i.e for some benificial purpose)
Hey, no need to beg
I'm not the dictator here, I only try to coordinate things. Everyone who cares to voice their opinion is heard. (For that matter, I consider making things less confusing, as this patch does, a beneficial purpose.)
Trylon wrote:At any rate, you should get rid of the trickscale
Sounds good to me. What was its purpose anyway? As far as I see, it's only an additional scale factor that could just as well be achieved by adjusting the X and Y factors directly? Does anyone use it?
Oh, and one more thing, tikibear:
Robert The Rebuilder wrote:Note that for the PyPRP devs to incorporate your fix, you should create your own subdirectory in
http://svn.guildofwriters.com/pyprp/contrib, then add your modified prp_MatClasses.py file.
Please don't just
add the modified file, but
copy it from the trunk and then apply the modification, as I describe
here. (In a nutshell, it makes it easier to review and merge your work, and uses less storage space on the server. For changes as trivial as this one, it doesn't matter a lot, but it can't hurt to get into the right habits from the start.) If you're not familiar with Subversion, I can help with that.