Mux Logger Objects

Derp

Didn't see this in the last 5 pages or so, so I'm not sure if we've ever talked about it, but -- does anyone know where we can find code for some of the cool logger objects that various MUX-based games have been using?

These are the ones where you turn them on and drop them in a scene, and they pick up all the poses before spitting out a nicely formatted version for copy-paste to a wiki?

Sunny

@derp

@ixokai @ixokai @ixokai

He has one he's made that is pretty much the best thing ever. Not only is it good for formatting, I was as a DM able to read a scene some of my players did without me on the game, later. From interacting with the code and the object. Right on the damn game.

Thenomain

@derp

The one you see in the OOC room for The Reach/Fallcoast/Fate’s Harvest is mine.

The pose logger belongs to @skew.

I have not seen Ix’s.

ixokai

Mine actually doesn't work on MUX (the Rhost version heavily uses @include), though I'm going to make it work for HorrorMU soon. When I do I'll post an update to my logger thread and ping you to see if you haven't found something you like yet.

Bobotron

@ixokai

... does it work on Penn?

ixokai

@bobotron Yes there's a penn version.

http://musoapbox.net/topic/2363/mux-logger-objects

The Penn version lacks a couple features like +log/undo but that should be easy to add.

EDIT: Derp idiot moment

http://musoapbox.net/topic/1476/loggers/7

Ashen-Shugar

@ixokai said in Mux Logger Objects:

Mine actually doesn't work on MUX (the Rhost version heavily uses @include), though I'm going to make it work for HorrorMU soon. When I do I'll post an update to my logger thread and ping you to see if you haven't found something you like yet.

Ixokai, MUX has trigger() so hypothetically you could recode to use trigger() instead of @include and it should, kinda sorta, work the same with minimal impact.

ixokai

@ashen-shugar No that wouldn't work at all. I use @include extensively for code-reuse purposes.

Ie, like:

&I.FIND-LOGGER lp=@assert setr(logger,locate(...))
&cmd.log-view lp=$+log/view *:@include me/I.FIND-LOGGER;@pemit %#=something with %q<logger>
&cmd.log-undo lp=$+log/undo =:@include me/I.FIND-LOGGER;

'trigger()' can't halt the queue of the calling command like @include can

Ashen-Shugar

@ixokai said in Mux Logger Objects:

@ashen-shugar No that wouldn't work at all. I use @include extensively for code-reuse purposes.

Ie, like:

&I.FIND-LOGGER lp=@assert setr(logger,locate(...))
&cmd.log-view lp=$+log/view *:@include me/I.FIND-LOGGER;@pemit %#=something with %q<logger>
&cmd.log-undo lp=$+log/undo =:@include me/I.FIND-LOGGER;

'trigger()' can't halt the queue of the calling command like @include can

Yea, I thought trigger() would work in-line but you're right, it works just like @trigger does.

Makes you wonder wtf it's even useful for.

Sorry about that. So yea, with MUX you're pretty much SOL without recoding it all to be in-line

faraday

@ashen-shugar said in Mux Logger Objects:

Makes you wonder wtf it's even useful for.

It was probably designed for the folks like me who code (well --- coded, since I've switched to Ares and never looked back) exclusively in functions over commands. The absence of a trigger function was highly annoying when I just wanted to kick off a separate thing in the midst of another command. It didn't happen a lot, but often enough that somebody probably requested it.

skew

@derp @Thenomain
I don't have a logger code myself, but we do have one on Fate's Harvest. I could see if Annapurna is okay sharing, or knows where it originally came from?

Thenomain

@ashen-shugar

Sorry about that. So yea, with MUX you're pretty much SOL without recoding it all to be in-line

Why? I can't find the code Ix is using so I can't comment on it, and I don't know what @include does.

--

@skew said in Mux Logger Objects:

@derp @Thenomain
I don't have a logger code myself, but we do have one on Fate's Harvest. I could see if Annapurna is okay sharing, or knows where it originally came from?

The logger is mine.

The POSE-logger was, I thought, yours. A logger is a logger.

ixokai

@thenomain said in Mux Logger Objects:

@ashen-shugar

Sorry about that. So yea, with MUX you're pretty much SOL without recoding it all to be in-line

Why? I can't find the code Ix is using so I can't comment on it, and I don't know what @include does.

http://musoapbox.net/topic/1476/loggers/7

The rhost one, not the penn one.

But, what @include does is sort of like @trigger, but in the current command queue. So if I put some stuff in INC_FOO, if I then @include me/INC_FOO, it will execute the INC_FOO stuff exactly as if it was in the original attribute. Then continue on-- unless something aborted the command queue. Inside INC_FOO, it has access to the full state of the calling attribute.

I have a "Standard Library" on the games I code for. In it I have a lot of common stuff I don't want to repeat over and over. One common is, "is the calling player staff, if not, report error and abort":

&IS-STAFF %'std'=@assert isstaff(%#)={@include %'ui'/FAIL=%#,Permission denied.}
&FAIL %'ui'=@pemit %0=[ui-fail(%0,%1)]

Now in actual commands, I can then do this:

&cmd.set-stat obj=$+set <asterisk>/<asterisk>=<asterisk>:@include %'std'/IS-STAFF;....do stuff

Its not saving a lot (Except in more complex uses), but it does allow code-reuse.

A common thing in my code is for argument 0 to be a target, a player. So:

&FIND-TARGET %'std'=@assert t(setr(target,pmatch(%0)))={@include %'ui/FAIL=%#,I can't find anyone named: [ansi(hw,%0)]};

&cmd.set-stat obj=$+set <asterisk>/<asterisk>=<asterisk>:@include %'std'/IS-STAFF;@include %'std'/FIND-TARGET;&_cg.%1 %q<target>=%2;@include %'ui'/SUCC=%#,Blah blah it worked.

Thenomain

@ixokai

Why is this important? If you timestamp the recorded log tightly enough (though I did timestamp + originating dbref), then there won't be any race conditions. If the system takes a moment longer to record the log because the command is sitting at the end of the queue, where's the harm?

This is more for Ash because he brought it up, but I'm not seeing the need.

edit: I just caught the use. You didn't mean inline for the command queue, you meant to pull @command-based code from one attribute to another and still properly run it.

Yeah, that would be nice.

To get this to work on Mux, a simple @edit as part of the install would be easy.

Annoying to maintain, but easy to install.

ixokai

@thenomain said in Mux Logger Objects:

edit: I just caught the use. You didn't mean inline for the command queue, you meant to pull @command-based code from one attribute to another and still properly run it.

I do absolutely mean inline for the command queue-- I'm just operating from a Rhost POV which uses 'inline' extensively and with meaning.

The command queue is a series of actions, they are executed in order. Some things add entries to the command queue. @trigger. @dolist. @include is different in that it operates in the current command, it pulls actions into it-- its like a @Trigger that happens in the current command and doesn't queue a new action (like @trigger does). @include has a few other special properties, but I won't focus on them right now. But there's more. @dol/inline is a Rhostism that does a @dolist which doesn't add entries to the command queue-- they all happen inline.

In Rhost, "inline" means, "a thing that, historically, queued a new action to run later, but now runs right here and now in the current command running on the queue."

Consider, what's the difference between:

@dol [lattr(obj/foo.*)]={@pemit %#=[get(obj/##)]}

and

@eval [iter(lattr(obj/foo.*),pemit(%#,[get(obj/%i0)]))]

The former puts each pemit on the queue. There's generally a bit of a delay there. The latter does it all now.

Rhost has @dol/inline, which lets you use command-syntax and operations (including @assert and @break and @include), to do them right now in the same entry in the command queue.

So yeah, I do mean inline in the command queue in that its not queuing new commands, but my terminology was deeply colored by my largely being a Rhost coder.

Thenomain

@ixokai

The command pulls text from another attribute so that it may be run in order by the command queue, "in-line".

We are nerding it up by disagreeing on terms but still conferring an understanding. That's one thing I love (both seriously and sarcastically) about coders: There is a great deal of time where a certain level of understanding is not enough. There is always more technical level to go. I remember a fight on Soapbox about the difference between Tiny's mod() and true modulus, and another about the reason math co-processors need extra help doing "9+9" math and how that deeply affects the way iter() works.

Whomever came up with the phrase "technically correct is the best kind of correct" is a liar on the highest order.

Which is my ultimate reason for this response.

Anyway.

Yes.

Ashen-Shugar

@thenomain said in Mux Logger Objects:

Yes.

Don't you mean maybe to the 99.9999999999999999999999999% of yes?

Thenomain

@ashen-shugar

Yes.

Derp

@Thenomain

These run off of a parent, right? Fallcoast's seem to be mostly set with a series of softcoded commands, which non-staffers can't see, right? Is there a version of this floating around somewhere that doesn't require elevated privileges to see the source for?

Thenomain

@derp

https://github.com/thenomain/Mu--Support-Systems/blob/master/Global Pose Logger.txt

I can check out and post @Skew's poselogger with his permission, of course.

(edit: nnnnghhhh, some of this is pretty horrible)