{% extends 'base/base.html' %} {% block content %}
ink is a scripting language built around the idea of marking up pure-text with flow in order to produce interactive scripts.
At its most basic, it can be used to write a Choose Your Own-style story, or a branching dialogue tree. But its real strength is in writing dialogues with lots of options and lots of recombination of the flow.
ink offers several features to enable non-technical writers to branch often, and play out the consequences of those branches, in both minor and major ways, without fuss.
The script aims to be clean and logically ordered, so branching dialogue can be tested "by eye". The flow is described in a declarative fashion where possible.
It's also designed with redrafting in mind; so editing a flow should be fast.
The most basic ink script is just text in a .ink file.
Hello, world!
On running, this will output the content, and then stop.
Text on separate lines produces new paragraphs. The script:
Hello, world!
Hello?
Hello, are you there?
produces output that looks the same.
By default, all text in your file will appear in the output content, unless specially marked up.
The simplest mark-up is a comment. ink supports two kinds of comment. There's the kind used for someone reading the code, which the compiler ignores:
"What do you make of this?" she asked.
// Something unprintable...
"I couldn't possibly comment," I replied.
/*
... or an unlimited block of text
*/
and there's the kind used for reminding the author what they need to do, that the compiler prints out during compilation:
TODO: Write this section properly!
Input is offered to the player via text choices. A text choice is indicated by an *
character.
If no other flow instructions are given, once made, the choice will flow into the next line of text.
Hello world!
* Hello back!
Nice to hear from you!
This produces the following game:
Hello world
1: Hello back!
> 1
Hello back!
Nice to hear from you.
By default, the text of a choice appears again, in the output.
Some games separate the text of a choice from its outcome. In ink, if the choice text is given in square brackets, the text of the choice will not be printed into response.
Hello world!
* [Hello back!]
Nice to hear from you!
produces
Hello world
1: Hello back!
> 1
Nice to hear from you.
The square brackets in fact divide up the option content. What's before is printed in both choice and output; what's inside only in choice; and what's after, only in output. Effectively, they provide alternative ways for a line to end.
Hello world!
* Hello [back!] right back to you!
Nice to hear from you!
produces:
Hello world
1: Hello back!
> 1
Hello right back to you!
Nice to hear from you.
This is most useful when writing dialogue choices:
"What's that?" my master asked.
* "I am somewhat tired[."]," I repeated.
"Really," he responded. "How deleterious."
produces:
"What's that?" my master asked.
1. "I am somewhat tired."
> 1
"I am somewhat tired," I repeated.
"Really," he responded. "How deleterious."
To make choices really choices, we need to provide alternatives. We can do this simply by listing them:
"What that's?" my master asked.
* "I am somewhat tired[."]," I repeated.
"Really," he responded. "How deleterious."
* "Nothing, Monsieur!"[] I replied.
"Very good, then."
* "I said, this journey is appalling[."] and I want no more of it."
"Ah," he replied, not unkindly. "I see you are feeling frustrated. Tomorrow, things will improve."
This produces the following game:
"What that's?" my master asked.
1: "I am somewhat tired."
2: "Nothing, Monsieur!"
3: "I said, this journey is appalling."
> 3
"I said, this journey is appalling and I want no more of it."
"Ah," he replied, not unkindly. "I see you are feeling frustrated. Tomorrow, things will improve."
The above syntax is enough to write a single set of choices. In a real game, we'll want to move the flow from one point to another based on what the player chooses. To do that, we need to introduce a bit more structure.
To allow the game to branch we need to mark up sections of content with names (as an old-fashioned gamebook does with its 'Paragraph 18', and the like.)
These sections are called "knots" and they're the fundamental structural unit of ink content.
The start of a knot is indicated by two or more equals signs, as follows.
=== top_knot ===
(The equals signs on the end are optional; and the name needs to be a single word with no spaces.)
The start of a knot is a header; the content that follows will be inside that knot.
=== back_in_london ===
We arrived into London at 9.45pm exactly.
Note that the game will automatically run the first knot it finds in a story if there is no "non-knot" content, so the simplest script is now:
=== top_knot ===
Hello world!
However, ink doesn't like loose ends, and produces a warning on compilation and/or run-time when it thinks this has happened. The script above produces this on compilation:
WARNING: Apparent loose end exists where the flow runs out. Do you need a '-> END' statement, choice or divert? on line 3 of tests/test.ink
and this on running:
Runtime error in tests/test.ink line 3: ran out of content. Do you need a '-> DONE' or '-> END'?
The following plays and compiles without error:
=== top_knot ===
Hello world!
-> END
-> END
is a marker for both the writer and the compiler; it means "the story flow should now stop".
You can tell the story to move from one knot to another using ->
, a "divert arrow". Diverts happen immediately without any user input.
=== back_in_london ===
We arrived into London at 9.45pm exactly.
-> hurry_home
=== hurry_home ===
We hurried home to Savile Row as fast as we could.
Diverts are intended to be seamless and can even happen mid-sentence:
=== hurry_home ===
We hurried home to Savile Row -> as_fast_as_we_could
=== as_fast_as_we_could ===
as fast as we could.
produces the same line as above:
We hurried home to Savile Row as fast as we could.
The default behaviour inserts line-breaks before every new line of content. In some cases, however, content must insist on not having a line-break, and it can do so using <>
, or "glue".
=== hurry_home ===
We hurried home <>
-> to_savile_row
=== to_savile_row ===
to Savile Row
-> as_fast_as_we_could
=== as_fast_as_we_could ===
<> as fast as we could.
also produces:
We hurried home to Savile Row as fast as we could.
You can't use too much glue: multiple glues next to each other have no additional effect. (And there's no way to "negate" a glue; once a line is sticky, it'll stick.)

