25 Oct, 2013, plamzi wrote in the 201st comment:
Votes: 0
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.

Some eye candy:



31 Oct, 2013, Zeno wrote in the 202nd comment:
Votes: 0
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?
31 Oct, 2013, plamzi wrote in the 203rd comment:
Votes: 0
Zeno said:
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.
04 Nov, 2013, plamzi wrote in the 204th comment:
Votes: 0
Some updates:

* 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.
17 Nov, 2013, plamzi wrote in the 205th comment:
Votes: 0
Quick update:

* 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.

* API Documentation has begun and already covers a fair bit of ground: http://www.mudportal.com/forum/api-docum... .

* 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.
20 Feb, 2014, plamzi wrote in the 206th comment:
Votes: 0
Quick update:

* 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.

* API documentation added for MistyBars.

* 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.
25 Feb, 2014, plamzi wrote in the 207th comment:
Votes: 0
Introducing the new site chat, for when it gets lonesome to develop or play:

25 Feb, 2014, Dean wrote in the 208th comment:
Votes: 0
Some nice progress there Plamzi!
25 Feb, 2014, Splork wrote in the 209th comment:
Votes: 0
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.
26 Feb, 2014, plamzi wrote in the 210th comment:
Votes: 0
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.

* Tablet support is currently limited.
26 Feb, 2014, Davenge wrote in the 211th comment:
Votes: 0
Can't seem to find the chat, I click "play" the window comes up, I'm logged into my account for the website but there's no Portal Chat for me. :(
26 Feb, 2014, plamzi wrote in the 212th comment:
Votes: 0
Right now, the chat piggybacks on the same proxy connection. It will show up in Game Center when you connect to a game.
27 Feb, 2014, plamzi wrote in the 213th comment:
Votes: 0
Moved chat to its own socket. So you no longer have to play :) Phew!
27 Feb, 2014, Tijer wrote in the 214th comment:
Votes: 0
lookin good… ability to see who else is connected to the chat would be nice tho… :P
27 Feb, 2014, Davenge wrote in the 215th comment:
Votes: 0
plamzi said:
Moved chat to its own socket. So you no longer have to play :) Phew!


Nice!
27 Feb, 2014, plamzi wrote in the 216th comment:
Votes: 0
Tijer said:
lookin good… ability to see who else is connected to the chat would be nice tho… :P


Of course–as soon as we hit 100+ concurrent chatters!
27 Feb, 2014, plamzi wrote in the 217th comment:
Votes: 0
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:
Votes: 0
28 Feb, 2014, Lyanic wrote in the 219th comment:
Votes: 0
plamzi said:
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).
28 Feb, 2014, plamzi wrote in the 220th comment:
Votes: 0
Lyanic said:
plamzi said:
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.
200.0/279