Some Beta testers have expressed their difficulty in the new Gametree syntax. If you have not personally expressed your frustration to me, I want to you let you know I was already ahead of you. I made a note in the User Manual node about the reference system being difficult to understand and that I would like to change it.

A user did give me a good idea on how to make the method easier for users, and now I have a plan of action that will integrate the users idea along with a addition of my own that will make it easy to create node references in any node.

Before the beta goes stable I will add a few changes to the Beta Gametree:
1. Add Reference button. This button will bring up a pop-up of the grametree that will allow users to select the node they want to reference. The software will then add a reference using the syntax. This method will be a universal method that can be added to all nodes.

2. Labels in Lists. List Nodes are a great way to organize references. All you need to do is make the reference and then push the button, how simple is that, right? However, after the reference is made it can be so archaic you might not even know what you are pressing anymore. So I will add labels to List nodes so users can pick a label that suits them best, then have an easy to understand reference.


These are two planned changes. Choosing Grid cells is going to be a bit tough, but it will be there in the future. If you have any other ideas to make the reference system easier drop a line in this thread.

Hmm, this would be a quite easy request.
Allow a command in std roller to have a seeded random with a random number between 0-1 with one argument, which should be the seed (And can be referenced in of course).
This would be nice for DM's, since then you can create nodes with "Random" monsters, based on a random value you can insert somewhere, I would love it at least.

First, thanks for the skype conversation.

Second, no. This idea is not going into Traipse. The Traipse node in beta comes with a Random Encounter table.



I can't use [0][0] or [0,0] because that is part of the die roller syntqax. I use (1,1) already in Beta.

This feature is already in 1.8.0/development version. The code changes are pretty much limited to the one file I think. You might want to improve on my user interface for adding the information though.

I think will improve on your interface. It's a great idea, but I don't like how it is implemented again.

The pop-up for adding a reference seems like a good idea. As for making it standard for nodes how would you go about that? Would this be within a design dialog and maybe some sort of design dialog base class? There are several things which are currently repeated code which might be usefully in such a base class.

(1) a text box to allow you to change the name of the node in the tree. Upon text change call the TreeCtrl function for updating the name, but only do it once the focus has left the field (or exit the dialog) because the indexing system otherwise has to constantly delete and re-add all the references in the tables for each character change. (this is already in the code but it's duplicated)

(2) it would be nice to have a separate save/exit and cancel/exit buttons. that might take more coding because currently the changes are all saved as soon as they are made so there's no "roll-back". For big nodes like grids when you accidentally delete a whole row or column of data that's a nasty problem. if you hit the exit button prompt for save changes? default yes.

I suppose not all the nodes need the tree-item selection feature for references. Grids, lists, text and macro, resources.

It's going to be a portable script so that it can be added to any other node GUI. The script will be activated when a button is pressed, then the user will see a pop up of the game tree and they can select a reference from there.

I honestly don't know how you plan on implementing this or what purpose it serves Standard. From what I have seen with the game tree everything is universal so your system might want to look at an efficient way of turning off nodes to remove the duplicates that must be happening.

You know what I am saying? If I have two player sheets with a node named Info then the user needs to un-index one.

The reason I am making this is because the syntax for Traipse did not enforce a complete PC Sheet re-write, it added new syntax to the game tree. However, the syntax has always been a crux for users to understand and this system will enable users to create references to nodes on demand without needing the syntax.



Mine will have it here too.

Well as it happens that's exactly what it does for you automatically. But you hardly ever need it because of course, in the example you give both nodes called index would work fine being in different character sheets.

Now if you had two nodes called index in the same character sheet.... well no that still works fine if you give a full path. But you have the option of de-indexing one of them so that the other can be referenced with a one word call. Very nice. The format becomes so painless you don't really need the find tree node pop=up thingy.

And it's all backwards compatible too.

And you can move a character sheet anywhere in your tree, put it in a container or take it out of one and it will all still work if you use the new system. For that matter you can add extra layers of containers and still have it work fine.

Even so I think the reality is there are serious flaws in the entire way the data is handled in OpenRPG. It's trying to do too much. A big rethink is most likely coming. The system needs:

Basic data entry (eg integers)
References (eg !@Strength@! )
Calculations (eg ((!@Strength@!-10)/2) )
Dierollers, /commands and other scripting
Display instructions: ie how the other nodes are arranged when you try to access them visually

Of all those things it's only the last which uses the tree structure. So why not take the first two things right out of the tree in the same way that Digitaxero's character sheet by variable works? Lacking that we ought to at least have at least a "don't display" option for a container, so all your data and calculation stuff isn't opened up with the rest of your stuff. But really the visual stuff ought to be handled by eg HTML or some other markup language but everyone knows HTML. Your character sheet becomes a piece of HTML with references translating values and sending off requests to update values. This stuff is done all the time in third party code. True, currently the tree format is used for three different formats of display at once (the tree itself, the "USE" dialog and with the new plugin it becomes a context menu tree too), but I'd swap that for one format done (potentially) really well. Also true you'd need another way to add data that was really simple, like a dialog that pops up with a list of variable names that your standard character sheet understands and the variables are displayed with their name and values in a list.

The tree format certainly does a lot for a little code. But it's a bit clunky.

OTOH no other VGT tries to enable user generated custom built character sheet display formats at all. You generally get either a standard one done for you (which means you're limited to the game system they selected or one like it) or you don't get one at all, just a flat list of variables, if that.

Of course it doesn't help that wxPython never did get around over the years to implementing an HTML view that works beyond Windows for anything more complex than <table> <font> <b> and <i> type stuff.

I guess I have been wrong about that this whole time. Maybe you can correct me on another matter. I have seen the PC Sheets people are making for your Standard game tree and they look atrocious. It looks like the users need to basically clone the sheet, one to hold the data and the other in this '.' container that references and re-references all the data.

In the system I am working on the game tree works like a set of folders on a HD. The user can create a node and from that node they can reference any data within it using one of the syntax methods, or they can reference outside of the node with another. The method really streamlines the PC Sheets, but the syntax is still archaic and unhandly to work with.

So what's up with the cloned data? I have a node lying around that has an enormous amount of nodes needed just to reference data.

Don't think anyone's yet been using the new developer version for making character sheets except me. So I assume you mean the old 1.7.5 through 1.8.0.4 stuff there. But that's in Traipse too, right? Basically there's no difference.



I don't understand. I do like to split up data and eg the die roller node that uses the data. eg for abilities I have 3 nodes. one for the strength, one for the strength bonus (a calculated value based on the strength), and one for a skill check die roller based on strength. It all depends how "programmed" you like your nodes to be. Some of it is style and others is that the more levels of indirection the more you can get bonuses and effects to work.

Cloning sheets for real (to get a 2nd sheet) actually works now. There's a neat "clone with replace" feature. If you have a sheet for a PC called "dog" you can make one for someone called "cat" in a couple of clicks.



That is definately not the impression I had of your changes. There was some discussion of implementing that and I decided against it in favour of the easy one-word "flat" reference to uniquely named leaf nodes.