MUDRammer help?

skew

Anyone out there possibly able to help? I'm using MUDRammer on my iPad. I turned on my bluetooth keyboard. There is a bluetooth keyboard setting, but when I use that, it collapses the keyboard, and then the input window ends up BEHIND the copy/paste/undo/redo bar.

See the image below:

what is?!

Anyone know how to remove this?

@mudrammer got any tips?

Roz

If you have a bluetooth keyboard, why would you need to an on-screen keyboard?

Auspice

Well, I know it used to leave the on screen keyboard there regardless of external. So... my guess is it may still just be ongoing tweaks?

skew

@Roz said in MUDRammer help?:

If you have a bluetooth keyboard, why would you need to an on-screen keyboard?

When you turn off the on-screen keyboard, the input window goes behind the undo/redo/copy/paste bar. That's my entire problem.

If you leave it "on", it goes black, and I can see my input field (but it eats up space).

Thenomain

@skew said in MUDRammer help?:

@Roz said in MUDRammer help?:

If you have a bluetooth keyboard, why would you need to an on-screen keyboard?

When you turn off the on-screen keyboard, the input window goes behind the undo/redo/copy/paste bar. That's my entire problem.

If you leave it "on", it goes black, and I can see my input field (but it eats up space).

This is a bug with MUDrammer that I didn't remember to file. @mudrammer sometimes reads here, but you'd probably be best contacting him more directly.

TiredEwok

I would contact him through the app itself. There is a feedback and support option that you can use to get help or in touch with him.

mudrammer

~appears in a puff of logic~

There are 2 things going on in your screenshot:

The big black space shouldn't show up when you have a bluetooth keybaord connected. Try enabling MUDRammer's Settings -> Advanced -> Bluetooth Keyboard option. This tells MUDRammer you have a hardware keyboard connected. After that's on, you can press the eject or show/hide keyboard key on your hardware keyboard to collapse the extra space.
The extra bar at the bottom is the shortcut bar, a new feature in iOS 9. You can hide it by disabling “Shortcuts” under iOS Settings -> General -> Keyboard.

MUDRammer should definitely handle both of these scenarios much better than it is today. Egg on my face...

Roz

So MUDRammer says it supports xterm, but it's only showing 16 colors for Arx. I can't find a setting anywhere to turn things off or on. Is this an Evennia thing? Is it just me?

ThatOneDude

What happens if you switch to DuckClient (app in chrome)?

Roz

@ThatOneDude Colors are fine there.

mudrammer

@Roz MUDRammer has full support for xterm (256 colors). There's no setting in MUDRammer for this; rather, this is almost always a terminal setting your character should make on the MU* you're connected to. Once you start receiving xterm colors, MUDRammer should display them properly.

Roz

@mudrammer Yeah, but every other client with 256 color options seems to display Arx correctly. There's not a setting I've had to switch on for any other client; the clients that support 256 colors just show them.

mudrammer

@Roz Other clients may be using TTYPE to automatically negotiate a terminal type with the server. MUDRammer supports TTYPE, but there's enough variation with terminal types that some servers may not recognize MUDRammer's support for xterm. I would recommend you look for a term (or similar) command in-game.

Roz

@mudrammer This must be an Evennia thing, because the codebase is so different from anything else. But there's no in-game switch. It specifically says it doesn't try to check what your client supports, actually: it just spits out xterm and your client either can read it or it can't:

------------------------------------------------------------------------------
Help topic for @color (aliases: color)

testing which colors your client support

Usage:
  @color ansi|xterm256

Prints a color map along with in-mud color codes to use to produce
them.  It also tests what is supported in your client. Choices are
16-color ansi (supported in most muds) or the 256-color xterm256
standard. No checking is done to determine your client supports
color - if not you will see rubbish appear.

Suggested: @color, ooc, look, @ooc
------------------------------------------------------------------------------

mudrammer

@Roz Hm, I'm not sure I follow? You say "there is no in-game switch", but your quoted text looks like the in-game switch you need. Seems like @color xterm256 should do it, right?

Roz

@mudrammer No no, the @color command in this instance just prints a color map, it doesn't set anything.

mudrammer

@Roz I connected to Arx with the debugger attached. Arx does engage in TTYPE negotiations with the client, which seems at odds with Arx's own in-game help on the @color command that you posted above.

Arx says DO TTYPE
MUDRammer says TTYPE MUDRAMMER
Arx says SEND TTYPE (per RFC 1091, if the server rejects a terminal type, the server can enumerate multiple ttypes in the client by requesting ttype again)
MUDRammer says TTYPE XTERM
Arx says SEND TTYPE
MUDRammer says TTYPE ANSI
Arx says SEND TTYPE
MUDRammer says TTYPE ANSI (MUDRammer has exhausted its list of ttypes and signals this by repeating the last ttype a second time)

It appears that Arx rejected all of MUDRammer's ttypes and ended up with ANSI, either because it was the default or because it was the last one that MUDRammer sent.

So... is it a bug in MUDRammer or in Arx? Probably both? ¯\_(ツ)_/¯

Roz

@mudrammer Thanks! At the suggestion of Arx's headwiz, I dropped this into a bug report for the coder.

Thenomain

@Roz said in MUDRammer help?:

@mudrammer Thanks! At the suggestion of Arx's headwiz, I dropped this into a bug report for the coder.

You stand in a dark room and face a mirror, then repeat the name three times: @Griatch, @Griatch, @Griatch.

@mudrammer's last post, two above. I understand that telnet negotiations can be a pain in the patoot, but it sounds better to get you both together on this one directly.

Griatch

@mudrammer

if the server rejects a terminal type, the server can enumerate multiple ttypes in the client by requesting ttype again

Evennia does not reject the terminal type when it keeps asking for TTYPEs. It follows the Mud Terminal Type Standard, where the server keeps asking the client for information and makes use of the info. So it properly records the client name, the XTERM terminal type and that it supports ANSI.

In this case it looks to be a bug in Evennia though, since it should have seen "XTERM" and assumed that to mean xterm256 is ok. I think I have fixed the issue, as mentioned in the Evennia issue tracker but have no access to Mudrammer so will wait to close it until it's tested.

In general, you can enforce options with @option xterm256=True. Use @option/save xterm256=True to have Evennia enforce settings persistently. For some clients not using TTYPE/MTTS this may be the only way to support its capabilities since Evennia will default to ANSI colors if it knows nothing about the client (this seems to usually be ok in practice) but will not presume xterm256 is supported.
.
Griatch