Posts made by grapenut

Very neat. You could do this on PennMUSH using the @http command without the PHP backend and news file interface.

@adrick Heh. I should probably stop sending those altogether. I don't think it really matters for anything anyway.

The MUSH Portal can connect to TeenyMUSH too! Try http://mushportal.com/?teenymush.dynu.net:8001/connect

The MUSH Portal is an integrated web platform for PennMUSH servers (PennMUSH v1.8.7p0 or higher required). The Javascript web client runs entirely in your own browser and is built with a responsive mobile-friendly UI. It features a fully customizable 256-color terminal emulator with a window manager that enables you to manage multiple chat spawn windows and integrated MUSH apps like a reader/composer for @mail and Myrddin's BBS. The configuration editor allows the user to define custom taskbar buttons, text triggers, command macros, automatic timers and key bindings. This is the initial beta release, so I would greatly appreciate feedback and suggestions.

For players: try it live on my very minimal demo server at http://www.mushportal.com, or try it on your own favorite PennMUSH v1.8.7p0 or higher game like the M*U*S*H development server at http://www.mushportal.com?mush.pennmush.org:4201. Works great on mobile!

For admin: add the MUSH Portal to your own website using the Github link above. Also included is an example implementation of the softcode event handler and global command object that integrates with the web client using the JSON API. This allows you to exchange information with the client behind-the-scenes so you can build your own custom apps like CharGen, +sheet, combat, friends list, etc. Please contact me if you need assistance or are interested in creating your own integrated apps. I would love to help!

If you have any suggestions or feedback please feel free to open an issue on the Github repository, or leave a message on the dev server at node.grapenut.org:2000.

@thenomain The issues with Firefox and Safari should be fixed now.

@thenomain Yeah it was recently reported that Firefox and Safari are having issues, though they were working not too long ago. I've done a ton of new updates recently and haven't gotten around to bug fixing other browsers yet. Chrome support is always 100%, and I've been told it currently is working fine in Opera as well.

@kumakun said in What's out there now and what has been attempted? A codebase discussion.:

@arkandel I wholeheartedly agree. I was /thinking/ of telnet because I wanted to make it approachable for people stuck to their telnet clients.

It would be interesting to define a websocket protocol to standardize server/client communications so someone so inclined could make a ws based client capable of connecting to multiple servers. I entertained a webRTC data connection for a second, but, overkill.

You will be happy to know that a websocket protocol and browser-based clients already exist for the latest PennMUSH release, with basic support for RhostMUSH in a private fork as well. The newest client can be found at https://github.com/grapenut/mush-portal with a live demo at https://node.grapenut.org. It already integrates with the basic stuff like room navigation/contents, @mail and Myrddin's BB. I'm currently working on per-game customization and integration for things like chargen, character sheets, or even browsing logs/wiki.

It features a full 256 color terminal with support for inline HTML/Pueblo and out-of-band JSON communication. There is a built-in windowing system which powers the @mail and +bb apps. Something like chargen or +sheet could spawn it's own fully interactive window. Some of the planned features include custom events, triggers, macros and keybinds. These could be used to create separate chat windows, for instance, where your channels and/or pages are displayed with custom coloring, etc. Your game's wiki could be accessed simultaneously through text in-game or formatted with HTML/CSS in a popup window.

There's no reason to choose one or the other. All of this runs on a standard PennMUSH server, so you can support the traditional telnet users while at the same time offering an enhanced experience for Web users. It comes with an event handler object that eases integration, but also works reasonably well for an updated PennMUSH without any server-side changes. It's built with JavaScript and ReactJS (like Facebook!), so there is a HUGE framework of tools available and it's pretty easy for people to modify to suit their needs. This is still very much a work-in-progress and I'm currently looking for help making it more mobile-friendly, with a possible native mobile app down the line.

@arkandel said in Site access blocked due to password being sent unencrypted.:

I won't have to do actual work to implement Let's Encrypt here.

https://certbot.eff.org/

It takes about 30 seconds using Certbot to setup Lets Encrypt for the web server of your choice. Handles all of the config updates for you. Handles automatic renewals for you.

