Exploration choice loops

#8

If you have fake_choice instead of choice you could have all the lines that start with *else *if and *goto after the fake_choice. Also why would you have two line_breaks? It makes it look like you are trying to boost your word count.

@Nahim looks like you would have to follow @Fiogan’s way then.

#9

I try to use *choice whenever possible (I believe that’s recommended by CoG in one of the blog posts, as well?) because it’s less likely to cause continuity errors, since you always MUST send every option to somewhere specific.

Also *choice doesn’t have potential problems if you need to nest within a loop, but *fake_choice sometimes does.

@Kelvin: Er, I’m not exactly sure what your meaning is with the ‘trying to boost your word count’ portion.

I always use *line_break when I want to make sure I have a paragraph break but there’s something besides text (meaning, code lines) around the required paragraph break. That way it’s easier for me to tell, at a glance, where my paragraph breaks are.

I had noticed, especially in complex scenes, that sometimes I would think a blank line meant I’d have a paragraph break, but because of the way I did the coding (whether it was when I using *if, or *goto, or *fake_choice, or whatever else) the paragraph didn’t always end up where I wanted it to be.

So I use blank lines for paragraph breaks in the middle of my text blocks, but I always use *line_break when code is directly on either side. Does that answer what you were asking?

And one *line_break doesn’t add an empty line, it just moves the text one line down, so it’s no good for paragraph breaks.

#10

@Fiogan it seems like we are getting off topic, which is probably my fault. I always seem to get off topic. If you want to keep talking about this though I would be happy to pm you.

1 Like
#11

All right! I thought, since it was a coding-related issue, explaining my reasoning for using *choice and *line_break might be helpful. Apologies if it was off-topic or otherwise irrelevant.

1 Like
#12

We prefer that you not use two *line_breaks in a row.

Instead, you should use *comment endif to assert the existence of blank lines.

Look at published Choice of Games’ code to see its use.

4 Likes
Ilyaaren: The Explosion
#13

Thanks! That’s very helpful to know.

#14

As another writer whose WiP is littered with double *line_breaks… why the preference?

4 Likes
#15

Doesn’t just hitting return twice in the midst of text give you a blank line without actually coding a line_break? The way I grokked it, hard line breaks are when you don’t want an double-line paragraph break as in single-spaced stanzas in a poem.

#16

Yes. I had been using the double *line_break for places where several threads of code converged, not in the midst of text blocks, mostly so I could tell for sure what ‘level’ the paragraph break would be.

#17

Not reliably at the end of a conditional text block.

The paragraph came to an end.
*if not(over_yet)
  After a few more words.

And a new paragraph began.

will render as a single para if over_yet is true.

In cases where you want the paragraph to end regardless of a conditional block – which in my game happens dozens of times – you need some way of hard-coding the para break.

1 Like
#18

Does it do that if you align the tab of the second line under the first?

#19

You mean, as in the example I just posted? (Where the 2nd line starts “*if not…”, and is aligned with the 1st, starting “The paragraph…”?) Yes, it renders as a single paragraph.

#20

That’s actually a great example. The traditional way of fixing this is just with a different hack, but one that preserves the blank line.

The paragraph came to an end.
*if not(over_yet)
  After a few more words.
*comment endif

And a new paragraph began.

The *comment asserts the level of indentation of the following blank line.

That said, six or more months ago, Dan took a crack at this, and in theory, if you download the latest version of ChoiceScript from GitHub, my hack isn’t necessary anymore. But I still prefer my hack, because it tells a code-reader what the author’s intention is. (Also, I have the suspicion that Dan’s “fix” might introduce a different set of problems, but I haven’t demonstrated that yet.)

3 Likes
#21

Got it. So all of my

The paragraph came to an end.
*if not(over_yet)
  After a few more words.
*line_break
*line_break
And a new paragraph began.

should change before I submit the Choice of Rebels draft? :slight_smile:

I had noticed (and welcomed) Dan’s update on the topic, and I’d thought I had a reasonably recent version of CS on my new laptop… but maybe not, as I’m still getting the old problem. I’ll redownload at some point and check.

#22

My post on the topic discusses detailed examples of what works and what doesn’t.

4 Likes
#23

Hi there! I’m very much new to this but I had a similar problem as @synapse and i saw your post @Fiogan. I made some adjustments like so:

*label options
*choice
 #1
  *hide_reuse
  you try this option but it fails
  *goto options
 #2
  *hide_reuse
  you try this option but it fails
  *goto options

I couldn’t get the *hide_reuse to work without an error popping up if it was before a # so i tried this.
It seems to be working for most part but the first time it loops back, all the options are there and if i tried that option again it would disappear the second time.
Was hoping someone could give me some insight to this.

Thanks in advance!

#24

The *hide_reuse needs to go before the option in order to work.

Try this?

*label options
*choice
    *hide_reuse #1
        you try this option but it fails
        *goto options
    *hide_reuse #2
        you try this option but it fails
        *goto options

What else are you planning to have in the choice? You’ll have to add either a counter and a loop, or a final option similar to this:

#3
    You try this option, and it succeeds!
    *goto movingforwards

Also you can display code with the proper formatting by using <pre> and </pre> on either side of the code.

1 Like
#25

Chiming in on the double *line_break aspect mentioned earlier, and that I use double *line_break any time I want a break from paragraph to paragraph…

The reason that I use them is for instances where simply adding a space between text doesn’t necessarily work. EG- if you’ve pathed one way, you get three sentences in paragraph X. If you’ve pathed another way, you end up with four sentences in paragraph X. Rather than two instances of the paragraph- I’d indicate a paragraph break in different places according to (whatever variables). And instances where sometimes you’ll encounter a page break in a place, and sometimes another paragraph before the page break. Whereas a double return doesn’t seem to be recognized unless there’s something after it; admittedly, there are many places where I could use a double space instead of two *line_breaks, I’d probably fuck up a bunch of coding doing it that way that I might not be able to catch easily because of pathing variance, and layout. Double *line_break is just very clear by way of organization, for me- plus I use blank lines to indicate places where I still need to write something.

Though I am absolutely certain it throws my word count off quite a bit. :\

1 Like
#26

Oh, sorry. Didn’t realize that was SO long ago, what with the relatively recent post. My bad.

#27

Hey @Fiogan. It worked like a charm thanks! and yup i added a final option.

1 Like