// Lines that start like this are comments. They're skipped over by the Kindliser.

// The following settings control what's printed by the Kindliser during it's run-through. 
// There are two parts to the process: data gathering, and output
// The data gathering stage shows what the Kindliser thinks you wrote, and the output shows how it thinks the final game should run. You'll probably find both of these pretty useless, but if something doesn't go as expected, they might be of use.

// To turn them on, remove the leading ! mark. By default, they're both off.

#datareport
!#outputreport


_Example of the Kindliser_

startparagraph
	This is the first paragraph of the game.
	* This is the first option 		[whichlinkstothisparagraph]
	* This is the second option 	[andthislinkshere]

whichlinkstothisparagraph
	define(avariable)
	This paragraph introduces a variable, called "a variable". It doesn't set it, though. The following line does. We then get pushed onto a new section.
	set(avariable)
	-> joinuppoint

andthislinkshere
	define(avariable)
	unset(avariable)
	Here's another paragraph. We set that variable to false (we don't need to; false is the default, but you get the idea. Note we can define a variable in lots of places if we need to). We run straight on from here.
	-> joinuppoint

joinuppoint
	Both routes end up here, but with different values of the variable
	* So this option only appears when the variable is true	[result:itwastrue]		{avariable}
	* And this one only appears when it's false 			[result:itwasfalse]		{!avariable}

result
- itwastrue
	This format is used to organise subsections.
	--> cont
- itwasfalse
	The --> below indicates we're moving to a section inside this heading.
	--> cont
 - cont
	ditch(avariable)
	And here's where we end up. That ditch means we're disallowing use of the variable we declared earlier. This is important, to stop data hanging around when we're not using it (which is massively expensive!) If the variable is later defined again, it will be zeroed as well.
	We can also unset(avariable) to make it false, but keep it in memory.
	-> morecomplexstuff
	
morecomplexstuff
	define(vara)
	define(varb)
	Now we'll do some more complex data work. Firstly, let's set these variables.
	* Set A				[set:a]
	* Set B				[set:b]
	* Set both			[set:both]
	* Set neither		[set:neither]
	
set
- a
	set(vara)
	--> cont
- b
	set(varb)
	--> cont
- both
	set(vara)
	set(varb)
	--> cont
- neither
	--> cont
- cont
	Now in this section we print things depending on these state values. Note that if I change a variable:
	unset(vara)
	...this won't have any effect on the text in this section.
	So here's our examples: {vara & !varb:a was true on its own}{!vara & varb:b was true on its own}{vara & varb:Both were true}{!vara & !varb:Both we false}.
	Also, we can say A was {vara:true|false}, or even A and B were {vara & varb:very true|a least a little bit false}.
	Note there's no OR condition. Also, conditionals can't be nested.
	We can also make conditional diversions. Note, these will jump the game away: they're handled in the order they appear.
	-> onlya 		{vara}
	-> orbingeneral {varb}
	-> neither 		{!vara & !varb}

onlya
	A was true!
	-> finalthoughts

orbingeneral
	So b was true, at least
	-> finalthoughts
	
neither
	And we're done!
	-> finalthoughts

finalthoughts
	So, a few final thoughts:
	- Be really careful with variables. Defining isn't too important - it's there really to help you track what you're doing - but ditching is critical. If you leave a variable unditched and hanging around it can potentially double your final storyfile in size. That's one doubling for each unditched variable. 
	- variables are really Boolean flags: they can be true or false, and that's it. By default, any flag is false. You can test for flags that have been ditched, but they'll always be false.