Action RPG Inventory System

[Neutronux]

[MENTION=42739]Neutronux[/MENTION] I said no becuase i miss read your qustion, and if you can move your character with the container UI open then there is a problem somewhere as this shouldn't happen.

Ok. Thanks. But my problem with that "if you can move character" is that the ServerCloseContainer is a Server event. As far my understanding of a Server event goes is that this is an event-type that's created for the client to get something done one the server ... with a "please".

Like:
Client: Please mighty server spawn me a projectile.
Server: Ok you got enough ammo ... or no way you are out of ammo bad client.

Client: Please mighty server open me that container.
Server: Ok you are close enough ... or no way you are too far away bad client.

So far it's implemented in the Action RPG... at least regarding the container.

However I'm in doubt that the Server even is even created for the other way around that sets the server in the position to ask with some please.
Server: But please tell me when I have to despawn that projectile. Ok?
Server: And please even tell me when I have to close that container if you move.
Client: Smiles. I swear by the flowerpot of my grandma that I would tell you if it's the time for you todo so.

You could follow me? I don't think that the close event could work that way if it's a Server event ... ever. So there is nothing that prevents the client to use the Container if he chooses to cheat and just says: Shame on you server if you don't know yourself where I am if I tinker with your container then you deserve it that I still loot it from somewhere else.


Edit: Or in other words. Its the job of the client to call a server event and the job of the server to do something or reject something in the response to the request (triggered on the client) afterwards. But as far my understanding of the eventype Server goes is that it's not the job of the Server to tell the client if he should call this or not (or if this is ever verified if its a event-type that's created for the Clients wishes). Its like the server could tell me if I have to push a mouse button for a further projectile... just not manually via mouse but in hope the code in the client is unmodified (and a ServerCloseContainer comes because the Client sends it). The event that protects the container should not be an eventtype thats created to be triggered from the client but that's called from the server no matter what (if the client ever sends something to the server or not). The event might stay but only for cosmetic stuff ... like: Hey server let me know when I should close that window ... as you would refuse to let me do something with it any longer. The point is... the server does not refuses it ... if the client don't brings him to that idea. At least as far my understanding of that used Eventtype goes.

[OverRated_AU]

[MENTION=42739]Neutronux[/MENTION] Yes that is correct there is nothing preventing a client from moving away from the container once its open, the inventory reference to the container has already been set, so ether add that extra node to check or force close it if the client moves away.

[Pirate]

[MENTION=42739]Neutronux[/MENTION] Yes that is correct there is nothing preventing a client from moving away from the container once its open, the inventory reference to the container has already been set, so ether add that extra node to check or force close it if the client moves away.

[MENTION=42739]Neutronux[/MENTION]
A server only solution would just be to move the close container call away from being input based and have a check run on the server to see if the characters position has changed(or velocity, etc) and if there is a valid container reference then call the close container logic and set the container reference to null. Easy peasy.

The ARPGIS demo content is just showing how to use the modular Inventory System. Please feel free to make changes to the existing InventoryPlayerController as the controller just sets up the inventory system as has some basic extras in there. It was never meant to be a fully finished game template that requires no changes, it's purpose is just to demo one way to use the component based modular Inventory System.

[Furinyx]

To weigh in on [MENTION=42739]Neutronux[/MENTION] and [MENTION=190677]OverRated_AU[/MENTION] convo about security - typically in a multiplayer game you want to reduce as much info as possible being sent between Client and Server.
No checks need to be done on the Server side for what the Client is doing in terms of making sure Client-only things like UI close off or particle effects activate, etc. Leaving the Client to determine how it closes is fine and if someone hacks their Client to have weird UI behaviour then that isn't going to be a security issue.

The security issue comes in to play if the client is still getting updates of container changes (new items placed in there, etc) when it shouldn't be or if they can still drag items out of it and into their inventory and have it replicated to the Server. The way this is generally handled is by having the Server do a simple check on whether or not the interaction is still valid on the Server-side (whether it be based on character position or other parameters) and ensuring it does not send out container updates to character's that cannot interact with it.
Having the Client tell the Server when it has moved or having the Server actively checking this is unnecessary, the Server should act independently in this scenario and when it runs any logic for the container it determines who it is updating or whether an interaction is valid when one is requested by a Client.