* [Open the gate] -> paragraph_2
* [Smash down the gate] -> paragraph_3
* [Turn back and go home] -> paragraph_4
=== paragraph_2 ===
You open the gate, and step out onto the path.
...
Using diverts, the writer can branch the flow, and join it back up again, without showing the player that the flow has rejoined.
=== back_in_london ===
We arrived into London at 9.45pm exactly.
* "There is not a moment to lose!"[] I declared.
-> hurry_outside
* "Monsieur, let us savour this moment!"[] I declared.
My master clouted me firmly around the head and dragged me out of the door.
-> dragged_outside
* [We hurried home] -> hurry_outside
=== hurry_outside ===
We hurried home to Savile Row -> as_fast_as_we_could
=== dragged_outside ===
He insisted that we hurried home to Savile Row
-> as_fast_as_we_could
=== as_fast_as_we_could ===
<> as fast as we could.
Knots and diverts combine to create the basic story flow of the game. This flow is "flat" - there's no call-stack, and diverts aren't "returned" from.
In most ink scripts, the story flow starts at the top, bounces around in a spaghetti-like mess, and eventually, hopefully, reaches a -> END
.
The very loose structure means writers can get on and write, branching and rejoining without worrying about the structure that they're creating as they go. There's no boiler-plate to creating new branches or diversions, and no need to track any state.
You absolutely can use diverts to create looped content, and ink has several features to exploit this, including ways to make the content vary itself, and ways to control how often options can be chosen.
See the sections on Varying Text and Conditional Options for more information.
Oh, and the following is legal and not a great idea:
=== round ===
and
-> round
As stories get longer, they become more confusing to keep organised without some additional structure.
Knots can include sub-sections called "stitches". These are marked using a single equals sign.
=== the_orient_express ===
= in_first_class
...
= in_third_class
...
= in_the_guards_van
...
= missed_the_train
...
One could use a knot for a scene, for instance, and stitches for the events within the scene.
A stitch can be diverted to using its "address".
* [Travel in third class]
-> the_orient_express.in_third_class
* [Travel in the guard's van]
-> the_orient_express.in_the_guards_van
Diverting to a knot which contains stitches will divert to the first stitch in the knot. So:
* [Travel in first class]
"First class, Monsieur. Where else?"
-> the_orient_express
is the same as:
* [Travel in first class]
"First class, Monsieur. Where else?"
-> the_orient_express.in_first_class
(...unless we move the order of the stitches around inside the knot!)
You can also include content at the top of a knot outside of any stitch. However, you need to remember to divert out of it - the engine won't automatically enter the first stitch once it's worked its way through the header content.
=== the_orient_express ===
We boarded the train, but where?
* [First class] -> in_first_class
* [Second class] -> in_second_class
= in_first_class
...
= in_second_class
...
From inside a knot, you don't need to use the full address for a stitch.
-> the_orient_express
=== the_orient_express ===
= in_first_class
I settled my master.
* [Move to third class]
-> in_third_class
= in_third_class
I put myself in third.
This means stitches and knots can't share names, but several knots can contain the same stitch name. (So both the Orient Express and the SS Mongolia can have first class.)
The compiler will warn you if ambiguous names are used.
You can also split your content across multiple files, using an include statement.
INCLUDE newspaper.ink
INCLUDE cities/vienna.ink
INCLUDE journeys/orient_express.ink
Include statements should always go at the top of a file, and not inside knots.
There are no rules about what file a knot must be in to be diverted to. (In other words, separating files has no effect on the game's namespacing.)
By default, every choice in the game can only be chosen once. If you don't have loops in your story, you'll never notice this behaviour. But if you do use loops, you'll quickly notice your options disappearing...
=== find_help ===
You search desperately for a friendly face in the crowd.
* The woman in the hat[?] pushes you roughly aside. -> find_help
* The man with the briefcase[?] looks disgusted as you stumble past him. -> find_help
produces:
You search desperately for a friendly face in the crowd.
1: The woman in the hat?
2: The man with the briefcase?
> 1
The woman in the hat pushes you roughly aside.
You search desperately for a friendly face in the crowd.
1: The man with the briefcase?
>
... and on the next loop you'll have no options left.
The above example stops where it does, because the next choice ends up in an "out of content" run-time error.
> 1
The man with the briefcase looks disgusted as you stumble past him.
You search desperately for a friendly face in the crowd.
Runtime error in tests/test.ink line 6: ran out of content. Do you need a '-> DONE' or '-> END'?
We can resolve this with a 'fallback choice'. Fallback choices are never displayed to the player, but are 'chosen' by the game if no other options exist.
A fallback choice is simply a "choice without choice text":
* -> out_of_options
We can use the square-bracket notation here as well:
* [] Mulder never could explain how he got out of that burning box car. -> season_2
Adding this into the previous example gives us:
=== find_help ===
You search desperately for a friendly face in the crowd.
* The woman in the hat[?] pushes you roughly aside. -> find_help
* The man with the briefcase[?] looks disgusted as you stumble past him. -> find_help
* [] But it is too late: you collapse onto the station platform. This is the end.
-> END
and produces:
You search desperately for a friendly face in the crowd.
1: The woman in the hat?
2: The man with the briefcase?
> 1
The woman in the hat pushes you roughly aside.
You search desperately for a friendly face in the crowd.
1: The man with the briefcase?
> 1
The man with the briefcase looks disgusted as you stumble past him.
You search desperately for a friendly face in the crowd.
But it is too late: you collapse onto the station platform. This is the end.
The 'once-only' behaviour is not always what we want, of course, so we have a second kind of choice: the "sticky" choice. A sticky choice is simply one that doesn't get used up, and is marked by a +
bullet.
=== homers_couch ===
+ [Eat another donut]
You eat another donut. -> homers_couch
* [Get off the couch]
You struggle up off the couch to go and compose epic poetry.
-> END
You can also turn choices on and off by hand. ink has quite a lot of logic available, but the simplest tests is "has the player seen a particular piece of content".
Every knot/stitch in the game has a unique address (so it can be diverted to), and we use the same address to test if that piece of content has been seen.
* { not visit_paris } [Go to Paris] -> visit_paris
+ { visit_paris } [Return to Paris] -> visit_paris
* { visit_paris.met_estelle } [ Telephone Mme Estelle ] -> phone_estelle
Note that the test knot_name
is true if any stitch inside that knot has been seen.
Note also that conditionals don't override the once-only behaviour of options, so you'll still need sticky options for repeatable choices.
You can use several logical tests on an option; if you do, all the tests must all be passed for the option to appear.
* { not visit_paris } [Go to Paris] -> visit_paris
+ { visit_paris } { not bored_of_paris }
[Return to Paris] -> visit_paris
The test:
* {seen_clue} [Accuse Mr Jefferson]
is actually testing an integer and not a true/false flag. A knot or stitch used this way is actually an integer variable containing the number of times the content at the address has been seen by the player.
If it's non-zero, it'll return true in a test like the one above, but you can also be more specific as well:
* {seen_clue > 3} [Flat-out arrest Mr Jefferson]
ink supports a lot more logic and conditionality than covered here - see the section on 'variables and logic'.
So far, all the content we've seen has been static, fixed pieces of text. But content can also vary at the moment of being printed.
The simplest variations of text are from lists, which are selected from depending on some kind of rule. ink supports several types. Lists are written inside {
...}
curly brackets, with elements separated by |
symbols (vertical divider lines).
These are only useful if a piece of content is visited more than once!
Sequences (the default):
A sequence (or a "stopping list") is a list that tracks how many times its been seen, and each time, shows the next element along. When it runs out of new content it continues the show the final element.
The radio hissed into life. {"Three!"|"Two!"|"One!"|There was the white noise racket of an explosion.|But it was just static.}
{I bought a coffee with my five-pound note.|I bought a second coffee for my friend.|I didn't have enough money to buy any more coffee.}
Cycles (marked with a &
):
Cycles are like sequences, but they loop their content.
It was {&Monday|Tuesday|Wednesday|Thursday|Friday|Saturday|Sunday} today.
Once-only (marked with a !
):
Once-only lists are like sequences, but when they run out of new content to display, they display nothing. (You can think of a once-only list as a sequence with a blank last entry.)
He told me a joke. {!I laughed politely.|I smiled.|I grimaced.|I promised myself to not react again.}
Shuffles (marked with a ~
):
Shuffles produce randomised output.
I tossed the coin. {~Heads|Tails}.
Lists can contain blank elements.
I took a step forward. {!||||Then the lights went out. -> eek}
Lists can be nested.
The Ratbear {&{wastes no time and |}swipes|scratches} {&at you|into your {&leg|arm|cheek}}.
Lists can include divert statements.
I {waited.|waited some more.|snoozed.|woke up and waited more.|gave up and left. -> leave_post_office}
They can also be used inside choice text:
+ "Hello, {&Master|Monsieur Fogg|you|brown-eyes}!"[] I declared.
(...with one caveat; you can't start an option's text with a {
, as it'll look like a conditional.)
Lists can be used inside loops to create the appearance of intelligent, state-tracking gameplay without particular effort.
Here's a one-knot version of whack-a-mole. Note we use once-only options, and a fallback, to ensure the mole doesn't move around, and the game will always end.
=== whack_a_mole ===
{I heft the hammer.|{~Missed!|Nothing!|No good. Where is he?|Ah-ha! Got him! -> END}}
The {&mole|{&nasty|blasted|foul} {&creature|rodent}} is {in here somewhere|hiding somewhere|still at large|laughing at me|still unwhacked|doomed}. <>
{!I'll show him!|But this time he won't escape!}
* [{&Hit|Smash|Try} top-left] -> whack_a_mole
* [{&Whallop|Splat|Whack} top-right] -> whack_a_mole
* [{&Blast|Hammer} middle] -> whack_a_mole
* [{&Clobber|Bosh} bottom-left] -> whack_a_mole
* [{&Nail|Thump} bottom-right] -> whack_a_mole
* [] Then you collapse from hunger. The mole has defeated you!
-> END
produces the following 'game':
I heft the hammer.
The mole is in here somewhere. I'll show him!
1: Hit top-left
2: Whallop top-right
3: Blast middle
4: Clobber bottom-left
5: Nail bottom-right
> 1
Missed!
The nasty creature is hiding somewhere. But this time he won't escape!
1: Splat top-right
2: Hammer middle
3: Bosh bottom-left
4: Thump bottom-right
> 4
Nothing!
The mole is still at large.
1: Whack top-right
2: Blast middle
3: Clobber bottom-left
> 2
Where is he?
The blasted rodent is laughing at me.
1: Whallop top-right
2: Bosh bottom-left
> 1
Ah-ha! Got him!
And here's a bit of lifestyle advice. Note the sticky choice - the lure of the television will never fade:
=== turn_on_television ===
I turned on the television {for the first time|for the second time|again|once more}, but there was {nothing good on, so I turned it off again|still nothing worth watching|even less to hold my interest than before|nothing but rubbish|a program about sharks and I don't like sharks|nothing on}.
+ [Try it again] -> turn_on_television
* [Go outside instead] -> go_outside_instead
=== go_outside_instead ===
-> END
ink has another format for making lists of varying content blocks, too. See the section on "multiline blocks" for details.
Text can also vary depending on logical tests, just as options can.
{met_blofeld: "I saw him. Only for a moment." }
and
"His real name was {met_blofeld.learned_his_name: Franz|a secret}."
These can appear as separate lines, or within a section of content. They can even be nested, so:
{met_blofeld: "I saw him. Only for a moment. His real name was {met_blofeld.learned_his_name: Franz|kept a secret}." | "I missed him. Was he particularly evil?" }
can produce either:
"I saw him. Only for a moment. His real name was Franz."
or:
"I saw him. Only for a moment. His real name was kept a secret."
or:
"I missed him. Was he particularly evil?"
ink provides a few useful 'game level' queries about game state, for use in conditional logic. They're not quite parts of the language, but they're always available, and they can't be edited by the author. In a sense, they're the "standard library functions" of the language.
The convention is to name these in capital letters.
CHOICE_COUNT
returns the number of options created so far in the current chunk. So for instance.
* {false} Option A
* {true} Option B
* {CHOICE_COUNT() == 1} Option C
produces two options, B and C. This can be useful for controlling how many options a player gets on a turn.
TURNS_SINCE
returns the number of moves (formally, player inputs) since a particular knot/stitch was last visited.
A value of 0 means "was seen as part of the current chunk". A value of -1 means "has never been seen". Any other positive value means it has been seen that many turns ago.
* {TURNS_SINCE(-> sleeping.intro) > 10} You are feeling tired... -> sleeping
* {TURNS_SINCE(-> laugh) == 0} You try to stop laughing.
Note that the parameter passed to TURNS_SINCE
is a "divert target", not simply the knot address itself (because the knot address is a number - the read count - not a location in the story...)
TODO: (requirement of passing -c
to the compiler)
You can make your own external functions, though the syntax is a bit different: see the section on functions below.
So far, we've been building branched stories in the simplest way, with "options" that link to "pages".
But this requires us to uniquely name every destination in the story, which can slow down writing and discourage minor branching.
ink has a much more powerful syntax available, designed for simplifying story flows which have an always-forwards direction (as most stories do, and most computer programs don't).
This format is called "weave", and its built out of the basic content/option syntax with two new features: the gather mark, -
, and the nesting of choices and gathers.
Let's go back to the first multi-choice example at the top of this document.
"What's that?" my master asked.
* "I am somewhat tired[."]," I repeated.
"Really," he responded. "How deleterious."
* "Nothing, Monsieur!"[] I replied.
* "I said, this journey is appalling[."] and I want no more of it."
"Ah," he replied, not unkindly. "I see you are feeling frustrated. Tomorrow, things will improve."
In a real game, all three of these options might well lead to the same conclusion - Monsieur Fogg leaves the room. We can do this using a gather, without the need to create any new knots, or add any diverts.
"What that's?" my master asked.
* "I am somewhat tired[."]," I repeated.
"Really," he responded. "How deleterious."
* "Nothing, Monsieur!"[] I replied.
"Very good, then."
* "I said, this journey is appalling[."] and I want no more of it."
"Ah," he replied, not unkindly. "I see you are feeling frustrated. Tomorrow, things will improve."
- With that Monsieur Fogg left the room.
This produces the following playthrough:
"What that's?" my master asked.
1: "I am somewhat tired."
2: "Nothing, Monsieur!"
3: "I said, this journey is appalling."
> 1
"I am somewhat tired," I repeated.
"Really," he responded. "How deleterious."
With that Monsieur Fogg left the room.
We can string these gather-and-branch sections together to make branchy sequences that always run forwards.
=== escape ===
I ran through the forest, the dogs snapping at my heels.
* I checked the jewels[] were still in my pocket, and the feel of them brought a spring to my step. <>
* I did not pause for breath[] but kept on running. <>
* I cheered with joy. <>
- The road could not be much further! Mackie would have the engine running, and then I'd be safe.
* I reached the road and looked about[]. And would you believe it?
* I should interrupt to say Mackie is normally very reliable[]. He's never once let me down. Or rather, never once, previously to that night.
- The road was empty. Mackie was nowhere to be seen.
This is the most basic kind of weave. The rest of this section details additional features that allow weaves to nest, contain side-tracks and diversions, divert within themselves, and above all, reference earlier choices to influence later ones.
Weaves are more than just a convenient encapsulation of branching flow; they're also a way to author more robust content. The escape
example above has already four possible routes through, and a more complex sequence might have lots and lots more. Using normal diverts, one has to check the links by chasing the diverts from point to point and it's easy for errors to creep in.
With a weave, the flow is guaranteed to start at the top and "fall" to the bottom. Flow errors are impossible in a basic weave structure, and the output text can be easily skim read. That means there's no need to actually test all the branches in game to be sure they work as intended.
Weaves also allow for easy redrafting of choice-points; in particular, it's easy to break a sentence up and insert additional choices for variety or pacing reasons, without having to re-engineer any flow.
The weaves shown above are quite simple, "flat" structures. Whatever the player does, they take the same number of turns to get from top to bottom. However, sometimes certain choices warrant a bit more depth or complexity.
For that, we allow weaves to nest.
This section comes with a warning. Nested weaves are very powerful and very compact, but they can take a bit of getting used to!
Consider the following scene:
- "Well, Poirot? Murder or suicide?"
* "Murder!"
* "Suicide!"
- Ms. Christie lowered her manuscript a moment. The rest of the writing group sat, open-mouthed.
The first choice presented is "Murder!" or "Suicide!". If Poirot declares a suicide, there's no more to do, but in the case of murder, there's a follow-up question needed - who does he suspect?
We can add new options via a set of nested sub-choices. We tell the script that these new choices are "part of" another choice by using two asterisks, instead of just one.
- "Well, Poirot? Murder or suicide?"
* "Murder!"
"And who did it?"
* * "Detective-Inspector Japp!"
* * "Captain Hastings!"
* * "Myself!"
* "Suicide!"
- Mrs. Christie lowered her manuscript a moment. The rest of the writing group sat, open-mouthed.
(Note that it's good style to also indent the lines to show the nesting, but the compiler doesn't mind.)
And should we want to add new sub-options to the other route, we do that in similar fashion.
- "Well, Poirot? Murder or suicide?"
* "Murder!"
"And who did it?"
* * "Detective-Inspector Japp!"
* * "Captain Hastings!"
* * "Myself!"
* "Suicide!"
"Really, Poirot? Are you quite sure?"
* * "Quite sure."
* * "It is perfectly obvious."
- Mrs. Christie lowered her manuscript a moment. The rest of the writing group sat, open-mouthed.
Now, that initial choice of accusation will lead to specific follow-up questions - but either way, the flow will come back together at the gather point, for Mrs. Christie's cameo appearance.
But what if we want a more extended sub-scene?
Sometimes, it's not a question of expanding the number of options, but having more than one additional beat of story. We can do this by nesting gather points as well as options.
- "Well, Poirot? Murder or suicide?"
* "Murder!"
"And who did it?"
* * "Detective-Inspector Japp!"
* * "Captain Hastings!"
* * "Myself!"
- - "You must be joking!"
* * "Mon ami, I am deadly serious."
* * "If only..."
* "Suicide!"
"Really, Poirot? Are you quite sure?"
* * "Quite sure."
* * "It is perfectly obvious."
- Mrs. Christie lowered her manuscript a moment. The rest of the writing group sat, open-mouthed.
If the player chooses the "murder" option, they'll have two choices in a row on their sub-branch - a whole flat weave, just for them.
Gathers are, hopefully, work intuitively, but their behaviou is a little harder to put into words: in general, after an option has been taken, the story finds the next gather down that isn't on a lower level, and diverts to it.
The basic idea is this: options separate the paths of the story, and gathers bring them back together. (Hence the name, "weave"!)
Above, we used two levels of nesting; the main flow, and the sub-flow. But there's no limit to how many levels deep you can go.
- "Tell us a tale, Captain!"
* "Very well, you sea-dogs. Here's a tale..."
* * "It was a dark and stormy night..."
* * * "...and the crew were restless..."
* * * * "... and they said to their Captain..."
* * * * * "...Tell us a tale Captain!"
* "No, it's past your bed-time."
- To a man, the crew began to yawn.
After a while, this sub-nesting gets hard to read and manipulate, so it's good style to divert away to a new stitch if a side-choice goes unwieldy.
But, in theory at least, you could write your entire story as a single weave.
Here's a longer example:
- I looked at Monsieur Fogg
* ... and I could contain myself no longer.
'What is the purpose of our journey, Monsieur?'
'A wager,' he replied.
* * 'A wager!'[] I returned.
He nodded.
* * * 'But surely that is foolishness!'
* * * 'A most serious matter then!'
- - - He nodded again.
* * * 'But can we win?'
'That is what we will endeavour to find out,' he answered.
* * * 'A modest wager, I trust?'
'Twenty thousand pounds,' he replied, quite flatly.
* * * I asked nothing further of him then[.], and after a final, polite cough, he offered nothing more to me. <>
* * 'Ah[.'],' I replied, uncertain what I thought.
- - After that, <>
* ... but I said nothing[] and <>
- we passed the day in silence.
- -> END
with a couple of possible playthroughs. A short one:
I looked at Monsieur Fogg
1: ... and I could contain myself no longer.
2: ... but I said nothing
> 2
... but I said nothing and we passed the day in silence.
and a longer one:
I looked at Monsieur Fogg
1: ... and I could contain myself no longer.
2: ... but I said nothing
> 1
... and I could contain myself no longer.
'What is the purpose of our journey, Monsieur?'
'A wager,' he replied.
1: 'A wager!'
2: 'Ah.'
> 1
'A wager!' I returned.
He nodded.
1: 'But surely that is foolishness!'
2: 'A most serious matter then!'
> 2
'A most serious matter then!'
He nodded again.
1: 'But can we win?'
2: 'A modest wager, I trust?'
3: I asked nothing further of him then.
> 2
'A modest wager, I trust?'
'Twenty thousand pounds,' he replied, quite flatly.
After that, we passed the day in silence.
Hopefully, this demonstrates the philosophy laid out above: that weaves offer a compact way to offer a lot of branching, a lot of choices, but with the guarantee of getting from beginning to end!
Sometimes, the weave structure is sufficient. But when it's not, we need a bit more control.
By default, lines of content in a weave don't have an address or label, which means they can't be diverted to, and they can't be tested for. In the most basic weave structure, choices vary the path the player takes through the weave and what they see, but once the weave is finished those choices and that path are forgotten.
But should we want to remember what the player has seen, we can - we add in labels where they're needed using the (label_name)
syntax.
Gather points at any nested level can be labelled using brackets.
- (top)
Once labelled, gather points can be diverted to, or tested for in conditionals, just like knots and stitches. This means you can use previous decisions to alter later outcomes inside the weave, while still keeping all the advantages of a clear, reliable forward-flow.
Options can also be labelled, just like gather points, using brackets. Label brackets come before conditions in the line.
These addresses can be used in conditional tests, which can be useful for creating options unlocked by other options.
=== meet_guard ===
The guard frowns at you.
* (greet) [Greet him]
'Greetings.'
* (get_out) 'Get out of my way[.'],' you tell the guard.
 He stares in reply, and draws his sword!
-> fight_guard // this route diverts out of the weave
- 'Mff,' the guard replies, and then offers you a paper bag. 'Toffee?'
Inside the same block of weave, you can simply use the label name; from outside the block you need a path, either to a different stitch within the same knot:
=== knot ===
= stitch_one
- (gatherpoint) Some content.
= stitch_two
* {stitch_one.gatherpoint} Option
or pointing into another knot:
=== knot_one ===
- (gather_one)
* {knot_two.stitch_two.gather_two} Option
=== knot_two ===
= stitch_two
- (gather_two)
* {knot_one.gather_one} Option
In truth, all content in ink is a weave, even if there are no gathers in sight. That means you can label any option in the game with a bracket label, and then reference it using the addressing syntax. In particular, this means you can test which option a player took to reach a particular outcome.
=== fight_guard ===
...
= throw_something
* (rock) [Throw rock at guard] -> throw
* (sand) [Throw sand at guard] -> throw
= throw
You hurl {throw_something.rock:a rock|a handful of sand} at the guard.
Labelling allows us to create loops inside weaves. Here's a standard pattern for asking questions of an NPC.
- (opts)
* 'Can I get a uniform from somewhere?'[] you ask the cheerful guard.
'Sure. In the locker.' He grins.  'Old as coal.'
* 'Are there dogs?'
'Hundreds,' the guard answers, with a toothy grin. 'Hungry devils, too.'
// We require the player to ask at least one question
* {loop} [Enough talking]
-> done
- (loop)
// loop a few times before the guard gets bored
{ -> opts | -> opts | }
He scratches his head.
'Well, can't stand around talking all day,' he declares.
- (done)
You thank the guard, and move away.
Options can also be diverted to: but the divert goes to the output of having chosen that choice, as though the choice had been chosen.  You shove the guard to one side, but he comes back swinging.
1: Grapple and fight
>
The following is valid, and frequently useful.
* "Are you quite well, Monsieur?"[] I asked.
- - (quitewell) "Quite well," he replied.
* "How did you do at the crossword, Monsieur?"[] I asked.
-> quitewell
* I said nothing[] and neither did my Master.
- We feel into companionable silence once more.
Note the level 2 gather point directly below the first option: there's nothing to gather here, really, but it gives us a handy place to divert the second option to.
So far we've made conditional text, and conditional choices, using tests based on what content the player has seen so far.
ink also supports variables, both temporary and global, storing numerical and content data, or even story flow commands. It is fully-featured in terms of logic, and contains a few additional structures to help keep the often complex logic of a branching story better organised.
The most powerful kind of variable, and arguably the most useful for a story, is a variable to store some unique property about the state of the game - anything from the amount of money in the protagonist's pocket, to a value representing the protagonist's state of mind.
This kind of variable is called "global" because it can be accessed from anywhere in the story - both set, and read from. (Traditionally, programming tries to avoid this kind of thing, as it allows one part of a program to mess with another, unrelated part. But a story is a story, and stories are all about consequences: what happens in Vegas rarely stays there.)
Global variables can be defined anywhere, via a VAR
statement. They should be given an initial value, which defines what type of variable they are - integer, floating point (decimal), content, or a story address.
VAR knowledge_of_the_cure = false
VAR players_name = "Emilia"
VAR number_of_infected_people = 521
VAR current_epilogue = -> they_all_die_of_the_plague
We can test global variables to control options, and provide conditional text, in a similar way to what we have previously seen.
=== the_train ===
The train jolted and rattled. { mood > 0:I was feeling positive enough, however, and did not mind the odd bump|It was more than I could bear}.
* { not knows_about_wager } 'But, Monsieur, why are we travelling?'[] I asked.
* { knows_about_wager} I contemplated our strange adventure[]. Would it be possible?
A "divert" statement is actually a type of value in itself, and can be stored, altered, and diverted to.
VAR current_epilogue = -> everybody_dies
=== continue_or_quit ===
Give up now, or keep trying to save your Kingdom?
* [Keep trying!] -> more_hopeless_introspection
* [Give up] -> current_epilogue
Global variables can be accessed, and altered, from the runtime as well from the story, so provide a good way to communicate between the wider game and the story.
The ink layer is often be a good place to store gameplay-variables; there's no save/load issues to consider, and the story itself can react to the current values.
The value of a variable can be printed as content using an inline syntax similar to sequences, and conditional text:
VAR friendly_name_of_player = "Jackie"
VAR age = 23
"My name is Jean Passepartout, but my friend's call me {friendly_name_of_player}. I'm {age} years old."
This can be useful in debugging. For more complex printing based on logic and variables, see the section on functions.
Obviously, our global variables are not intended to be constants, so we need a syntax for altering them.
Since by default, any text in an ink script is printed out directly to the screen, we use a markup symbol to indicate that a line of content is intended meant to be doing some numerical work, we use the ~
mark.
The following statements all assign values to variables:
=== set_some_variables ===
~ knows_about_wager = true
~ x = (x * x) - (y * y) + c
~ y = 2 * x * y
ink supports the four basic mathematical operations (+
, -
, *
and /
), as well as %
(or mod
), which returns the remainder after integer division.
If more complex operations are required, one can write functions (for recursive formulas and the like), or call out to external, game-code functions (for anything more advanced).
Results of operations - in particular, for division - are typed based on the type of the input. So integer division returns integer, but floating point division returns floating point results.
~ x = 2 / 3
~ y = 7 / 3
~ z = 1.2 / 0.5
assigns x
to be 0, y
to be 2 and z
to be 2.4.
We've seen conditionals used to control options and story content; ink also provides an equivalent of the normal if/else if/else structure.
The if syntax takes its cue from the other conditionals used so far, with the {
...}
syntax indicating that something is being tested.
{ x > 0:
~ y = x - 1
}
Else conditions can be provided:
{ x > 0:
~ y = x - 1
- else:
~ y = x + 1
}
The above syntax is actually a specific case of a more general structure, something like a "switch" statement of another language:
{
- x > 0:
~ y = x - 1
- else:
~ y = x + 1
}
And using this form we can include 'else-if' conditions:
{
- x == 0:
~ y = 0
- x > 0:
~ y = x - 1
- else:
~ y = x + 1
}
(Note, as with everything else, the white-space is purely for readability and has no syntactic meaning.)
Note these tests don't have to be variable-based and can use read-counts, just as other conditionals can, and the following construction is quite frequent, as a way of saying "do some content which is relevant to the current game state":
=== dream ===
{
- visited_snakes && not dream_about_snakes:
~ fear++
-> dream_about_snakes
- visited_poland && not dream_about_polish_beer:
~ fear--
-> dream_about_polish_beer
- else:
// breakfast-based dreams have no effect
-> dream_about_marmalade
}
The syntax has the advantage of being easy to extend, and prioritise.
Conditional blocks can be used to control story content as well as logic:
I stared at Monsieur Fogg.
{ know_about_wager:
<> "But surely you are not serious?" I demanded.
- else:
<> "But there must be a reason for this trip," I observed.
}
He said nothing in reply, merely considering his newspaper with as much thoroughness as entomologist considering his latest pinned addition.
You can even put options inside conditional blocks:
{ door_open:
* I strode out of the compartment[] and I fancied I heard my master quietly tutting to himself. -> go_outside
- else:
* I asked permission to leave[] and Monsieur Fogg looked surprised. -> open_door
* I stood and went to open the door[]. Monsieur Fogg seemed untroubled by this small rebellion. -> open_door
}
...but note that the lack of weave-syntax and nesting in the above example isn't accidental: to avoid confusing the various kinds of nesting at work, you aren't allowed to include gather points inside conditional blocks.
There's one other class of multiline block, which expands on the list functionality previous mentioned. The following are all valid and do what you might expect:
// Sequence: go through the alternatives, and stick on last
{ stopping:
- I entered the casino.
- I entered the casino again.
- Once more, I went inside.
}
// Shuffle: show one at random
At the table, I drew a card. <>
{ shuffle:
- Ace of Hearts.
- King of Spades.
- 2 of Diamonds.
'You lose!' crowed the croupier.
-> leave_casino
}
// Cycle: show each in turn, and then cycle
{ cycle:
- I held my breath.
- I waited impatiently.
- I paused.
}
// Once: show each, once, in turn, until all have been shown
{ once:
- Would my luck hold?
- Could I win the hand?
}
Sometimes, a global variable is unwieldy. ink provides temporary variables for quick calculations of things.
=== near_north_pole ===
~ temp number_of_warm_things = 0
{ blanket:
~ number_of_warm_things++
}
{ ear_muffs:
~ number_of_warm_things++
}
{ gloves:
~ number_of_warm_things++
}
{ number_of_warm_things > 2:
Despite the snow, I felt incorrigibly snug.
- else:
That night I was colder than I have ever been.
}
The value in a temporary variable is thrown away after the story leaves the knot in which it was defined.
TODO: check this is actually true
A particularly useful form of temporary variable is a parameter. Any knot or stitch can be given a value as a parameter.
* [Accuse Hasting]
-> accuse("Hastings")
* [Accuse Mrs Black]
-> accuse("Claudia")
* [Accuse myself]
-> accuse("myself")
=== accuse(who) ===
"I accuse {who}!" Poirot declared.
"Really?" Japp replied. "{who == "myself":You did it?|{who}?}"
"And why not?" Poirot shot back.
Temporary variables are safe to use in recursion (unlike globals), so the following will work.
-> add_one_to_one_hundred(0, 1)
=== add_one_to_one_hundred(total, x) ===
~ total = total + x
{ x == 100:
-> finished(total)
- else:
-> add_one_to_one_hundred(total, x + 1)
}
=== finished(total) ===
"The result is {total}!" you announce.
Gauss stares at you in horror.
-> END
(In fact, this kind of definition is useful enough that ink provides a special kind of knot, called, imaginatively enough, a function
, which comes with certain restrictions and can return a value. See the section below.)
Knot/stitch addresses are a type of value, indicated by a ->
character, and can be stored and passed around. The following is therefore legal, and often useful:
=== sleeping_in_hut ===
You lie down and close your eyes.
-> generic_sleep (-> waking_in_the_hut)
=== generic_sleep (-> waking)
You sleep perchance to dream etc. etc.
-> waking
=== waking_in_the_hut
You get back to your feet, ready to continue your journey.
...but note the ->
in the generic_sleep
definition: that's the one case in ink where a parameter needs to be typed: because it's too easy to otherwise accidentally do the following:
=== sleeping_in_hut ===
You lie down and close your eyes.
-> generic_sleep (waking_in_the_hut)
... which sends the read count of waking_in_the_hut
into the sleeping knot, and then attempts to divert to it.
The use of parameters on knots means they are almost functions in the usual sense, but they lack one key concept - that of the call stack, and the use of return values.
ink includes functions: they are knots, with the following limitations and features:
A function: - cannot contain stitches - cannot use diverts or offer choices - can call other functions - can include printed content - can return a value of any type - can recurse safely
(Some of these may seem quite limiting, but for more story-oriented call-stack-style features, see the section of Tunnels.)
Return values are provided via the ~ return
statement.
To define a function, simply declare a knot to be one:
=== function say_yes_to_everything ===
~ return true
=== function lerp(a, b, k) ===
~ return ((b - a) * k) + a
Functions are called by name, and with brackets, even if they have no parameters:
~ x = lerp(2, 8, 0.3)
* {say_yes_to_everything()} 'Yes.'
As in any other language, a function, once done, returns the flow to wherever it was called from - and despite not being allowed to divert the flow, functions can still call other functions.
=== function say_no_to_nothing ===
~ return say_yes_to_everything()
A function does not need to have a return value, and can simply do something that is worth packaging up:
=== function harm(x) ===
{ stamina < x:
~ stamina = 0
- else:
~ stamina = stamina - x
}
...though remember a function cannot divert, so while the above prevents a negative Stamina value, it won't kill a player who hits zero.
Functions can be called on ~
content lines, but can also be called during a piece of content. In this context, the return value, if there is one, is printed (as well as anything else the function wants to print.) If there is no return value, nothing is printed.
Content is, by default, 'glued in', so the following:
Monsieur Fogg was looking {describe_health(health)}.
=== function describe_health(x) ===
{
- x == 100:
~ return "spritely"
- x > 75:
~ return "chipper"
- x > 45:
~ return "somewhat flagging"
- else:
~ return "despondent"
}
produces:
Monsieur Fogg was looking despondent.
For instance, you might include:
=== function max(a,b) ===
{ a < b:
~ return b
- else:
~ return a
}
=== function exp(x, e) ===
// returns x to the power e where e is an integer
{ e <= 0:
~ return 1
- else:
~ return x * exp(x, e - 1)
}
Then:
The maximum of 2^5 and 3^3 is {max(exp(2,5), exp(3,3))}.
produces:
The maximum of 2^5 and 3^3 is 32.
The following example is long, but appears in pretty much every inkle game to date:
TODO: Explain the hyphen? (And fix glue so this actually works...!)
=== function print_num(x) ===
{
- x >= 1000:
{print_num(x / 1000)} thousand { x mod 1000 > 0:{print_num(x mod 1000)}}
- x >= 100:
{print_num(x / 100)} hundred { x mod 100 > 0:and {print_num(x mod 100)}}
- x == 0:
zero
- else:
{ x >= 20:
{ x / 10:
- 2: twenty
- 3: thirty
- 4: forty
- 5: fifty
- 6: sixty
- 7: seventy
- 8: eighty
- 9: ninety
}
{ x mod 10 > 0:<>-<>}
}
{ x < 10 || x > 20:
{ x mod 10:
- 1: one
- 2: two
- 3: three
- 4: four
- 5: five
- 6: six
- 7: seven
- 8: eight
- 9: nine
}
- else:
{ x:
- 10: ten
- 11: eleven
- 12: twelve
- 13: thirteen
- 14: fourteen
- 15: fifteen
- 16: sixteen
- 17: seventeen
- 18: eighteen
- 19: nineteen
}
}
}
which enables us to write things like:
~ price = 15
I pulled out {print_num(price)} coins from my pocket and slowly counted them.
"Oh, never mind," the trader replied. "I'll take half." And she took {print_num(price / 2)}, and pushed the rest back over to me.
Function parameters can also be passed 'by reference', meaning that the function can actually alter the the variable being passed in, instead of creating a temporary variable with that value.
For instance, most inkle stories include the following:
=== function alter(ref x, k) ===
~ x = x + k
Lines such as:
~ gold = gold + 7
~ health = health - 4
then become:
~ alter(gold, 7)
~ alter(health, -4)
which are slightly easier to read, and (more usefully) can be done inline for maximum compactness.
* I ate a biscuit[] and felt refreshed. {alter(health, 2)}
* I gave a biscuit to Monsieur Fogg[] and he wolfed it down most undecorously. {alter(foggs_health, 1)}
- <> Then we continued on our way.
Wrapping up simple operations in function can also provide a simple place to put debugging information, if required.
Interactive stories often rely on state machines, tracking what stage some higher level process has reached. There are lots of ways to do this, but the most conveninent is to use constants.
Sometimes, it's convenient to define constants to be strings, so you can print them out, for gameplay or debugging purposes.
CONST HASTINGS = "Hastings"
CONST POIROT = "Poirot"
CONST JAPP = "Japp"
VAR current_chief_suspect = HASTINGS
=== review_evidence ===
{ found_japps_bloodied_glove:
~ current_chief_suspect = POIROT
}
Current Suspect: {current_chief_suspect}
Sometimes giving them values is useful:
CONST PI = 3.14
CONST VALUE_OF_TEN_POUND_NOTE = 10
And sometimes the numbers are useful in other ways:
CONST LOBBY = 1
CONST STAIRCASE = 2
CONST HALLWAY = 3
CONST HELD_BY_AGENT = -1
VAR secret_agent_location = LOBBY
VAR suitcase_location = HALLWAY
=== report_progress ===
{ secret_agent_location = suitcase_location:
The secret agent grabs the suitcase!
~ suitcase_location = HELD_BY_AGENT
- secret_agent_location < suitcase_location:
The secret agent moves forward.
~ secret_agent_location++
}
Constants are simply a way to allow you to give story states easy-to-understand names.
There are two core ways to provide game hooks in the ink engine. External function declarations in ink allow you to directly call C# functions in the game, and variable observers are callbacks that are fired in the game when ink variables are modified. Both of these are described in Running your ink.
The default structure for ink stories is a "flat" tree of choices, branching and joining back together, perhaps looping, but with the story always being "at a certain place".
But this flat structure makes certain things difficult: for example, imagine a game in which the following interaction can happen:
=== crossing_the_date_line ===
* "Monsieur!"[] I declared with sudden horror. "I have just realised. We have crossed the international date line!"
- Monsieur Fogg barely lifted an eyebrow. "I have adjusted for it."
* I mopped the sweat from my brow[]. A relief!
* I nodded, becalmed[]. Of course he had!
* I cursed, under my breath[]. Once again, I had been belittled!
...but it can happen at several different places in the story. We don't want to have to write copies of the content for each different place, but when the content is finished it needs to know where to return to. We can do this using parameters:
=== crossing_the_date_line(-> return_to) ===
...
- -> return_to
...
=== outside_honolulu ===
We arrived at the large island of Honolulu.
- (postscript)
{crossing_the_date_line(-> done)}
- (done)
-> END
...
=== outside_pitcairn_island ===
The boat sailed along the water towards the tiny island.
- (postscript)
{crossing_the_date_line(-> done)}
- (done)
-> END
Both of these locations now call and execute the same segment of storyflow, but once finished they return to where they need to go next.
But what if the section of story being called is more complex - what if it spreads across several knots? Using the above, we'd have to keep passing the 'return-to' parameter from knot to knot, to ensure we always knew where to return.
So instead, ink integrates this into the language with a new kind of divert, that functions rather like a subroutine, and is called a 'tunnel'.
The tunnel syntax looks like a divert, with another divert on the end:
-> crossing_the_date_line ->
This means "do the crossing_the_date_line story, then continue from here".
Inside the tunnel itself, the syntax is simplified from the parameterised example: all we do is end the tunnel using the ->->
statement which means, essentially, "go on".
=== crossing_the_date_line ===
// this is a tunnel!
...
- ->->
Note that tunnel knots aren't declared as such, so the compiler won't check that tunnels really do end in ->->
statements, except at run-time. So you will need to write carefully to ensure that all the flows into a tunnel really do come out again.
Tunnels can also be chained together, or finish on a normal divert:
...
// this runs the tunnel, then diverts to 'done'
-> crossing_the_date_line -> done
...
...
//this runs one tunnel, then another, then diverts to 'done'
-> crossing_the_date_line -> check_foggs_health -> done
...
Tunnels can be nested, so the following is valid:
=== plains ===
= night_time
The dark grass is soft under your feet.
+ [Sleep]
-> sleep_here -> wake_here -> day_time
= day_time
It is time to move on.
=== wake_here ===
You wake as the sun rises.
+ [Eat something]
-> eat_something ->
+ [Make a move]
- ->->
=== sleep_here ===
You lie down and try to close your eyes.
-> monster_attacks ->
Then it is time to sleep.
-> dream ->
->->
... and so on.
Tunnels are on a call-stack, so can safely recurse.
TODO: Review this section to ensure examples are sensible!
So far, everything in ink has been entirely linear, despite all the branching and diverting. But it's actually possible for a writer to 'fork' a story into different sub-sections, to cover more possible player actions.
We call this 'threading', though it's not really threading in the sense that computer scientists mean it: it's more like stitching in new content from various places.
Note that this is definitely an advanced feature: the engineering stories becomes somewhat more complex once threads are involved!
Threads allow you to compose sections of content from multiple sources in one go.
* "What did you have for lunch today?"[] I asked.
"Spam and eggs," he replied.
* "Nice weather, we're having,"[] I said.
"I've seen better," he replied.
- -> house
== walking ==
We continued to walk down the dusty road.
* [Continue walking]
-> house
== house ==
Before long, we arrived at his house.
-> END
It allows multiple sections of story to combined together into a single section:
I had a headache; threading is hard to get your head around.
It was a tense moment for Monty and me.
We continued to walk down the dusty road.
1: "What did you have for lunch today?"
2: "Nice weather, we're having,"
3: Continue walking
On encountering a thread statement such as <- conversation
, the compiler will fork the story flow. The first fork considered will run the content at conversation
, collecting up any options it finds. Once it has run out of flow here it'll then run the other fork.
All the content is collected and shown to the player. But when a choice is chosen, the engine will move to that fork of the story and collapse and discard the others.
Note that global variables are not forked, including the read counts of knots and stitches.
In a normal story, threads might never be needed.
But for games with lots of independent moving parts, threads quickly become essential. Imagine a game in which characters move independently around a map: the main story hub for a room might look like the following:
CONST HALLWAY = 1
CONST OFFICE = 2
VAR player_location = HALLWAY
VAR generals_location = HALLWAY
VAR doctors_location = OFFICE
== run_player_location
{
- player_location == HALLWAY: -> hallway
}
== hallway ==
<- characters_present
* [Drawers] -> examine_drawers
* [Wardrobe] -> examine_wardrobe
* [Go to Office] -> go_office
- -> run_player_location
= examine_drawers
// etc...
// Here's the thread, which mixes in dialogue for characters you share the room with at the moment.
== characters_present(room)
{ generals_location == player_location:
<- general_conversation
}
{ doctors_location == room:
<- doctor_conversation
}
== general_conversation
* [Ask the General about the bloodied knife]
"It's a bad business, I can tell you."
- -> run_player_location
== doctor_conversation
* [Ask the Doctor about the bloodied knife]
"There's nothing strange about blood, is there?"
- -> run_player_location
Note in particular, that we need an explicit way to return the player who has gone down a side-thread to return to the main flow. In most cases, threads will either need a parameter telling them where to return to, or they'll need to end the current story section.
Side-threads end when they run out of flow to process: and note, they collect up options to display later (unlike tunnels, which collect options, display them and follow them until they hit an explicit return, possibly several moves later).
Sometimes a thread has no content to offer - perhaps there is no conversation to have with a character after all, or perhaps we have simply not written it yet. In that case, we must mark the end of the thread explicitly.
If we didn't, the end of content might be a story-bug or a hanging story thread, and we want the compiler to tell us about those.
-> DONE
So cases where we want to mark the end of a thread, we use -> DONE
: meaning "the flow intentionally ends here".
Note that we don't need a -> DONE
if the flow ends with options that fail their conditions. The engine treats this as a valid, intentional, end of flow state.
You do not need a -> DONE
in a thread after an option has been chosen. Once an option is chosen, a thread is no longer a thread - it is simply the normal story flow once more.
Using -> END
in this case will not end the thread, but the whole story flow. (And this is the real reason for having two different ways to end flow.)


| Interface | Description |
|---|---|
| DbFace |
The interface is used as a pseudo Database interface.
|
| Class | Description |
|---|---|
| Accountant |
The class supports main routines datawise, makes decisions on whether or not
to deal with next target, depending on the recorded "database".
|
| CLIGrammar |
The class is depending on the jopt-simple library and is used to describe
the grammar of CLI options that Run.java takes.
|
| DataDiver |
DataDiver is the class that does the actual recursion.
|
| DefaultParms |
This class keeps important runtime parameters that the business logic has to
consider at any time.
|
| EnumOf |
This class contains two shadow type enum "databases".
|
| ForeignCode |
Foreign code is kept in this Class, that means the code whose authors are not
precisely known.
|
| Func |
Here are concentrated some simple functions (oops, methods) we constantly
need.
|
| LogHandler |
From here we initialize our Java logger.
|
| ParseGSB |
The data engine we use - GSB (Google Safe Browsing) - is a reputation service
to indicate whether an internet site is clean or is it contaminated by the
malware.
|
| ParseRIPE |
The ParseRIPE class is to raise an argument against RIPE public interface to
return the constituency (extent of IP networks) of a country.
|
| Run |
The runnable from CLI class, honouring CLI options and no multi-threading at
all.
|
| SyslogLikeFormatter |
The class describes a Unix Style Syslog formatter which makes java native
logging more or less usable.
|
| TypeWriter |
The class handles some simpliest kind of the file logging and hides these
pecularities from the upper layers.
|
| Enum | Description |
|---|---|
| EnumOf.cc |
An enum collecting possible country codes RIPE is serving.
|
| EnumOf.level |
A shadow enum mimicking the Level class.
|
| EnumOf.preyCodeWord |
Target sorting ontology - any of these is a kind of target we wish to
account.
|


--- layout: page status: publish published: true title: An MFC PopupEdit Control author: display_name: Tomas Restrepo login: tomasr email<EMAIL_ADDRESS>url: http://winterdom.com/ author_login: tomasr author_email<EMAIL_ADDRESS>author_url: http://winterdom.com/ wordpress_id: 1108 wordpress_url: http://winterdom.com/?page_id=1108 date: '2009-04-28 02:33:22 +0000' date_gmt: '2009-04-28 02:33:22 +0000' categories: - Uncategorized tags: [] comments: [] ---
The PopupEdit class is a simple CEdit-derived MFC class, that behaves very much like the edit control that appears when you edit an entry in a ListView control. It's designed to be very easy to use, and I think you might
find it useful in your own applications.
Using the control is very simple: Call PopupEdit::Create()
to create the control. After that, you call PopupEdit::Show()
to make it visible. When you show it, you can specify the rectangle (in client coordinates of the parent window) where you want to display it, along with an initial text. Every time the control goes away, it resets its text back to "" (an empty string).
When the control is displayed, it will automatically grab focus and select the string in it. When the user presses the Enter key to accept the new text, the control will send a PE_TEXTIN
message to the parent window, with a pointer to the text in the LPARAM
of the message. That way, it's very easy to grab the new text. After that, or if the user presses ESC or gives another control the focus, the PopupEdit control will hide itself.
One nice thing of the control is it's ability to auto-resize itself to make the string fit, just like the ListView control does. This is only done if the control has the PE_AUTOHEXPAND
style.
Grab the file here:


This useful port of call is about halfway up the east coast of Baja California.
Position 27°19.5’N, 112°15.3’W.
Port Captain's office is inside the big ferry terminal at the southwest corner of the harbour. Immigration is half a block south.
The dockmaster at the marina can arrange for clearance.
The old marina is located by the bright turquoise building in the NE corner of the municipal harbour, past the ferry terminal.
There is also a new marina here, with all facilities.


PALE RIDER (director: Clint Eastwood; screenwriters: Michael Butler/Dennis Shryack; cinematographer: Bruce Surtees; editor: Joel Cox; cast: Clint Eastwood (Preacher), Michael Moriarty (Hull Barret), Carrie Snodgrass (Sarah Wheeler), Sydney Penny (Megan Wheeler), Doug McGrath (Spider Conway), Chris Penn (Josh LaHood), Richard Dysart (Coy LaHood), Richard Kiel (Club), John Russell (Stockburn); Runtime: 120; Warner Bros.; 1985)
Reviewed by Dennis Schwartz
The cowboys of the Old West ride again in this tried and proven Western tale from Clint Eastwood. It's the saga about a lone mysterious man representing 'good' fighting the forces of 'evil,' taking up sides with those who don't have the strength or courage to stand on their own, and when he wins he rides off into the sunset by his lonesome self, stoically ignoring what he hears in the distance -- an attractive young hero-worshipping girl crying out that she loves him. This theme has been done better many times before and in a superior way in such films as "Shane (53)" and in Clint's own "High Plains Drifter (72)." This film adds little to the genre, except it is a visually stunning film as photographed by Bruce Surtees and Clint's heroics are enjoyable to watch, as he unabashedly brings back many of the Western's classic confrontational scenes, such as the showdown on Main Street and of the helpless man made to dance as the gunslingers fire away at his feet. Otherwise, this is a somewhat disappointing venture, not because it isn't well-acted or directed, but because it is so stale that it becomes uninvolving.
A big mine company is feuding with a motley group of independent prospectors, who have a legal claim to the one place in this small California town's territory that they don't own, Carbon Valley. In an attempt to get rid of them so that they could employ their hydraulic mining operation to rape the entire valley of all its natural resources, the mine owner harasses them at their camp site and their hired thugs beat them up if they go to town. In one such raid on the prospector's quarters, a 15-year-old girl, Megan Wheeler (Penny), watches as her dog is killed. Burying the dog, she reads from Revelations: "Behold a pale horse; and his name that sat upon him was Death." She further prays for a miracle and in the next shot the preacher (Eastwood) rides down from the hills.
Needing supplies, the boyfriend of Megan's mother, Hull Barret (Michael Moriarty), rides into town alone, and when he comes out of the general store he is attacked by the thugs who work for the mine owner Coy LaHood (Dyson). Silently, the preacher appears in town and then disappears as if he were a ghost. He is then seen picking up a hickory stick and smacking it over the gang's heads, avenging the beating they just administered to Hull.
The two women are attracted to him, and the preacher must ward off the impulsively inclined Megan's advances by telling her that she should wait for the right guy to come along. It soon becomes clear, after seeing the preacher's back scarred from numerous bullet wounds, that he's on a personal mission of revenge.
The twenty or so independent prospectors feel safe with the preacher around and turn down a chance to sell their claims for a thousand dollars each to LaHood, as the preacher just tells them what the offer is without offering his opinion. But LaHood counters by damming up the creek, thereby preventing them from panhandling and by bringing a vicious marshal, Stockburn (Russell) and six of his deputy gunmen into town to force them out.
In a twit about the preacher's rejection of her, Megan takes a ride along the big mining company's site and the owner's hot-blooded son Josh (Chris Penn), grabs and tries to rape her just as the preacher comes along and frees her.
For the climax, Stockburn' men come silently into town. They are a rough looking bunch of desperadoes, all wearing long dusters, giving the final shootout, a very recognizable Western touch. The gunman-turned-preacher has retrieved his gun from storage and goes after the man who almost killed him once, which results in a classic Western shoot-out.
Clint is once again a nameless drifter, a role he could play blindfolded by now. It's a fine film for those who don't mind that hero-worshipping is a good chunk of the plot, and that what was metaphorically hinted at never develops because of the film's awkward presentation.
REVIEWED ON 2/1/2001 GRADE: C+
Dennis Schwartz: "Ozus' World Movie Reviews"
http://www.sover.net/~ozus
<EMAIL_ADDRESS>© ALL RIGHTS RESERVED DENNIS SCHWARTZ
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


password-generator
A simple client-side password generator made in JavaScript.
Live Demo
Generator can be used live here.
Issues
Copy to clipboard not supported on mobile.- Browsers that do not support the copy to clipboard functionality will default to selecting the newly generated password so the user can then manually copy it.
Contributing
Contributions are welcome! Found a bug, feel like documentation is lacking/confusing and needs an update, have performance/feature suggestions or simply found a typo? Let me know! :)
See how to contribute here.
TODO
- [x] Make alternate method allowing mobile users to easily copy generated password
License
This project uses the MIT License.


