It was a delight yesterday to discover that the Quest map could be controlled dynamically. I've updated my two main games (L Too and (Giantkiller Too ) to make map visibility optional (though not really expecting anyone to hide it for the classic experience...let me know if I'm wrong!).

I would be even more delighted if I could do the same with the game panes. Is there a similar neat trick for hiding them dynamically as well?

I'm probably missing something here... are you talking about this?
request (Hide, "Panes") = this will hide then all.

JS.eval ("$('#compassLabel').css('display', 'none')")
JS.eval ("$('#compassAccordion').css('display', 'none')")

You can switch the compass part for:
statusVars
inventory
placesObjects

Edit:
Pix talking about cool stuff.

Outstanding! That indeed is what I was hoping to find. Thanks!

Cool. I'm still so new at this I rarely get to help anyone. I think I'm happier than you right now! :)

Glad to help! I'm afraid I'm guilty of not searching the forum before putting out the message because I didn't think it could possibly be that simple. I'm surprised I haven't come across it being used in games I've played as it seems reasonable to give players this choice at the beginning. I'm now working through my games to see the implications of adding the panes as they weren't there before. Some adjustments are needed but I've also found something odd that I'll probably post about tomorrow after I've had a look to see if anyone has raised it :)

Thanks for reminding me… I've got a partially-finished chunk of code on the back burner to do dynamic panes.
(Inventory, placesobjects, custom pane, command pane, compass, statusattributes, map, and room image panel are all implemented as uidialogs. which can be docked onto the sidebar either by the player dragging them there, or by JS commands. Currently at the point of resolving issues with some existing code that resizes the inventory list depending on the number of items in it; which currently doesn't play nicely with allowing the player to freely resize panes)

@mrangel
That sounds like a lib I want :)

all implemented as uidialogs

Genius!

@mrangel, as you are working on dynamic panes, this is probably the place to bring up questions about the adjustments that need to be made to a game when this facility is implemented (a problem for me!). Before I get into that, however, was there ever any discussion about bringing up the panes outside the main display area (still to the right) if there is space on the player's screen? This would avoid layout adjustments altogether.

this would be a problem for those who don't have extra screen space (mobile device users)... the best would for them to be popup windows (iframes, I think in web GUI programming/coding) which you can click on and drag them (as well as enlarge/shrink their dimensions: height~width) to where you want them

Yes hegemonkhan, a separate floating window would be even better from a player and game developer perspective. Does it create a headache for the Quest management team, however?

I think I saw some of (KV/mrangel/pixie)'s posts/threads with 'iframes' in their code/GUI-UI-code work... so I think it's possible... not sure how much hassle it would be though

Oops, wrong thread.

I have actually played with this before. My favorites were the map in a dialog popup and the compass in a dialog popup.

https://textadventures.co.uk/forum/quest/topic/hqokwdlme0wxfjs3h1jssg/movable-compass

https://textadventures.co.uk/forum/quest/topic/hqokwdlme0wxfjs3h1jssg/movable-compass#1c08d18a-8773-42c8-8f81-0f10f125d309

The mobile browser handles the panes completely differently, and there is no map.

---

---

---

---

---

I have a game which puts the compass in a dialog pane (although I'd bet mrangel's code is much different).

It works great online and in the desktop player:
http://textadventures.co.uk/games/view/6zbqlw5souownbtgimryha/compass-fun

...but it doesn't work worth a damn in a mobile browser. Even if the compass actually showed up here, you cannot drag and drop the dialog popup on mobile.

a separate floating window would be even better

Please, no. Not unless it is optional. I like my game in one place.

I think mrangel's method would please everyone (except mobile player, who are pretty much screwed no matter what).

I bet his dialog popups will look just like the current panes, and that they are arranged identically when play begins. From there, we can drag them wherever we please, close them, and/or resize them individually.

Please, no. Not unless it is optional. I like my game in one place.

For me, this is all about options. I personally like the map and hyperlinks but not the game panes as they don't seem to add much extra value and tend to take the players attention away from the story...but, that's just my opinion! I'd love to create flexible games that allow all, some or none of the features according to the players preferences expressed at the time the game is played.

KV, I'm not pushing for floating game panes! It would be helpful, however, if game panes didn't disrupt the main game window when they appeared regardless of how that is achieved.

See, I don't like the map. I very much dislike it. It is in my way. It is only a distraction. And it takes up half of the screen!

If you feel the same about the panes, then I understand completely.

In most of my games, you can enter PANES to toggle the entire element on or off.

  <command name="panes_cmd">
    <pattern>panes;toggle panes</pattern>
    <script>
      JS.eval ("isElementVisible('#gamePanes') ? uiHide('#gamePanes') : uiShow('#gamePanes');")
    </script>
  </command>

In most of my games, you can enter PANES to toggle the entire element on or off.

@KV, I've just looked at Easter Eggs, and the space there is fixed rather than the demo which shows, as I would expect, the space to be recovered? Could you just as easily have put that reserved area to the right of the main play area and allow the map to come and go at the top?

I've just looked at Easter Eggs, and the space there is fixed rather than the demo which shows, as I would expect, the space to be recovered?

I made Easter Eggs in a modified version of Quest. Since publishing, I lost that Quest build in the shuffle, and I'd have to put forth quite a bit of effort to edit any games I made with that build because I had a few modified libraries included (which I have also "misplaced").

...but you are right. I noticed that Easter Eggs behaved that way while posting this. I had to say "most of my games," just to keep my foot out of my mouth.

Also note that I really mean "most of my Quest games", 99% of which are incomplete. I can't finish a real game using Quest, unless it's co-authored. (My 'actual' game was made with Inform, and it isn't tied to this account.) With Quest, I get distracted by all the bells and whistles I can add, and I end up doing more coding than writing.

I was going to use Easter Eggs as the example, and I was sad when I realized I'd messed that bit up. I may rewrite it just to fix three mundane things...

Anyway, to squeeze in a Quest lesson:

In Easter Eggs, I put:

JS.eval("$('#gamePanes').toggle();")

This does NOT change the width of #divOutput (which is where the main text is displayed).

Instead, use the JS functions built into Quest for simplicity's sake:

JS.eval("isElementVisible('#gamePanes') ? uiHide('#gamePanes') : uiShow('#gamePanes');")

Could you just as easily have put that reserved area to the right of the main play area and allow the map to come and go at the top?

With some extra work, some testing, then a little more work, but that kind of goes against the page design, anyway. Plus, that would depend on the end user playing the game in a window which is at least a little wider than 950px (for the main area) + 216px (for the panes).

Okay KV, unless someone comes up with a simple solution, I'll look at the general implications of adjusting the drawing/display area when the panes are moved in an out. I have used part of the drawing area available for the map for some of my puzzles. In principle, it should just mean an adjustment to the origin when the panes are introduced or removed but I never really understood the grid drawing facilities properly (v. little documentation) and made the pictures as much by experimentation as anything else.

I'll come back to this thread when I know more. Tomorrow I'm putting up "The Pain of Panes: Issue 1" so apologies in advance if you see this as an attack... :)

I'll look at the general implications of adjusting the drawing/display area when the panes are moved in an out.

Does the last bit of code I posted not do it?

I never really understood the grid drawing facilities properly

Neither have I.

I'll come back to this thread when I know more.

Me too.

Tomorrow I'm putting up "The Pain of Panes: Issue 1" so apologies in advance if you see this as an attack.

Psshht!

No worries!

We are merely sharing opinions.

In fact, if I ever seem argumentative, it's because I'm attempting to be funny.

Yep. This is the good code:

JS.eval("isElementVisible('#gamePanes') ? uiHide('#gamePanes') : uiShow('#gamePanes');")

NOTE: The map will not center itself until you change rooms the first time after toggling the panes.

This should center the map and everything.

JS.eval ("isElementVisible('#gamePanes') ? uiHide('#gamePanes') : uiShow('#gamePanes');")
if (GetBoolean(game, "gridmap")){
  Grid_DrawPlayerInRoom (game.pov.parent)
}

Try the MAP and PANES commands in Easter Eggs now. (I think I fixed them.)

Thanks KV, all looks fine with a combined dynamic use of maps and panes in normal circumstances. In my case, I was also using the map area as a drawing/display area for some puzzles and each needed individual attention. In two cases, the displayed material was narrow enough that it could be left in the same position when the panes were brought in or taken out. An additional complexity was that I allowed players to break out of puzzles, usually to obtain a hint, and return to to them. Within a puzzle, I've simply excluded a change to maps or panes, which seems reasonable. In one puzzle, a diagram explaining a puzzle filled the full window width without the panes. Fortunately, however, as this was an .svg file, I was able to scale it by 20% and move it to the left when panes were introduced and reverse the process when they were taken out.

Most time has been spent working around some unexpected issues raised by the information shown in the panes and allowance for clicking on directions rather typing then (...send a message if you want the details!). As threatened, I'll explain the issues in separate threads. Some experimentation is needed in most cases to enable me to explain these properly.

Oh... So you get just as crazy as I do while creating games... Then, you get it all working, and the display settings are out of whack sometimes. (I now realize where you were coming from when posted about UNDO a while back, too!)

Our recent discussion has also revealed the solution to undo not working on maps...use Grid_DrawPlayerInRoom (game.pov.parent) every time!

With Richard Headkid's fix for my final issue with game panes (white space appearing when panes switched out), dynamic games seem to be sorted, and can be seen in the updated Giantkiller Too game uploaded a bit earlier. This also sues dynamic maps and dynamic hyperlinks. Thank you all for your tireless support, with a special mention to KV who has looked at just about every question/issue I've raised, in spectacularly quick time. I'll try to summarise the dynamic facilities in a separate thread, which will also bring together the few remaining open issues.