From: Andy R. <and...@gm...> - 2007-05-29 02:05:31
|
> > I have been working on the camera manager and have modified it to allow > looking and zooming and attaching the camera to an actor (defined in my > actor manager port). I currently have the python connection to the camera > manager operational. Python can call all the functions of the cam mgr. In > order to support having the cam mgr do anything I have installed the > standard RF1 key mapping into my version of the input manager. I can now > look and zoom with the keyboard or the mouse from the C++ built-in manager. > I am now going to write a similar functionality in Python. I have added a > two level Python override possibility to the camera manager. I made the cam > man able to handle multiple cameras; the users may want to create a two > player split screen game or simulation. A Python script can be run before > the cam mgr manage function that runs every update. This script can turn > off any further built-in functionality if so desired. The built-in cam mgr > manage function also performs logic for each camera that is defined. I > allow for a Python script that runs before each camera's built-in manage > logic is run and another that can run after the built-in logic. The one > that runs before can turn off the individual camera's built-in logic if > desired. Before I write the Python version of the logic I need to provide > user input for the Python program. I can't decide the best way to do this. > I currently have the key or mouse listener set a camera boolean variable > when the user requests look mode. The camera mgr uses these (look, > lookright, lookleft, lookup, and lookdown, etc.) booleans to animate the > active camera. I don't know whether the user input should set data items in > the cam mgr, like this, and Python can get the relevant user input from the > camera mgr or if Python should have a generic way of getting user input, or > both? What do you think? Great progress, thanks so much! I think it should be more or less generic, and then the user can create a camera object and map his own keys to it by getting the key states himself and adjusting the camera manually, and also providing a few subclasses of rfobjects.camera which have predefined, common layouts like the wsad fps camera, etc. > Or have you already decided this or actually implemented something? I > keep thinking about how the user input should be provided to the individual > subsystems, but I can't seem to come up with anything I like. I hope you > have some ideas. I'll have to think about how I would do it. > I have used Boost v1.34 and Python 2.5 along with the latest version of > Ogre (v1.4). Boost v1.34 has the exec, import and exec_func macros (very > nice). Yeah, in my working copy of RF2 I'm using Boost 1.34's import to easily get backtraces during python exceptions and provide a message box showing the script error when it occurs. > You never did answer my earlier question about why you weren't using the > latest version of Ogre. Sorry, I didn't see the question. They changed the api slightly in 1.4breaking the build, so I just haven't taken the time to port it yet. It's definitly on my todo list. > Let me know what you think. I'm moving pretty fast and don't want to go > the wrong way. I think it sounds good. I'm not sure about how the API is designed; I imagined it being the managers aren't really visible, and objects are handled. IE rather than rfmanagers.camera.create(), rfobjects.camera(). I'm sorry to not have a concrete document laying out everything in RF2 and how it should work; I am working on a complete spec which will detail everything in RF2, as well as the tools, right now. It won't be set in stone; changes are certainly welcome of course as always, but it lays out generally what RF2 should be and will be updated to match the current state of things. It might take a little bit, but afterwards it should solve any problems of wasted work or not knowing what to do next, and I again apologize for being so disorganized! Best Regards, - Andy Riordan |