welcome to the syrtis war ghost tour <spooky music starts playing> where YOU become the ghost!

These screens open dsRPGDialog, which uses rpgPagePaneInit to generate the panes from a list of structs with information about the descriptions and actions. The faulty actions in these lists have only a label. The screens used to work and the lists haven't changed recently, but rpgPagePaneInit has. So the default action must previously have been to exit the screen (case 1 of the switch that creates the action). Now the default is to continue to the next page (case 2) unless it's on the last page, which is not the case when it's on the main menu. I verified that exiting the screen (via console) correctly exits the main menu and returns to the station's dock screen. We could fix these screens by adding nextPage:'exitPane to the leave action, but maybe it's better to restore the default or find a better way to detect when there is no next page?

More experiments: These screens work correctly in 1.7. But changing the git version to use the versions of rpgPagePaneInit and rpgPageCount from 1.7 doesn't entirely fix the problem. Instead, it forces you to go through the panes in order, then exit, regardless of which actions you select. Again, the data that defines the screens hasn't changed. So I guess either rpgPagePaneInit calls a function that has changed that I missed, or a built-in function's behavior has changed.

Well, I can't figure out how this ever worked in the first place.

But I can see three options for fixing it:

1) Leave the functions unchanged and just fix any pane lists that exit from a pane other than the last one to have nextPage:'exitPane.

2) If the pane after the current one in the list has an ID, assume we're at the last page, so the default action will be to exit, rather than continue to the next one. I should check that this won't break any existing screens, but presumably panes with ID are reached by navigating by ID.

3) Since the data lists need to be rewritten for translatability anyway, just rewrite them as proper dockScreens and deprecate this whole convoluted mess, since it's basically the same amount of effort and code length.

OK, mystery solved. Back in 1.7, dsRPGDialog didn't use rpgPagePaneInit. It had different code where if there are no actions in the data for a pane, it creates an action to go to the next pane, but if there is an action with no effect specified, it defaults to exiting the screen. So another fix (option 4) would be to change rpgPagePaneInit to work this way. I'm not sure whether this is more or less likely to break other screens than option 2 above.

Several other screens depend on rpgPagePaneInit and some of the screens that use it are already properly translatable, so option 3 is out.

I used a regular expression to search (probably) all the structs in the game with an actions field. These two are the only ones that expect an action with no nextPage field to exit the screen. Several of them do expect such an action to continue to the next pane, so option 4 isn't good. Exactly one (in HuaramarcaMission07.xml) expects such an action to continue to a pane that has an id field. So I can go with option 1, or option 2 and remove the unnecessary ids in that file.

I think I'll go with option 2 because it doesn't require changing Eternity Port.

https://github.com/kronosaur/Transcendence/pull/93/commits/13d3d85671a9219ef1639ba0e9613802249066eb

This was due to 2edd39dd in PR79 where I modified RPGDialog to use the rpgPagePaneInit function as they were _almost_ identical.

However, I did not notice that dsRPGDialog and rpgPagePaneInit had different behavior when the pageDesc had a list of actions - i.e. if the actionDesc did not define nextPage/nextPane then dsRPGDialog would assume ‘exitScreen while rpgPagePaneInit assumes ‘nextPage

Note - both assume the same behavior (default nextPage: ‘nextPage) for pageDesc without a list of actions

Overall I would prefer option 1 - change the two Eternity port screens as these are the only cases which made use of the old dsRPGDialog behavior (and fixing this comment)

My main objections to option 2 are it affects both the case where you have a list of actionDesc or a simple pageDesc and both the case where nextPage is Nil or explicitly to ‘nextPage

• i.e. it hasn’t just changed the default action when nextPage is Nil, but made panes with an ID impossible to reach without explicitly navigating by ID

Right, that's a good point. Now I'm less than 100% sure this change won't break anything. On the other hand, I like the behavior when nextPage is actually Nil for an action in a list, because it makes it less likely to accidentally create an inescapable screen. What about separating the behavior so Nil exits in this case but 'nextPage goes on?

Edit: That looks like this. Also, the comments at the top are out of date, but they do contain some info that isn't in the comments for rpgPagePaneInit, so they should be merged.

George merged the more narrow fix, where it only exits if an explicit action in the list has no next page specified and the next page has id.

Fixed in 1.8 Beta 3 with the merged changes from @NMS.