Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Please just straight up explain: Fading out/transitioning out animations for passages in Sugarcube 2
(Caution: traces of High-Octane Sarcasm and Passive-Agressiveness)
Hello!
I'm a newcomer to twine, and so far the community, atmosphere and the tool itself has appeared to be very pleasant. I was fiddling around with sugarcube 1.x since it had the save functionality I wished to have - but after looking over the features I decided to move over to sugarcube 2.x.
Just like the title inclines; what happened to fading out passages in Sugarcube 2.x? In my humble opinion, the way it behaves in contrast to Sugarcube 1.x is just too abrupt, sudden and all around painful for the eyes when the text fades in but doesn't fade out.
I've looked around for a solid three hours only becoming more and more frustrated as I went along. So far, I have not found an answer, so I registered and turned to people whom hopefully can properly instruct me about it or perhaps, instead, share the infamous legendary tale of how that very rudimentary and almost mandatory functionality was passed onto the twinergods as a sacrificial gift in hope to increase the quantity and ripeness of the yearly twine-harvest held by the reclusive underground occult of twinerprophets and twinermonks ... or something to that effect.
Here, the config parameter (which I stumbled upon time after time again) config.passages.transitionOut is being described as determening "[...] whether outgoing passage transitions are enabled." Alright, fair enough, except that;
config.passages.transitionOut = 1010; mearly delays the transition by 1010 milliseconds. Nothing is faded out.
And
config.passages.transitionOut = "opacity"; does nothing except freezing everything. Apparently it doesn't have access to the value "opacity" or doesn't know what it is. The entire story/program gets stuck on the passage that it's supposed to transist from indefinately, trying to do what it's supposed to do but failing miserable instead. Forever. So that's nice.
In this thread, the concept is discussed and apparently solved by adding the string of code to the CSS stylesheet (with the authors fix) in Twine 2. However, I'm not sure if it even is Sugarcube 2, since it's not stated in the thread and I don't know how old it is (seeing as the thread is from 2014). This does nothing on my end - it doesn't even come near to functioning. No opacity is being changed.
So, cut short: How do I accieve this? How do I make passages in Sugarcube 2.x, used in Twine 2.x on a windows desktop, fade out with just as good of a job as it does fading in? (I mean, really, what? What even is this? Why did the author remove it in the first place, or at the very least, make it disabled on default and then sending whomever wanting to fix it on an untold wild goosechase? Is this feature not supported anymore? What was implemented in favour of it? Is nothing sacred anymore??)
*breathes in; breathes out* - Thank you in beforehand.
Hello!
I'm a newcomer to twine, and so far the community, atmosphere and the tool itself has appeared to be very pleasant. I was fiddling around with sugarcube 1.x since it had the save functionality I wished to have - but after looking over the features I decided to move over to sugarcube 2.x.
Just like the title inclines; what happened to fading out passages in Sugarcube 2.x? In my humble opinion, the way it behaves in contrast to Sugarcube 1.x is just too abrupt, sudden and all around painful for the eyes when the text fades in but doesn't fade out.
I've looked around for a solid three hours only becoming more and more frustrated as I went along. So far, I have not found an answer, so I registered and turned to people whom hopefully can properly instruct me about it or perhaps, instead, share the infamous legendary tale of how that very rudimentary and almost mandatory functionality was passed onto the twinergods as a sacrificial gift in hope to increase the quantity and ripeness of the yearly twine-harvest held by the reclusive underground occult of twinerprophets and twinermonks ... or something to that effect.
Here, the config parameter (which I stumbled upon time after time again) config.passages.transitionOut is being described as determening "[...] whether outgoing passage transitions are enabled." Alright, fair enough, except that;
config.passages.transitionOut = 1010; mearly delays the transition by 1010 milliseconds. Nothing is faded out.
And
config.passages.transitionOut = "opacity"; does nothing except freezing everything. Apparently it doesn't have access to the value "opacity" or doesn't know what it is. The entire story/program gets stuck on the passage that it's supposed to transist from indefinately, trying to do what it's supposed to do but failing miserable instead. Forever. So that's nice.
In this thread, the concept is discussed and apparently solved by adding the string of code to the CSS stylesheet (with the authors fix) in Twine 2. However, I'm not sure if it even is Sugarcube 2, since it's not stated in the thread and I don't know how old it is (seeing as the thread is from 2014). This does nothing on my end - it doesn't even come near to functioning. No opacity is being changed.
So, cut short: How do I accieve this? How do I make passages in Sugarcube 2.x, used in Twine 2.x on a windows desktop, fade out with just as good of a job as it does fading in? (I mean, really, what? What even is this? Why did the author remove it in the first place, or at the very least, make it disabled on default and then sending whomever wanting to fix it on an untold wild goosechase? Is this feature not supported anymore? What was implemented in favour of it? Is nothing sacred anymore??)
*breathes in; breathes out* - Thank you in beforehand.
Comments
The TheMadExile would be a better person to answer your question but based on a quick look at the SC2 source code I believe the transition-in and transition-out class names may of been changed to passage-in and passage-out but I could be wrong.
Nothing happened. In both versions of SugarCube, there is, by default, a 400ms opacity-based ease-in transition for incoming passages and no outgoing passage transition. As the author, I would know (you're also free to check their publicly available source code, if you think I'm lying or simply woefully misinformed).
Various kinds of outgoing transitions are possible, using CSS-based transitions, but you have to both enable them AND provide the appropriate CSS style, as none are included (IIRC, very old versions of SugarCube 1.x used to include styles for outgoing CSS-based transitions, but even then they were never used unless enabled).
I have no idea what outgoing transition you think you were/are seeing in SugarCube v1, but without the influence of something you haven't mentioned (e.g. using additional code/styles), there is not, literally cannot, be an outgoing transition by default. I don't know what to tell you other than that.
An outgoing transition is patently useless in most cases. Calling them "almost mandatory" is a bad joke. You may like them, and that's totally fine, but let's get real.
Case in point, you are one of the very few who've complained about SugarCube (both versions) lacking them by default—if you aren't, in fact, the very first to do so (I certainly don't recall anyone else complaining, "Of all the worst possible things. This is…. The. Worst. Possible. Thing!"). I'm not saying people haven't asked how to enable them, there's been the occasional query, but no one else has either complained or reached this level of hyperbole.
As noted above, the style to actually do the transition is also necessary, and not included.
Here's an example leveraging the default passage transition (400ms opacity-based ease-in) to enable both an incoming and outgoing passage transition.
Goes in your script section (Twine1: script-tagged passage, Twine 2: Story JavaScript): Goes in your stylesheet section (Twine1: stylesheet-tagged passage, Twine 2: Story Stylesheet):
body { overflow-y: scroll; } .passage-in, .passage-out { position: absolute; opacity: 0; }The forced overflow setting is necessary, otherwise you might see some jitter. The absolute positioning is necessary for the passages to occupy the same space, so they can cross-fade, otherwise there no point in having both transitions.Other kinds (e.g. dissolves) and durations of transitions are possible, as well as separate transitions for each. Though, they would require different styles, and possibly config.passages.transitionOut setting.
Yeeah ... Straight up complaining while exaggerating and being the most hyperbole you've seen yet - aint' that a nice thing for a change? I guess I was just in that mood, trying to be humorous while also wanting to gain attention to my problem.
If you, the author; found yourself thinking "what kind of lunacy is this?" then I've kind-of succeeded. If you instead found my rude portrayal of your skilful programming (I wouldn't be here if I could do it better myself, which I can't) to be mostly offensive, then, yeah, my bad. You're absolutely right, a feature like this isn't mandatory, and this was all a bad joke on my part.
Thanks for your support and patience.