WorldForge Community

erik:

Great that you've started to code. However, for stuff that changes how the input system works I think I need to hear more about your thoughts, basically since we want to have a stringent user interface.

The way it's planned is to have the mouse wheel control zoom in and out when in a) movement mode b) in gui mode with the mouse over the "render window", i.e. not over any gui element. The first one is easy to implement using the keymappings in ember.conf (though I have to add key events for the mouse wheel buttons; there aren't any right now since mouse wheel movements are not technically keyboard events); the second one is harder though since there's no way to do that by using the key mapping code as Ember technically will be in the "gui mode" state, even though the cursor is over the render window. So we might want to wait with the latter one.
The keymappings are defined in ember.conf. There's currently three different keymapping "states". "general" applies all the time, "gui" applies when in gui mode and "movement" applies when you're in movement mode.

I don't see why you want to move the camera around while pressing the left mouse button: this already happens when in movement code. A special case is the entity renderer widget, which is shown when creating a new character and in the modeleditor, but that doesn't affect the main camera.

The way the main camera works is that the user is free to change the camera independent of the Avatar. At a certain interval (which can be set in ember.conf) Ember will however update the direction of the Avatar to face the way the camera currently points and send this update to the server (it's a certain interval to prevent swamping the server with data).

Input is handled in a way that decouples the actual action from the input through using both the key mapper and console objects. I.e. almost all input operations should be expressed as console commands, so that they can be dynamically bound to different keys, or scripted in console scripts etc.. So for example for moving forward:


* the user pressed "w"
* a n
* the keymapper iterates over all input event since the last frame, and tries to see if there's a matching console command
* it does a lookup for "w" and find the command "+move_forward", which it then executes
* the AvatarController class listens for the "+move_forward" console command and when it recieves it, it updates the state of the avatar to be moving forward
* later on, in the same frame, the AvatarController will recieve a command to process the avatar for this frame: it then checks what the current state is and moves the avatar accordingly

Console commands that start with "/" are one shot commands. Those that start with "+" will make something happen until a similiar command prefixed by "-" (such as "-move_forward") is sent. The keymapper handles the matching of "+" and "-" commands and key presses and releases. (So that when the user later on releases the "w" key a "-move_forward" console command is sent.)

So for a camera zoom function, we would need to create console commands for "/camera_zoom_in" and "/camera_zoom_out", make the AvatarCamera understand and act on these commands and then add bindings in ember.conf which binds them to the mouse_wheel_up and mouse_wheel_down events (which aren't there yet).

/camera_zoom_in" and "/camera_zoom_out" 

if button == EmberOgre.Input.MouseButtonLeft

 class myFrameListener: public ExampleFrameListener
   {
   protected:
     float buttonTimer;
   public:
     myFrameListener(RenderWindow* win, Camera* cam): ExampleFrameListener(win, cam)
     {
       buttonTimer = 0;
     } 
     bool frameStarted(const FrameEvent& evt)
     {
       float time = evt.timeSinceLastFrame;
       buttonTimer -= time;
      
       if (/*is KeyDown?? */ && buttonTimer <= 0)
       {
         buttonTimer = 0.5;
         //jump code
       }
       return true;
     }
   };