Tweaking Worldly Tooltip

[Josharias]

Name: Worldly Tooltip
Summary: Shows players what they are looking at
Current Goal: Fix layout to deal with multiple lines of extra data
Curator: Josharias
Location: https://github.com/Terasology/WorldlyTooltip
Compatibility: Singleplayer, Multiplayer
Screenshots:

Ideas:

• Surface entity information into the tooltip. Things like: how full is the chest, is the furnace almost done, how much health is left...
• Enhance the tool tips with graphics, e.g., show the icon for items, texture for blocks. Maybe even interface elements can be displayed (thermometer for furnaces, progress indicators, ...)
• Tool tips integrate closely in the 3D environment. Instead of showing them at a fixed position on screen they could be floating in the world - similar to overhead player tags.
• A key to trigger the visibility and/or settings to configure the tool tips. With a key stroke the user can choose whether s/he wants to see (a) no tool tips, (b) tool tips only after a delay of 1s, or (c) always and direct tool tips. The settings could include the configuration of tool tip range (e.g. for objects within 10 blocks) and objects (e.g. only usable items).
• Highlighting of the entity the player is looking at. This may become useful when multi-block structures should be inspected.

Any more ideas?

2014-09-30 update idea list

 

[Skaldarnar]

A great and really helpful feature.

Since you are asking boldly for other ideas and suggestions I will name some that come to my mind.

• Enhance the tool tips with graphics, e.g., show the icon for items, texture for blocks. Maybe even interface elements can be displayed (thermometer for furnaces, progress indicators, ...)
  
• I would like to see the tool tips integrate closely in the 3D environment. Instead of showing them at a fixed position on screen they could be floating in the world - similar to overhead player tags.
  
• A key to trigger the visibility and/or settings to configure the tool tips. With a key stroke the user can choose whether s/he wants to see (a) no tool tips, (b) tool tips only after a delay of 1s, or (c) always and direct tool tips. The settings could include the configuration of tool tip range (e.g. for objects within 10 blocks) and objects (e.g. only usable items).
  
• Closely related to the point above (and also optional): highlighting of the entity the player is looking at. This may become useful when multi-block structures should be inspected.

This is obviously a set of random thoughts on this topic, but maybe one or another are useful or inspiring

 

[shartte]

Have you had a look at the MC mod "WAILA" and what it provides? I think it has some additional UI integrations and separates the block Name from the name of the Mod it comes from, for example.

 

[Josharias]

WAILA was definitely the inspiration for this. It was just so useful.

 

[Marcin Sciesinski]

Any idea how this module will be integrated with the said blocks? Is it going to fire an event at the entity player is looking at?

 

[Mike Kienenberger]

Any idea how this module will be integrated with the said blocks? Is it going to fire an event at the entity player is looking at?

Would it be better to simply define a tooltip component with the text? That seems more appropriate than firing an event.

 

[Marcin Sciesinski]

This would require a lot of updates to the component, for example imagine a block that does some work over time and you'd like to visualize a progress 1%...2%... etc. You'd have to set the component after each progress, and it would have to be done for each block in the game that does that, which might be too expensive. Maybe instead the tooltip could fire an event at the entity and entity would calculate it's text/progress as needed.

 

[Mike Kienenberger]

Setting a variable is trivially cheap, looking up the component is also inexpensive, and almost all of the entities in the game would have either no tooltip or static tooltips, with dynamic tooltips being the exception. In comparison to the actual work being performed which is tracked by the tooltip, I doubt that the tooltip variable update is significant.

On the other hand, firing events is expensive.

 

[Marcin Sciesinski]

The thing is, that the entities will be (most likely) updated by the server and sent over the network to clients that "observe" the chunks these entities are in.

If you say that firing events is expensive, then please keep in mind that for each entity update there is at least one event fired. So, firing an event for getting the tooltip contents would probably be cheaper, also - this could be done by the client, as long as it has all the information it needs to generate the tooltip info.

 

[Mike Kienenberger]

The thing is, that the entities will be (most likely) updated by the server and sent over the network to clients that "observe" the chunks these entities are in.

If you say that firing events is expensive, then please keep in mind that for each entity update there is at least one event fired. So, firing an event for getting the tooltip contents would probably be cheaper, also - this could be done by the client, as long as it has all the information it needs to generate the tooltip info.

Are you certain you could compute a tooltip without using the same number of events? I would think you have one event to request the tooltip value, and then a return trip to get the result. And are you certain that it would be cheaper to continually send a single "get-tooltip" event versus sending only the changes when a dynamic tooltip value changes?

