| Age | Commit message (Collapse) | Author |
|---|
|
screen
|
|
So far 4 seems like a good balance for performance and quality. 2 is great for quality, with 6 or 8 being for higher performance. Also bring back the gaussian filter - may end up adding the FXAA filter though instead.
|
|
|
|
|
|
|
|
floater closed
|
|
|
|
|
|
LLViewerDynamicTexture::updateAllInstances
|
|
false if no render needed
|
|
|
|
leaphelp() (no argument) shows a list of all LEAP APIs.
leaphelp(API) shows further help for a specific API.
Both forms query LuaListener's LeapListener and report its responses. In
future we might reimplement leaphelp() as a Lua function.
Add LuaState::getListener() method, which checks whether there's a LuaListener
associated with this LuaState and returns a pointer if so.
Add LuaState::obtainListener() method, which finds or creates a LuaListener
for this LuaState and returns its pointer.
Both the above use logic migrated from the Lua listen_events() entry point,
which now calls obtainListener() instead.
|
|
|
|
help() with no argument lists all our viewer builtins.
help(function, function, ...) shows help text for each named function. Each
argument can be either a string or the function in question (e.g. help(help)).
To support Lua-related text containing line breaks, make LLTextEditor::
pasteTextWithLinebreaks() a public template method. Change the existing
implementation, which specifically accepts (const LLWString&), into its
LLWString specialization. The generic template passes llconvert(arg) to that
specialization, the one real implementation.
Make LLFloaterLUADebug methods call pasteTextWithLinebreaks() instead of
insertText(), which ignores newline characters.
To allow help() to accept an actual function as well as a string name, add a
lookup-by-function-pointer map to LuaFunction. (A Lua function does not store
a name.) Make the constructor store an entry in the new lookup map as well as
in the original registry map.
Change LuaFunction::getRegistry() and getRegistered() to getState() and
getRState(), respectively. Each returns a std::pair, but the first binds
non-const references while the second binds const references.
|
|
|
|
As a function parameter, an assignment expression or a `return` expression,
`ll_convert()` can infer its target type.
When it's important to specify the TOTYPE explicitly, rename the old
`ll_convert()` function template to `ll_convert_to()`. Fix existing usage.
|
|
|
|
|
|
|
|
--lua "chunk" runs the specified Lua chunk at startup time.
--luafile pathname runs the specified Lua script file at startup time.
You may specify more than one --lua or --luafile switch on the command line.
|
|
Since the description shows up in the log output, it's better to see just the
script filename than to see "runScriptFile('filename')".
|
|
respect simulator feature PBRTerrainEnabled
|
|
more inaccurate than usual alpha sorting (#781)
|
|
|
|
That means that as you use the floater, variables that you assign and
functions that you define are available to subsequent Lua chunks.
|
|
* secondlife/viewer#771: Put PBR material swatch behind feature flag
* secondlife/viewer#771: Make viewer respect PBRMaterialSwatchEnabled from SimulatorFeatures
|
|
|
|
We add a suffix to let us publish a Lua foo() function that wraps a C++ foo()
function. Of course the lua_CFunction must accept lua_State* and extract its
parameters from the Lua stack, so it must invoke different C++ code than the
C++ foo() function it's trying to reach. So the lua_CFunction is a method of
the LuaFunction subclass instance named foo_lua.
The suffix was _luadecl, but since the class name shows up in log messages,
make it the more streamlined _lua instead.
|
|
The chunk:
return 1, 2, {}
differs in two ways from:
print(1, 2, {})
First, print() engages the Lua tostring() builtin, so it displays values as
Lua sees them. (For a table, tostring() displays "table: hex", which isn't so
wonderful.) But LLFloaterLUADebug serializes the LLSD converted from the Lua
return values.
Second, we've overridden print() to engage a function that writes to the
viewer log as well as displaying to LLFloaterLUADebug. (As we go forward, most
Lua scripts won't be run manually by LLFloaterLUADebug.) The values returned
by a Lua chunk aren't implicitly logged. Each C++ caller wanting to evaluate a
Lua expression can choose whether to log the results.
|
|
|
|
|
|
|
|
Improve PBR terrain loading robustness
|
|
|
|
|
|
|
|
SimulatorFeatures
|
|
|
|
|
|
|
|
|
|
Extend the LuaFunction::Registry map to store helptext as well as the function
pointer.
Add help text to every existing lua_function() invocation.
|
|
|
|
|
|
macOS clang produces fatal warnings when trying to pass a const char*
parameter to luaL_error() (-Wformat-security). Temporarily suppressing that
requires #pragma clang directives which, in turn, produce fatal warnings in
VS.
Moreover, VS recognizes that luaL_error() never returns, and so diagnoses the
following return statement as unreachable code. But that return statement is
the whole reason for lluau::error()'s existence...
|
|
|
|
|
|
|
|
Add a new test<1>() that tests returning values from a Lua chunk using
LLLUAmanager::waitScriptLine(). This exercises lua_tollsd() without yet
involving LLEventPump machinery.
For that purpose, extract from test<2>() the sequence of (description,
expression, LLSD expected) triples into a static C array. The new test<1>()
returns each such expression as a result; test<2>() posts each such expression
to a test LLEventPump.
test<2>() now uses waitScriptLine() instead of pumping the coroutine scheduler
a few times and hoping. The pump-and-hope tactic worked before, but no longer
does. waitScriptLine() is more robust anyway.
Move the former test<1>() to test<3>() because it exercises still more
machinery, specifically listen_events() and await_event(). Because this test
involves a handshake with C++ code, use startScriptLine() to launch the Lua
coroutine while providing a definite way to wait for completion later. Again,
startScriptLine() followed by get() on the returned future is more robust
than the previous pump-and-hope code.
Similarly, the former test<3>(), now renamed test<4>(), uses startScriptLine()
and Future::get() instead of pump-and-hope.
|
|
Break out for LLLUAmanager consumers the promise/future semantics of
waitScriptFile() and waitScriptLine(). startScriptMumble() uses
runScriptMumble() to launch a coroutine to run the specified Lua script or
chunk, providing an internal adapter callback to set a promise on completion.
It then returns to its caller the future obtained from that promise. This
allows a caller to call startScriptMumble(), run in parallel with the Lua
coroutine for a while and then call get() on the returned future to wait for
results.
waitScriptMumble() is then trivially implemented using startScriptMumble().
Fix runScriptLine()'s logic to abbreviate the passed Lua chunk for use as the
description. We were erroneously assigning back through a string_view of the
parameter, which overwrote a temporary string in the argument list.
With Lua 5.4, listen_events() tried to discover the main "thread" (Lua
coroutine) associated with the current lua_State so we could call async
callbacks on that thread. Luau doesn't seem to provide that feature, so run
callbacks on whichever thread calls listen_events().
Reinstate original multi-argument lua_print_msg(), tweaked to avoid the Lua
5.4 lua_rotate() function, which is missing from Luau.
|