Cars
Trips
Edit car
Back
Save
Please fix errors below:
Model
[errors]
Number
[errors]
Load Capacity
[errors]
Characteristics
[errors]
Driver
[errors]


Given a string of digits and a target integer, insert + and * operators between the digits until the resultant equation results in the target, printing the result. If no possible equation exists with the given string, print "No solution found".
Ex: "123456" and 464 prints 12*34+56
| Digits: | |
| Target: | |
| Answer: |


This is a demo of mtlazy image lazyloading with retina support. IE9 and up. Based on lazyr.js.
A small, fast, modern, and dependency-free library for lazy loading. This is a fork of Layzr.js bringing in ie9 support and some other features we needed for service projects at MT.
Lazy loading boosts page speed by deferring the loading of images until they're in (or near) the viewport.
We want to explore. We’re curious people.  We believe in what we’re doing. Now it’s time to go.
It suddenly struck me that that tiny pea, pretty and blue, was the Earth.  I didn't feel like a giant. I felt very, very small.
There can be no thought of finishing for ‘aiming for the stars.’ Both figuratively and literally, it is a task to occupy the generations. And no matter how much progress one makes, there is always the thrill of just beginning.
Spaceflights cannot be stopped. This is not the work of any one man or even a group of men. It is a historical process which mankind is carrying out in accordance with the natural laws of human development.
Spaceflights cannot be stopped. This is not the work of any one man or even a group of men. It is a historical process which mankind is carrying out in accordance with the natural laws of human development.
We are all connected; To each other, biologically. To the earth, chemically. To the rest of the universe atomically.
Buy why, some say, the moon? Why choose this as our goal? And they may as well ask why climb the highest mountain?
A Chinese tale tells of some men sent to harm a young girl who, upon seeing her beauty, become her protectors rather than her violators. That's how I felt seeing the Earth for the first time. I could not help but love and cherish her.
We want to explore. We’re curious people.  We believe in what we’re doing. Now it’s time to go.
It suddenly struck me that that tiny pea, pretty and blue, was the Earth.  I didn't feel like a giant. I felt very, very small.
There can be no thought of finishing for ‘aiming for the stars.’ Both figuratively and literally, it is a task to occupy the generations. And no matter how much progress one makes, there is always the thrill of just beginning.
Spaceflights cannot be stopped. This is not the work of any one man or even a group of men. It is a historical process which mankind is carrying out in accordance with the natural laws of human development.
Spaceflights cannot be stopped. This is not the work of any one man or even a group of men. It is a historical process which mankind is carrying out in accordance with the natural laws of human development.
We are all connected; To each other, biologically. To the earth, chemically. To the rest of the universe atomically.
Buy why, some say, the moon? Why choose this as our goal? And they may as well ask why climb the highest mountain?
A Chinese tale tells of some men sent to harm a young girl who, upon seeing her beauty, become her protectors rather than her violators. That's how I felt seeing the Earth for the first time. I could not help but love and cherish her.