In regards to Neutronux's valid query, he was wondering if there are possible security checks done somewhere else that isn't directly apparent. While he doesn't directly answer the question, the developer seems to imply that there isn't with saying that it was not designed as a solution but as an example; though, I'm not sure why it is stated having multiplayer-support when he is saying the multiplayer is actually implemented as a demo example (although likely the multiplayer-support just implies replication of inventory and nothing further, though that leaves it as an incomplete multiplayer system).

If you're developing a serious game that you don't want hackers to exploit and want more perspective on it - I'd advise scrapping any downloaded multiplayer logic and implementing your own, rather than relying on a Marketplace developer to make it hack-proof; especially as they can't always cover everyone's use-cases. It is best to save using implementations provided by others as a reference, rather than as a solution; however, a valid use-case would be for a prototype where flaws and design-oversights are not of any concern.

[OverRated_AU]

To weigh in on [MENTION=42739]Neutronux[/MENTION] and [MENTION=190677]OverRated_AU[/MENTION] convo about security - typically in a multiplayer game you want to reduce as much info as possible being sent between Client and Server.
No checks need to be done on the Server side for what the Client is doing in terms of making sure Client-only things like UI close off or particle effects activate, etc. Leaving the Client to determine how it closes is fine and if someone hacks their Client to have weird UI behaviour then that isn't going to be a security issue.

The security issue comes in to play if the client is still getting updates of container changes (new items placed in there, etc) when it shouldn't be or if they can still drag items out of it and into their inventory and have it replicated to the Server. The way this is generally handled is by having the Server do a simple check on whether or not the interaction is still valid on the Server-side (whether it be based on character position or other parameters) and ensuring it does not send out container updates to character's that cannot interact with it.
Having the Client tell the Server when it has moved or having the Server actively checking this is unnecessary, the Server should act independently in this scenario and when it runs any logic for the container it determines who it is updating or whether an interaction is valid when one is requested by a Client.

In regards to Neutronux's valid query, he was wondering if there are possible security checks done somewhere else that isn't directly apparent. While he doesn't directly answer the question, the developer seems to imply that there isn't with saying that it was not designed as a solution but as an example; though, I'm not sure why it is stated having multiplayer-support when he is saying the multiplayer is actually implemented as a demo example (although likely the multiplayer-support just implies replication of inventory and nothing further, though that leaves it as an incomplete multiplayer system).

If you're developing a serious game that you don't want hackers to exploit and want more perspective on it - I'd advise scrapping any downloaded multiplayer logic and implementing your own, rather than relying on a Marketplace developer to make it hack-proof; especially as they can't always cover everyone's use-cases. It is best to save using implementations provided by others as a reference, rather than as a solution; however, a valid use-case would be for a prototype where flaws and design-oversights are not of any concern.

Pirate the developer has always stated the UI is for demoing the inventory only, if people want to use this as a starting point there free to but it was never intended to be used out of the box, adding a server check on a server function isn't going to add anymore bandwidth all the server is doing is looking to see if the client is valid before using these functions, your statement is pointless and has no meaning, the client role is to call these server events and if these server event has no way of knowing if the client is valid to use them is just plan dumb which is what you pretty much just said.

[Neutronux]

Pirate the developer has always stated the UI is for demoing the inventory only

100% multiplayer support does not mean only replication... at least not for everybody. The setup for the player controller might be demo ... but all those Server do something with your container events are part of the framework and don't verify (as some other Server events do). So in my opinion they deserved a bit more love regarding cheat prevention. Anyway it is like it is... and I think it's not all bad. I still don't regret my purchase at all. However adding cheat prevention is a bit like using a non-threadsafe library in a multithreading environment. It's not always just that easy like to put a mutex on the top afterwards.

adding a server check on a server function isn't going to add anymore bandwidth all the server is doing is looking to see if the client is valid before using these functions

I think he don't means the server check but how the gui gets closed. As far I remember actually the clients sends the server that he should close the inventory and (only) then the server sends back the client that he should close the GUI. This "close GUI" could be a predicted client only implemention as well as the "may use container" should be a server only implemention. But I don't care that much regarding this one more event as it does not happen every frame.

[Pirate]

100% multiplayer supported means the inventory system was designed with optimizations for MP in mind and following good design patterns. I'm not really sure what the problem is on your end.

But saying it doesn't support multiplayer and it's bad is your opinion and I respect that. If you would like a refund let me know and contact epic.

There is a lot of inaccurate assumptions being made on this topic and unfortunately I'm at the airport and not able to call out and respond to every point.

When you send the client command to the server to close the inventory it invalidates the reference so the problem you seem to really have is with the server just telling the client it's finished processing the clients request then the client closes the UI.

If you want to trigger the client UI close first then call the server logic that's your choice. But going out of your way to say it's completely hackable because the UI closes last not first is simply untrue. The ARPGIS was also built with the assumption most people buying it aren't programmers or understand networking in bluepeints I made the choice to flow the logic in a way to help people understand sending commands and recieving a response from the server if the command is validated. This design is consistant in all of the ARPGIS and allows simply following the flow of logic making it easy to understand and practically self documents what is going on. This design choice does not add any real networking bandwidth overhead for the benefits of readability and understanding of logic gained.

[Neutronux]

But going out of your way to say it's completely hackable because the UI closes last not first is simply untrue.

I think you misunderstood that. Nobody said that. The gui does not matter regarding security. Its hackable if the server still allows the client to do things when he should not be able to do it anymore or depends on the client to make this decision. This is the case in the player controller of the demo that sends an event after movement (good) but a (ClientTo)Server event (bad). Anyway this was discussed already and you are right you could fix this via invalidating the container reference (triggered from the server - instead of the client as it's the case right now). I've fixed that already. So far I just gave an answer to the post of OverRated_AU as an answer to Furinyx... because I don't think his plans was dumb as he wrote.

flow of logic making it easy to understand and practically self documents what is going on.

Yes it looks clean. Thanks. This was even one reason why I choosed to continue without recreating it from scratch. Its easy to oversee some paths if you did not create something yourself regarding security.

[NeonNewt]

Hmm, for some reason I am able to add an item to my character's inventory but when I check for it, it isn't returning as there. I duplicated the Misc_Human_Skull item and customized its inventory item properties and then made it so that when I use a certain actor it will give the player that new item. I am able to see the item in my inventory, drop it, pick it back up, etc. Problem is that when I call CheckInventoryForItemAmount with the new item's ItemID and an amount of 1, HasItemAmount returns false. Any ideas?

[Pirate]

Hmm, for some reason I am able to add an item to my character's inventory but when I check for it, it isn't returning as there. I duplicated the Misc_Human_Skull item and customized its inventory item properties and then made it so that when I use a certain actor it will give the player that new item. I am able to see the item in my inventory, drop it, pick it back up, etc. Problem is that when I call CheckInventoryForItemAmount with the new item's ItemID and an amount of 1, HasItemAmount returns false. Any ideas?

is the check being done as the server or the client? It has to be done by the server. A good way to debug is with the print string node as it will output Server: first if the command is run on the server.

[Demonith]

I have problem when loot a body after that my camera not moves at all

[NeonNewt]

It is being run from the server so I am at a loss. Edit: It is able to see the inventory as I can get its size which returns 28. When I do a loop and print out the inventory's contents, one of the slots says it contains the correct item.

[DiziART]

if set parameter "Max loot items" == "Inventory size" - you see message error

[Pirate]

I have problem when loot a body after that my camera not moves at all

What version of the ARPGIS are you using? A bug introduced in Unreal made the hover states not reset when a widget is hidden.

Please check in your InventoryPlayerController that you have applied this workaround fix until epic resolves the bug.

[Pirate]

if set parameter "Max loot items" == "Inventory size" - you see message error
[ATTACH=CONFIG]129220[/ATTACH]
[ATTACH=CONFIG]129221[/ATTACH]

Yes as [MENTION=22077]Zeiten[/MENTION] says you need to make sure the loot list has enough items in the list to be less than or equal to your max items specified in the loot actor.