|
|
|
@ -16,17 +16,17 @@ screen. If you need very specific low-level control, those APIs might be the
|
|
|
|
|
right choice for you. However, here are some reasons you might want to implement
|
|
|
|
|
an overlay widget instead:
|
|
|
|
|
|
|
|
|
|
1. You can draw directly to an existing viewscreen instead of creating an
|
|
|
|
|
#. You can draw directly to an existing viewscreen instead of creating an
|
|
|
|
|
entirely new screen on the viewscreen stack. This allows the original
|
|
|
|
|
viewscreen to continue processing uninterrupted and keybindings bound to
|
|
|
|
|
that viewscreen will continue to function. This was previously only
|
|
|
|
|
achievable by C++ plugins.
|
|
|
|
|
|
|
|
|
|
1. You'll get a free UI for enabling/disabling your widget and repositioning it
|
|
|
|
|
#. You'll get a free UI for enabling/disabling your widget and repositioning it
|
|
|
|
|
on the screen. Widget state is saved for you and is automatically restored
|
|
|
|
|
when the game is restarted.
|
|
|
|
|
|
|
|
|
|
1. You don't have to manage the C++ interposing logic yourself and can focus on
|
|
|
|
|
#. You don't have to manage the C++ interposing logic yourself and can focus on
|
|
|
|
|
the business logic, writing purely in Lua if desired.
|
|
|
|
|
|
|
|
|
|
In general, if you are writing a plugin or script and have anything you'd like
|
|
|
|
|