--- title: Login modal category: modal order: 20 description: A modal can be a useful place to put a login form. --- Login modal


Accesses OpenWeatherMap's (owm) <https://openweathermap.org/> API. 'owm' itself is a service providing weather data in the past, in the future and now. Furthermore, 'owm' serves weather map layers usable in frameworks like 'leaflet'. In order to access the API, you need to sign up for an API key. There are free and paid plans. Beside functions for fetching weather data from 'owm', 'owmr' supplies tools to tidy up fetched data (for fast and simple access) and to show it on leaflet maps.
| Version: | 0.8.1 |
| Depends: | R (≥ 3.1.2) |
| Imports: | magrittr, httr, jsonlite, plyr, tibble, tidyr |
| Suggests: | leaflet, whisker, testthat, covr |
| Published: | 2018-11-03 |
| Author: | Stefan Kuethe [aut, cre], Amanda Dobbyn [ctb] |
| Maintainer: | Stefan Kuethe <crazycapivara at gmail.com> |
| BugReports: | https://github.com/crazycapivara/owmr/issues/ |
| License: | MIT + file LICENSE |
| URL: | https://github.com/crazycapivara/owmr/, https://crazycapivara.github.io/owmr/ |
| NeedsCompilation: | no |
| Materials: | README NEWS |
| In views: | WebTechnologies |
| CRAN checks: | owmr results |
| Reference manual: | owmr.pdf |
| Package source: | owmr_0.8.1.tar.gz |
| Windows binaries: | r-devel: owmr_0.8.1.zip, r-release: owmr_0.8.1.zip, r-oldrel: owmr_0.8.1.zip |
| OS X binaries: | r-release: owmr_0.8.1.tgz, r-oldrel: owmr_0.8.1.tgz |
| Old sources: | owmr archive |
Please use the canonical form https://CRAN.R-project.org/package=owmr to link to this page.


{{title}}
- Client Revoke client
- Local authority reference
- Check permission Yes
- Challenge permission No
| Effective date | Rateable value | Capacity | From | To | Actions |
|---|---|---|---|---|---|
| 1 Apr 2010 | £28500 | Owner | 1 Apr 2017 | Present |
| Effective date | Rateable value | Capacity | From | To | Actions |
|---|---|---|---|---|---|
| 1 Apr 2010 | £28500 | Owner | 1 Apr 2017 | Present |


Frequently Asked Questions
Yes!! The camp is free to all rising 8th and 9th grade girl(s). Housing and all meals are included.
All students must apply for the camp online through this website. A completed application consists of the following: Completed online registration form, College of Charleston Liability Release and Waiver, and Bosch Waiver and Release of Liability. All applications must be completed and submitted by (***application due date***). Girls are accepted on a first come first serve basis. Students will be notified of their acceptance by (***acceptance date***).
Information about pick-up and drop-off locations will be sent
directly to the parent(s) when approved for Girl’s Day Out 2020.
For Security Purposes, Parent(s) are
REQUIRED to sign his/her daughter(s) in/out
of the camp. If your daughter is riding home with a friend or family
member, please notify Camp Coordinators by July 20, 2020.
Yes, there will be a state security officer sitting at the front desk of the residence hall.
Room Keys: All girls will receive a room key & key fob which are required to enter and exit the building. There is a $100 fee to replace a lost key or key fob. Girls will be given pouches that can be placed around their necks to store the keys.
Thursday Dress Code: The girls will be visiting the Bosch facility on
****date here****. All girls are
REQUIRED to wear
pants below the knees, shirts with a sleeve, and closed-toe
shoes
for the tour. The Dress code is in accordance to Bosch Safety
Policy. If your daughter is not dressed appropriately, she will not
be able to participate in the tour.
Friday Dress Code: Girls may wear shorts, jeans, or pants as bottoms. We recommend
that girls wear tennis shoes, sandals, or other comfortable walking
shoes.
Saturday Dress Code: Girls will receive a GDO Summer Camp t-shirt at registration on
****date here****. All girls are
REQUIRED to wear the t-shirt on
****date here****
as the official camp uniform. Girls may wear shorts, jeans, or pants
as bottoms. We recommend that girls wear tennis shoes, sandals, or
other comfortable walking shoes.
During the sessions, the campers will not be able to use their phones. Girls will only be permitted to use phones during breaks and free time.
The camp will provide food (breakfast, lunch, dinner and snacks) for the girls. If your daughter has any special dietary needs, please inform GDO Camp Coordinators via email by ***insert date here***, if it was not included in the application.
If your daughter takes medication, please inform GDO camp coordinators via email by ***insert date here***, if it was not included in the application. Upon check-in, please ensure that your daughter leaves her medication with the registration desk. The GDO staff will not administer the medication to your daughter. However, a registered nurse will be on staff and will be able to monitor your daughter take her the medicine.
Girls will be randomly assigned to their room based on age and grade. Girls are randomly assigned to rooms to prevent bullying and cliques. This allows the girls to meet new people, and to provide them with a true college experience. Often, when girls attend college, they are not able to choose a roommate.
Parents are required to sign his/her daughter(s) in/out of the camp
daily. Parents will also be responsible for watching a 2-3 minute
video at check-in on ***insert date here*** and
signing a consent form. The video contains important information
each parent will need to know about the camp.
Parents are not required to attend the entire camp. However, a
parent session is held on ***insert date here*** in
the College of Charleston School of Science and Mathematics Building
(202 Calhoun Street). Parents are asked to join their daughters for
a short program and a complimentary lunch. The program will consist
of a parent-only session and an awards ceremony. See details of
parent session below:
GDO Parent Session
• College Information Session: The session will
consist of local colleges briefly providing an overview of their
college and programs of register. Following introductions, a
moderated question and answer session will begin. Each College
representative will be prepared to address the following type of
questions: cost of tuition, courses they should focus on in high
school, scholarship information, etc.
• Cyber Security Session: The session will consist
of an overview of popular apps, impact of a child’s cyber profile on
her future, trafficking, sexting and laws associated with sexting.
 SEE CHECKLIST FOR A LIST OF ITEMS TO BRING
