This patch fix the existing word API for mist and global ambient lighting.
Add deprecated message to disableMist()
Add setUseMist(enable).
Details
Diff Detail
- Repository
- rB Blender
Event Timeline
Even if the functions weren't working someone still might call them and get a python error now, so that can potentially break existing scripts. I'll let the game engine developers decide if they want to break the API this way, it's not really my decision.
If it's ok to do this then this looks good to me.
Overall, things look okay to me. One nit-pick, setUseMist() might be better than setEnableMist(). I'm okay which renaming functions that didn't work, but it might be good to get Dalai's and Campbell's opinions as well since they usually show a bit more restraint than I do on such topics.
On another note (not really for this patch), we probably should be more consistent with our usage of the terms "mist" and "fog."
Should we rename the python method enableMist() also to setUseMist()?
I accidental put the properties_game.py into this patch. So this changes should not be applied if the patch will be added.
Let me know if I a updated patch is needed.
Renamed the method and the python api enableMist() to setUseMist()?
Removed properties_game.py.
Any decision on game engine API compatibility here?
Most of these mist patches look good to me and I could commit them, but they depend on each other and this is the first one.
If you keep setMistEnd (instead of renaming it) and disableMist (use ShowDeprecationWarning and keep setUseMist) then I think this can be committed without a review from Campbell or Dalai.
Changes:
- Keep setMistEnd (instead of renaming it) .
- Kepp disableMist (use ShowDeprecationWarning).
- Changed ShowDeprecationWarning macro in PyObjectPlus.h.
Tests:
- All set functions.
- DisableMist deprecation Wwrning.
Hmm... I know see that the way to previously enable fog was to set one of the fog parameters. I much prefer the way this patch does this (explicit enable/disable), but this could still break existing games if committed. I'm fine with this, and we can make sure to have a note in the release logs about the changes.
IMHO on breaking compatibility in a new version of Blender GE it is not the breaking of it but the need for adequate documentation on what is changed and how to fix it and a simple announcement to mailing lists that compatibility might need to be updated.
Than with all of those wanting to support the new version they can then quickly patch to be compatible again. It sounds simple and unnecessary or obvious to state but in the workflow of devs and in practical usage this is an issue that needs addressing IMHO.
| source/gameengine/Expressions/PyObjectPlus.h | ||
|---|---|---|
| 68โ83 โ | (On Diff #1893) | This seems unrelated, changes to style or preference are OK, but prefer split them out if they're not related to the patch. |