Howdy, Stranger!
Categories
- 6.2K All Categories
- 3.1K Everything Achaea
- 1.5K North of Thera
- 26 Archives of the Terraformer
- 257 The Matsuhama Arena
- 885 The Golden Dais of Creation
- 299 The Scarlattan Theatre
- 149 The Blank Canvas
- 2K Getting Help
- 412 General Questions
- 258 Quick Class Questions
- 1.3K Tech Support
- 313 Client Help
- 486 Curing Systems and Scripts
- 841 Off-Topic
- 255 The Wander Inn
- 586 The Universal Membrane
- 298 Class Discussions
- 298 Individual Class Sections
- 20 Alchemist
- 9 Apostate
- 30 Blademaster
- 9 Depthswalker
- 14 Druid
- 4 Infernal
- 20 Jester
- 19 Magi
- 34 Monk
- 11 Occultist
- 8 Paladin
- 7 Priest
- 29 Runewarden
- 18 Sentinel
- 26 Serpent
- 20 Shaman
- 9 Sylvan
HTML5 Suggestions
I know there's a feedback button, but it strikes me that it might be useful to have a thread allowing for discussion rather than a bunch of independent feedback responses. I'm not really sure where to put it given that this is technically for "client help" and not suggestions, so please move it somewhere more appropriate if this isn't the right place.
Having fiddled with the HTML5 client now, there are a few places where I think some clear improvements could be made without too much work.
(1) Documentation. This is a no-brainer. Right now, this is probably the single greatest headache. It doesn't need a manual (though that would be nice), but there has to be a resource where I can just see all of the methods in the client object laid out in a simple way. It took me nearly half an hour of digging through the code by hand to find out that the way to retrieve the client's target was client.current_target(). That's unacceptable. This should be priority #1. Whoever is in charge of this should stop working on anything else and just get the documentation done - waiting until the client is "finished" is going to mean never having documentation ever.
(2) More documentation. Basic functions would be nice, but what would be wonderful is documentation allowing us to easily write our own widgets for those beautiful little frames. The ones that already exist are nice, but if it were relatively easy to write a limb counter display and get it to show up in one of those tabbed frames? Get out of town.
(3) Packages and groups. Reflex packages are groups, or at least they should be. Groups should be easy to package and export. The division between packages and groups isn't doing anything right now except adding needless complexity to the system and clunkiness to the UI (since you have to use that drop-down menu to switch between packages rather than the quite nice UI for opening and closing groups). Get rid of "packages" and make it possible to export any group. When you import a group, it should just appear as a top-level group like any other group.
(4) Add scripting to keybinds. This one is just mysterious - keybinds should have the same action types as aliases rather than only being able to send commands. I imagine this is just an oversight. Right now, having to make a function and call it via a command if I want a keybind to run code is very messy.
(5) Get rid of "functions". I think I understand the idea behind these, but it isn't a good one. JavaScript already has functions. You define them with the function keyword. Having this weird degenerate pseudo-alias additional "function" thing is confusing and doesn't actually add anything - if you want your alias to call a function, instead of selecting "call a function" as its action, you should just be selecting "execute a script" and writing the function call directly into it. Anyone who is capable of writing the code in a function is also capable of writing a normal function call. This is especially a problem given that you can call functions like aliases from the command line, which means you need to give them really silly names if you don't want to be able to accidentally run them from the normal prompt. If you want an alias, you should use an alias. Functions should not be aliases. If you want a function, you should use a function. Functions should just be normal JavaScript functions. This is an easy fix: just get rid of the separate "function" UI element thing. At the very least don't ever force me to use them like you do right now with onLoad - the problem with getting rid of them right now is that the only place to define global functions so that you can call them from alias scripts is the funky onLoad "function", which brings us to the even more crucial #6.
(6) Turn onLoad into a separate type of UI element. For one, the "function" UI objects ought to go, so we need some generic place to store the functions we're going to be calling in the normal JavaScript way. More crucially, it's extremely bizarre that you can call the code in onLoad by typing "onLoad" into the normal game prompt. That should pretty emphatically not be possible. If someone wants to write an alias to do that, sure, go right ahead, but it shouldn't be the default, unalterable behavior. That's crazy. Instead, just add a new pane to the whole UI for "scripts". These are scripts that execute when the system loads in (and rerun whenever you save them) - functionally they're all just a series of onLoad "functions". This corresponds pretty much exactly to Mudlets "scripts", which is the right way to do it. If you're writing a serious system of any kind, your onLoad is going to be gigantic and this also helps to organize it without resorting to having onLoad call a bunch of "functions" that become callable like aliases from the normal game prompt.
New functionality is always nice, but I honestly think the HTML5 client is already plenty powerful for very nearly anything you could want to do. The few features it doesn't offer pale in comparison to the problems of usability. What the HTML5 client needs right now is not more features, it needs documentation and it needs simplification. The package/group distinction isn't doing anything useful. The concept of "functions" is, if anything, doing active harm to the usability of the whole thing. onLoad is an incredibly clunky way to handle an absolutely essential function (inserting variable and function declarations into the global namespace on load).
These are the things holding the HTML5 client back, not lack of features.
Having fiddled with the HTML5 client now, there are a few places where I think some clear improvements could be made without too much work.
(1) Documentation. This is a no-brainer. Right now, this is probably the single greatest headache. It doesn't need a manual (though that would be nice), but there has to be a resource where I can just see all of the methods in the client object laid out in a simple way. It took me nearly half an hour of digging through the code by hand to find out that the way to retrieve the client's target was client.current_target(). That's unacceptable. This should be priority #1. Whoever is in charge of this should stop working on anything else and just get the documentation done - waiting until the client is "finished" is going to mean never having documentation ever.
(2) More documentation. Basic functions would be nice, but what would be wonderful is documentation allowing us to easily write our own widgets for those beautiful little frames. The ones that already exist are nice, but if it were relatively easy to write a limb counter display and get it to show up in one of those tabbed frames? Get out of town.
(3) Packages and groups. Reflex packages are groups, or at least they should be. Groups should be easy to package and export. The division between packages and groups isn't doing anything right now except adding needless complexity to the system and clunkiness to the UI (since you have to use that drop-down menu to switch between packages rather than the quite nice UI for opening and closing groups). Get rid of "packages" and make it possible to export any group. When you import a group, it should just appear as a top-level group like any other group.
(4) Add scripting to keybinds. This one is just mysterious - keybinds should have the same action types as aliases rather than only being able to send commands. I imagine this is just an oversight. Right now, having to make a function and call it via a command if I want a keybind to run code is very messy.
(5) Get rid of "functions". I think I understand the idea behind these, but it isn't a good one. JavaScript already has functions. You define them with the function keyword. Having this weird degenerate pseudo-alias additional "function" thing is confusing and doesn't actually add anything - if you want your alias to call a function, instead of selecting "call a function" as its action, you should just be selecting "execute a script" and writing the function call directly into it. Anyone who is capable of writing the code in a function is also capable of writing a normal function call. This is especially a problem given that you can call functions like aliases from the command line, which means you need to give them really silly names if you don't want to be able to accidentally run them from the normal prompt. If you want an alias, you should use an alias. Functions should not be aliases. If you want a function, you should use a function. Functions should just be normal JavaScript functions. This is an easy fix: just get rid of the separate "function" UI element thing. At the very least don't ever force me to use them like you do right now with onLoad - the problem with getting rid of them right now is that the only place to define global functions so that you can call them from alias scripts is the funky onLoad "function", which brings us to the even more crucial #6.
(6) Turn onLoad into a separate type of UI element. For one, the "function" UI objects ought to go, so we need some generic place to store the functions we're going to be calling in the normal JavaScript way. More crucially, it's extremely bizarre that you can call the code in onLoad by typing "onLoad" into the normal game prompt. That should pretty emphatically not be possible. If someone wants to write an alias to do that, sure, go right ahead, but it shouldn't be the default, unalterable behavior. That's crazy. Instead, just add a new pane to the whole UI for "scripts". These are scripts that execute when the system loads in (and rerun whenever you save them) - functionally they're all just a series of onLoad "functions". This corresponds pretty much exactly to Mudlets "scripts", which is the right way to do it. If you're writing a serious system of any kind, your onLoad is going to be gigantic and this also helps to organize it without resorting to having onLoad call a bunch of "functions" that become callable like aliases from the normal game prompt.
New functionality is always nice, but I honestly think the HTML5 client is already plenty powerful for very nearly anything you could want to do. The few features it doesn't offer pale in comparison to the problems of usability. What the HTML5 client needs right now is not more features, it needs documentation and it needs simplification. The package/group distinction isn't doing anything useful. The concept of "functions" is, if anything, doing active harm to the usability of the whole thing. onLoad is an incredibly clunky way to handle an absolutely essential function (inserting variable and function declarations into the global namespace on load).
These are the things holding the HTML5 client back, not lack of features.
0