| Age | Commit message (Collapse) | Author |
|---|
|
Another trivial leak fixup.
|
|
This triggers immediate cleanup of the replaced context.
It's being done after the new context is fully installed as the
replacement, with an eye towards enabling a baton style handoff
of the existing context's owned pipes to the replacement, for
taps they have in common. That's not being done yet, but it'd be
impossible if the gc occurred before creating the replacement,
since the existing context's pipes would already be untapped (and
removed).
|
|
Another trivial leak fixup
|
|
On shutdown til_stream_untap_owner() will call into the pipe_dtor
hook if set. So until now this was just (harmlessly) leaking the
rkt_pipe_t allocated by the pipe_ctor hook on the road to process
exit.
But in the interests of silencing ASAN about leaks on graceful
exit, I'm tying up these loose ends.
This dtor will also be utilized for performing a FORGET_TRACK via
Rocket once that's a thing.
While here I also got rid of the pipe_dtor return value, as it's
unused with no clear potential purpose (for now).
|
|
Now you can seed the scene editing with a top-level serialized
scene in "as_arg" form, just like NEWSCENE.
The current scene being edited is shown in serialized form for
convenient copy & paste into an editor for manipulation, between
the []s both to also show what the default seed will be if you
just press enter. When using the copy & paste w/editor approach,
you'd just paste the tweaked form directly into the waiting
prompt before hitting <enter>.
Regardless of what happens at the initial EDITSCENE prompt, the
current implementation always goes through an interactive
visiting of all the settings. Simply pressing enter at those
individual settings will accept their current value from the
serialized seed, or a default if not present in the settings.
|
|
This doesn't need to be a distinct state since it's basically
just a banner for the start of the newscene process which never
recurs, it's not an interactive prompt or dialog of any kind...
|
|
Basically everywhere the
TIL_MODULE_HERMETIC|TIL_MODULE_EXPERIMENTAL exclusions were being
applied needed TIL_MODULE_BUILTIN added.
Mostly this is to prevent randomizers from tripping over builtins
in the available modules lists they draw from.
Because builtins aren't visually interesting by themselves, and
in some cases don't currently even have a means of being
randomized properly like ref's path setting.
This wasn't needed previously since builtins were kept off the
modules list altogether. But since 1a6210be that changed and
they must be explicitly filtered by flag instead.
Note I deliberately left the rkt case with just a TODO comment.
It's not a randomizer situation, and it might be acceptable to
let rkt just show everything all the time in the module lists.
That whole situation there is for advanced users.
Also note that without this, rtv et al would easily trigger an
assert on NULL setup due to the "none" builtin. Since there's
still work to be done there in callers properly handling NULL
@res_setup on a successful finalize. But this commit mitigates
that by avoiding the builtins in the randomizers.
|
|
This gets rid of the ad-hoc module lookups previously necessary
for finalizing the nested module setups. Now that the
til_estup_t.creator tracks the creating module, the
rkt_scene_module_setup() wrapper can take care of finalizing.
|
|
Particularly with nested modules it's annoying to have to stow
the module separate from the setup during the setup process.
If the baked setup included the module pointer in the
non-module-specific-setup part of the setup, then nested settings
could finalize using the generic module setup wrapper and just
rely on this til_setup_t.creator pointer to contain the
appropriate module. Which should enable tossing out a bunch of
copy-n-pasta surrounding nested modules setup.
Note this has to be a void* since til_setup_t is a generic thing
used equally by both the fb code and the module code. Hence why
this is called "creator" and not "module", as well as the void*
as opposed to til_module_t*.
Also if rototiller ever grows a sound backend, the setup
machinery will be reused there as well, and it'll be yet another
creator handle that isn't an til_fb_ops_t or a til_module_t.
It's assumed that the callers producing these setups won't be
trying to pass them to the wrong places i.e. a module setup
getting passed to an fb backend and vice versa.
I'm mildly annoyed about having to move the various til_module_t
blocks to above the module's foo_setup(), but it seemed like the
least annoying option. This may be revisited.
|
|
Most of the time in scener you want to add a compose, you
basically never want blank, so the :blank thing was kind of silly
from the perspective of what happens most often.
|
|
rkt_setup() and rkt_scener_update() had distinct implementations
for scene module setup. This consolidates that where trivial to
both use the new til_module_setup_full() with appropriate
parameters, wrapped up in rkt_scene_module_setup().
The finalizing phase is still ad-hoc which is mildly annoying,
but if finalizing just passed into rkt_scene_module_setup() there
wouldn't be the til_module_t onhand for sticking in rkt_scene_t.
So the code to extract and lookup the module from the settings
would still be needed anyways, as the whole til setup_func api
isn't limited to modules so the baked til_setup_t doesn't come
back with a til_module_t hanging in there. Maybe in the future
this gets changed a bit, there could for instance be a void* in
til_setup_t where something usage-specific goes, like the
relevant module in the case of a module's setup. Something to
consider for the future.
Consolidating these in the pre-finalize phase at least ensures
consistent behavior in initial rkt::scenes setup vs. scener
editing/new scenes.
|
|
When creating nested setting instances, just pass down the full
raw value so if there's any prefix on the value it can be
realized as a prefix for the first entry in the nested instance.
|
|
The application of overrides was still done via ad-hoc value
manipulation. This changes to use til_setting_set_raw_value() in
the obvious manner.
|
|
Trivial refactor s/til_setting_spec_check/til_setting_check_spec/
so it operates on a til_setting_t as opposed to the bare value.
With the containing til_setting_t onhand it can be responsible
for bypassing the check when til_setting_t.nocheck is set.
Adjusted callers in setup_interactively() and rkt_scener_update()
accordingly.
|
|
It's relatively acceptable to use this hammer for the other
errors like ENOMEM especially when this isn't some enterprise-y
service that must endure overload conditions gracefully.
But the setup_finalize() step is rather likely to find invalid
settings, especially now that til_setting_t.nocheck with the ':'
prefix is a thing.
This commit doesn't try resume the setup at the invalid setting
(yet, that will require further til_module_t.setup() method
work), but it at least doesn't rudely disconnect. The user just
gets dumped back to the SCENES state main prompt.
|
|
The existing code assumed til_module_t.name was equivalent to the
name setting's value. That's no longer a safe assumption, and if
the module was made possible via something like nocheck, that
needs to be preserved in the randomized setup.
So this gets the name out of the setting instead, using the new
raw value getter.
|
|
This makes RKT_SCENER_FSM_SEND_NEWSCENE_SETUP* handle ':'
prefixed values correctly, now using the new
til_setting_[sg]et_raw_value() API instead of directly messing
with til_setting_t.value.
It should now be possible to specify anything as a value
regardless of what's in the list for multiple choice settings.
Which does create opportunity for serious breakages... there will
definitely be crashes if you do silly things. Some
til_module_t.setup() methods have historically assumed the
spec_check would police the values reaching them. Those will
have to be made more robust now that this is getting wired up.
|
|
Since blank is a builtin, at least for now it requires explicit
override since the builtins aren't added to the modules values
list and filtering is going to be always applied shortly.
|
|
The "tiller" base (base being a Rocket concept) was always a bit
spurious. Maybe "til" would make more sense, but "rkt" is more
contextually specific.
I think when I originally picked "tiller" I was prioritizing
picking something unlikely to collide with another directory
name. But the way Rocket is naming the directory in the
filesystem it gets suffixed with an _ anyways.
|
|
The "compose,compose,compose,compose" default was never intended
to be permanent, but gave a set of scenes to test the Rocket
integrations like scene selection and scene-specific tracks
without any additional effort.
Now that there's scener for easily adding/editing scenes, and
things are just generally more mature, I think it makes sense to
just go back to something minimal here.
I'd really rather just have it be "", but that's not handled well
presently. There isn't really a way to start with an empty
scenes set for rkt. Which is awkward, but "blank" is close.
It'd just be nice to start with an altogether blank slate rather
than having to always edit the default first scene when starting
anew...
|
|
Now that the "scener" interface seems to be semi usable and
capable of editing... things are looking more complete in the
sense that there's no huge gaping holes and a lot of the dust has
settled.
It's also looking pretty good for this sticking around long-term,
so I'm removing the experimental flag making this more
discoverable and visible in general.
There's still work to be done surrounding GNU Rocket the library,
like getting it using non-blocking connects, and there's a need
for forgetting tracks which the protocol doesn't support
currently. But it'd be silly to wait on getting those things
upstream before making rkt more visible.
|
|
This augments the NEWSCENE_SETUP state to also handle editing
existing settings, which is slightly different but actually
overlaps with the already implemented invalid input stuff.
There's still work to do, and the UX is kind of awkward at best.
But this takes us from having no ability to edit existing scenes,
to being able to actually make edits interactively while it's all
live... with a modicum of interactive guidance via the setup
machinery.
It basically behaves just like creating a new scene, except
instead of the <enter>-accepted "preferred" values, you accept
the existing relevant setting. So as-is, when editing, you have
no shortcut for getting back the "preferred" value for a given
setting. That's been replaced with the existing value for that
setting.
You also get seemingly spurious redundant queries for module
names in things like compose::layers, but they're really not the
same since the first time you get asked it's actually the full
settings string you're getting an opportunity to specify
wholesale, but can accept to seed the layer's settings as-is,
which you will then be given an opportunity to edit piecemeal.
It's that subsequent piecemeal editing of the individual settings
within the nested instance that can feel like a spurious
duplication, especialy when a given layer has just a bare-value
module name and no subsequent settings.. like "plasma". You'd be
asked if you want "plasma" for the layers/[N], then asked if you
want "plasma" _again_ for the layers/[N]/[0] since the module
name is an unnamed setting at position 0 within the layers/[N]
instance.
It was tempting to try streamline that a bit, but there's
actually utility in having an opportunity to paste in a full
settings string for the layers/[N] if you have a serialized scene
onhand you want to dump in there. Then after that, you can juts
smash enter as much as necessary to accept what you pasted in
without editing those in the piecemeal phase. Or, if there was
actually something in what you pasted you did want to change,
change it during that piecemeal phase.
I think it at least kind of works.
|
|
Better spearate the generic error line from surrounding text with
an extra newline
|
|
This was a bit of an aspirational misnomer, editing scenes isn't
actually implemented yet. What the EDITSCENE state currently
implements is the per-scene dialog+prompt, which originally was
going to just be the scene editing flow but became more of a
"view a specified scene's details" with a prompt of its own.
Nothing functionally changes, just mechanical internal renames.
|
|
This is leftover from development when it used a fmt string in
combination with the key, before the desc path was getting
properly appended.
|
|
On Linux I don't notice a significant affect on anything letting
rkt try connect every frame when offline but in creative mode.
On Windows however, Dan reported significant latencies in the
Scener prompt responsiveness and visible slowdowns in this
condition.
I suspect the WIN32 Rocket library's sync_tcp_connect() code is
the real problem here. But for now I can ameliorate things a bit
by just hammering on that code path less when unconnected.
|
|
This is only relevant to creative mode. Stops RocketEditor from
continuing playback endlessly until user intervention beyond the
current end of the demo.
|
|
Prepartory commit for pausing playback upon entering 99999 scene
It needs to trigger only on the edge of entering the scene to
permit RocketEditor to unpause playback even if still in scene
99999, if that's what the user is trying to do. It'd be annoying
to have it just keep asserting a paused state until the scene idx
leaves 99999...
But this also enables triggering anything on scene change edges,
for future stuff.
|
|
- strip off the leading /path/to/rkt/module prefix
- separate taps from their scene context path with ':' vs. '/'
RocketEditor doesn't currently support recursive grouping, so
this is as good as it gets.
Note this commit will break the existing tracks for alphazed, so
you'll have to use a newer .zip for track data if building your
rototiller from source. Or build from a prior commit.
|
|
Preparatory commit for rewriting track paths a bit to better
group things in RocketEditor. I'll need access to
rkt_context_t.til_module_context_t.setup->path for prefix
matching purposes..
|
|
During rkt_scener development this append was at one time needed,
as there was no retained reference to the scenes_settings for
deriving paths from.
Now that the path is derived from the actual scenes setting
instance it's just resulting in a double trailing /scenes in the
"/module/rkt/scenes/scenes:" heading
Purely cosmetic fix
|
|
Pressing '=' at either prompts now makes scener's current scene
the current Rocket scene.
While you could already do this manually by just looking at the
scenes list for the one with the '*' in the Rocket column while
either watching a production and pressing <enter> repeatedly to
keep refreshing the scenes list... that's cumbersome and
annoying, now just use this shortcut.
Since this just copies Rocket's scene to the Scener scene index,
it needed to properly handle scene 99999... hence the previous
commits.
|
|
While there's no actual context for 99999, it's a state we need
to represent visibly somehow.. so just make it appear like an
epilogue scene off the end.
I've included the Rocket/Scener/Pinned status columns
consistently as well so you at least still get a visible
indication when you've done something like pinned 99999 somehow
(not that this is possible presently, but with future changes
there will be more ways to copy the Rocket idx into Scener's idx)
|
|
rkt_scener needs to know this value so define it in rkt.h and
switch over all the existing 99999 instances.
|
|
This seems to make things work well enough for mingw+wine
Will probably revisit in the future. Adding an ewouldblock
helper rather than duplicating the ifdeffery seems likely
Let's just leave it like this for now and find out if a real
windows test succeeds
|
|
This is available in win32, unlike inet_aton()
|
|
|
|
trivial simplification
|
|
Silly typo, one of those fun C instances where it's surprising
how silently mostly-working such a blatant mistake can be.
For posterity:
The way this was even observed as having an affect is while
verifying graceful handling of connections broken while in the
listen backlog.
With an active scener session idle at the prompt, start another
telnet, connecting without receiving any banner (queued via
backlog), ^]cl that backlogged telnet. Then start another
telnet in the same way. Now go to the idle scener session and
quit. The latest telnet would just sit there, seemingly blocked
behind the broken-while-backlogged connection.
But what was really happening was the banner send got the error
on the broken connection after accepting, as you'd expect. This
bug in the errno tests prevented detecting the genuine error
though, leaving the broken session connected indefinitely.
Fun!
|
|
After putting the recv() in a for(;;) to not have to render a
frame per byte received, I completely dropped the ball on moving
the return and adding the continue to actually finish the change.
This makes creating new scenes via pasting long settings strings
far less laggy. A future improvement would be to not recv() a
byte at a time, but this really isn't a perf-sensitive thing.
|
|
This changes things so rkt won't exit with an error @ startup if
RocketEditor isn't already listening. It also tolerates
RocketEditor going away, and will show a "OFFLINE" overlay status
text should that happen w/connect=on.
Some status text has also been added to the "EXIT SCENE" 99999
scene for both the RocketEditor connection and the scener
enabled/disabled status. No indicator yet for if scener has a
connection though, only if it's listening or not via listen=on.
|
|
Remove spurious space
|
|
|
|
Trivial related indentation adjustment too
|
|
This adds a BBS-style interface for creating new scenes in a live
rkt session.
It listens on tcp port 54321 on localhost by default, just use
telnet to connect, the rest is fairly self-explanatory.
This is still early days, but it's a whole lot more than nothing.
|
|
With the "ref" builtin module established and seeming to work
well enough, it looks unlikely we'll need access to unresolvable
module names in the contexts.
The thinking originally was that these names might have special
syntax making them more generic. E.g something like
"@/module/rkt/scenes/[1]/drizzle" for a module_name would have
been supported, which would get resolved either at context create
or even later (as in the ref builtin) at render time.
But the ref builtin is using a path setting, so module names just
stay module names.
Maybe in the future a special syntax will be added for brevity
reasons, but it does make the code more complicated vs. module
names just being names and resolving them entirely at setup time.
Anyhow, this commit does away with the module_name in the
context's scenes. You can still access it via
til_module_context_t.module.name anyways... it's basically just a
resolution-of-name-to-context time constraint that's being
codified now.
|
|
In the interests of improving error handling of interactive
setups, return the setting that was invalid when setup returns
-EINVAL.
For now this is only supported for non-finalized/non-baking setup
calls, i.e. (!res_setup).
In the future I want this also supported for finalizing when
res_setup is set. A lot of the -EINVAL returns are actually
during that stage (or need to be added) due to that being when
the more sensitive parsing occurs going from strings to native
numeric types and such.
The main reason it's not already being done in this commit is
it'll churn quite a bit to get there, since the setup funcs don't
generally have the setting pointers onhand at that phase. It'll
require changing the string-value-centric local variables to
instead all be the til_setting_t* holding those values.
And if setup funcs aren't going to be so value-centric, the
settings API will likely change to not even return the values
directly anymore and only return the full-blown til_settings_t as
the main return pointer, perhaps rid of their res_setting use
even.
Anyway, while here I did some random little cleanups too.
|
|
Make this a distinct heap allocation so it can be enlarged when
editing the scenes... (preparatory commit for scenes editing)
|
|
Preparatory commit for adding an interactive scene editing server
of sorts. It'll go in a separate listing, but needs these types
as it'll operate on rkt_context_t->scenes[].
|
|
This was written when module names were going to have an
@/path/to/context "handle" syntax. But instead I went the "ref"
builtin module route, with path=/path/to/context as a setting.
While it's more verbose in the settings, it "just works"
everywhere that can take a module+settings because the ref
builtin is just another module like any other.
So this TODO is referring to something that won't happen in a
"ref" builtin world.
|
