Okay, I've only started playing with this. I've been going through the posts, C&Ping every good example I see to understand it.

One area I'm interested in is using links that don't require player input. In other words, you could create a text flow without interaction. One useful thing this would allow is for you to describe different aspects or elements every time a game is played (i.e. a woman could be "sexy", "voluptuous", "sinfully svelte", whatever). My goal is to make a game that you can play over and over, solving a logic puzzle that randomizes.

Anywho, while trying to understand the flow and workings of Squiffy, I came on a strange thing. The code below is the example - just working on getting text, value setting, Booleans and such to work together.

In a nutshell, if you pick up the gun and work through an active you-gotta-click-it link, "attack" sets. If you don't pick up the gun and go through the indirect link, "attack" doesn't set. Can someone explain why this works as it does? It has something to do with the if-else statement - that's the real difference.
====
[[my game]]:

You see a gun sitting in the alley. Do you [[pick it up]] or [[leave it there]]...

[[pick it up]]:

You pick up the gun. Good deal!
@set guninhand

[[Now walk out into the street]](street)

[[leave it there]]:

You kick it under a dumpster. Nothing good comes from guns.
@set not guninhand

[[Now walk out into the street]](street)

[[street]]:

You are now on the spaceport street.

{if guninhand: [[hot]]}{else:{cold}}

[[hot]]:

@set attack = 6

{battle}

[[cold]]:

@set attack = 3

{battle}

[[battle]]:

You go onto battle with a {attack} attack value.

Welcome.

That's a really interesting bit of code. Seems to show that Squiffy if/else is capable of doing more than I thought.

-------------------------------------------
{if guninhand: [[hot]]}
------------------------------------------

This seems to directly route the script to the [[hot]] section if guninhand is true. (Which I didn't know it could do.) Once there, it executes the command to set the 'attack' attribute, because your script is actually 'at' that section.

---------------
{else:{cold}}
---------------
What I think is happening is . . .
The 'else' part is not directly routing the script to the [[cold]] section. It's trying to load/display/"embed" the (string) *contents* of that section, (which is what I would expect from reading the docs.) So, it ignores "@set attack = 3". But it displays the {battle} content correctly, because it's a string. If you add . . .
-------------------------
@set defence = 5
{defence}
-------------------------
. . . to the [[battle]] section, you'll see the same thing happening. "@set" is ignored; so {defence} is displayed -- but has a 'null' value. (@set defence = strong) is null, too.

So . . . if you change the else part to {else:[[cold]]}, the code sample works as intended.

Your response is interesting. How Squif works is not as straight forward as I imagined (and right now, I'm just trying to figure out how versatile it can be). On the earlier example, it's very curious when you rewrite the street section as follows (see, I was playing more with if/elses and if you could overload them)...
===
[[street]]:

You are now on the spaceport street.

{if guninhand:
@set attack = 6
Youve got gun.
}
{else:
@set attack = 3
You don't have gun
}

{battle}
===

What is weird here is that the code WILL go down the correct path, mentioning the correct string. However, regardless of which path you take, you will get the correct text but 'attack' will alwaysbe set to 3! That's just strange - I could have accepted that it doesn't interpreted the set command correctly, but it seems to pick the wrong one when you multiline the command.

I think I'm still looking at this with a more traditional coding POV. I'll have to start thinking Squiffy if I'm going to get anywhere.

Post-thought - maybe Squiffy is interpreting handling the string printing within the coding modules, but handles setting variables at the end of the section, regardless of their placement in logic structures.

Yes.
If you remove the "@set attack = 3" statement, for example, you'll see that attack does get set to 6 first. Then, (if attack = 3 statement is included), the value is being reset. Both commands are being carried out, regardless of whether guninhand is true or false.

I'm pretty sure Squiffy runs through all the "code" stuff (setting variables and so on) in a section or passage all at once, and only once per turn. (And by turn I mean the time from one click to the next).

If you're interested in seeing exactly how it works, the compiler source is here

Ahh! Now it all makes sense

Seriously, it does. I found that {} jump and assumed that it was actually a clickless move to the next section. But no, having read what you said, I'll have to turn my brain around and look at this differently. I guess the {} jump really isn't a good idea. It isn't going there - it's inserting the section HERE.

Still, I'll have to see if there is some use for this trick.

Bluevoss wrote:Ahh! Now it all makes sense

Seriously, it does. I found that {} jump and assumed that it was actually a clickless move to the next section. But no, having read what you said, I'll have to turn my brain around and look at this differently. I guess the {} jump really isn't a good idea. It isn't going there - it's inserting the section HERE.

Still, I'll have to see if there is some use for this trick.

Ya - I think this is more on-track. But . . . I'd rather say it inserts, not the section itself, but (whatever in the section IS NOT code) HERE. If the section is all JS, or @ commands, nothing happens at all.

I don't know if this adds anything to the conversation, but for what it's worth:

@start Begin

[[Begin]]:
This is the beginning. Now, let's 'embed' the content of another section: {Middle}  Did I just "jump" to another section?  No -- I just embeded the text content from the Middle section. The Middle section embeds the text content from the End section, so embedding 'Middle' embeds 'End' here as well.

That "null" you see above, is because Squiffy is trying to display an attribute ("JTxt") value without the attribute having been set. Jumping (by clicking) to the Middle section will set the value, and display a whole sentence instead of "null".

<b>If the embed-text thingy had actually "jumped" to another section, the hyperlink for Middle ("  jump  " below) would be disabled.</b>

Now -- let's [["  jump  "]](Middle) to the Middle section.

[[Middle]]:
    var jumpText = 
    "<p style='color: blue';><i><b>You jumped here ('Middle'), by clicking, so the JS code to set the value of the 'JTxt' attribute is recognized and activated, and you see this blue sentence. You see the same thing from the End section, because the End is embedded, not 'jumped to' with a click, or JS 'story.go' command.</b></i></P>"
    set("JTxt", jumpText);
<p style = "color:blue";>
{JTxt}
</p>

<p style="color: chocolate"><b><big>
This is from the 'middle' section.</big></b>
</p>

{End}

[[End]]:
    set("Jtxt", "JTxt is reset");

@set JTxt = "JTxt is reset"

<p style = "color: red";>
This is in the End section.
<br>
This End section includes both JS and Squiffy code to set the JTxt attribute to "JTxt is reset".
</p>

{JTxt}

Many thanks. I see what my misconception was. That's what I get for (a) tinkering and (b) assuming.

This reminds me of my first car. Nobody was hurt too badly...

Bluevoss wrote:Many thanks. I see what my misconception was. That's what I get for (a) tinkering and (b) assuming.

This reminds me of my first car. Nobody was hurt too badly...

Squiffy is pretty new, so I think all public 'tinkering' stands a good chance of helping us all get to know it better.