Client-Side Spacing


  • Pitcrew

    I am on a game which has no posebreak and sadly, attempts to talk staff into adding one have failed. In a 1-on-1 scene, I can use %r to provide some pose spacing, but that doesn't work when there's multiple people in the scene.

    I've heard before of people configuring something on themselves (soft code) or on their client. Is there a way to do this that won't affect, say, pages and channels? I'm using Atlantis and the game itself is on TinyMUSH.


  • Pitcrew

    This would be a beautiful thing


  • Coder

    Sadly, since there's no OOB data classifying lines over standard telnet from TinyMUSH, while it's possible to make extra lines show up in Atlantis through the event system, it would be very hard to do without potentially affecting @mail, +bb, etc.

    Only the server has context to know the type of output, in order to reliably do this.


  • Coder

    That said, you could almost certainly do it using ahear via softcode, depending on how pose/say work on that game. If it comes from a language system you'll be able to check the enactor, for instance.

    However, trying to write softcode in browser from a phone is not something anyone sane should attempt, so someone else may be able to help.


  • Coder

    Assuming it is on a newer server a simple @hook/after for the various commands with a %r would for posebreaks for everything wanted.


  • Coder

    Both the @hook and @ahear would have to be global though to work right AFAIK. You can make your own poses have spacing around them with personal soft code, but I'm unaware of any trick for affecting other people's.


  • Coder

    Right, but a simple ifelse(hasattr(%!,poseon),%r,) in the hook would default it to off. I am kind of amazed hooks haven't been personalized yet so players could hook things on as a secondary to global hooks, but then again, the possible security risks are astronomical.


  • Coder

    @Seamus Yeah the code is ludicrously simple and already exists in various forms for the taking, so I don't get why staff would be so adamantly against putting in a global hook. But since that's what we're dealing with according to OP I think they're stuck.


  • Coder

    @faraday Maybe it is code ignorance. A looking fear of a security risk.


  • Coder

    @Seamus said in Client-Side Spacing:

    @faraday Maybe it is code ignorance. A looking fear of a security risk.

    It can be, but the idea has merit.

    What do people think about adding a SPEECH_PREFIX and a SPEECH_SUFFIX attribute on themselves that if met when anyone is issuing a say or pose at your location it will issue the speech_prefix, the message, then the speech_suffix?

    There would be no method to identify the player doing it and it wouldn't evaluate functions, only %-substitutions.

    This would be a hardcode mod.

    Thoughts?


  • Coder

    @Ashen-Shugar I think that's a worthwhile idea in a lot of ways, but I don't think it'll help the original poster a lot in this case, sadly. Unless you can convince their staff to swap out the hardcode to pick up a feature.

    I also do think there could be an argument made for functional expansion; if I had the origin command in a register, I could do interesting conditional things like add out-of-band data for the client to process. Like adding a conveniently, consistently parseable string saying 'this is a page from <X>' with a begin/end tag, so that even multi-line pages could be pulled into a specific spawn.

    Of course, at that point, you're making this wildly more complicated, but it's still a personal pipe dream... to have a way to snag multi-line outputs for client-side processing. And if we're discussing adding user-specific formatting hooks that have a chance to alter output, making them conditional based on the origin command and enactor makes me happy.

    From a more practical standpoint, making a way to process the entire output would allow for other nice things, like 'if this is a say/pose/emit, replace all instances of %r%t with just %r, trim %r off the beginning and end, then append %r to the end.' Because then you've just managed to standardize formatting even for the people who want first-line indents, or who add %r to the end of their poses already.

    But at that point we're probably getting a bit beyond the scope of the original request.


  • Coder

    @Sparks said in Client-Side Spacing:

    @Ashen-Shugar I think that's a worthwhile idea in a lot of ways, but I don't think it'll help the original poster a lot in this case, sadly. Unless you can convince their staff to swap out the hardcode to pick up a feature.

    I also do think there could be an argument made for functional expansion; if I had the origin command in a register, I could do interesting conditional things like add out-of-band data for the client to process. Like adding a conveniently, consistently parseable string saying 'this is a page from <X>' with a begin/end tag, so that even multi-line pages could be pulled into a specific spawn.

    Of course, at that point, you're making this wildly more complicated, but it's still a personal pipe dream... to have a way to snag multi-line outputs for client-side processing. And if we're discussing adding user-specific formatting hooks that have a chance to alter output, making them conditional based on the origin command and enactor makes me happy.

    From a more practical standpoint, making a way to process the entire output would allow for other nice things, like 'if this is a say/pose/emit, replace all instances of %r%t with just %r, trim %r off the beginning and end, then append %r to the end.' Because then you've just managed to standardize formatting even for the people who want first-line indents, or who add %r to the end of their poses already.

    But at that point we're probably getting a bit beyond the scope of the original request.

    Well, I may have just done it in a workable way.

    I have right now three arguments being passed to the SPEECH_PREFIX and SPEECH_SUFFIX.

    %0 - The pose/say that was last done (which would include multi-line)
    %1 - The date in the form MM/DD/YYYY
    %2 - The time in the form HH:MM:SS

    I essentially want to avoid functions as how this works could potentially cause some loop-parsing if I was to enable function evaluation.

    What you're essentially looking for is a way to actually format the poses and says like a @pageformat ala Penn.

    While this can be in the cards for a future update, right now it's too costly to add for poses and says.

    Update: This has just been pushed to the latest Rhost 4.0 git repo for those who use Rhost.

    Update #2: This also handles @emit and \


  • Coder

    @Ashen-Shugar

    Why split date and time when there is timestamp available?

    I'm thinking enactor dbref may also be good, a quick and dirty nospoof.

    Also a pony.


  • Coder

    @Thenomain said in Client-Side Spacing:

    @Ashen-Shugar

    Why split date and time when there is timestamp available?

    I'm thinking enactor dbref may also be good, a quick and dirty nospoof.

    Also a pony.

    Because it was easy to do, and some people may find date superflurous over time.

    Also, dbref#'s added, though if the enactor is tagged 'spoofing' then the dbref# will return as #-1.


  • Coder

    @Sparks said in Client-Side Spacing:

    I also do think there could be an argument made for functional expansion; if I had the origin command in a register, I could do interesting conditional things like add out-of-band data for the client to process. Like adding a conveniently, consistently parseable string saying 'this is a page from <X>' with a begin/end tag, so that even multi-line pages could be pulled into a specific spawn.

    Of course, at that point, you're making this wildly more complicated, but it's still a personal pipe dream... to have a way to snag multi-line outputs for client-side processing. And if we're discussing adding user-specific formatting hooks that have a chance to alter output, making them conditional based on the origin command and enactor makes me happy.

    And..... done.

    This is optionally available in the latest RhostMUSH 4.0 engine with the @admin (config) parameter posesay_funct enabled (default disabled).

    The SPEECH_PREFIX and SPEECH_SUFFIX attributes only work for connected player types, and will not work if the attribute is set NO_COMMAND.

    If you trigger the cpu alert (by blowing away the cpu alert) it naturally logs the attempt then sets the attribute NO_COMMAND for safty sake.

    So, you got your pipe-dream. Enjoy :)


Log in to reply
 

Looks like your connection to MU Soapbox was lost, please wait while we try to reconnect.