After deliberating with a non-Traipse user about how Namespace is such a needed entity in his games, and that same user offering an idea I felt made massive corrections in the way Namespace was handled, Traipse is now bringing back Namespace. Namespace is currently in Alpha and will be released in Ornery Orc Patch-2, hopefully in early- to mid-May.

This is how the new Namespace works. There are two syntaxes, Namespace Internal (!= .. =!) and Namespace External (!& .. &!). Each method is slightly different.

Namespace Internal: This must be called from a node. This method now does not care where your node is in the game tree, it will find the top most node you are looking for and then look for your reference. In early testing this has been working great. I have only one known issue so far that is a must to work out. Currently Namespace Internal only uses one reference, either a grid or a node. This will causes problems when you need to be a little more specific, but I think I can iron this one out in a few hours.

Namespace External: This can be called from chat or from a node, but it works a little differently. External starts at the tree and looks for you first reference, but unlike the specific string format that Namespace had previously been drilled down too, External now works more like a lightning bolt. It will find the top most data and attempt to use that, but you can narrow down the broad scope search to one container node.

Namespace External does not call the look through the root right now, so you will need to reference at least two nodes. This also can be ironed out in a few hours of coding.

With Namespace comes an inherit problem, the main reason I have strayed from Namespace. The problem is that Namespace finds the top most data and uses that. I do have some error prevention that I am working on for this. This prevention would determine if your reference is deeper than the node found, and if it is then it would bypass that node and look for another.

This is still Alpha, so there are going to be some bugs that need to be worked out. But I think with this new model of Namespace I am able to erase some of the previous inconsistencies with data that plagued Namespace. Also, with the Internal method users will have a much easier time with their sheets. Because they can move nodes around and the reference will find the correct data, they can focus on playing a fun game and having a tidy gametree instead of doing paperwork to "clean house".

Current Namespace Documentation

Is this in addition to the other weird stuff you had going on? What do YOU mean by a namespace?

Well you know my thinking here; and I know you wont want to hear it again. I had this system sorted out years ago and it works fine. I've been play testing it for years. I don't see the point in your banging your head against it.

You can't even describe how your system works to people. Even I didn't understand what you just posted and I am genius, a programmer and someone who is deeply into this stuff. Don't underestimate how big a problem that is. People have to have an intuitive feel for how it works or its all pointless. My namespaces work just as anyone would expect and are a piece of cake to explain. They work so damn well I bet I wouldn't even have to explain them. It's exactly what you'd guess from the name. But if I did explain it, it would be short and intuitive as in:

"When you mark your character sheet as a namespace it means that OpenRPG only looks inside that namespace for the node it is trying to find (assuming it knows what namespace to look in to begin with, which it can figure out in a number of ways). The references work as if the entire gametree was replaced with just the contents of that namespace. As if the namespace container was the "root" node of it's own gametree structure."

There's no funny extra coding ... just the exact same !@....@! format everyone was using anyway. It's backwards compatible.

I really have never understood your need to re-invent the wheel only with square corners.

Btw, if you do keep going with I'd simply forget about trying to explain it in words and just give a bunch of examples using images.

yes.

O_O, genius? K. The person who asked for it likes it.[/quote]

This is the action I am trying to prevent. Players can get a long fine, the GM having to shuffle around the nodes to find the correct monster node is a pain in the ass.

You are just pissed. Post something positive next time please.

Pissed at what?

This perhaps?



Now you constantly say Traipse is more stable than 1.8.0, which may be right since it was forked from 1.8.0 and 1.8.1 is not yet released, so all you'd have to do to earn that comment is fix one bug, just as I've fixed bugs in 1.8.1 too, but exactly how do you figure this Traipse namespace thing is "more stable" than mine? Have you even used it? Mine is used in actual live play every week.

I'm not going to rag on you for saying it's more stable when you just changed your mind about the code, because I think change in view of experience is vital -- I changed mine a few times too. But not recently. It's pretty much a finished polished product now. Your's is not.

But no, not angry. I don't get angry really. Except at inefficency and this whole dual approach to handling the exact same problem does seem inefficient. Non-compatible character sheets for both branches of the fork too. Bad, bad, bad.

I tried to say something positive when I suggested using images of examples to teach the rules of the new code. I can't comment on the rules themselves as I can't figure them out from the text description. Frankly even the paragraph I wrote on my system just makes it sound more complicated than it is. Maybe this is better:

Whatever. Cry about it then, genius.

Have YOU used yours? The nodes are horrendous. There is a duplicate of the PC Sheet just so the players can move their nodes around. And if it's not that, it's the setting and unsetting of the arbitrary Namespace. How is a GM supposed to play quickly when he/she has to keep setting unsetting Namespace? It sucks dude, and I am not the only person that feels that way. Sorry.

