Pain with Panes: Issue 3: Expanding Whitespace

Thanks everyone for the help with dynamic game panes. That's a really useful feature. In adding it to my game, however, I've noticed that when panes are hidden there is white space between the dialogue text and the input window at the bottom of the page and this effect gets worse after panes have been moved in and out a few times. Anyone know a quick fix?


JS.eval("$('#txtCommandSpacer').height(10);")


Sorry Richard, that didn't work. I've been whittling the problem down to something I could post here. In the game below, use the command 'gaptest' three times, then 'panes' twice to see the white space problem. The amount of text being printed affects the size of the white space but I haven't worked out the precise relationship. I can't begin to guess the issue here!

<asl version="550">
  <include ref="English.aslx" />
  <include ref="Core.aslx" />
  <game name="Test">
    <gameid>0e1e8167-0c69-4d58-900a-90d86f8a9452</gameid>
    <version>1.0</version>
    <firstpublished>2018</firstpublished>
    <attr name="panes_on" type="boolean">false</attr>
  </game>
  <object name="room">
    <inherit name="editor_room" />
    <description>An empty room.</description>
    <object name="player">
      <inherit name="editor_object" />
      <inherit name="editor_player" />
    </object>
  </object>
  <command name="gaptest">
    <script><![CDATA[
      // Open Grid
      JS.ShowGrid (300)
      // Display largish message
      msg ("Maze B is the same as A but with points 12 and 13 connected and its starting point is 7. <br/>Maze C is similar to Maze B, but has 8 and 9 connected instead of 12 and 13; it uses a starting point at 7.<br/>Finally, Maze D is the same as C but its starting point is 3.<br/><br/>Maze B is the same as A but with points 12 and 13 connected and its starting point is 7. <br/>Maze C is similar to Maze B, but has 8 and 9 connected instead of 12 and 13; it uses a starting point at 7.<br/>Finally, Maze D is the same as C but its starting point is 3.<br/><br/>Maze B is the same as A but with points 12 and 13 connected and its starting point is 7. <br/>Maze C is similar to Maze B, but has 8 and 9 connected instead of 12 and 13; it uses a starting point at 7.<br/>Finally, Maze D is the same as C but its starting point is 3.")
      // Close Grid
      JS.ShowGrid (0)
    ]]></script>
    <pattern>gaptest</pattern>
  </command>
  <command name="panes">
    <pattern>panes</pattern>
    <script><![CDATA[
      if (game.panes_on) {
        request (Hide, "Panes")
        JS.eval ("$('#txtCommandSpacer').height(10);")
        game.panes_on = false
        msg ("The game panes have been hidden. Type <i>panes</i> again to restore them.")
      }
      else {
        request (Show, "Panes")
        game.panes_on = true
        msg ("The game panes are now visible on the right. Type <i>panes</i> again to hide them.")
      }
    ]]></script>
  </command>
</asl>

I will be able load this game up in about an hour, and I'll see what I can find.


Until then, you could try this:

Replace request (Hide, "Panes") with JS.uiHide("#gamePanes"), and replace request (Show, "Panes") with JS.uiShow("#gamePanes").


ETA

This, it turns out, is not a fix, but request is being deprecated, so these changes are still a good idea.


See next post for the fix.


JS.eval("var reHeight = 0;  $('#divOutput').children().each(function(){reHeight += $(this).height();});  $('#divOutput').css('min-height',reHeight);")

ETA: Modified PANES script

<asl version="550">
  <include ref="English.aslx" />
  <include ref="Core.aslx" />
  <game name="Test">
    <gameid>0e1e8167-0c69-4d58-900a-90d86f8a9452</gameid>
    <version>3.0</version>
    <firstpublished>2018</firstpublished>
  </game>
  <object name="room">
    <inherit name="editor_room" />
    <description>An empty room.</description>
    <object name="player">
      <inherit name="editor_object" />
      <inherit name="editor_player" />
    </object>
  </object>
  <command name="gaptest">
    <script><![CDATA[
      // Open Grid
      JS.ShowGrid (300)
      // Display largish message
      msg ("Maze B is the same as A but with points 12 and 13 connected and its starting point is 7. <br/>Maze C is similar to Maze B, but has 8 and 9 connected instead of 12 and 13; it uses a starting point at 7.<br/>Finally, Maze D is the same as C but its starting point is 3.<br/><br/>Maze B is the same as A but with points 12 and 13 connected and its starting point is 7. <br/>Maze C is similar to Maze B, but has 8 and 9 connected instead of 12 and 13; it uses a starting point at 7.<br/>Finally, Maze D is the same as C but its starting point is 3.<br/><br/>Maze B is the same as A but with points 12 and 13 connected and its starting point is 7. <br/>Maze C is similar to Maze B, but has 8 and 9 connected instead of 12 and 13; it uses a starting point at 7.<br/>Finally, Maze D is the same as C but its starting point is 3.")
      // Close Grid
      JS.ShowGrid (0)
    ]]></script>
    <pattern>gaptest</pattern>
  </command>
  <command name="panes">
    <pattern>panes</pattern>
    <script><![CDATA[
      hidemsg = "The game panes have been hidden. Type <i>panes</i> again to restore them."
      showmsg = "The game panes are now visible on the right. Type <i>panes</i> again to hide them."
      JS.eval("if (isElementVisible('#gamePanes')){ uiHide('#gamePanes'); addTextAndScroll('"+ hidemsg + "') }else{uiShow('#gamePanes'); addTextAndScroll('"+ showmsg + "');}")
      JS.eval("var reHeight = 0;  $('#divOutput').children().each(function(){reHeight += $(this).height();});  $('#divOutput').css('min-height',reHeight);")
    ]]></script>
  </command>
