I'd really like it if comparing an undefined boolean with False would return True (and thus allow a chapter to be shown) if the variable has not been created. Without this, having any form of inventory/purchase system means that the inventory needs to be set up/declared at the start of the story. While it's doable, it is a bit of a pain.
Undefined doesn't mean false, so I don't like that way of handling it. Slightly related to the Formula Parser suggestion as it would allow handling such cases conveniently, making it possible to set the values of undefined variables.
Yes, but we don't have the ability to check for Undefined. Also, using <,>,<=,>= with booleans doesn't make sense either, but the system is implemented to evaluate them as false. What's the difference with Undefined? If we can have one nonsense, can't we have both? Within the chapter text you can use "if else" to check for false/undefined, but there's no way of doing it within the view conditions. Unless I'm mistaken the formula parser doesn't apply to chapter visibility does it? I thought it was score change only. My preference would of course be to allow checking true/false/undefined, but I figured that this would be easier and probably wouldn't break anything. Of course forcing the variables to be defined at the start has the advantage of having an easy and sensible reference place to check if you can't remember what you called something! In the specific case I'm thinking of using it (inventory tracking) the distinction between undefined/false is irrelevant. I simply want to be able to hide a chapter that lets a reader purchase an item if they already have the item. Sure, they could just use their brain and not click it, but from a usability point of view it'd be nicer if they weren't show irrelevant options. Amusingly, I just checked how it's handled within in-text if statements, and there Undefined is handled as FALSE. I.e. {if HaveItem=True}True{else if HaveItem=False}False{else}Undefined{endif} shows False. It's only in the chapter view conditions where it's a problem. Perhaps it would be better if chapters also showed up if a visibility check returned an error.
Oh, that is only possible in If-Statements in chapters. Well, these operators don't result in a comparison at all but lead to a syntax error which gets interpreted as false. In the chapter, if a variable doesn't exist in the reader's score, the condition will be skipped as well. Yes, and even if it would technically be possible to implement something similar for conditions I think it could lead to performance problems as all conditions of all child chapters must be evaluated when viewing a chapter. The function I had in mind is "IFNOTSET( {non-existing-variable} ; 0 )", placed in the chapter before the condition. Well, as you can't combine two conditions it would be necessary to have the options "true or undefined," "false or undefined," "true and defined," and "false and defined." That won't work on published stories where some readers already have progressed save games. You would have to use a version-system which can tell the reader that their save game is out of date or a function like hinted above.
That makes for amusing reading. You've taken each point and seem to have analysed it out of context. When mentioning the <=/boolean comparisons my point was simply that your statement "Undefined doesn't mean false" is kind of inconsistently implemented. In one place (intext) you can handle it, while in the other (visibilty) you can't. Perhaps just adding a default condition if the view options don't evaluate would work. With regards to undefined variables the conditional block isn't skipped at all when dealing with them. If you use the IF/ELSEIF/ELSE statement I posted it shows that undefined is evaluated as FALSE. Though, what is the relevance of this comment? I was simply mentioning that in-text it's possible to deal with undefined variables, but not in visibility conditions. How it works is irrelevant. However, it is inconsistent with your mention that you don't like undefined being treated as false, as that's how it is treated in in-text conditions. With regards the formula parser, I wasn't suggesting that it be applied to visibility conditions, just that you mentioned it as a solution, though I didn't see how. Having to put IFNOTSET... in the previous chapter is ugly and worse than just defining them all at the start of the story. Instead of having the 4 options T/U F/U T/D F/D, it could be simpler to have one other button, "default" which is either Show or Hide, and would apply if the condition failed for any reason, including the variable being undefined. Finally, I wasn't meaning that the code should be changed to force people to define variables at the start, rather, this is how it IS currently, and in some ways isn't a bad thing. E.g. I've now got a handy/logical reference point to check for the correct spelling/capitalisation of my variables. Basically I was saying although I wish I could handle undefined within the conditions, the way it is currently which forces us to define them up front isn't without merit. As an alternative to any changes, how about this behaviour is at least mentioned in the Chyoa conditional branches guide? Perhaps in Chyoa3.0 some kind of variables panel could be available for authors that shows all variables used in the story to help with correct spelling/caps, and could let you define defaults as well. Kind of like how immersion variables have one place where all are shown. My preference would be for a side panel like how about/score currently work. It'd be preferable if it showed for authors without having game mode active as it's annoying to have to keep switching gamemode on and off to see variable states/edit chapters you don't have access to currently based on the current state of variables. If we did have a separate variables panel it'd be nice if you could directly edit them as well, so (as author) you didn't have to 'read' through the story to be able to test conditions etc. Also, how do you quote in this forum? I don't see any quote links or bb code to do it.
Well... there is a small syntax error in your example it should be Code: {if HaveItem=True}True{elseif HaveItem=False}False{else}Undefined{endif} instead of Code: {if HaveItem=True}True{else if HaveItem=False}False{else}Undefined{endif} So the chapter skips on undefined boolean as well as on undefined variables of the other types. (Though I could imagine adding another option to check against undefined) Would be kind of the same as having 4 buttons as you would have 4 options as well. Then, these options should be available for all variable types as the other types fail the conditions as well when they are undefined. For a story in development, you will sooner or later reach a point where you have to introduce a variable afterward. So I think that would be a quite handy solution instead of forcing the reader to start over when using a version system or - even worse - let them being stuck at some point of the story. From my current point of view, I would avoid making the conditions any more complex but rather find ways to precalculate such conditions in the parent chapter. Though we'll see what Friedman comes up with for the next version. I added to 7. Conditions of Conditional Branches. and to 9. miscellaneous of Conditional Branches - If-Statements Do you think that is that sufficient? Maybe you want to put your workaround of determining if a variable is undefined within a chapter into the Conditional Branches Showcase (Examples and Source Code) The only way to do that would be to show all variables of all chapters of the whole story, no matter if it is in a parent chapter, child chapter, or another branch. You mean defaults if the variable doesn't exist? You mean a "sandbox" to test the Conditional Branches If-Statements? Reading through the story shouldn't be necessary as it will become pretty lengthy as soon as you reach a decent chapter depth. To test things deep in the story, I'd recommend creating an unpublished child chapter where you create a set of variables which you want to test, then link directly to the chapter you want to test. Highlight the text you want to quote and click on the Reply link which appears. Full quote is also possible with the Reply button at the bottom right of a post. That doesn't work for quotes in quote, though you can do it manually. Code: [QUOTE="dirtytyke"]quoted text[/QUOTE] [QUOTE]quoted text[/QUOTE] You could also use the BB Code editor (icon on top right of the editor window)
Ah, you're right, I did make a mistake with the ifelse syntax and it does work as you mentioned. I think your additions to the guide are adequate. I'd imagine anyone who can work with the conditional variables would be able to figure out the workaround easily enough so I don't think it's worthwhile to add it anywhere. Having the text about undefined not being evaluated though is another matter as it's a great time saver if you know that in advance. Yes I did mean something like a sandbox. I have been creating chapters just to set variables but it's kind of an ugly way of doing it. Chyoa3 would be great if you didn't need to do stuff like this. That's exactly what I was thinking. A list of all variables used anywhere in the story. If they were all declared using a panel like that then undefined variables wouldn't be an issue. Perhaps you either add them there, or as soon as you add a new one anywhere during creating a chapter it appears there with a default value. Also, thanks for the quote info, and sorry if my previous response seemed rude. I've been told I sometimes come off like that when I didn't mean it that way...
There is the suggestion God Mode which suggests a debug mode. I'm all for it, though I think it has to wait until v3 While it should be possible to collect all variables, it could be somewhat difficult to track if a variable isn't in use anymore. If you delete it from one chapter, you would have to check all other chapters to see if the variable is in use for any other chapter. Default values would only work if you do that on the edit story page. Otherwise, you would be able to overwrite another author's default value.
Ah, I didn't see this in the 'All suggestions so far' thread. Liked. I forget that other people could be working on a story... It seems like gamemode stories could be very difficult to manage correctly with multiple contributors.
I think so too. I guess that the story owner should take a major role in managing variables in most game mode story concepts.