Please visit the Contact Us page if you have any questions or concerns. A number will be provided prior to the camp in case of emergencies.
You will be able to sign and submit these forms after submitting the application. If you have already done so, and did not submit these forms, please check the application verification e-mail you received for a link. If you submitted an application and did not get an e-mail, please Contact Us.
A link was sent in the application verification e-mail you received after submitting your daughter's application. If you submitted an application and did not receive any e-mails from us, please Contact Us.


We're currently uploading several more templates. They will be available soon.
Enjoy our Premium Items! Your ThemeStreet.Net Staff.
404 - Sorry, the requested page does not exist
Reasons why you should choose
our templates
- We are creating high quality and conversion landing pages which will sell your product / service easily.
- Customize each template easily. Templates come in several colors and layouts.
- You get full functional HTML5/CSS3 code, SCSS code and layered PSD files.
- Customer Support in several ways - via Facebook, Twitter, Email or our unique ticket system.
- Regular updates for ALL items (HTML/CSS templates, Wordpress themes, etc).
- The best affiliate deal. Register and become our affiliate.
- Minimum 2 premium items per month. Graphics such as logos, icons and other elements will also be available soon.
- We are listening your wishes. Send us your wishlist and we'll create a unique template for you (and other members)!
Make a wish
& we will fulfil it for you!
Simply enter a description of a template you need, and we'll give our best to make a modern and catchy design to meet your needs. We will choose the best of all wishes and make a unique design and code, and upload it on our website.
Make a wish