@derp said in Setting up a builder Bit:

they will be regularly running searches and doing privileged @dols to fix things and ensure consistency

You would be better off giving them additional see_all powers. A builder already controls everything it owns.

As of last night Raevnos pushed the SQLite branch to master which means PennMUSH has the json_query() and json_map() functions for parsing JSON strings. The code for PennMUSH to receive JSON data is already there but not hooked to anything, so it should be a quick fix to allow Penn to receive JSON and pass it to a handler.

The website never needs to send softcode, that was just an example. For a lot of things, you will want dedicated commands that are just used by the website to generate a JSON response that don't have a terminal equivalent (e.g. context menus, player lists, etc). But for something like a +finger or +who you can show the standard text in the terminal, show a popup version with links and images on the side, embed links and images directly in the terminal text, or some combination of the 3.

@faraday said in A new platform?:

Anyway, I never said it was impossible to build a web portal in PennMUSH, I said it was not the soundest technical approach and false to equate it with a robust and dedicated JSON API. But best of luck to you regardless.

Sorry. I didn't mean to suggest that Penn's economy-class JSON API was in any way equitable to Ares' robust and dedicated first-class JSON API. Thanks for your kind wishes I guess?

@faraday said in A new platform?:

No, it really isn't, and there are a ton of articles on the web like this one explaining why. Websockets require a lot of fallback layers to implement properly across different browsers and versions, and are prone to significant firewall issues.

Websockets work great for what we are doing. We don't have the same requirements or fault tolerances as an enterprise website doing financial transactions, for instance. If your command doesn't get through because the connection died, the command is sent again after reconnecting. It is subject to the exact same firewall and proxy issues as your telnet connection, and I probably won't lose too much sleep if it doesn't work perfectly on IE9.

Again, no it can't. There's a reason JSON as a structured parsing language has overtaken other homegrown string parsers, because it addresses countless issues like nested quotes and whatnot.

JSON is just plain text. A command is just plain text. Specifics of JSON parser implementations aside, regular commands allow you to easily reuse all the same server-side code you've already written. What kind of data do you envision needing to be sent to the server from a web client that absolutely must be in a JSON object, and how would you allow telnet users to achieve the same functionality while only using standard commands?

I applaud you/whomever for attempting to retrofit web capabilities onto older MU servers for those who want to use it. That's a positive. But arguing that a cobbled-together "think wsjon()" thing is equivalent to a first-class dedicated JSON API flies in the face of every good programming practice I know.

I just cobbled together a quick softcode example for how to do what you asked from the browser. There is a first-class JSON API in PennMUSH for building the objects with proper formatting and escaping. I would absolutely recommend making a dedicated command for triggering an event like that rather than trying to cobble it together on the fly, but you asked.

I'm not trying to say what you've done with Ares was easy, or that making a web portal for PennMUSH wouldn't be a lot of work. There isn't a web portal built for PennMUSH yet exactly because it is a lot of work. To suggest that it's impossible because it would be hard or because the network protocol is somehow limited is a mistake though.

@faraday said in A new platform?:

For a single command, sure it's not so bad, but if you wanted to convert one of the existing code suites like mine or Volund's? It would be a massive undertaking.

Yes, somebody will have to do some work to implement a new thing. Putting data into a JSON object and sending it is not the hard part though. It's a simple extra softcoding task that's less complicated than the @pemit part of a command. One person could implement it for yours or Volund's code suites and then it would be done for everybody. The hard part is figuring out what data to send and how to display it in the browser.

Except that then limits the web client to implementing only what you can do with regular text commands.

JSON is sent as a string. Whatever complex information you would want to format into a JSON object can just as easily be formatted as a +command that=has=multiple=arguments. If you really want to send commands as JSON you can make a { command that parses it, but then you still need to implement individual handlers on the MUSH for different objects and commands. It's easier to just use the regular command interface that we already have implemented, with perhaps an additional low level version of some complicated +commands that accept multiple arguments at once.

For example - you couldn't do something like a character directory, because there is no single "get me a list of all characters" command. (You'd have to add one.)

The client can send a think command with whatever softcode to generate an arbitrary JSON list of players, e.g.

conn.send('th wsjson(\{"playerlist": [[iter(lsearch(all,type,player),"%i0",,\,)]]\})')

The only difference is that the display is event-driven instead of inline, but that's the standard paradigm for browser user experience anyway.

Also websockets are useful, but a bit unreliable for the basis of a robust web implementation.

It's as reliable as your telnet connection to the MUSH. You need to be connected and authenticated to exchange useful data, but reconnecting is handled automatically in the background whenever the connection is lost. It's no more or less reliable than using an API key to grab some data from a google API.

Just to be clear - I agree with you that you can make a web client with PennMUSH given enough time and effort. All I'm saying is that I don't think you can make "the same sort of web portal" as you said earlier. The interface limits what you can do.

I disagree. The only limit is that nobody has done it yet. I commend Ares and Evennia for tackling this problem. My original comment was only to say that PennMUSH (and RhostMUSH too) can be retrofit to have a similar web portal interface if someone with web developing skills is interested. It can be done in parallel with the existing telnet interface to support both types of users.

@faraday said in A new platform?:

@grapenut That’s cool but my general point was that you have to go implement all that from scratch. Existing commands like +who and page and +finger don’t do JSON intrinsically (right?).... and is there a way to send JSON commands //to// the game?

Building and sending JSON data strings is trivial though. The hard part is doing something useful with it on the client. What each game chooses to display and how is going to be different for every game, so it needs to be implemented from scratch anyway. A +who side panel in the browser could be something like an angular.js list and you just feed it an array of player data that you build at the same time as you are @pemitting it to the terminal. Same thing for a +sheet or a map, etc.

As for sending JSON commands to the MUSH there's really no need and implementing a parser wouldn't be worth it. It's just formatted text so you might as well send it as regular text commands.

@faraday said in A new platform?:

Not effectively though. You can do a basic web client, but to do more advanced integrations requires a more advanced interface. Just shipping commands like "WHO" to the game and trying to parse ASCII text back out is not going to get you very far.

The MUSH can send JSON (in addition to ASCII) for out of band communication with web clients. It's as easy as adding wsjson(object) to the end of your @pemit. It is only sent to web sockets so you don't have to worry about hiding it from telnet connections.

@three-eyed-crow Don't forget, with the websocket client you can make the same sort of web portal with any MUSH.

I have been working on an idea for turn-based 2d combat using the web client to draw an overhead view of the tilemap and characters. I was thinking a smaller 16x16 grid within each room, like the original Zelda.

Roleplaying does not inherently mean assuming the identity of a unique character. For some it means inserting their own alter ego into a fantasy setting. That's why it can be difficult for them to separate the IC actions from the IC or OOC motivations.

What's wrong with min-maxing? If players enjoy doing that, why keep them from it?

Obfuscating things leads to people not understanding and not wanting to use your system. Players want to feel like they are in control of their decisions, and to do that they need all the information on the rules and state of the game.

I think what you really want to do is make min-maxing less effective as a strategy. Break your stats down into tiers, for instances 0-33 is tier 1, 34-66 is tier 2, 67-100 is tier 3. Stat comparisons can use the tiers as the main weight, with the actual stat values being a minor modification to that. An 80 and a 100 would both be tier 3, but the 100 would perhaps have a small advantage that scales with diminishing returns.

@nymeria I'm so glad you like it!

You'll need to be good with Javascript in order to do much else with the minimal example client. I kept the HTML/CSS very basic so you can copy and paste it into your own website. A little spit and polish on the styling will go a long way towards blending with your theme.

I've been working on a more advanced example that's bundled with a window manager to allow for multiple panels, e.g. a detachable channel window or a dynamic map. I hope to make it a little more straight forward for MUSH Wizards to use JSON to drive those displays without needing to know any Javascript.

I'm also looking to make it more mobile-friendly with better CSS. I'm very much open to ideas and suggestions for improvement!