Weird "error message" - Does Twine really work ?

Question

This is Twine 2.1.3 and SugarCube 2.18.0. Whenever my game reaches that passage:

$log
<<if $enemy.weapons.length > 1>>
	<<set _i to random(0, $enemy.weapons.length - 1)>>
<<else>>
	<<set _i to 0>>
<</if>>	
<<set $enemy.currentWeapon to $enemy.weapons[_i]>>
<br>$enemy.currentWeapon.monsterAttack
<<set $log to $log + "<br>" + $enemy.currentWeapon.monsterAttack>>

<<set _result to 0>>
<<set _dice to random(1, 20)>>
<br>_dice
<<if _dice == 20>>
	<<set _result to 1>>
	<<set _hit to "<br>Vous êtes touché, et vous subissez ">>
	<<set _N to random(1, $enemy.currentWeapon.maximumDamage)>>
	<<set _hit to _hit + _N + " points de dommage !>>
<</if>>
<<if _dice == 1>>
	<<set _result to -1>>
	<<set _hit to "<br>" + $player.missed>>
	<<set _N to 0>>
<</if>>

<<if _result == 0>>
	<<set _dice to _dice + $enemy.XP>>
	<<if _dice > $player.AC>>
		<<set _result to 1>>
		<<set _hit to "<br>Vous êtes touché, et vous subissez ">>
		<<set _N to random(1, $enemy.currentWeapon.maximumDamage)>>
		<<set _hit to _hit + _N + " points de dommage !>>
	<<else>>
		<<set _hit to "<br>" + $player.missed>>
		<<set _result to -1>>
		<<set _N to 0>>
	<</if>>
<</if>>
_hit
<<set $log to $log + _hit>>

I get that fabulous error message: "Error: child tag <</if>> was found outside of a call to its parent macro <<if>>". 

Having had other problems of the same interesting kind with Sugarcube and Harlowe, I'm beginning to think that there is a biiiiig problem of principle somewhere. That's why I'm asking the question : is Twine really working ?

And I'd like to know what's wrong in my syntax, which is as basic as it can be ? And I'm prepared to offer abject apologies if needed.

Thanks.
 

Answer 1

NOTE: When supplying example code you want to other people to debug for you, you need to also supply the structure of any complex variable values it depends on so that the answer-er doesn't need to work that out for themselves. Otherwise the answer-er gets other error messages instead.

There are two lines (of the same code) within your code where you are not closing the String value being added to the _hit variable.

<<set _hit to _hit + _N + " points de dommage !>>

should be

<<set _hit to _hit + _N + " points de dommage !">>

... this is causing the parser to throw the error you are seeing.

Answer 2

My humblest and most abject apologies as promised, greyelf . Thank God, you're here !

I'll tell you something: Having read a post published by Emily Short on her blog entitled "So, Do We Need This Parser Thing Anyway?", I am absolutely convinced that Inform is the past (unless Vorple makes a hit) and that Twine is part of the future.

But I savagely and fearlessly declare hereby that at the moment Twine is NOT mature and can be nothing less than exasperating. I am a keen follower of Twine, and it seems that if you want to create anything that is non-trivial with it you need an extensive knowledge in:

• Programming in non-standard languages,
• Advanced HTML,
• CSS, preferably cryptic,
• Twine's internal logic,
• Harlowe's and / or SugarCube's internal logic.

And I add that I am NOT interested in that  ... in those things. And I don't even want to know that they exist. You know what ? I just want to create IF. Period.

And I must sadly add that, compared with Twine, on the purely technical side, Inform is practically flawless. When you have grasped their bizarre pseudo-English programming language, that's it. And their editor picks out the common syntax errors such as mine , as do the most common and free editors such as, say, Notepad++. I don't want to be unduly negative, but... When you think that with Harlowe ( and you should know because of the way you've been helpful with me on that very subject ) the passage's text doesn't even wrap naturally when you resize the window, but that's a shame! In 2017 this has no right to be a problem! This has no right even to exist!

That takes me back to an earlier period of my life. You have seen from my site that I create 3D models. I used Blender, an extraordinarily attractive and free but unreliable product. So, I soon as I got the money I switched to Maya. Not cheap at 1,000 euros per year, but flawless and as such worth it.

Sorry for having lost my temper.

 

Comments

This should be a comment on greyelf's answer, not its own answer.

You're certainly entitled to your opinions (however uninformed), and you're allowed to feel frustrated or whatever, but the simple truth of the matter is that no program or tool as complicated as this can protect you from all syntax errors all the time, not even glorious Inform.

---

@thierry_saint_malo:

Thank you for stating your opinion on the current state of the Twine 2 application, and for your suggestions of possible enhancement to the application's three editors (Standard, Javacript, and CSS) that would potentially improve an end-user's experience. Although I believe that the Issues page of the Twine 2 project's repository would be a better place to make those suggestions, and if you do decide to do this can you please break those suggests apart into separate new issues so that they can be evaluated by the developers (I'm not one of them) individually.

While many of the things you stated in your comment are true, I believe comparing the current Twine 2 application against the current Inform 7 IDE is a little unfair. As I understand it, the Inform IDE is on it's 7th major release (and who knows how many minor versions since it's 1st major release) and the Twine 2 application is on its 1st major release, so this is a little like comparing a T-Model Ford with a Tesla Model S.

There is a large variance between the number of software developer hours that have gone into each of the two products, and to further complicate the matter the Inform editor has to handle a single (Inform) scripting programming language where as the Twine 2 standard passage editor needs to handle at least three (one for each of the included story formats) TwineScript programming languages and possibly more as new story formats are created.

This is not saying that improvements can't be made, just that those improvement take time and effort, and that the level of complexity of needing to support multiple TwineScript languages can increase the amount of time and effort needed.