| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
--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
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
Confusion between light diffuse and light color in HDR auto-adjust mode
|
|
While the SUNLIGHT_COLOR uniform is initialized with getSunlightColor() when not
auto-adjusting for HDR, it is overwritten with getSunDiffuse()*auto_adjust_factor
when auto-adjusting, causing very bad lighting discrepancies in the latter mode
(especially when not at midday or midnight).
Let's use getSunlightColor() everywhere, shall we ?...
|
|
|
|
|
|
yet used
|
|
|
|
|
|
Add LuaState::expr() that evaluates a Lua snippet and reports back any result
(or error) left on the stack.
Add LLLUAmanager::runScriptFile() and runScriptLine() overloads that accept a
callback with an (int count, LLSD result) signature. The count disambiguates
(error, no result, one result, array of results). Also add overloads that accept
an existing LuaState instance. Also add waitScriptFile() and waitScriptLine()
methods that pause the calling coroutine until the Lua script completes, and
return its results.
Instead of giving LuaState a description to use for all subsequent checkLua()
calls, remove description from its constructor and data members. Move to
expr() and checkLua() parameters: we want a description specific to each
operation, rather than for the LuaState as a whole. This prepares for
persistent LuaState instances.
For now, the existing script_finished_fn semantics remain: the callback will
be called only when the LuaState is destroyed. This may need to change as we
migrate towards longer-lasting LuaState instances.
Make lua_function(name) macro append suffixes to the name for both the
LuaFunction subclass declaration and the instance declaration. This allows
publishing a lua_function() name such as sleep(), which already has a
different C++ declaration.
Move the Lua sleep() entry point to a standalone lua_function(sleep), instead
of a lambda in the body of runScriptFile().
|
|
https://github.com/secondlife/viewer into materials_featurette/mirrors
|
|
|
|
#665 Make viewer respect MaxTextureResolution from SimulatorFeatures
|