Queries
Basic GET queries
Once you’ve got the setup sorted you’re only ever going to need to write queries for your data. Let’s get started with a simple query to load our user:
// components/user.js
import React, { PureComponent } from 'react';
import PropTypes from 'prop-types';
// tectonic
import load, { Status } from 'tectonic';
import UserModel from '../models/user.js';
// We use the @load decorator to dispatch a query for a single user item.
//
// The query instance itself is returned from `UserModel.getItem` on the model
// itself. `getItem` returns a query for a single model item, whereas `getList`
// returns a query specifying that we need a list of items.
//
// The object passed into `getItem` and `getList` are query parameters used in
// the API call. For this reason you need to know the sources that you want to
// hit, along with their required parameters. If a source definition has
// required parameters that aren't specified here when creating the query the
// source will never be called (as it doesn't pass validation tests).
//
// Finally, remember how we specified the queryType of sources? The `getItem`
// and `getList` functions specify a queryType of 'GET', so only API endpoints
// that return data will be considered.
@load((props) => ({
user: UserModel.getItem({ id: props.userId }),
posts: PostModel.getList({ userId: props.userId }),
}))
class UserWrapper extends PureComponent {
static propTypes = {
// automatically injected status models, containing the http response
// code, any error messages, and the overall status of the query
status: PropTypes.shape({
user: PropTypes.instanceOf(Status),
posts: PropTypes.instanceOf(Status),
}),
// the data loaded via tectonic
user: PropTypes.instanceOf(UserModel),
posts: PropTypes.arrayOf(PropTypes.instanceOf(UserModel)),
}
render() {
// ...
}
}
Pretty simple, eh? The core part of loading data is ${model}.getItem
or
${model.getList}
. Here’s an overview of what happens in the background:
- The query created by your model (eg.
getItem
) is added to the resolver’s queue. - Queries are automatically deduplicated (eg. 100 components can request the same user using the same params, and only one request will be made)
- After all components have mounted the resolver begins its resolution of each
query:
- We check each query to see if we have cached data already available to skip unnecessary API requests. If so, this data is passed to the component
- Attempt to find a valid source definition for the API query, given the query type, params and model requested. If no source definition can be found a warning is thrown
- When a source definition is found we invoke the source’s driver with the source and query information
- The driver performs its logic and calls an onSuccess or onError function; this updates the status of the query in Tectonic and is reflected in your component
- On success caching information is passed from the driver’s response, data is saved to the tectonic reducer and finally data is passed in to your component.
There’s more that goes into each of this, though that’s the general overview and is most of what you need to know. The full explanation of both the decorator and resolution process is explained in the INTERNALS section of the documentation.
Before you continue, it’s important to note:
The resolver ignores any queries which have undefined parameters! If you
have params in getItem
or getList
which are undefined the query will be
skipped.
This is to enable dependent data loading, which we explain next.


Scots boy who died from dehydration and norovirus may have waited five hours to see doctor
A court heard how four-year-old Leylan Forte died in Montrose after becoming seriously ill.
by Tim BuglerA young boy who died from dehydration, gastroenteritis and norovirus may have faced a delay of five hours before he was seen by a doctor, a court was told yesterday.
A fatal accident inquiry into Leylan Forte’s death in Montrose on April 27, 2015, will be held next year.
The four-year-old suffered from suspected autism, cerebral palsy, an eating disorder and wasn’t able to communicate.
A preliminary hearing at Forfar Sheriff Court heard the probe would look into whether out-of-hours helpline NHS 24 and Leylan’s GP practice, Annat Bank Surgery in Montrose, “responded adequately” to calls.
The court heard NHS 24 was contacted at 6am and the surgery at 8.20am.
Carol Whyte, procurator fiscal depute to the inquiry, said the Crown’s information suggested that a GP then went to assess Leylan at 11am.
She added a pathologist would comment on whether the delay is likely to have contributed to Leylan’s death.
Helen Watts, counsel for NHS 24, said: “It would be my suspicion that a pathologist would not be the best person to comment.”
The preliminary hearing was continued until December 13.
The fatal accident inquiry has been ordered because of “serious public concern about his death”.
Last year Leylan’s devastated parents threatened to sue NHS 24 over his death, after receiving a report from a professor of medicine in which, according to them, the expert expressed a belief that the official health helpline had given them wrong advice.
Leylan’s mother, Leanne Smith, who has herself since died, told a reporter at the time: “With better advice Leylan might still be alive.”


Color in material design is inspired by bold hues juxtaposed with muted environments, deep shadows, and bright highlights.
Teradata product usage recommends selecting primary and accent colors from these Material Design colors:
Each Material Design color has several available hues. It's recommended to use 3 hues for your primary and 1 for your accent, like:
When using a primary color in your palette, this color should be the most widely used across all screens and components.
Palettes with a secondary color may use this color to indicate a related action or information.
When using a primary color in your palette, this color should be the most widely used across all screens and components.
Palettes with a secondary color may use this color to indicate a related action or information.
When using a primary color in your palette, this color should be the most widely used across all screens and components.
Palettes with a secondary color may use this color to indicate a related action or information.
To manually color a background, use our simple bgc utility class:
choose from any of the material colors, in hues from 50, 100, 200, 300, 400, 500, 600, 700, 800, 900 (and A100, A200, A400, A700 for all except brown, grey & blue-grey)
To manually color a background, use our simple bgc utility class:
choose from any of the dark material colors, in hues from 500, B100, B65, B40, B30 & B15


