Ah no, I forgot about the other half of it.

Once you have done the translation [string ==> node] you still need to extract the value of the node as a string [node ==> string]. I tend to think of that as the easier and more straight-forward part of it but we are diverging there too.

Specifically once I have the node I have arranged things so that getting the data out is this simple:



Now exactly what get_value() does may be complex internal to the node handler but my referencing system doesn't care. I just changed my nodes so they all have such a function and it defaults to "None" in the base class. All the nodes that can't be references such as image nodes, minilibs, linknodes etc return None. Those that can return something useful (text, macro, gridrow, list, resource) do so. But your code doesn't have a get_value() so you pick out what kind of node you have and then follow different code for each. ie the code that should be inside the handler object is in your referencing code. The referencing code should be able to say to the node handler "give me your value".

If you don't do that then we have to drag all the nodes and all their code into the referencing system as a dependency. See what I mean there?

Now there's one catch here. Just as I have a little extra piece of data (parserContext) flying around my referencing functions, you have a little extra piece of data you use to extract the value of your node handler. You might be doing it with the custom nodes (ie the StarWars and d20 bunch) but you are definately doing it with the grid. You are basically passing in some data such as the cell's grid co-ordinate when you are calculating the value of the node. so your function would be more like this:



Hopefully that queryContext can just be a string like "(1,3)" or "([1d3], [1d2])" but you may need something more complicated if you want to support those custom nodes (I do NOT want to support them!) I don't think you do though; I think you only need it for the grid.

This is good programming practise anyway of course; object orientated. But there's an immediate benefit of decoupling the nodes from the referencing system.

I actually read the rest, but I think being kicked off by this guy in the most childish manner makes me care less.



Who is 'we'? If you want too, go ahead and fork it!

Wait a second. This is another one of those red herring ideas that this so called pro comes up with. So where the heck am I supposed to start from to turn all my changes into a plugin? I started from the Release Candidate trac that I worked on. The RC Trac I was using to have people Beta test with.

So, this guys methods are mentally unstable to me by now. He expects me to go forward and reverse everything I have done just so I can stay closer to the "Core"? What a rip off, what a waste of my time .. and if he was my tech support I would want my money back.

I can't believe this loon. It's another 'code re-write' task and for what? This time a downgrade? Jesus, dude. If Traipse was Vista we would talk.

So to recap:
Standard interface for the referencing system and node handlers allows users to switch out entire reference system.
=============================================================

Getting back to the goals of the .. well the "game tree system" I suppose since we just extracted the referencing system per se as a small replaceable widget within the larger pattern...

(1) die rollers
(2) math

Die rollers.
========
The main issue for me is how fast can I roll the dice once I need to. How few clicks or key presses. In 1.7.X you've got (1) find the node in the tree and r-click/send to chat, (2) find the node in the Use dialog and hit send. In 1.8.0+dev you add (3) r-click on the mini and select from the menu and (4) type the name of the roller into chat. I also have primitive Linux-style tab word completion to help with (4)

I suggest we also add (5) toolbar buttons for the commonest die rollers. That's how MapTools does it (sadly the ONLY way). Well a toolbar button for every option is silly but for the most common it's fine. For example 90% of the die rolls I make are probably limited to just 4-5 die rollers. So how about make them a one-click? With an individual icon, from the icon list, for each button to remind you? But unlike macro F-keys we already have, these toolbars change according to the PC alias selected. Search, Initiative, Attack, Listen / Spot maybe. For the wizard Spellcraft comes up a lot.

Another idea: could we insert a Use dialog into a whisper tab on the chat window? You go to that tab and instead of showing a chat history it shows the Use dialog for some character.

Second issue for die rollers: how fast can I roll a bunch of die rolls at once? Normally for me this is rolling initiative or "everyone make a spot check" which is why I created the /all command. That works very nicely although of course I could just have created a text node that had everyone's initiative typed out by hand, or even put it into a macro. Not much to add here. Between /all and just creating a new node that about covers it.

