This topic is locked
- Removed Lua completely - done [Rincewind]
- Python interpreter integration - done [guyver6]
- Python-Console integration - done [guyver6, Garo]
- Easy binding of our classes to Python - done [Garo]
- CEGUI Python scripting module with CEGUI bindings - done [guyver6]
- Refactored settings to be more rubust to use - done [guyver6]
- Binded settings to Python - done [Garo]
What's left to do is loading settings from config files. I see 2 options:
- Use Ogre::ConfigFile and register all settings that ParamConverter class can parse
- Execute config files as Python scripts that will set those settings
I prefer to do a little additional work and write code that uses Ogre::ConfigFile. Rationale? I intend to introduce settings categories, this will make using python scripts harder, you would have to write sth like:
param.baseview.camera_x = 3 param.baseview.camera_y = 2 param.baseview.camera_z = 5 # where baseview is category name and camera_* is param nameUsing Ogre config file is simpler:
[Baseview] camera_x = 3 camera_y = 2 camera_z = 5 [AnotherCategory] the_var = n[3, 1, 2]This allows us to group them more visibly in config files. Btw, the param.category... access from Python is available all the time for the purpose to use it in scripts and in console.
Btw, as you you may noticed the strange n[3, 1, 2] syntax for a setting. Well, what it says is: 3D normalized (unit) vector along vector [3, 1, 2]. Yes, settings can now be 2D, 3D and 4D vectors as well as color values (RGBA, A optionally). This is still not implemented for Python, but it's there when you want to create new param (Param is a class that holds a value of a setting, it's responsible of getting that value to user or setting it, as well as converting string's like the one above to the actuall type). Settings class is responsible for registring new params with string names (Param class has doesn't have to have a name if you want to instantiate it) and for getting Params value to user (specified by name). It mostly has static methods now, so you only need to do
Settings::get<Bool>("some_bool_var");to get a value. Everything else is done behind the scenes.That's all for now. If you want to talk about some of the stuff covered by this post, I'm on IRC
EDIT: from all of it I've forgotten to write a little about my ideas of having trunk compilable all the time and to ease others work. I propose to do a branch for every feature you want to create and then merging this feature to trunk, when it's ready and tested. This will:
- allow others to correct small errors and bugs in trunk while you don't have to worry that some small commit will make you correct all your code, just because this small correction conflicts with your new code
- help maintain trunk as stable as possible
- work in small groups on particular features to polish them as much as possible without conflicts with other features
My proposition is to call branches "feat-featurename", like "feat-items" or "feat-python" for the last 2 most active branches. After a branch is merged into trunk it should be deleted from repo (history of it remains, but the branch isn't visible in later revisions).
EDIT2: OK, I've forgot the password to updater FTP so I can't upload new packages, and Updater symlink on our normal ftp doesn't work. I'm waiting for new password from mindstormmaster, then I'll proceed with everything.
Edited by guyver6, 09 January 2006 - 12:01 PM.