And yes, I have used your current dev, and after I peak at the bugs that still remain I shut it down and live on. I am not copying any of your code anymore even. I don't need too, nor do I want too.

What are you talking about?

Firstly I use it every week for 4 hours. How often do you use Traipse in live play?



Oh you must mean the "horrendous" way can just type in /all Initiative and have all PCs roll their initiative or the way I can find out quickly which PCs have the best Knowledge: Arcana roll. Or the way it keeps track of the to hit and damage when a PC has been sickened in combat, or how it allows me to shapechange my druid at the click of a button and have a complete set of different attributes apply. How I can roll dice with the mini right-click menu NONE of which your system is anywhere near doing, right?

Yeah absolutely horrendous.



What are you on about? I do have blank sheet to make it a snap to make new character sheets. Not as fast as the DM who uses XSLT but still the Clone with Replace feature -- which you don't have -- makes it pretty damn easy. is that what you mean?



I've never had to do that. Why would you ever change it? What are you even talking about?



Do you even have a copy of the code? As far as I know only Paul uses it beyond my group. But I don't think he uses the new reference system (which is fine since UNLIKE Traipse my system is backward compatible). Who else are you talking about with this weird statement? This queer passive aggressive appeal to some anonymous authority "other people".



I am pretty sure I fix more bugs since the 1.8.0 fork than you do and that you copied my code more than vice versa (in fact I don't think I ever copied code from Traipse) so your loss, not mine, but I agree that it gets harder to compare the code, and that is unfortunate.

Look, prof, I have been I think, more than patient with your constant badmouthing of OpenRPG's main branch over your claims of "stability" for Traipse and all the rest of it. Unsubstantiated hype for the most part, and I have not complained before. In part because I know you were not treated well in that whole incident. But I am getting a bit tired of being told now that my code sucks or that my product is unstable which is what you are saying when you are talking about 1.8.1 -- although god knows it hasn't been released yet (no fault of mine) and is in daily state of change so in that sense it is "unstable" of course. But when you talk about the reference system your comments are just ludicrous. The fact is OpenRPG's 1.8.1 has a better system. And not just a bit better. It's a solid piece that was developed over several years. The fact is that code is well written and tested.

Once 1.8.1 comes out I don't want to hear any more about how crap you think other people's stuff is, OK? It's not good for the wider community who just hear "OpenRPG is full of bugs and the devs constantly slag each other off". And if you really do know about some 3rd party user who is play testing my unreleased code -- which I really doubt -- then please tell me who they are so I can get some feedback.



That isn't feedback.

Perhaps I should stop commenting about this issue with you, although I am sure if the roles were reversed and Traipse had a better system you'd be telling people about it every day.

I stopped here because it shows you are out of touch.


EDIT: And continued. I am not going to fight with you. Results are results, so 'when' your supreme leader lets you update the software .. go ahead brag dude. Until then, you bring an argument or saucy words, I'm not responding.

Namespace Internal now utilizes a process I call, FutureCheck. Once Namespace finds a reference you requested, FutureCheck determines if you are looking for more, and if the reference found has what you are looking for.

This new feature allows references to look like this (using the 4e PC Sheet node that comes with Traipse):

!=Abilities=! This will return the value of the Abilities text node found in the Using the 4e PC Sheet node
!=Abilities::(3,2)=! This will return the value of your PCs Strength mod (or grid cell 3,2 in the Abilities grid)

This is as far as I want to develop for Internal now. I will be adding FutureCheck to External soon.

Another example of FutureCheck in action, using the same node:

!=Slot 1=! This will return the Slot 1 text node found in the Back pack tabber because that is the first one it will find.
!=Belt::Slot 1=! This will return the Slot 1 text node in the Belt tabber
!=Inventory::Slot 1=! This will again return the Slot 1 text node found in the Back pack tabber, again because it is the first node found.

And now Namespace External works nearly identical to the previous Namespace, starting from the gametree root itself. Namespace External utilizes FutureCheck as well, so you can be more specific about the location of the node and narrow down the tree's search.

With the changes made to Namespace in Traipse I am very pleased with namespace and how it works. Users will not need to fiddle around with their node names, set / unset Namespace or Index ... or basically paper work. The two models will allow gamers to game without needing to worry if their gametree is picking up on the wrong data.

I don't have plans yet to remove the recursion model that I worked, but the thought is on the table. My argument was previously that users need the control of their nodes but namespace made that really difficult. If a user were to move a node, they would be forced to do paper work to fix all of the broken references. If the change does come about I will make it easy on users to convert their nodes.

While Standard has taken steps to combat the old Namspace problems, it is not without user input. And because it requires user input errors can occur when a user does not understand the method. So I digressed from Namespace.

I hope you enjoy the new Traipse namespace model. This is, to me, the Namespace that I wanted and I felt that users deserved.