Third issue: modifying the die rolls. I see you have a take ten and take twenty option in one of those sheets. I have a plugin that had a slash command called /10 and one called /20 that did much the same thing. Not ideal either way. There's also the ? thing which has been used in the past. Other game systems may wish to modify other aspects of the dice. I don't like the way the ? brings up a modifier dialog every time but maybe if you could do it selectively. When a Ctrl-key is held down or when a toolbar button is toggled "in"? Dialog pops-up. You want a bunch of options here. Probably keyed to the system like the die rollers themselves are. For D&D you want a series of check boxes for common die roll mods like "charge:+2" or "flank:+2" and your take 10 and 20 options. If there is a space for an arbitrary bonus you can also have the option of typing in a reason for it (somehow printed out with the die roll result). d20 system never really changes the number of die or the other complex things other systems have. Their pop-up dialogs would be more complex.

Which brings me to feature #4 for die rollers. I would love to have the system explain a die roll's adds for you. Because my DM is often "how on earth do you get plus 12?" and also I like to see it to know the system is working right. This concept is easier for d20 because there's only one variable to mess with. An explanation comes down to simply "where do all the bonuses come from?" A d20 explanation could look like: "bab:+3, str:+4, tower shield:-2, rage:+2, magic longsword:+1, flank:+2, charge:+2. total: +12". It might be tough to get this generalised enough to cover all the other systems, especially since I don't play them. But a cool feature I think.

Well (1) I am also a professional computer program and (2) no, this is my idea not DigitalXero's.

But yes this is one of those pro ideas that actually work very well. Encapsulation. Inheritance. Object orientated.

Common interfaces on the server/client stuff is what allows Traipse to work with OpenRPG servers. Common interfaces on the referencing system and node handlers would allow us to grab each others code easier. Specifically plugins I have written to do stuff with my referencing system could be made to work with yours too (...uh... I think!)

Hey -- it was just an idea. Mostly benefiting you assuming that the client base for Traipse will remain a minority, and assuming that I continue to get features thrown down faster than you do <big grin>

Just kicking ideas around helps me a lot.

The math
=======

This is where MapTools falls down utterly and makes OpenRPG the better product even before we added all this stuff. MapTools does no math whatsoever. They basically have macros on a toolbar instead of F-keys. No referencing at all. Other VTS tend to sell out to one or other (OK-- always D&D) game specific system to do math. They then know what the variables for the game system are and hard code it all. Or most of them. You can never do all. (Someone wrote those custom nodes for OpenRPG that acted more like that system-specific strategy).

Only OpenRPG ever tried to do both math and total generalisation. Now in 1.7.X it was always just string-string substitutions for the references, which were then parsed as math in the die roller parser. Pretty primitive but it worked. You want to simulate an increase in Dexterity in your character sheet? Edit by hand the Dex node and it will do the math on those skills and so on.

Moving forward then.
(1) the data needs to be shared. When someone is adding bonuses they need to make those changes to the other players' copies where appropriate. Otherwise the math will disagree.
(2) we have got bonuses and effects now - interface needs to be waay better.
(3) we could do with more logic features. Currently we have + - * / min max if...else and parentheses. You could really have just about anything you can eval including custom python functions in a plugin. Security against viruses might be an issue. Meh.
(4) Triggers. We need something to do something when eg. your HP reaches zero
(5) Timing / Clock. We need to be able to hook up stuff that happens every round like the roll for dying characters, or a duration for effects so you don't forget to remove that +4 strength from Bull's Strength.
(6) Scripting. While much of the concept is already covered elsewhere you could get much more again with scripting... probably in Python?

I have mentioned these ideas before so this is mostly trying to express them again within a framework that makes sense so I can more easily think to myself, "what else?"

Get your head out of your ***. You are really out of touch. And your idea ... total crap. Anything else you want to add?