Newb question: Is client.js run from the client or on the server?

[Ragnar]

My apologies for the probably very basic question but I'm curious where that script's functions actually run, my curiosity stems from where I'd looking to place some conversions from mud-derived MXP-like short-hand to html code.  I'm hoping its running on the client itself that's all.  IE if the mud sends something like 'BG-black' which client.js has a function that would convert that to <span style="background-color:black"> I'm hoping that's only done after the shorter version has made its way up from the mud to the connection server.php process and across the internet to the client before converting it to the full html based code.  (those are just examples, I haven't actually imped anything like this yet).  Purely from a bandwidth conservation perspective is what I'm hoping that's the way it operates.

[Michael Elford]

Short answer, client.js is run on the client only.

Longer answer...

Everything in wm_server is run on the server, everything in wm_client is run in the clients browser.  If you check out my previous post on MXP, you'll see how I've implemented it with a whole lot of regex's.  This includes stripping out things like Mobs/Items/Prompts/Mini-Maps and putting converting them into HTML "stuff".  It's not pretty (yet) but once you extract the data you can do anything you want with it.

Depending on your implementation, just watch that a player can't screw with other people by sniffing out some of your MXP code and then "SAY"ing it or otherwise getting the mud to output it.

[Ragnar]

This is fantastic to hear :)  I was leery of injecting full html due to the added bandwidth but it sounds like if its done on the client's side that makes it moot.  yah I've considered concepts to avoid players injecting their own and I've got a method in mind to utilize my existing colour escape code to do this (my mud automatically filters out specific sequences that are known to be 'server-side-only' codes out of all input before its processed so even if they figure out what the escape code is that the webclient is watching for they can't trigger it.  Good times :)  I've already setup the mud to be listening on two ports with the regular port for telnet sessions and the other only visible to the phub server and accepting webclient along with the mud flagging those connections appropriately so it knows which ones to send the special stuff to vs regular inline.  The whole goal in this is getting stuff like HP/Mana bars to display on the webclient and slowly shift our vMap concept over to it as well.