Having mapped 8,000 rooms of an extremely difficult world, I'm pretty confident that the new mapper has enough juju to handle other worlds as well. At this time, folks, let me know if you want certain features to make mapping your world possible/easier.
If anyone expresses interest, I'll work with them closely to make sure that anything in terms of feeding the data, storing, and tweaking the resulting map, flows without hiccups. For instance, if you are sending location data in a certain format that the mapper doesn't support OOB, let me know where to look and I'll add support.
Also, if you have any questions about what is already possible, and maybe implementation tips, use the forum on mudportal.com.
Are there any articles on how to get started on expanding my client features on here? I think I saw some scattered posts, but I'm hoping for something organized so I can jump into it.
If I need to be more specific, hmm. I guess some questions: Set the default screen size? Disable triggers? Custom logo (outside telnet app)? Filter chat channels to secondary window?
Are there any articles on how to get started on expanding my client features on here? I think I saw some scattered posts, but I'm hoping for something organized so I can jump into it.
If I need to be more specific, hmm. I guess some questions: Set the default screen size? Disable triggers? Custom logo (outside telnet app)? Filter chat channels to secondary window?
You can start by reading this thread and looking at the commented examples under "Articles & Files".
Could you post your specific questions to the support forum on the site? I'd rather address them there, as a step towards keeping everything in one place.
* New plugin, GroupTab, posted under "Examples". Displays group status and optionally your char's affecting spells. Understands Aardwolf-style GMCP. For a preview, connect to Bedlam with &debug=1 parameter.
* The ChatterBox plugin now emits the "chatterbox" event, after which it can dock other plugins as tabs (the GroupTab uses this functionality in the sample code). ChatterBox now has a more minimal look, and it supports "hidden" tabs that can be used to achieve more flexible output.
* Cleaned up on-connect protocol negotiations and added MSDP meta data being sent on client connect, including user's IP.
* Extended "Config" options in Javascript, including the option to soft-disable triggers for your game.
* New module, LoginPrompt, allows you to add a fast and easy cool-looking login dialog. It's a good example of what you can do with the Modal helper module.
* More configuration options let you control better how the app looks to your players. For example, the "solo" parameter lets them use Game Center's features but only lists your game and its profiles.
* App windows can now be collapsed down to their toolbar and their state saving for registered users has been improved.
* Many under-the-hood improvements toJujuMapper, including faster path-finding for click-to-move.
Games that do interesting things with the app API, MXP, or any other "beyond telnet" features, have a very good shot at being featured more or less permanently on the homepage.
* Based on excellent feedback from an RPI admin, added a multi-line input option that should make editing descriptions oh so much nicer.
* Smart copy and paste in ScrollView. Ability to download a log file at any moment with one click.
* ANSI Italics now supported.
* Docking custom tabs now supported by all windows, not just ChatterBox.
* You can now easily override the default processing functions for JujuMapper and MistyBars. For instance, you can configure them to listen to MSDP instead of GMCP and parse the data any way you need.
* Game Center now includes a folder with the complete current listing of games from MudConnect.com. Even if a game is not listed on TMP, players will be able to access it, save profiles for it, and customize their experience.
I love seeing how the site is coming together, great job. Hopefully I can grab a few minutes of free time this week and get a link up for you guys and your client.
Who says your game doesn't have its own mobile app?
If your browser is logged into the portal, any macros and triggers for the game will be auto-loaded.
Granted, native apps are more capable. But this is currently the only mobile app (I know of) that has MXP support. And you can't beat the part where you get it with 0 effort.
* Tested on iPhone iOS7. Test on other phones, report issues, and win bonus points.
I've enabled CloudFlare on the portal, so let's see what that does for performance. Thanks to Zeno for suggesting it.
P. S. For those interested, I'm using the safest settings right now, and I've only had to tweak a few lines of code. They claim this would still result in about double the speed. I don't think I can (ever?) enable their medium settings because they mention async loading of all JS. How would one ever make sure that no code on the page assumes previous code has loaded? Just thinking about it makes my head hurt. Maybe they don't mean what I think they mean…
28 Feb, 2014, Ssolvarain wrote in the 218th comment:
They claim this would still result in about double the speed. I don't think I can (ever?) enable their medium settings because they mention async loading of all JS. How would one ever make sure that no code on the page assumes previous code has loaded?
That's actually an easier problem to solve than you'd think. I'd be happy to discuss it with you over e-mail/PMs (since it's lengthy, and depends on your specific code and use cases).
They claim this would still result in about double the speed. I don't think I can (ever?) enable their medium settings because they mention async loading of all JS. How would one ever make sure that no code on the page assumes previous code has loaded?
That's actually an easier problem to solve than you'd think. I'd be happy to discuss it with you over e-mail/PMs (since it's lengthy, and depends on your specific code and use cases).
It's not so much that I don't know how to do it. It's that I don't know what they'll be doing. For example, are they able to recognize and not cache the dynamically generated code when people insert customizations? That's a very non-typical use case: it's a php file serving potentially different js every time, and some of it may depend on frameworks being loaded ahead of it.
I know that if I care to optimize that much, I can just do my own async loading, using success callbacks or chained promises even. But is it time well-spent? After all, the centerpiece of the site is the client, and the client page is almost entirely built by JS, so it's not like loading it async will make the HTML load faster in the eyes of users.
If anyone expresses interest, I'll work with them closely to make sure that anything in terms of feeding the data, storing, and tweaking the resulting map, flows without hiccups. For instance, if you are sending location data in a certain format that the mapper doesn't support OOB, let me know where to look and I'll add support.
Also, if you have any questions about what is already possible, and maybe implementation tips, use the forum on mudportal.com.
Some eye candy: