1) Taking into account target move vector and speed. However aiming is not
ideal, since attack strength can't be controlled directly. I did achieve
almost 100% accuracy updating it everyframe but then thought it would be
unfair, cause AI should mimic human targetting.
2) Also added in this commit func to measure real attack durations for
weapon.
When physics attempts to move by a very small amount, precision losses
caused Bullet to trigger an assert in debug from normalizing a zero
length vector.
Called setEnabled on channels now effects whether those channels
notify listeners, rather than whether they register changes to
their controls. This was making channels get stuck on "1" when the
GUI was activated.
Also ensured GUI activity can invalidate player controls even if
that activity is closing the GUI, by re-ordering a check.
And fixed a comment.
- Use quest names as identifiers, not quest IDs. This ensures that quests with different IDs, but the same name (e.g. A2_4_MiloCaiusGone and A2_4_MiloGone) are merged properly, as they should.
- Switch display from BookPage to MWList. Handles word-wrapping and scrolling properly.
- Fixes a bug where the quest index would not be updated when opened.
Added FindDirectX scripts from Ogre so that FindOgre.cmake doesn't
fail silently to find the libraries correctly.
Modified top-level CMakelists.txt:
- Correctly set include dirs, preprocessor definitions, and add
libraries for static Ogre plugins.
- Correctly set preprocessor definitions for static MyGUI.
Modified launcher, openmw, and opencs to link the static Ogre plugins.
Fixed FindSDL2.cmake to set a variable that contains only the SDL2
library, so that the launcher doesn't incorrectly link against
SDL2main.
Fixed FindMyGUI.cmake to correctly look for static variants.
Fixed FindOgre.cmake to set variables for DirectX plugins correctly.
Fixes an issue where inputs could be processed by both GUI and
gameplay systems. An enabled/disable has been added to OIS
channels, and OpenMW now disables player gameplay hotkeys when
a GUI element has focus. GUI hotkeys are left enabled.
It turns out I was erroneous about problem (1) in my original commit
message. I thought that in an edge case the OpenMWGUI could both handle
the same event on the frame the GUI was closed. My test for
this was broken. So after brainstorming many possible unsatisfactory
solutions to this event handling, it's luckily not necessary!
There are two major differences to the old implementation:
- Activate can now be called on its own, e.g. in the console. In Vanilla this appears to be a no-op, so it is unlikely to be used and the potential for breakage is low.
- The Action to execute is now determined when Activate is called, not when OnActivate is called. This however makes sense, since there may be a time difference between the two, and the object (or the player) could have changed in the meantime, requiring a different Action.
Fixes#1166 and #1346.
This bug would cause the player to jump when jump was assigned to
Space and they closed a dialog with Space. I tested vanilla
MW for behaviour and found that Jump was the only basic input which
MW does not allow when closing dialogs (i.e. if Space is assigned to
move forward, MW will move you forward after closing the dialog).
There were two reasons for the bug:
1) OpenMW GUI does not consume UI events
2) Jump occurs so long as key is down (not only on first key down)
To minimally fix the bug, I made it so that keypress events can be
consumed by the GUI and not passed along to the player control
input manager (1). However, if the player holds space, they will still
jump (as the subsequent key held events will be captured and cause
a jump).
Unfortunately, there is no idiomatic way that I could find in the
OpenMW input manager to perform events only on key down. Instead,
I introduced a variable which tracks whether the jump key has been
pressed for the first time within the current frame (2).
Note: I was initially concerned that limiting the jump event to
KeyDown and not Key Hold would cause issues with swimming,
levitating, or variable height jumping. However, after a bunch
of testing in vanilla MW and exploration of the OpenMW codebase
I could find nothing suggesting the need to capture the jump
key being held.
