George: DockScreen pagination and ShipInterior enhancement

[alterecco]

PKodon and I had a long talk this morning about how to handle the problem that
occurs when there are too many actions added to a DockScreen. This is a general
problem, but it particularly applies to the ShipInteror screen, as that is
typically where modders add an action for accessing features specific to their mod.

We came up with two solutions, independent of each other. The first solution
solves the overflowing action problem for all screens, but will be harder to
implement. The second solution can be done in the current system, but only
applies to the ShipInterior screen.

The first solution is to add pagination to DockScreens. There would be a small
indicator on the action pane showing where in the list the player currently is.
There would then be two keys (customizable in settings.xml) that allow the
player to go forward and backwards in the list. We suggest a sensible default
would be '[' and ']'. Perhaps there could be a small onscreen text that
explained what keys to use (or it should just be in the F1 help text). The
reason for not making the forwards/backwards actions regular DockScreen
actions, is that it might end up clobbering keys for other actions. We also
considered a scrollbar and buttons clickable only by mouse, but discarded that
because it would not be cool to make a mouse only interface.

The second solution applies only to the ShipInterior. It is based on a concept
made for the original DSF, the External Interfaces screen. The idea is, that if
vanilla included a "Ships computer" action in the default ship interior screen,
then modders could easily add actions to that screen, without fear of
overflowing. It would also add a little flavour to the ship interior. It would
of course not prevent a modder from adding to the main ship interior, but we
believe it would quickly be adopted. Examples of mods that could make use of
this are: G.O.D, VUI, Captains Log, Cargo Summary, Weapons Extended and Statis
Pod. In general any mod that has a DS where information is shown or settings
can be changed. Right now, many of these mods add actions to the default pane
of the ShipInterior or have a usable item that pops up a DS (essentially
cluttering important interfaces).

I have made a version of the External Interfaces concept that can be plugged
directly into vanilla. It is named Auxiliary Systems, but could be named
anything. It is a simple DS, and the means of adding elements to it is equally
simple. Here is an example. Just create an item that looks like this:

Code: Select all

<ItemType
  UNID=       "&itAuxiliarySystemsHookExample;"
  name=       "(auxiliary systems hook example)"
  attributes= "AuxiliarySystems"
  virtual=    "true"
  >

  <!-- optional image -->
  <!--Image imageID="&rsItems1;" imageX="0" imageY="288" imageWidth="96" imageHeight="96"/-->

  <StaticData>
    <Title>"Some Title"</Title>
    <Subtitle>"Some subtitle (optional)."</Subtitle>
    <Action>(scrShowScreen gScreen &dsSomeScreen;)</Action>
  </StaticData>
</ItemType>

The Auxiliary Systems DS will pick up any virtual items that has the
AuxiliarySystems attribute, and display it in the screen (a custompicker). When
an item is selected, it will run the action associated with that. Simple. The
system can easily be expanded to provide more features, but this ought to be
sufficient. Also, any code can be run from the action, not only screen changing.
You can get the code here:
http://drop.alterecco.net/transcendence ... ystems.txt


So, two different proposals for two related problems. Personally I would really
like to see the second proposal implemented in vanilla. Even if you implemented
DS pagination it would still be a valuable addition with nice flavor.

I look forward to hear what you think of these suggestions.

[george moromisato]

I like the idea of a "Ship's computer" screen, but I'm a little worried about adding extra complexity. I have a couple of ideas:

OPTION A:
1. Vanilla includes a copy of Auxilliary Systems DS.
2. The Ship's screen enumerates all item types and if it finds an item with "AuxilliarySystems" attribute, it adds an action that navigates to the Auxilliary Systems DS.
3. Extensions add items as appropriate.
4. Vanilla itself would not include any auxilliary items, but any extension could.

OPTION B:
1. Extensions that need an Auxilliary Systems DS include a module that implements it.
2. The engine is enhanced so that duplicate modules are folded together.
3. The Auxilliary Systems DS in the module adds itself to the Ship's screen if there are appropriate items.

The advantage of option B is that it could be used as a technique for may other shared resources (such as DSF). I haven't thought through all the details, so I'm not even sure that it will work properly, but it might be worth a shot.

As to the general problem of actions in a dock screen, I would like to implement the following (in this order):

1. Dynamically adjust the room for actions. Right now, we can't fit more than 8 actions on a screen because we start painting the actions at a fixed location. If the actions always used up as much room as needed, then we could add more.

2. If necessary, shrink the height of each action, so that more can fit in the given space.

3. Add scrolling, to actions (as you suggest).

I think that by adding #1 and #2 we can get at least 16 actions on a single screen. That might be enough for most purposes. Eventually, #3 might become necessary. But maybe in those cases a custom list UI is bettery anyway.

[PKodon]

Though alterecco did not mention it, we had discussed one other possible option, but it would mean a rewrite of how the engine adds new options to a dock screen (including modifying the new hook you added).

This would convert the actions to an open-ended list, such that, if the list contained more than (your current limit of) 8 entries, added by various mods and modules, then scroll elements would be added to the dock screen, and a "sliding window" into the list would be used for displaying what could be shown on the dock screen.

This could work for any dock screen, but in order for it to work with the Vanilla dock screens, it would probably require a rewrite of all the dock screens (unless somehow the list were kept solely in the engine, and nothing but the current means of adding selections to dock screens (including the new hook) were used.

We had left that out, as possibly too complicated, and too radical of a change.

Another issue we discussed, but decided not to mention in the initial post, was how to handle duplicate hot keys (that is, the situation where 3 mods define the same hot key for an action). Some means of tabbing through the selections should probably be considered, while we're considering these other issues.

Edit:

I just thought of something: how does your "shotgun" approach to mod loading affect this sort of thing? I ask, because, as I understand it, mod loading is random, so I don't really understand how dependencies are handled (when one mod is dependent on another, or several).

[alterecco]

I am also glad that you like this idea :)

I would definitely vote for option A. I don't really see a big need for option B, and the added complexity (in implementation and use) does not really justify it. I don't really think that something like DSF would benefit greatly from being some sort of explicit dependency. I agree that there is no need for the action to be present if there are no items using it. As for vanilla including any items of this kind, I would leave that up to you :D (perhaps in the future you would, if it became a useful enough feature)

As for the general DS improvements, I think your proposals sound good. In any case, if we have something like the "Ship's Computer", the main bottleneck would be taken care of, and the problem is not likely to appear in other places, at least not in the current screens in vanilla.

If you want to include something like the auxiliary DS in vanilla then I have a few suggestions to improve it:

1) When building the gHooks list, include both virtual items and regular items. This would allow a regular item to define the hook directly in its staticdata, without having to create a new virtual item just to hold the hook. So, something like:

Code: Select all

(setq gHooks (append
    (or (typFind "i +AuxiliarySystems") (list))
    (or (typFind "iV +AuxiliarySystems") (list))
))

2) Add a filter action to the DS. If you have tried one of the recent versions of G.O.D then you will know what I refer to. It is basically an action that switches pane to a textinput, allows the player to enter a string, and when pressing Enter, limits the displayed items to those with titles that match the search string and switches back to a normal pane. This greatly helps navigate longs lists of item rapidly.
If you like that concept, I could implement it for you, seeing as I have done it a couple of times before.

Well, that is all I can think of. I hope that this will make it's way into the next version. I think it is an exciting and novel addition :)