World: r3wp

http://www.pointillistic.com/open-REBOL/moa/steel/liquid/plug/plug-quickstart.html

Josh: for simple data compilation and changes (like a D&D character 
creation/evolution), I suggest writing an aspect-oriented type of 
node set for your  application.

I have the ground-work for in if you want to try it out, its ready 
to use, I even built some interactive glass prototypes with it.

basically, how this works is, you have a generic object which you 
pass around from node to node.  each node may add/display/change/remove 
one or all of the attributes in the objects.  


Just plug some aspect-managing node to your "current" node and that's 
it, over and over.   Its as easy as calling a function on an object. 
 the difference is that all states of your character are still available 
up till its creation. 


 you can even branch off at any point and try out another combination 
 with NO risk of corrupting your previous data.

the nice thing is that the "aspects" may act on the values of other 
aspects.  

one aspect could be "dexterity".  

another could be mod-dexterity


the first one sets it , the second one increases it or reduces it.

then another aspect called "armour-class" can be added and it know 
to use the current dexterity bonus to itself.


now you can build up the whole character, up to 12th level like this 
(adding all skills and levels, etc), and at the end, decide you want 
to see how it results with an elf, instead... then paf, you change 
the root aspect "race" to elf, which causes dex to increase by one, 
and since everything is still connected, your ac is increased by 
one, without ANY single other thing to do than ask for the resulting 
character.

the trick is to implement the "rules" within the aspects themselves. 
basically returning some kind of error (or warning) when some rule 
is broken within a node.  (going above some limit, impossible selection 
based on race, etc)

using this technique, I was able to do skining which is independent 
of the gui engine underneith.  one only has to support the aspects 
in his skin and the skins (and gui using them) remain valid, even 
though you are running on opengl or vid.

sorry for the long post... hope I make sense.

I did try the tutorial, but I was stuck beyond the !sum example. 
 I think I just need to actually see something more complex to figure 
it out.

I'd like to try the ground work that you created,

I am not familiar with aspect-oriented programming, so if you have 
some suggestions on what to read to learn more, that would be helpful

hum I just did a bit of googling for it ... can't remember ... IIRC 
a few good references on wikipedia.

But a more complex example would be very helpful, otherwise I'm dead 
in the tracks

yeah I understand... really I do.


as I used to say... "I buit it, and it works really well... but I 
still don't know how to use it !"

paradigms shifts are never easy to face.

but I have spent many hours using liquid, testing it prototyping 
it, and even building an OS Operating Environment with it...and I 
now know its a viable idea.

so... I'll do this for you this week-end (since I have time  :-)

I'll build up a quick and dirty aspect-driven, character creation 
tool  :-)

That would be great

with a gui.

I'ts going to be View only (actually probably direct faces)

in order to leave any gfx issues out of the understanding of the 
tool.

sure, of course

I also have a simple graphics package which uses AGG directly with 
liquid, so I'll use that to further show liquid ties in from end-to-end.

basically, the gui will be plugged-in to the aspects directly, and 
the aspects data entry will also be plugged-in directly to the gui 
 :-)

no VID.  just AGG  ;-)

ok, well... guess I'm going to log off now... I have work to do! 
 ;-)

SOunds great!  If you can't get it finished, at least show me a sizable 
component of it so I can get some ideas

:-)

what I'll do is post all of this on rebol.org, so the whole world 
gets  a view of it  :-)

I've been wanting to do this for ages.... but having someone actively 
looking out for it... makes it much more compeling to do  ...

I'll announce it here when the first parts are available.

hehe, just remember, I'm stuck here doing nothing until you finish 
;-)

yep.

i'm excited

I'm working on it...  :-)

I have a double set-back though... the old aspect code was for a 
previous version of liquid...

and it was profoundly prototypish, I realise.  not enought comments 
for me to even remember how to use... so I'm scanning my old test 
code in order to make it much more usable.

note... the test application is called glass.r   ( an infamous name 
if there is one  ;-)

hehe, yeah, I'm starting to finally fix all my poor coding practices, 
especially with naming.   Anyways, sounds good,  again, you don't 
need to do the whole char gen or anything, but just a good chunk 
for me to see how to put things together

One note:  on http://www.pointillistic.com/open-REBOL/moa/steel/liquid/plug/plug-reference.html
 when I use Opera, nothing after section 2.1.1 gets displayed.  Works 
fine in Firefox though

But I want to see glass.r ;-)

strange, cause its a static html page ... just one or two table.... 
in this case... I must say that opera seems to be the issue  ;-)

did you try reloading the page?

btw wrt the old code, I realised the issue... I had cleaned up the 
lib, and stopped half way....   so the naming changed, a few features 
missing... :-(

fixing it up... will have something during the week..  its the fabled 
week of at school... so I'll have my kids with me the whole week...

of = off

ok, so I have something to send to you... what I have is not really 
usefull to send to rebol.org without any kind of discussion, documentation. 
 I did something different than expected.  I just built a simple 
dataflow driven fsm engine which switches aspects on demand.  then 
I defined aspects which operated on a face, and made a very simple 
feel which sets the various states.

this is the whole feel:
	feel: make feel [
		engage: func [face action event][
			switch action [
				down [fsm/set-state 'pressed]
				up [fsm/clear-state 'pressed]
			]
		]
		
		over: func [ face action pos][
			either action [
				fsm/set-state 'over
			][
				fsm/clear-state 'over
			]
		]
	]

the dataflow takes care of calling any aspect which are built up 
from linked nodes.  basically, you build up a stylesheet by connecting 
nodes together and can branch off at any point, simply reusing the 
previous styles as a base... the cool thing is that the styles aren't 
absolute, you can define more than one style for a single state, 
so that a series of nodes can handle only the edge, others the color, 
yet you can include both in another style  (in my case, the base 
style has both)