If tooltips are states, you are not going to update the tooltip more than once per "step" at most, and if you do, you're not going to need to broadcast the change more than once per "step" at most. Multiply that times the number of dynamic tooltip-changing systems.

If tooltips are events, you must broadcast one "get tooltip" event every "step."

I suspect that you might be overestimate how often dynamic tooltips would need to be changed. However, you definitely have more experience than I do in this area due to your module work. What would you estimate as the number of times the total number of progress tooltips for your modules would need to be updated per step (or per 100-steps or some larger increment)? Let's assume that we have optimized the engine so that we do not send values which haven't changed. That is, if the progress was 9% and it's set again to 9%, we don't perform any expensive operation.

 

[Marcin Sciesinski]

If the tooltip is calculated on the client, it should not be a big burden, after all that's how the UI is currently done, it is re-created on each frame. I don't think it's particularly large problem to do the same thing for the tooltip. The event approach saves processing on the server (very precious) and network updates required.

You could probably go for a hybrid approach. If an entity has a specific component, say "FixedTooltipComponent" than just use it, if it does not, but has "DynamicTooltipComponent" then send an event to it.

 

[Josharias]

I think you both might be right about this. We should avoid implementing systems that require frequent component updates from server to client. Also, we should implement systems that allow extension.

Using client side events we can allow extension by executing external code to resolve UI content. It would then be up to the external code to play nice and do something that does not require server updates.

The tooltip module could provide a basic component (FixedTooltipComponent) that can be added to entities to provide an easy way for a developer to get their foot in the tooltip door. However, it would still be up to the developer to play nice in the sandbox.

 

[Florian]

There are two developments in a similar direction going on currently too:

Gimpanse and myself started independently on working on a "player tags" feature. Gimpanse took the approach of placing standard UI components at a 2D position in such a way, that they appear to be at the correct 3d location. A screenshot of what Gimpanse made: http://i.imgur.com/JhysGAD.png and the current work in progress code he posted for me on IRC: http://pastebin.com/2XEMPsF9

I was thinking more in the direction of adding a text billboard component called "FloatingTextComponent". The latter component specifies a text whcih gets rendered at the location of the entity (if it has a location). This floating text component can than not just only be used to render name tags of players, but could also be used to render upwards floating damage values or names of NPCs and animals

In addition to that component, the plan is to also introduce a NameTagOwnerComponent class. A entity with that component gets automatically a floating text assigned which shows it's DisplayNameComponent value above the head.

I put my current code on an experimental branch in case someone wants to have an early look on it:
https://github.com/flo/Terasology/commits/experimental-name-tags

It's far from perfect, but the most important things work already. Here is a screenshot of item picup entities with a DisplayName and NameTagOwner component.

As they pickup items can rotate, the texts don't end up always on top. The texts don't get centered yet either too.

@Josharias: About component updates: I am not an expert in that region, but I would guess that only component fields with @Replicate get transfered over the network. There is also a ReplicationCheck interface which components can implement.

About the idea of world toolips: I think it's cool. I hope I have more time tomorrow for a more complete reply.

 

[Josharias]

It turns out, the item tooltip architecture could be reused easily for the block tooltips. The WorldlyTooltip fires a GetItemTooltip event that allows addition of tooltip lines. Adding health to the tooltip was a matter of adding this:

    @ReceiveEvent
    public void getDurabilityItemTooltip(GetItemTooltip event, EntityRef entity, HealthComponent healthComponent) {
        event.getTooltipLines().add(new TooltipLine("Health: " + healthComponent.currentHealth + "/" + healthComponent.maxHealth));
    }

I have added block rendering and extra tooltip data to this module.

Also, now using [alt] will toggle between block url and display name.

 

[msteiger]

What kept you guys from finishing it? Can you give a quick summary on what's done and what's still to do? That would be quite helpful ..

 

[Josharias]

Presently, there is a HUD ui element that can display additional information about a block entity that is currently being targeted. One can extend the information using the same mechanism as the inventory item tooltips.

This seemed to satisfy my initial urge of assisting with basic diagnostics and to help clarity in videos to help understand what I was pointing at.

 

[msteiger]

I'm sorry, the question was ambiguous - I meant the experimental-name-tags branch that @Florian brought up. It could be useful for players, NPC, towns and quests (rotating questionmark icons above trigger elements). While the in-game tooltips are surely useful, the floating 3D text seems to be a better fit for those things, I think.