Inventory and generic interactions #1252
Conversation
flo
force-pushed
the
inventory-and-generic-interactions
branch
from
f893c0e to
2530aed
Compare
| public float interactionRange = 5f; | ||
| /** | ||
| * Specifies the current interaction target. It points for example to a standard chest when the player has opened it. |
There was a problem hiding this comment.
If a setter should be used, wouldn't it be better to make this a getter/setter pair backed by a private field? Or does that interfere with serialization?
|
The interaction target could move away too. E.g. when the chest is in a minecart. So if I don't do it in a loop I would have to do it at character and target movement. Since interactions are limited to characters there won't be that many interactions going on at the same time. So performance should not be an issue. So I went for this solution for simplicity. About the interactionTarget field being public: No component field I have seen so far uses a getter and setter. So I assume there is a reason for this practice. |
|
Cool stuff :-) This might also be of interest to @MarcinSc who did some inventory work in the past, and of course @immortius at an architectural level. I believe the public field is a thing, yeah. |
|
Bump - @immortius or @MarcinSc either of you out there with any thoughts on this? @flo - before merging this would you entertain an additional request from me? :-) This PR has a special request to properly use the new feature that'll get lost the moment this PR is closed, along with several other cool features added elsewhere over time but then not left obvious enough for anybody to find and use. We don't really have any serious docs or instructions on how to use inventory-bearing entities. Would you be up for expanding the javadoc and/or (preferably and!) enhancing the wiki page a bit? https://github.com/MovingBlocks/Terasology/wiki/Inventory There's also a separate page for a Chest - https://github.com/MovingBlocks/Terasology/wiki/Chest - but I think that should be deleted as too specific for the wiki. Long-term my design hope is to run one forum thread per major feature like this in either Core Projects (http://forum.terasology.org/forum/core-projects.54 - feel free to post an Inventory thread for doc/functionality discussion) or the Module forum and match that with a wiki page (or for modules a readme or whole wiki depending on its depth) |
|
I created a forum post. I might change the concept / pull request a bit based on the feedback. For a wiki entry it's to early I think. I don't even know if it will make it in. |
|
Fair enough - good idea :-) Linky for reference: http://forum.terasology.org/threads/inventory-and-generic-interactions-a-simple-way-to-hook-in-new-interaction-screens.1106/ |
The current interaction target of a character (e.g. a container) gets now stored within a new CharacterComponent field called interactionTarget. A new utility class CharacterUtil can be used to easly specify the current interaction target of a character. At the start of an interaction an InteractionStartEvent gets sent to the target entity (e.g. the container). Systems can listen to this event to open certain UI dialogs. As the event is sent to the target, it is possible to filter for interaction events of entities with certain components. This event replaces the old OpenInventoryEvent. At the end of an interaction an InteractionEndEvent gets sent. Systems can listen to this event to close certain UI dialogs.
Reasoning:
1. The field does not get used
2. The field didn't contain usefull values:
-> The list got only extended but never reduced.
3. Via the interactionTarget field of the character,
it is now also possible to check if a player is allowed to perform
an access.
Reasoning: Preperation to make the container screen configurable via a new InventoryUIComponent.
The new InteractionScreen component can be added to entities to make them open a custom dialog during interactions triggered by hotkey E. This new concept gets now also used for chests.
…sed. A module developer that usess the InteractionScreen component should not need to know about the need to update the interactionTarget field of the character. This patch makes will make automatically opened interaction screens, also automatically update the interactionTarget field when they get closed. For that purpose a new event is introduced called ScreenLayerClosedEvent which gets sent to the client component when a screen layer gets closed.
Reasoning: One of it's method has little to do with a charcter.
…eived. This commit contains also some minor other changes like javadoc and making InteractionEndEvent go to the owner only.
This change adds a ActivationRequestDenied event. The ActivationRequestDenied event is sent when the server determined that the activation done by the client is invalid. The ACtivationREquestDenied event is then used to trigger the interaction end, which will result in a closed interaction window.
…ible to modules. Reasoning: To allow modules to cancel the interaction when their special UI got closed.
flo
force-pushed
the
inventory-and-generic-interactions
branch
from
2530aed to
99c4922
Compare
|
There seems always more to fix and improve but I think I should stop at this point and wait till this pull request gets through. Afterwards I plan to prepare some pull requests for some modules that used the old AccessInventoryAction component. Tomorrow I plan to update the forum post to explain the events in this new pull request further. The main new thing is, that the interaction get now predicted on the client in a predictedInteractionTarget field. The authority validates the interaction and stores the current interaction in authorizedInteractionTarget. |
|
Okay so we put this PR back into the review cycle for merging soon'ish then :-) |
|
Tested this locally in my integration workspace with all stable modules. We need to fix the following modules to go along with this change:
@flo - could you review real quick and recommend what might be needed? If easy maybe we can throw matching PRs together and I can merge those at the same time :-) @Josharias - I guess Machines/Workstation do not fail but they work better? Cool! (re: forum) |
|
Okay, not sure what was wrong with my workspace last night, but I was clearly too sleepy to figure it out :-) Journal is fine as is some other stuff that looked weird. Rails is still broken, but I'm sure @small-jeeper can figure it out, will poke him separately and reference the forum thread Thanks @flo ! |
|
Thanks for merging @Cervator ! I checked the Rails module, but apparently the compilation issue got already fixed by @small-jeeper All modules which uses the AccessInventoryAction component, need the following adjustment: - "AccessInventoryAction": {},
+ "InteractionTarget": {},
+ "InteractionScreen": {
+ "screen": "engine:containerScreen"
+ },Otherwise the custom chests they added can't be used. I will prepare some pull requests. |
|
Wow apparently @Josharias did already update the WoodAndStone, Workstation and TerraTech I created a pull request for CopperAndBronze: Terasology-Archived/CopperAndBronze#2 |
This patch series makes it very easy to create new dialog based interactions with blocks. It also converts the existing chest access to the new system.
All interactions based on the new system will have the following features:
Modules that added new chests that use the old mechanism need to perform the following adjustment to their entities:
The InteractionTarget component triggers the sending if interaction events and the setting of the interaction fields.The InteractionScreen behavior will show the specified dialog when the user starts interacting with it. Without any further system implementation the interaction features listed above will apply: So it's possible to add new dialogs without implementing any event processing system!
It should also be possible to extends the workstation module so that it makes use of the new interaction system. That way all workstation based modules would get interaction powered dialogs.
For more details please have a look at the commit messages, which often have more than one line.
Noteworthy other changes: