Sandcastle-Builder
Sandcastle-Builder copied to clipboard
eternaldensity
Don't scroll logicats off the screen while I'm trying to solve them
Every time I am trying to solve a logicat puzzle, the game will auto-scroll my browser to the least convenient position. For instance, the one I just did was in the bottom section of the screen where there is enough space to see the whole puzzle, but the game was automatically scrolling it to be half off the screen.
This happens at intervals and is not particularly great, since I'm trying to hit a tiny button within a time limit and scrolling the screen means that I end up hitting another tiny button which may not necessarily be correct.
This automatic scrolling doesn't seem to happen at any other time, so I guess it could be either:
a. deliberately put there to annoy people b. something intended to keep the puzzle on the screen which is utterly failing to do so c. something unrelated which happens to scroll the screen while redundakitties are visible
Its b and c - and really needs some expertise to fix. It has been reported several times and unfortunately the problem is in code that is not mine (and I don't really understand).
The best way to get round that problem is to make a fave of logicats that way you can make it stay where you want and it wont scroll if you make it big enough.
Yes, it's really annoying. I just unlocked logicats and fail to solve them because of this. But I'll try the fave thing. :)
How do I make a Fave showing the logicat puzzles? It seems to me that the title of the boost to show is "Redundakitty" but if I enter that in the Fave chooser, it's ignored.
'Caged Logicat' works for logicat puzzls that are not from Redundakitties. I am not sure it will be possible to do it for Redundakitties.
"Caged Logicat" is already up the top, so the problem isn't happening for that one. I was entirely talking about Redundakitties when I reported it.
I'm not good at JavaScript but from what I can see, the Redundakitty is constantly removed and added to the DOM while it's visible. That has to be the reason for the scrolling effect.
Is there really need to do so?
When the mechanics changed to the current method it solved other faults, unfortunately this one has been around for a while LucidCrux tried to improve it, but it still needs atention (It is not in areas I have much knowledge)
Molpy.repaintRedacted() is called every NP, and even though a visible Redundakitty <div> element doesn't change position in the DOM, it's detached from the DOM in the beginning of the method and reattached in the end (at the same position). I suspect this is the reason for the scrolling behavior. What you can do to fix it? I think you'd need some logic to decide whether or not it's changing position in the DOM tree before you remove it and add it again.
The problem is something like this:
http://stackoverflow.com/questions/10418281/prevent-page-from-scrolling-after-dom-manipulation
So solution proposed in that thread is to set minimum dimensions for image/div. Do we know consistently what's expected height/width for RK's div? Anyway, I'll try to look into it tomorrow.
I think what you need to know is the minimum height of the parent that the RKs div is in so that this element is not resized for that short moment when the RKs div is detached.
I guess you could use the current size as the minimum size. Then at least I guess you know it will fit. Probably.
Though, I rather like the idea of detecting that it will be re-added and avoiding the removal entirely. It seems odd to remove something from the DOM only to put it back in the same cycle. But then, I haven't read the code yet either.
The issue with detaching and readding the div also causes the spoiler video to reload itself (thereby restarting) every NP if it's selected as the RK.
I made some changes but don't know how to test them - I'll reference my branch here, so if you know how to checkout you'll be able to test it locally with yout save.
Sorry, I'm a newcomer to GitHub and SB. Which branch are the changes on?
Here it is: #1236
UPD: On this: https://github.com/erp-lsf/Sandcastle-Builder repository, branch named after number of this issue.
My patch will be included in the next release, so you'll be able to test it.
I think this fix broke the RK puzzles. In the last five minutes, I've experienced three or four times that a RK was available but it wasn't visible. I've seen RKs that give me "Not lucky" and the spoiler video, but no puzzles, so I suspect that these are the ones that are broken in v3.652.
Please see the attached image.
Molpy.Redacted.location
is 1 which means that an RK should be visible in the Sand Tools Section but it isn't.
I'll explain what I did. I added guard value keepPosition which is set true when you click on show button, and it's generating puzzles for solving. If it's value is set to true then Molpy,repaintRedacted() is skipped because I thought that this method corresponds for RK jumping. Seems like it also broke RK unfolding. I have another idea - find RK div declaration, and add minimal height to it. But I'm not sure will it help, because method detaches div and prepending it back. But for now, I'll push fix onto the corresponding branch. BTW: Join the development, or at least testing - if you don't know how to work with git or github, I'm glad to help you.
I'll not probably do any development at this point because I don't have any JavaScript or other frontend development experience (I'm a Java backend programmer) but I'll post bugs when I encounter them and try to debug them as well as I'm able to. I have a basic knowledge of Git so I'll check out out the #1207 branch from your repos and run it instead of the online version as soon as you've committed a new fix. From what I can see you've only undone the keepPosition stuff at this point.
Your branch doesn't work at this point because you didn't revert your previous changes correctly. You just removed this line from gui.js:807:
if(Molpy.Redacted.location == 0 || Molpy.Redacted.keepPosition) return; // Don't repaint because redacted is not active or we have puzzles waiting
instead of reverting it to its original version
if(Molpy.Redacted.location == 0) return; // Don't repaint because redacted is not active
Rather than revert I have spent a bit of time modifying erp-lsf's original patch to hopefully work - trying tests now
This is a tough nut, but I am getting there. keepPosition is now tri-state.
Still working on it - I have found a deeper bug that has been there for a very long time.
The scrolling is fixed, its just logicats are broken (and probably always have been) for the first time since taking over from ED I have had to ask him what something was supposed to do.
Ouch that took a long tme to unravell. The underlying code was broken. Now fixed (I hope)
Yeah, my RK puzzles are back and they seem to stay where they're supposed to be :)