I most certainly do not mean the 1.7.5 material.

Wait until I get home so I can describe what I am looking at first hand. I had a couple users that wanted to convert a Standard PC Sheet to a Traipse Beta sheet and I continually thought to myself ... WTF?

While I admit the Beta syntax is new and I did not expect them to quickly make the switch either, I did however, not expect it to be such a hard transition. This is without the sheet in front of me, but what I a remember seeing was this HUGE sheet that I could have put together in just a few nodes. It was horrendous because they had to create a node for the Str Mod, the Dex Mod, the this and that mod ... plus some odd dozen die rollers, and I thought ... gross

With the Traipse game tree a user can reference a grid, and with the new Child Reference system then can reference Grid Cells from within the grid really easy. Say the grid is named Attributes (appropriate). The user just needs to reference !!Attributes::(1,1)!! to get the top left most cell.

With that I saw, users created a container node that was named with a period, then they would create all these references which contain values and modded rolls, and i about puked. I seriously puked just a little.

Ok, I am looking at it now and it is gawd awful.

The user has a container that is labelled '.' Inside that is form called DO NOT TOUCH!! oh k....

Inside that node is a library of more nodes. A set of nodes for Mods and a HUGE, HUGE HUGE set of nodes for rollers.

Yeah that is 1.7.5 (through 1.8.0.4)

They couldn't reference grids back then. I stick all my basic data in grids now too with 1.8.0+ developer version. I use the grid row's name so it still looks like !@strength@! and there's none of that (1,1) stuff needed. It just assumes you are using a list format where column 1 is the name of the value and column 2 the value itself. Each row is visible on the tree ctrl with the name shown being the contents of column 1. So for abilities I have a grid called abilities with seven rows (first is a header).

I assume whoever designed the character sheet wanted a way to hive off their "I don't really want this stuff displayed" stuff like the raw data and calculations so they put it into a container called dot. That's a legal name... barely. Still legal even now I've tightened things up. It's not a decision forced by OpenRPG but a design decision to separate as-it-were user interface from implementation within the character sheet.

Also since in 1.7.5 they had to write out the fullpath for references well a one-character name is short to type. !@Inigo::.::...@!

But since it is a sheet designed for 1.7.5 should it not work right out of the box in your Traipse (and my 1.8.0+ developer version)? backwards compatibility and all that. For sure you could make it a bit nicer to look at now, and too some new functionality is added like understanding min(,) and max(,), but people often want to stick with what they've got.

One thing: using grids much more underlined for me the need for a good "cancel" or even "undo" button on the grid edit.

LOL, some I have seen had a node for every spell in the SRD. Slow as anything to index before the new map code.

That is what I am trying to say. It is definitely NOT 1.7.5. They use the new reference system of using the Sheet name.

As for the grids thing, I can't stand that method either. It's not really a grid but more of a list. The grid I have allows users the full capability of a grid .. no cut corners.

That's too bad. I am trying to find a method where our differences can somehow meet in the middle and it does not look like that is about to happen.

If you get the newest Traipse Beta I have a really streamlined 4e sheet in there. It's incomplete, no doubt, but that is for legal reasons. Users can complete it, I will just have a skeleton.

I would have to see the sheet. You could actually reference by top container name in 1.7.5 -- it was a little known feature I added. A precursor of namespaces. Very little known I'd say....

This is done now. The transition is pretty simple and in pre-Alpha it works really well. If you give an item a caption the Use Menu will show the caption and not the value.

This will work just like the old dialog, only there is an extra entry for the caption.

This addition is as hard as I had expected it to be, maybe a little harder. My current progress allows me to pop-up an entire gametree. The problem is ... it works exactly the same. I think this is going to require a more major script write than I had hoped for. -or not- I will basically duplicate portions of the tree, but then I will need to add a new node handler 'on_use' function and remove the regular pop ups.

In the end the user will be able to press the Reference button and the software will create a reference for the person. It will take some time, but it will be done.

I am on the last leg of the EZ_Tree Reference System's early functionality. I made it a lot easier than I could have. The final step is to take the two maps and compare them so that the reference created is the most efficient. This is going to be a little rough, but let me try to explain.

Example Tree:


The above example is a little like the 4e PC Sheet that I have worked on. Ok, let me explain how this will work. Let's say you are editing the Attacks List node and you want to reference your At Will Power Text node. It's pretty simple for me, but others it's not so the software will do the harder thinking. With the new system just edit the List Option you want and press the Reference Button. A Game Tree window will pop-up and then you can navigate to the At Will Power Text node and double click it. The Attacks List will insert the most efficient reference, in this case a Child Reference which will look like this !!Combat::At Wills::0::At Will Power!!

I don't expect users to understand the underlying code .. but I have no intention of making it a totally behind the scenes object either. So what the user will be able to is hide the code with a Caption .. at least in the List nodes so far. The reason I want the hard code visible is because a person who does understand it might want to learn how it works and develop with it. Also, reducing the code to a background object ruins the openness of the software.

Now, this system is going to find the most efficient reference for the node you are in. So if you are in the At Wills Power Text node and you want to add a reference to your Abilities Grid (currently not done), you will be able too and it will work with the new Parent Reference. So if you add a reference to the (1,3), ie the Str Mod Calculation in my sheet, you will be able to and the reference will look like this: !#Abilities::(1, 3)#!

You will even be able to reference from other sheets, but this might cause a bit of a headache if you move data around because the way the tree map works currently. You would be using a Root Reference, ie, the regular !@ @! reference that is stagnant and location dependent. Sorry.

I hope to have this fully implemented and on the Alpha trac late in the night or early tomorrow morning. It will spend some time in Alpha before going Beta .. if you are nervous about using Alpha, that's ok. It can be fragile. Enjoi!

EDIT: Whoops! Forgot to mention. What I do plan on doing with the code for other nodes that won't have a caption (Grids, Text), is to create a calculation system that returns the data in a clean format when the node is in Use Mode or Pretty Print. Pretty Print I am 100% on, but not 100% on in Use Mode.

The new Alpha is up with the EZ_Tree Reference System in partial working order. Lists and Text nodes work for now. The system currently only creates a Child Reference.

I also fixed the Parent Reference and that now works like it should.

I also fixed a bug with Tabbers and Forms that caused the nodes included to show up in Design Mode. Now Design Mode is Design Mode and Use Mode is Use Mode.