Quote - Yes, if the Lux code is wrong, that code should be changed.
But to keep people able to use the alpha exporter the best possible way, it should work with what people get from the LuxPage. That doesn't mean that existing code should be changed, so no one remembers the correct code later on. Maybe add a parameter to query for every workaround.

I'm fine with that but let's be really more careful about specifying dates of download and/or very specific LuxRender version numbers.

I downloaded 0.7 at two different times, and now I have two different behaviors. If we change LuxPose to compensate for today's version, it breaks the version on my laptop that was from two weeks ago, that has the correct fov at all times.

And the firefly problem will force people to stay behind. If I had been a LuxRender user in the days of 0.6, and then I saw how badly 0.7 behaved, I would have stayed on the older version.

I think that I'll add a parameter right now that specifies the LuxRender version you're going to export to and what date you got the code (or binary) so that if there are weekly differences (as I expect there will be on such a project) we can put all the different logics in the exporter and leave it to the user to choose which to use.

---

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)