I was going to try and list some bugs I could see in your code but I can't get traipse alpha working and it doesn't create a crash-report.txt or even a myfiles/runlogs file (there's not even a runlogs directory!)

So I am just going to guess at some issues you might be having on the basis of looking at the code.

(1) It looks like you are not backwards compatible with 1.7.1 in as much as that code supported finding a leaf node by its unique name even if it was not a top level node.

(2) It isn't backwards compatible with 1.7.5's introduction of the top container plus leaf node format (this doesn't really matter because nobody knew about it but for completeness I mention it). Neither is 1.8.0+ for that matter.

(3) The way you mix calls to ParseNode, ParseMap and ParseParent is a bit crazy. It's a simple idea and the code should be simple too. You need to check for your special codes !! and !# before you check for !@ in ParseNode. That way you keep it simple and easy. You could probably pull out several calls to these functions and it still work as well or better.

(a) If the first node sent to chat, or the first piece of text typed into chat, is the one with !# or !! coding won't it be missed right now? Now I can see why you wouldn't want to consider the possibility for text typed in because there's no node context and therefore no "map" to grab. But there is one if the node you are right-clicking on and sending to chat has a !! or !# in it.

(b) because of the broken up way you are handling ParseNode you could get a situation where one reference returns a string which contains a !@ and another returns a string with a @! and then the whole is re-interpreted as a new reference. That has not been the case in the past and so nobody wants that to happen. It's not very likely, but its a product of the spaghetti logic.

(4) One of the reasons ParseParent is hard for you to explain is that it does two quite different jobs according to whether it hits the exception or not.

Now in the example of its use above you have the case where it hits the exception. That route is basically a full path within the context of the top level container that you are in. As a result it will (I think) break if you eg. place the entire character sheet within a container. So it fails the test of locality (it shouldn't matter where the character sheet is - it should carry on working wherever it is moved).

Now that is the exceptional case and I thought it was odd that you'd explain the way ParseParent is supposed to work in terms of the exceptional case. The non-exceptional route takes the !#....#! path and tries to match the first name in the path against the "map" of the node it is in to find where it should hook. It does so by looking down the list by the way. You want to look backwards up the list in case there are two names the same in the path because otherwise you'll get the least local one. It's kind of a weakness that you have this problem when the full path has a repeated name within it, although that probably won't happen. A bigger problem with it is that you remove the last name in the list. Why? If you didn't do that then your !# could mimic a lot of the functionality of the !!. It's not intuitive. it also means the logic blows up if you put a !# reference in top level node or even in a 2nd level node.

At least --- from what I can guess at without being able to run traipse.

David... download the .ZIP file, run setup.py, and then try again. I have not added those folders to the repository because the setup creates them.

I am just talking about the syntax there. I think it would be cleaner syntax to make all the references be of the form !@....@! and indicate these special types by means within those tags. Such as !@parent::...@! and !@child::.....@! But it's not a big deal.



It's a very hard piece of coding to get right. I had to fix dozens of bugs in mine before I checked it in and several since. Really it needs tests because it's just very hard to spot the bugs either by looking at the code or trying to manually test. However the next best way to check your code is to get someone else to look at it. A fresh pai of eyes.

So I am making constructive criticism. Specifically the way ParseParent calls ParseNode and ParseMap, and ParseMap calls both the others and ParseNode calls both the others too... nasty. All ParseParent and ParseMap do is make a string substitution based upon the contents of the map tag, right? I would call them both from ParseNode before you look for the !@...@!. Then in ParseMap and ParseParent don't call the other two at all, just drop back. That makes all three functions called in grand total 4 times and ParseNode is the only recursive one. it will also fix the bugs i mentioned I think.

A lesser refactoring would be to only call the grid and custom node handlers from resolution(). So basically everything goes through the same code route then. It all starts through ParseNode and ends up at resolve. Resolve then says what kind of node do I have? if it is a text node I return the text, if it is a grid i do this, if it is a custom I do that, if it is a list node I do the other, if it is a macro node i extract the data this way etc etc.



Well we both agree on that. Within character sheet locality is common to both systems. What i find interesting is that you've gone a step further and got some within-sheet locality so eg. if you moved some of the pieces around inside the character sheet it will still work. eg if you decided to make special attacks a sibling of the attacks container in your example. That's a side effect of the other goal here which was to allow multiple character sheets to work (in my case you can clone them with rename in one step - btw that code is very easy for you to grab so you should, it's cool!) What you have is a little more locality which allows for sub-containers within the character sheet to be duplicated with rename and still work. That idea is growing on me but I doubt customers were asking for it

(1) Using !@parent:: .. @! and !@child:: ..@! is distracting in itself and it adds a lot to type. I chose the syntax !! and !# because it is simple and it simplifies the text a person needs to type to two or three names. It's new, but it is easy to remember.

You are also forgetting EZ Tree, but that is because you can even start the software. That hurts my feelings a little that you can't start the software considering you are a developer and I have explained multiple times on how to get the Beta. The EZ Tree will allows users to not even need to worry about what to type, they can just create a reference.

(2) I don't think I could handle everything in the resolution function at once. It needs to loop for each instance that has not been parsed.

Well I agree it's simpler; I just would prefer to not expand the tag we are using. Currently the tags openrpg tends to use are the !@...@! one, the /commands and that $ sign usage in one of the plugins. Every time something new is added I feel I ought to change the validation functio that tests for dodgey looking node names.

But that's me being parsimonious probably. As above I wouldn't actually suggest something like !@local::....@! but rather would try to make locality implicit somehow and I suggested that all references of just one word should be considered local. Pretty radical perhaps but I think it would work, and the fact you only have one node name to worry about would make the lookups easier to fiddle with.

Sorry about the traipse download. I think I had it working before just by downloading the files. I haven't looked at in a while because I've been busy with actual roleplaying stuff. Meta-stuff mostly. For example I have a 5th level group about to attack 16 salamanders currently (in the Temple of Elemental Evil in fact). Hopefully not noble Salamanders - did they even have those in 1st ed. But mostly I've been checking over the old session logs for clues and missing loot. We've been playing the campaign two years so there's quite a lot of it.

Ah... but I have a problem with the zip file install:



The problem with putting everything in the resolver might be the custom nodes. I didn't even try to make them work, though they might, with the new 1.8.0+ system. The whole point is those are self-contained character sheets doing their own thing so why would anyone need to reference them? Well maybe they would but I don't fel like supporting them much. Hard enough to keep them working as it is. Have you seen the code repetition in those things? Wow. And why make 4 copies of what is essentially the same d20 design?

David I seriously don't know how to help you man. Traipse comes with a portable version of mercurial, I just tested it on my WindowsXP and Windows Vita virtual machines and I do not get that error.

I can't even think you are having a conflict with your installed mercurial because I have mercurial installed on my linux machine and I use the same files that I tell others to use.

The error is basically telling you that it cannot find mercurial. Did you delete that?

Why does it even need to look for mercurial? I thought we had de-coupled mercurial from the openrpg code per se? I was running start_noupdate.py

My hg is still there.

I downloaded the zip file, moved it to an empty folder somewhere, unziped it in the folder, moved down a directory (called "Traipse") and ran setup.py and then I moved down another directory (called "System") and ran start_noupdate.py

'we' as in you and your team. I kept mercurial. You need to run Traipse.pyw.

I thought it was removed before you split? Why bring it back? I'll try the traipse.pyw tonight.

No it wasn't.

I did not want the stupid update manager that is in standard. It works like a piece of crap, takes forever, and it's options are limited to one developer. I've been told the standard updater will update only the files that have been updated, but it doesn't on my computer. It forcefully re-writes the software. If I want one files skipped I can't have it with the standard updater.

It's been over half a year since I forked. Why are you so interested in Traipse now?