London, Shanghai and Hong Kong 2014
Left Sydney in the last week of November 2014 for London.
Australia’s contribution to fashion is the Ugg boot. Strangely, among all the boutiques in Knightsbridge, this was the only shop where people were queuing.
My hotel room was upgraded to a Superior Room. The photograph below shows both walls. The cupboard on the right hand side is so small that my jacket doesn’t fit entirely within (actually the coat hanger doesn’t fit either).
A hat shop in Convent Garden. Need to get a deerstalker some day.
Sweet shop.
Also in Covent Garden.
Foyle’s is my favourite London bookshop. The new renovation is superb.
I met this guy inside Foyles. Unfortunately, you can’t tell the size from this photo but it was huge.
Cafe Nero in South Kensington.
Gangster having breakfast.
Inside the Victoria and Albert Museum.
Went to mass at the Brompton Oratory (where everything but the sermon was in Latin).
Gave a talk at Bristol University. I had thought Bristol would be a hick town with one general store and petrol station but it is a beautiful city.
This is the Bristol Museum. They made these planes there in the early days of aviation.
Then it was to Hong Kong, their airport has a similar plane on display.
This is the approach to Pudong Airport, Shanghai.
Shanghai at night.
The banquet at the International Conference on Field Programmable Technology was a cruise.
Near Fudan University (Pudong Zhangjiang campus).
We went to the Shanghai antiques market on Dongtai road.
This Oba-mao t-shirt was popular.
Lunch at a noodle bar.
Stayed near the Shanghai Railway Station.
We made a day trip to Hangzhou.
Biggest carp I’ve ever seen.
West Lake, Hangzhou.
Visitors posing for a photo.
The Chinese University of Hong Kong (“Umbrella movement”).
A colleague brought the geekiest bottle of wine you’ve ever seen to dinner.
A packed train.
Newly renovated Page One bookstore in Tsim Sha Tsui.
Government housing museum.
Consumerism gone wild. I thought all these people with rolling luggage were on their way to the airport but actually it is to carry their shopping.
Of course, we had many wonderful meals.
Mock shark’s fin.
Pigeon.
Chinese lamb casserole.
Peking duck.
Chiu Chow oyster pancake.
Chiu Chow pepper and pig intestine soup.
Vegetarian duck.
Beef soup.
Shredded duck with pocket bread.
Sweet and sour pork.
Mango pudding.
The two pandas and green “bamboo” in the foreground were a fancy desert.
Shrimp dumplings.
Storm near Sydney.
Sydney skyline.


{# subject: New submission from {{ form.name }} #} {# fromEmail: {{ craft.systemSettings.email.emailAddress }} #} {# fromName: {{ craft.systemSettings.email.senderName }} #} {# replyToEmail: {{ craft.systemSettings.email.emailAddress }} #} {# includeAttachments: true #} {# description: New submission sample email template #}
Submitted on: {{ dateCreated|date('Y-m-d H:i:s') }}


Ephesians 4:19
Who being past feeling have given themselves over unto lasciviousness, to work all uncleanness with greediness.


A class of event handling objects.
More...
|
| | EventObject (float x, float y, Texture2D texture) |
| | A constructor. More...
|
| |
|
| EventObject (float x, float y, string assetName) |
| |
| bool | isPressed (Vector2 pressedLocation) |
| | Returns true if parameter coordinates are inside the EventObject. More...
|
| |
|
virtual void | update () |
| |
| | Object (float x, float y, Texture2D texture, Layer layer) |
| | A constructor. More...
|
| |
| | Object (Texture2D texture, Layer layer) |
| | A constructor. More...
|
| |
| | Object (float x, float y, string textureName, Layer layer) |
| | A constructor. More...
|
| |
| void | loadAssets (ContentManager content) |
| | Loads any unloaded assets. More...
|
| |
| Vector2 | getCenter () |
| | Returns the location of the center of the object on the screen. More...
|
| |
| void | setLocation (float x, float y) |
| | Used to set the location of the object. More...
|
| |
| void | draw (SpriteBatch sb) |
| | Draws the object. More...
|
| |
|
| static Object | createSilentObject (float x, float y, Texture2D texture, Layer layer) |
| | Returns a silent object. More...
|
| |
| static Object | createSilentObject (float x, float y, string textureName, Layer layer) |
| | Returns a silent object. More...
|
| |
|
Vector2 | location |
| |
|
bool | active |
| |
|
bool | loaded |
| |
|
string | assetName |
| |
| Texture2D | texture |
| | The texture of the object. More...
|
| |
|
Layer | layer |
| |
|
bool | Active [get, set] |
| | A boolean variable that indicates whether or not the object should be updated and drawn.
|
| |
|
Layer | DrawLayer [get, set] |
| |
|
Vector2 | Location [get, set] |
| | Vector2 variable that stores the location of the object.
|
| |
|
Vector2 | TextureSize [get] |
| |
A class of event handling objects.
Part of the object partition.
Inherits Object.
| wp_engine.EventObject.EventObject |
( |
float |
x, |
|
|
float |
y, |
|
|
Texture2D |
texture |
|
) |
| |
|
inline |
A constructor.
- Parameters
-
| x | object location (x-coordinate) |
| y | object location (y-coordinate) |
| texture | the texture of the object |
| bool wp_engine.EventObject.isPressed |
( |
Vector2 |
pressedLocation | ) |
|
|
inline |
Returns true if parameter coordinates are inside the EventObject.
- Parameters
-
| pressedLocation | the location which the user pressed (Vector2) |
- Returns
- boolean, true if parameter coordinates are inside the EventObject
The documentation for this class was generated from the following file:


#assign elastic_start = "true">
There is an example application at ebean-orm-examples/example-elastic which you can investigate / clone etc.
Add ebean-elastic
as a dependency to your project.
This will automatically register with Ebean as the document store implementation.
io.ebean ebean-elastic 12.2.1
On each of the entity beans that we want to have indexed in ElasticSearch add the
@DocStore
annotation.
Additionally we can add mapping for:
@DocCode
on properties that should not be analysed@DocSortable
on properties that we want both analysed and not analysed@DocEmbedded
to include embedded documents (denormalise) for @ManyToOne and @OneToMany propertiesRefer to mapping for more details.
At this point Ebean is able to generate mapping JSON for each bean type annotated with @DocStore
.
ebean.docstore.url
is required and specifies the url of the ElasticSearch server to use. Currently
the alternative of using the native transport is not supported.
ebean.docstore.active
is required to be set to true to indicate the document store integration is active.
If ebean.docstore.generateMapping
is set to true Ebean will generate mapping files for each index
and these will by default be generated into src/main/resources under elastic-mapping.
When ebean.docstore.dropCreate
is set to true when Ebean starts it will drop and re-create all
the indexes. Alternatively we can use ebean.docstore.create
to create only indexes that have not
already been defined.
Refer to Mapping generation for more details.
Review the issues logged against the ebean-elastic to see what currently is not supported, future enhancements etc.


High voter turnout in Hong Kong district polls
Hong Kong: Voters on Sunday turned out in large numbers to the polling booths for the district council election, which is seen as a test of support for Hong Kong’s embattled Chief Executive Carrie Lam. Long queues of voters were witnessed at polling stations before the voting officially began at 7.30 a.m..
By 4.30 p.m. local time, more than 2.1 million people had voted (52.14 per cent) as compared to 7,54,705 voters (24.18 per cent) within the same timescale during the previous election in 2015, BBC reported, citing data from the Hong Kong electoral authorities.
The 4.13 million people (in a city of about 7.5 million residents) eligible to vote will choose 452 councillors out of the 1,090 contesting candidates from the 18 districts of Hong Kong. The number of registered voters has increased by one million compared to the 2015 elections; 392,600 of them were added in the last year, coinciding with the protests, and 58 per cent of them are aged between 18-20, Efe news reported.
Although the position of Councillor carries little practical power, Sunday’s elections are seen as a barometer to gauge the political leanings of the city in the wake of the pro-democracy movement that has led to prolonged protests on the streets in recent months, as well as determine the support enjoyed by the pro-mainland Chief Executive Carrie Lam. (IANS)
Also Read: Pope Francis in Japan, sends messages to China, Taiwan, Hong Kong
Also Watch: Watch | Lahorighat BJP Mandal President’s effigy burnt by party members


Any information you can provide will help our technical team get to the bottom of this issue.
Thanks for the feedback!
Name
Your email address
Comment (required)
There was an error. Please try again later.
Powered by


Emu6510
Emu6510 is an experimental emulator for the 6510 family of microprocessors found in computers such as the Commodore® 64.
Goals
The project will be developed in four phases:
1) Documented opcode emulation - no undocumented opcodes. - Done.
2) Frequency emulation - throttling down to 1-2 Mhz. - Done.
3) Exact cycle support. In other words if an instruction took 7 clock
cycles on a 6510 then it will take 7 clock cycles in the emulator as well. - Done.
4) Undocumented opcodes. - Done.
Currently, the only thing supported is the emulation of the processor itself. The further emulation of an entire machine, such as, say, a Commodore® 64, is still remaining to be done. This may take a while.
The first goal of this project is to emulate a Commodore® 1541/1571/1581 disk drive on an ODROID® H2.
Learning Resources
The following websites were used as excellent resources for learning to write an emulator.
- emulator101.com - 6502 emulator
- the 6502 microprocessor resource
- 6502/6510/8500/8502 Opcodes
- Extra Instructions Of The 65XX Series CPU
References for the 6510 microprocessor
- C64 Programmers Reference Guide starting on page 24 (232)
- MOS 6510 Data Sheet
API Documentation
Documentation of the API can be found here: Emu6510 API


Overview
Top level directory for Threading Building Blocks (TBB).
Directories
- examples folder
- Documentation for the library.
- include
- Include files required for compiling code that uses the library.
- examples
- Examples of how to use the library.
- ia32, intel64, ia64
- Platform-specific binary files for the library.
Copyright © 2005-2009 Intel Corporation. All Rights Reserved.
Intel, Pentium, Intel Xeon, Itanium, Intel XScale and VTune are
registered trademarks or trademarks of Intel Corporation or its
subsidiaries in the United States and other countries.
* Other names and brands may be claimed as the property of others.


Dashboard
My Products
Transactions
Store Settings
My Account
Sign Out
« Menu
Hi, Lingga
Dashboard
Setting
Logout
3
Hi, Angga
Cart
My Account
Update your current profile
Your Name
Your Email
Address 1
Address 2
Province
West Java
City
Bandung
Postal Code
Country
Mobile
Save Now


Open Weather ARSW
Weather of the City
Get Weather
General Information
City
Base
Visibility
Dt
Timezone
Weather information
Id
Main
Description
Icon
Coordinates Information
Lon
Lat
Main Information
Temp
Feels_Like
Temp_min
Temp_max
Pressure
Humidity
Wind Information
Speed
Deg
all
SYS Information
Type
Id
Country
Sunrise
Sunset


FOMC minutes to send firm signal to set the bar high for additional accommodation – TD Securities
by Dhwani MehtaThe TD Securities Analysts offer a sneak peek at what to expect from Wednesday’s US Federal Reserve (Fed) October meeting’s minutes due for release at 1900 GMT.
Key Quotes:
“We expect the FOMC minutes from the October meeting to elaborate on the Committee's decision to ease rates while also sending a firm signal to set the bar high for additional accommodation.
We anticipate discussions to touch upon what "material reassessment" of the outlook would lead the FOMC to shift its policy stance. The minutes may also provide further insights into the Framework Review debate.”


3D Art Gallery
menu
🔍
Browse
🔍
Browse
Featured
Artist Name
Favorites
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
Clear Favorites