Server -> Client, Model -> View suggestions

[theTrav]

Just from working around in the client a little, I've come accross a few things that I'd really like to suggest.

When you do your inventory overhaul, I'd really love to see a system where the client can send the server a message that says
"take item <id> out of container <id> and [move to container/equipory <id> | drop on ground]"
That would allow me to do some more fun inventory management stuff, which is going to be a bit clunky for me to do with the current implementation of "move item" which relies on the state of currently opened containers, which was most recently opened etc.

[Pacho]

Seconded!

[theTrav]

Another suggestion:

Currently Item Crafting sends a make message to the server, the server handles the make and then sends the client an inventory update (if it's open) or a log message if an error occurred. Neither are tied to the craft widget in any way.

I'm all for decoupling messages from widgets, but I'm a big fan of the request/response model. If we could have the client send a message saying "I want to craft this recipe with these items" and get back a message from the server saying either "your craft failed because of snah" or "your craft succeeded, item Snah has now been added to your recipe and items Foo and Bar have been destroyed" then the client could do a bit more clever stuff with the crafting process.

The primary difference being that the communications are all tied together by a message ID as opposed to being tied together by a widget ID or not at all, which requires the client to maintain a detailed model of the servers opinion of UI state.

[theTrav]

Another one,

The Action Menu currently looks extremely server driven. It would be much nicer for the server to simply provide a request/response message pair to say "what actions can I access?" "you can access 1,3,212 and 5" and then have the client decide how to display those options to the user, and which hotkeys to use.


I hope I'm not coming across as pushy or demanding with all these suggestions, they are of course just things that would make my life as a modder easier, I'll work around them of course and if they don't get implemented no big deal.

[loftar]

Generally, I constantly find myself balancing between more or less client knowledge and having a hard time deciding on which I like the best. On the one hand, it is, of course, good to be able to mod the client, which requires more knowledge on the client side of things. On the other hand, it is very nice for me to be able to implement new features entirely on the server side without having to touch the client code. The various meters are probably the perfect example: It would be very useful to be able to move the health/stamina/&c meters around or do various other things with them, but then I couldn't add new meters arbitrarily from the server whenever I feel like it without modifying the client with it. It is very hard for me to decide what to do with all this. For sure, though, there are a couple of ugly things which should be cleaned up in various ways.

"take item <id> out of container <id> and [move to container/equipory <id> | drop on ground]"

This is probably a good idea. The problem is that it would require me to keep inventory IDs on the server and reverse mappings of item IDs, which I don't currently have. I'll have to think about it.

The Action Menu currently looks extremely server driven. It would be much nicer for the server to simply provide a request/response message pair to say "what actions can I access?" "you can access 1,3,212 and 5" and then have the client decide how to display those options to the user, and which hotkeys to use.

But... that's how it is. The server sends PAGINAE messages which contain updates to the client's list of available actions, which is stored in the Glob. If you look at MenuGrid.cons(), you'll see that it fetches the global action list from ui.sess.glob.paginae and construct the current view from that. Navigating inside the menu is done entirely on the client.

[theTrav]

But... that's how it is. The server sends PAGINAE messages which contain updates to the client's list of available actions, which is stored in the Glob. If you look at MenuGrid.cons(), you'll see that it fetches the global action list from ui.sess.glob.paginae and construct the current view from that. Navigating inside the menu is done entirely on the client.

Heh, yeah I actually had a fair bit of trouble figuring out precisely what was going on there with the paginae and the cons things.
Some time after having posted this I did notice that the server sent everything pretty much straight away I think I should take another bash at it using the PAGINAE handling code to build my menu rather than using the MenuGrid code (I just want a list to start with, but eventually I might even hard code the buttons and not require what the server sends in PAGINAE).

The craft interaction is probably the most complex state I've had to keep track of so far, and even that's only 3 widgets/message types