</asl>

Many thanks Richard. I've pasted that into my game and the problem has gone away. Hopefully that's my last issue and I'll be ready to release the fully dynamic game tomorrow after a thorough test.

Is this a fix that will be made to show and hide at some point?


You are very welcome.

I'm not sure if this would be something the guys would add to Quest. I think most games either have panes or they don't, so it isn't very necessary.

(Plus, it's only truly necessary during a call to uiHide(), now that I think about it, but it should be hurting anything the way it is.)


If you want your uiHide() to do this every time, just add this to your user interface initialisation script, then you won't have to worry with it in any more code (it will resize automatically with each call to uiHide()):

JS.eval("var uiHideBak = uiHide;function uiHide() {uiHideBak(); var reHeight = 0;  $('#divOutput').children().each(function(){reHeight += $(this).height();});  $('#divOutput').css('min-height',reHeight);")

Again thanks Richard. An updated version of Giantkiller Too has just been uploaded which includes this adjustment. As it only seems to be needed when panes are removed, I've limited the adjustment to that case. I'll leave the thread open in case someone can comment of the source of the problem and a possible fix to uiHide().


Glad it worked!


My thoughts concerning possible changes to uiHide() (which may be unfounded):

When we hide the panes during play, the existing text fills that empty width, and the white space at the bottom is born. That's because we are manipulating settings after the text has printed. This wouldn't be considered a bug (or an issue). Everything works out of the box. We are creating the problem when we make your changes to the default display settings.

Quest constantly checks the heights of the elements in divOutput, then sets the minimum height of divOutput to the sum of those heights. When we hide the panes during play, that is a big, fat monkey wrench. Quest is not expecting that at all. It's a mod. So, we must modify uiHide() while we're making the other changes.


I believe uiHide() is used every time an element is hidden, even when we (the game authors) are not calling uiHide(). It doesn't only hide the panes either. It hides any and every element in the window. Adding my code to the function would be a waste of space in 99% of games, and it would make every Quest game's code (at least a little bit) less efficient. (Quest has trouble running online already, and this would slow it down just a little bit more.)


So, for the greater good, I think we should have to modify uiHide() while adding code to games to hide and show elements which are normally either static or non-existent.


Quest constantly checks the heights of the elements in divOutput, then sets the minimum height of divOutput to the sum of those heights.

I still don't understand why this is necessary.


Tried another game where the panes were on throughout the game but switched off for an epilogue at the end. The calculation was so far out at that point that no text at all was showing. It's as if there is an error in some calculation being performed behind the scenes that builds up as the games goes on. The fix above sorted it out but it would be nice to understand the problem!


K.V.

Every time something is printed during play, Quest adds that new element's height to the main element's min-height.

So, one game begins with divOutput's min-height set to 169px.

image


Then I take 1 turn which prints my command plus 2 lines of code, the min-height of divOutput becomes 245px.

image


What is the purpose of that? I do not know. I assume there is a purpose, though. ...or at least that there was once a purpose.


I don't see the purpose.

The browser will display the div with either the specified min-height, OR the total height of all the elements inside it. Whichever is higher. If the min-height is 0, the element will be dynamically sized to fit its content.

As far as I can tell, Quest sets the min-height to be the sum of the sizes that all of the individual content divs were at the time they were added. If the content divs get bigger later on (panes appearing, the window being narrowed, or font size increasing), the min-height will be ignored because it's less than the content height and the browser will handle the size correctly. If nothing weird happens, the min-height will be ignored because it's the same as the content height, and the browser will handle sizing correctly. If the height of content panels is reduced (because the window becomes wider, the panes are hidden, a ShowMenu block is hidden, or a few other cases) the min-height will introduce empty space equal to the difference at the bottom of the output. Every case I've seen, this is treated as a bug, and is patched by yet another special-case in which the min-height has to be manually recalculated.

I'd really like to know what circumstances this is actually useful in. Is there a case where we want to add whitespace at the bottom of the output?


K.V.

The only thing I can think of (which may not even be relevant) is that trick to stick the command bar to the bottom of the page from the beginning of play.

http://docs.textadventures.co.uk/quest/ui-javascript3.html#sticking-the-command-bar-to-the-bottom-of-the-screen


That doesn't use (or rely on) the min-height style rule; it's a different kind of whitespace. (a fixed-width margin, rather than making the div bigger than it needs to be)


K.V.

Hrmm...

Well, I'll open Quest in Visual Studio and search the entire project for "min-height". If it's used for anything, I would think this would lead me to it (if there aren't too many hits on the search).


K.V.

The only place I see it is in addText().

I commented this line out of my addText(), and I don't see any negative effects (in fact, it completely solves this issue):

//$("#divOutput").css("min-height", $("#divOutput").height());

This topic is now closed. Topics are closed after 60 days of inactivity.

Support

Forums