It looks like you're new here. If you want to get involved, click one of these buttons!
/* Define up a setting to control the rate of inter-passage text fade-in. */ Setting.addList('textDelay', { label : 'Choose how long it takes for text to appear.', list : ['No delay', '1s', '2s', '3s'], default : '3s' }); /* Set up a postrender task to handle fading in each text section based upon a player selected delay. */ postrender['delayed-text'] = function (content) { // Find all elements containing the `delayed` class. var $elems = $(content).find('.delayed'); // Text appearance delay (in milliseconds). var delay; switch (settings.textDelay) { case '1s': delay = 1000; break; case '2s': delay = 2000; break; case '3s': delay = 3000; break; default: delay = 0; break; } if (delay > 0) { $elems.each(function (i, el) { $(this) .delay(delay * (i + 1)) .fadeIn(1000); // 1 second fade-in }); } else { $elems.removeClass('delayed'); } };
/* Set sections containing the `delayed` class to be hidden initially. */ .delayed { display: none; }
@
Comments
In javascript passage write:
In passage write: If you want to make the link invisible but still can be autoclicked, in css write
Gave that one a shot and clicking anywhere but directly on the link results in nothing happening. I created a seperate test story with nothing but the code provided, and still no dice.
Write this in javascript instead:
Only problem is, it doesn't wait until the link is revealed by the delayed text effect, no matter where you put the span class and link. I presume it's because the Javascript seeks out all instances of 'next' when you mousedown, and whether the link has been displayed or not is irrelevant, since it hasn't been explicitly told this is important.
The reason I'm trying to wait until the full passage has displayed before the 'Click Anywere' part kicks in is because if they click prematurely and/or think it's finished displaying, they may miss out on vital text telling them something. Because it's half RPG, half VN, I can't really include a back option without causing several other issues.
That said, if there's not a way to make that work, I may have to weigh up which is the lesser of two evils, since clicking anywhere to proceed is a very neat feature.
At the end of the passage just write SugarCube 2's equivalent of
<<silently>><<timedcontinue 4s>><span class="next">link</span><</silently>>
I don't know what timedcontinue is in sugarcube 2.
It's just <<timed>> in sugarcube 2.
@.delayed; is.
@.delayed in a passage delays the text.
@.delayed is used in any given passage.
@.delayed - one for each paragraph. So if each delayed holds back text for 3 seconds, that's 3 x 7 = 21 secs.
@.delayed, so that's 3 x 5 = 15 seconds.
I mean, technically you could do this math for every single passage and then set it at the top. E.g. A quick eyeball of a passage tells me there's 5 instances of Delayed, so I manually write in 5 x (whatever the user set delay is) = whatever the timed delay needs to be. That would make it match up. But what you've got then is a situation in which you're doing a math equation for every passage you write, a calculation you've got to maintain and update for each passage, highly subject to human error.
@.delayed once in a passage, the solution would work just fine.
I apologize if it sounds like I'm shooting down freely and helpfully given suggestions. That's really not my intent!
Something like:
You'll need to initialize the story variable $clickTimer in your StoryInit special passage. Then you can just plug in <<timed $clickTimer>>...<</timed>> where you need it.
You're fine, just a minor miscommunication, I think.
As an aside, maybe moving an automatic continue that isn't based on the text delay time to somewhere on the keyboard, like the spacebar, would be a good idea as a sort of shortcut. Much lower chance of accidentally skipping through if it's placed there.
Also, with the code used above, it might be possible to accidentally skip scenes while clicking around in the ui-bar menus and such, which could be problematic.
Looking at the timed macro, it seems to use a "<<timed 10s>>" kind of thing rather than a straight number. Not sure if that's the problem, but it could be.
As you said, I'm thinking that a key binding might be better at this point. It wouldn't need to interact with the delayed text, and if I separate any important item gain / stat loss etc events to separate passages or make it stand out at the top, I can migitate the risk of things being missed.
Small chance of clicking too early, but probably the lesser of evils. And I've got thousands of passages to do, so I should probably stop worrying about the UX and more about actually getting the game's shell done.
Anyway, I did this- my first attempt at actually trying to mess with Javascript instead of just mooch it off other people.
Javascript:
CSS
A Passage
and so on. You could make a widget which is gradiated enough to deal with many instances.
Then you'd have each passage use a limited vocabulary of option 1, option 2 etc and then just put the widget in front of the link each time.
Eg in passage
All you'd then have to do is put the correct <<set>> macro at the start of each text line.
That's basically what my story does. The code I gave was originally written in my story for a key bind.
I edited my post about a hundred times but I'm happy with it now, in case you read it before. I use widgets to handle this. If statements are simple and easy to code, and widgets saves you having to recode every passage.
Looking at my code, I made a handful of mistakes, and this is one of them. I'll have an update later today.
1. @Chapel Try the following, which leverages DairynGM's textDelay setting and uses a temporary variable:
2. The following: Is much better written as: There's no point here in selecting one set of elements, simply to search through it for another set. Simply select the correct set to begin with.
There's also no point in using a class for something which, by its very nature, must be unique on the page. I'd recommend making next an ID.
3. @DairynGM I'm going to assume you're using some kind of UI. Laboring under that assumption, you are likely going to have issues with the suggestions so far as clicking on the UI will also trigger the next passage link even though that was probably not the player's intention.
@TheMadExile Does the inbuilt Sugarcube sidebar count? By default, I've got it tucked away and semi-transparent, with the ability to click it back and forth. There's a few things in that menu so far. Character Info / Stats, the Quest Journal, and the Inventory.
This could be a problem, but I'd have to see how it works in practice. Scenes where choices are made would by default not have the screen-click enabled, only the ones where 'Next' is pretty much the only option.
I was planning to build UI elements as mentioned a week or so back in a thread, but these would be more informative than interactive elements. E.g. A box to the top right corner which displays in-game time, so you don't have to open the tucked away sidebar to see what time it is.
I guess I'll put together a test and see what the UX is like, and if it's an acceptable tradeoff.
I've already replaced the Next with an clickable animated arrow and included the Spacebar to skip ahead. It's such a small change, but it makes the whole thing feel a lot more smooth and user friendly.
I didn't really make any real suggestions to avoid the ui problem because it depends on the ui you use and how you want to fix it.
My options screen is in its own unique passage, not an overlay, so I avoid it like that. I also use key binds only. My clicks are limited to elements currently hovered over.
The other way, though a bit more clunky, is to put the link within an <<if>> statement and have the ui activate a variable that sets the if to false.