This allows using a coroutine to build up a more complex sequence including transitions (eg. scripted cutscene), as well as provide a standard way to register callbacks upon completion of the transition.
These were removed by 88dbb31daa under the assumption that they were not used, but it has recently come to my attention that there is still code out there that uses these.
PriorityCallbacks has been updated to be compatible with Python 3 by only comparing the priority, rather than the (priority, callback) tuple. This also has the side-effect of ditching the bisect dependency.
Also moves testing code from the source to the unit tests.
This is designed to sanity-check the buildsystem, ensuring that the
expected BUILDING_ macros are defined at the expected time. It
also helps catch cases where the wrong BUILDING_/EXPCL_ macros
are used.
Allows accessing `base` object and several other builtins from the ShowBaseGlobal module.
It doesn't bother with builtins that are available as members of the base object such as `render` and `loader`.
Fixes#182
- Do not take into accound SBS if it is not enabled
- Always return value for getSize()
- Properly handle SBS for window-events
- Redo positioning of aspect2d(p) markers exactly as
they are created when adjusting aspect ratio
Signed-off-by: deflected <deflected@users.noreply.github.com>
This introduces AsyncFuture as a new base class of AsyncTask. It's modelled after asyncio's Future class, except that it is thread-safe and you can use result() to block the current thread waiting for the future to finish (of course this is not necessary for use with coroutines).
AsyncFuture should be used for any operation that finishes in the future, to get the benefit of awaitability within coroutines as well as a standard interface for querying status and results of the operation as well as cancelling it. As such, it's been implemented in various places, including texture.prepare() and win.trigger_copy().
Note that AsyncFuture is intended to be used *once*; it cannot be used more than once. As an example of how this works, tex.prepare() will return the same future as long as the prepare isn't complete, but when it is done, subsequent calls to tex.prepare() will return a new future.
Set "mirror" camera to always have the same roll as the mirror
-> otherwise the model in the mirror will move unexpectedly
Set y coordinate of the mirror corners to the cameras distance
-> This fixes a crash and keep the mirrored model at correct sizer
Closes: #194
If one needs to use find() or findAll() not for debugging purposes (like for getting the function or arguments for some binding), then the print functions in these methods are really unwelcome. find() is the only nice way to get this info (other then de-name-mangling __callbacks)
Sam Edwards
bfrisby2000
rdb
Michael Wass
deflected
fireclawthefox
wezu
John Cote