State of the generic nodes
Posted by davidbyron on 2009-08-07 06:42
Looking at the nodes' behaviour as part of thinking about improvements discussed elsewhere in my proposed features. I hope snowdogl or DJ can throw light on the original intent of these behaviours....
(1) OK so each node can Design, Use, Pretty Print or send to chat. What does all that mean? As far as I can see design ought to be an initial setup rarely used, perhaps used offline out of play sessions, perhaps even only used by the designer of a complex set of nodes arranged into a "characater sheet" for other users. Use otoh is the way the node is used in play including common simple edits to eg the value of a number, but mainly the use would involve sending something to chat. Pretty print is a graphical display that doesn't get sent to chat and chat is the... well often the same thing sent to chat. Pretty print and chat have no additional input since they do their thing immediately whereas "use" will bring up a dialog and you then have to press a button or something to send to chat. But there are exceptions to this general concept.
(2) container nodes don't "do" anything; they are just a means to group child nodes on the tree and also to control how the child nodes are displayed with "use".
If that's roughly the case then there are some bugs.
a) the "Form" container appears to do nothing more than be a static vertical splitter. what's the point? it has a width and a height which are not used.
b) the "Group" container does not display its children during "use" and so won't work as part of a character sheet
c) "Splitter" and "Tabber" containers display children during 'design" which I don't think they should.
d) the macro node has no "use" dialog. it just sends is text straight to chat (same as "send to chat") which means it is invisible within its parent container's "use" dialog.
I was wondering about pulling together the macro and text nodes into one typ, and the various container nodes into one type.
Might do with some better metaphor. I like "use". Design is OK but the title/caption of the dialog says "edit". Pretty print seems to basically mean "open in its own dialog" as opposed to sending the exact same thing to chat. maybe "popup" instead? or "show"? Should some of these four things be disabled if they make little sense for the node? For example pretty print only make sense for fairly big things.
Some nodes have optional "send to chat" buttons in the use dialog. eg list, text, macro. What is the point of not having such a button? Does the absence of a "send" button mean the node is meant to be a variable essentially, only used by being referenced from another node? of course list boxes can't be referenced like that right now (shame). And for some reason the macro has a "send" button in its design dialog not its use dialog (which it doesn't have one of - instead automatically sending to chat if you ask to "use").
I added a new node "resource" as part of playing with all this. As with all the other node's its unique. It has no default 'send to chat" message as to operate it you need a user input. You open the "use" dialog, specify the input and then hit the send button. I was thinking of sending a message saying how much of the resource you had left in words but for the purposes of getting effects to work it might be better to send a simple integer. If some nodes represent an integer implicitly, like resource or like say a die rolling text node but their send to chat is more complex than just a number, do we need a function on each node "getIntegerValue()"?
Nodes don't have any means to cancel edits, whether complex edits through the design dialog or simple in live play edits through the "use" dialog. Exit from the dialogs means "save changes" generally. This is counter-intuitive to a new user though presumably openrpg users are used to it now.
(1) OK so each node can Design, Use, Pretty Print or send to chat. What does all that mean? As far as I can see design ought to be an initial setup rarely used, perhaps used offline out of play sessions, perhaps even only used by the designer of a complex set of nodes arranged into a "characater sheet" for other users. Use otoh is the way the node is used in play including common simple edits to eg the value of a number, but mainly the use would involve sending something to chat. Pretty print is a graphical display that doesn't get sent to chat and chat is the... well often the same thing sent to chat. Pretty print and chat have no additional input since they do their thing immediately whereas "use" will bring up a dialog and you then have to press a button or something to send to chat. But there are exceptions to this general concept.
(2) container nodes don't "do" anything; they are just a means to group child nodes on the tree and also to control how the child nodes are displayed with "use".
If that's roughly the case then there are some bugs.
a) the "Form" container appears to do nothing more than be a static vertical splitter. what's the point? it has a width and a height which are not used.
b) the "Group" container does not display its children during "use" and so won't work as part of a character sheet
c) "Splitter" and "Tabber" containers display children during 'design" which I don't think they should.
d) the macro node has no "use" dialog. it just sends is text straight to chat (same as "send to chat") which means it is invisible within its parent container's "use" dialog.
I was wondering about pulling together the macro and text nodes into one typ, and the various container nodes into one type.
Might do with some better metaphor. I like "use". Design is OK but the title/caption of the dialog says "edit". Pretty print seems to basically mean "open in its own dialog" as opposed to sending the exact same thing to chat. maybe "popup" instead? or "show"? Should some of these four things be disabled if they make little sense for the node? For example pretty print only make sense for fairly big things.
Some nodes have optional "send to chat" buttons in the use dialog. eg list, text, macro. What is the point of not having such a button? Does the absence of a "send" button mean the node is meant to be a variable essentially, only used by being referenced from another node? of course list boxes can't be referenced like that right now (shame). And for some reason the macro has a "send" button in its design dialog not its use dialog (which it doesn't have one of - instead automatically sending to chat if you ask to "use").
I added a new node "resource" as part of playing with all this. As with all the other node's its unique. It has no default 'send to chat" message as to operate it you need a user input. You open the "use" dialog, specify the input and then hit the send button. I was thinking of sending a message saying how much of the resource you had left in words but for the purposes of getting effects to work it might be better to send a simple integer. If some nodes represent an integer implicitly, like resource or like say a die rolling text node but their send to chat is more complex than just a number, do we need a function on each node "getIntegerValue()"?
Nodes don't have any means to cancel edits, whether complex edits through the design dialog or simple in live play edits through the "use" dialog. Exit from the dialogs means "save changes" generally. This is counter-intuitive to a new user though presumably openrpg users are used to it now.
Home / Developer API / Tour / Get a Project - Solutions for Bug & Issue Tracking, Collaboration Tools, Subversion Hosting, Git Hosting
Openrpg is powered by Assembla.
3 Comments
By Digitalxero on 2009-08-07 07:48
a) the "Form" container appears to do nothing more than be a static vertical splitter. what’s the point? it has a width and a height which are not used.
The difference is the Form will actually resize it's children and itself to try and fit all of it's children on the panel where a splitter lets the user decide how to size it by dragging the sash.
b) the "Group" container does not display its children during "use" and so won’t work as part of a character sheet
This is by design, a group node is just a method of grouping related objects together without enforcing some display style on them. When designing my own character sheets I always start with a Group as the first node that I name as the character name.
c) "Splitter" and "Tabber" containers display children during ‘design" which I don’t think they should.
I agree
I was wondering about pulling together the macro and text nodes into one typ, and the various container nodes into one type.
The reason they are separate is because the Macro Node is an action, so double clicking on it auto sends it to chat, where as the Text Node is a content Node and double clicking on it opens its dialog.
Some nodes have optional "send to chat" buttons in the use dialog. eg list, text, macro. What is the point of not having such a button? Does the absence of a "send" button mean the node is meant to be a variable essentially, only used by being referenced from another node? of course list boxes can’t be referenced like that right now (shame). And for some reason the macro has a "send" button in its design dialog not its use dialog (which it doesn’t have one of – instead automatically sending to chat if you ask to "use").
The absence of the send button means the contents of the Node are not designed to be sent to chat in a general way. It does not make sense for a multi line text node that I use to track my inventory to have a send to chat button. The reason the Macro has a Send button from it's design view is so you can test the macro while designing it.
I may be odd in how I use the tree, but my character sheets are designed to never be opened unless you are making an edit. I dont like cluttering up my screen with node windows and I find it much more useful to take the time to design my character sheets from the beginning with actions in mind so I can just double click macros as needed.
The node type I really wish existed was a grid like the Stat or Skill grids in the built in Character sheets. Where in the design view you should be able to set the calculation used, the dice roll generated and the number of rows. Then in the use view you can set the name,value pairs for each row. The node should also act like a container so when you expand it a macro with the generated dice role is listed in the tree for each row.
I would not put a ton of effort into improving node and tree functionality right now, do fix bugs, but when we do the redesign to make openrpg use ElementTree instead of the minidom it is going to require a redesign of the how the gametree operates on the back end anyways. (I spent an hour the other day looking though that code and wanted to just rewrite it from scratch it was so bad)
By davidbyron on 2009-08-09 00:22
Some of the nodes have sub-parts that show up on the tree as leaf nodes even though they don't really work like normal nodes. Specifically the grid node has its rows show up (but not the cells) and the d20 variants have various sub-parts show up. Most normal operations fail for these nodes. You can't drag and drop things into the grid or d20 node, nor can you drag its nodes out. You can't clone them or delete them, it makes no sense to 'send to player" you can't "design" on them or "use" them. Pretty much the only thing that does anything with a row node is send to chat and the d20 nodes just do that when you right click.
This is a problem if I want to eg. collect the names of all the variablesI have -- what is the pathname of the contents of a cell on a grid? Currently the reference system doesn't work for grids (just text and macro nodes) but there's no reason for that. I'd have to access it by giving the name of the main node eg "Foo::Bar::MyGrid" and then some other data like a cell co-ordinate that the node can figure out internally what it means. But since the rows are also nodes maybe it would look more like "Foo::Bar::MyGrid::Row1" and then something to indicate which cell within the row? Similarly do I reference a d20 Will save by "D20 character::Saves::Will" or by "D20 Character" and add some additional information on the end of that some how?
In my plugin I access a cell value with "Foo::Bar::MyGrid::Row1" and just assume cell 1 (ie the second cell) is the value I want. That works fine for grids that are lists of unrelated captioned values. In general though it seems like these "dummy" nodes might not be smart enough to know about their contents. All they are intended to do is allow someone to have an alternative GUI to the "Use" dialog for the main node. So maybe any query for data should go to the main node. So the "dummy" nodes shouldn't be reference-able. But then how do i know when i am iterating through the tree which are main nodes and which are dummy?
By davidbyron on 2009-08-09 01:01
Let's say I want a node that rolls an attack or a skill roll for me. Very common use for a node. Now I want to do more with it. I want to search the tree for things like that roll, list them and allow some system to edit them on the fly by eg boosting an attack die roll representing a Bull's Strength spell. This is handled currently by internal references (generic character sheet) or by python code (d20-like sheet). The die roll itself is the display node and then there's a variable held elsewhere. So you have two nodes. One has some words in English like, "Inigo attacks with his longsword" and then the die roll. In my case I also sometimes list in italics things like "possible sneak attack damage ...". And another node just has a number like "5" which is the basis of the other node's die roll. Now those two nodes are related so they probably have related names and in a system where name uniqueness is the ID system that's a problem. It's also cumbersome. I'd prefer it if both were the same node but had different responses under different circumstances. If the numbers were easily accessible we could do scripting more intuitively. The d20-like nodes don't do much mathematical manipulation. If, For, some arithmetic and of course, knowing how to reference values. The tree nodes are basically GUI stuff that contain also some variables. Need to be able to cleanly extract those variables and store them to be referenced from scripts or effects or anything else people come up with (reports? "Who's got the best Search skill?" which PCs know how to speak Goblin?)
One problem is that many die rolls don't have just the one value. And its worse for non-d20 systems because in d20 you don't have to worry about the number and size of dice generally although damage rolls do. Still not too many things mess with the number and size of dice compared to just an add to the dice, but how often is that true for other systems?