Announcement

Collapse
No announcement yet.

Action RPG Inventory System

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    I tried setting the inventory_slot with doubleclick instead of 1-rightClick. However, it seems that DoubleClick (right) works fine, but Left is never triggered. I tried searching around but couldnt find anything. I made a copy of a clean project and tried removing some functions (MouseDown/Up, Drag, Move, etc, as someone said on previous previous preeevious posts) leaving only mousedowndoubleclick, but still the double right click would trigger, the double left click wouldnt. Any insights [MENTION=39476]Pirate[/MENTION] .

    Another question: is it possible to make the mesh targetable, instead of the target capsule? in the editor it works, but on dediserver it doesnt. im starting to think that maybe the engine doesnt support this, but ill keep looking though
    Last edited by Namesis; 02-02-2017, 11:37 PM.

    Comment


      Originally posted by Namesis View Post
      I tried setting the inventory_slot with doubleclick instead of 1-rightClick. However, it seems that DoubleClick (right) works fine, but Left is never triggered. I tried searching around but couldnt find anything. I made a copy of a clean project and tried removing some functions (MouseDown/Up, Drag, Move, etc, as someone said on previous previous preeevious posts) leaving only mousedowndoubleclick, but still the double right click would trigger, the double left click wouldnt. Any insights [MENTION=39476]Pirate[/MENTION] .

      Another question: is it possible to make the mesh targetable, instead of the target capsule? in the editor it works, but on dediserver it doesnt. im starting to think that maybe the engine doesnt support this, but ill keep looking though
      If you look in the Inventory Slot Widget you would just need the Left click action to do the same as the right click which is to call the USE ITEM logic from the IMC. Not sure what you are doing but it is just as straight forward as having the UMG logic bound the same. The Drag shouldn't be interfering with the Left click as the drag only starts if you are holding and dragging.

      I don't see why not, again I'm not changing how Unreal works in the Demo. You would just want to make the mesh have the collision properties needed for the trace to hit it and then remove those settings from the Capsule.
      \\VANGUARD INTERACTIVE

      Marketplace - Action RPG Inventory System | Multiplayer TopDown Kit | Advanced Social System
      Multiplayer TopDown Kit Tutorials - Merging The Action RPG Inventory System | Removing the Fog of War
      Action RPG Inventory Tutorials - Merging Into Your Project | Adding New Items | FPS Controls w/ UI Mode Toggle

      Comment


        Also everyone it looks like they fixed one of the bugs in Unreal 4.15.

        You can now set your Container/Inventory/Equipment widgets back to enable window drag by default.
        They fixed the UMG bug that was causing the Container window to break and stop working after being dragged.

        Go into each of the widgets and simply set the bool IsWindowLocked to false by default.
        \\VANGUARD INTERACTIVE

        Marketplace - Action RPG Inventory System | Multiplayer TopDown Kit | Advanced Social System
        Multiplayer TopDown Kit Tutorials - Merging The Action RPG Inventory System | Removing the Fog of War
        Action RPG Inventory Tutorials - Merging Into Your Project | Adding New Items | FPS Controls w/ UI Mode Toggle

        Comment


          Originally posted by Pirate View Post
          Also everyone it looks like they fixed one of the bugs in Unreal 4.15.

          You can now set your Container/Inventory/Equipment widgets back to enable window drag by default.
          They fixed the UMG bug that was causing the Container window to break and stop working after being dragged.

          Go into each of the widgets and simply set the bool IsWindowLocked to false by default.
          Hello
          What I did is:
          replace the Icon (image) for a Border. The Icon (image) wouldnt have the MouseButtonDoubleClick event (aka only allows MouseDown Events), yet the Border had :P, so replacing those "Palette" items did the trick. After that just replug the EventBinds (Mousedown, MouseUp, MouseMove, MouseDownDoubleClick), make sure the doubleclick was checking if was leftmouse, remove the bool of the RightMouseclickDown and make a new one for the double click and so on. It seems a better idea to keep it as a border I guess, since it has all the features image has and the mouseup/down/move/doubleclick events.

          I'll check again the mesh thingy.
          Last edited by Namesis; 02-03-2017, 04:13 PM.

          Comment


            Server_CloseContainer possibility to cheat? If you move then it's called (only) from the client on the server (which sets the CurrentContainer to 0 that's used later by the UseContainer events that run on authority). Shouldn't this be something that's called even from the server and run on the server to avoid a modified client just wipes this event and runs miles away and still got permission from the clueless server to loot the container from there (as the UseContainer is still valid on the Server if the bad Client did not tell the Server: Please close it for me)? Or did I oversee something here?

            Comment


              Originally posted by Neutronux View Post
              Server_CloseContainer possibility to cheat? If you move then it's called (only) from the client on the server (which sets the CurrentContainer to 0 that's used later by the UseContainer events that run on authority). Shouldn't this be something that's called even from the server and run on the server to avoid a modified client just wipes this event and runs miles away and still got permission from the clueless server to loot the container from there (as the UseContainer is still valid on the Server if the bad Client did not tell the Server: Please close it for me)? Or did I oversee something here?
              Yes you are correct but a client shouldn't be able to move away from the Container, from memory i added in a safeguard so if the client lost focus on the viewing container it would auto close it, if you really wanted to make this hack proof all you would need to do is to call the GetUsableActor and get its inventory component and compare it to ContainerInventory before allowing any interaction.

              Comment


                Originally posted by OverRated_AU View Post
                from memory i added in a safeguard so if the client lost focus on the viewing container it would auto close it
                Yep but even this unfocus is only called from the client. So both safeguards (move away or lost focus) are in clients hand.
                The only safety that really works is on OnActorUse where the server checks (once) itself via a linetrace if that actor is true or some dream of a hacked client. However the server never checks this again (for all those container use events). If it's open then it's open forever until the client is in the mood to tell the server he should close it.


                if you really wanted to make this hack proof
                I hope everybody would make this hack proof. Cheating sucks.


                all you would need to do is to call the GetUsableActor and get its inventory component and compare it to ContainerInventory before allowing any interaction.
                I think this have to be included into Server_UseContainerItem, Server_MoveContainerItem, Server_TakeContainerItem, Server_DepositContainerItem, Server_EquipFromContainer, Server_UnequipToContainer, Server_SplitContainerItem and Server_SplitItemFromContainer.

                Comment


                  Originally posted by Neutronux View Post
                  Yep but even this unfocus is only called from the client. So both safeguards (move away or lost focus) are in clients hand.
                  The only safety that really works is on OnActorUse where the server checks (once) itself via a linetrace if that actor is true or some dream of a hacked client. However the server never checks this again (for all those container use events). If it's open then it's open forever until the client is in the mood to tell the server he should close it.




                  I hope everybody would make this hack proof. Cheating sucks.




                  I think this have to be included into Server_UseContainerItem, Server_MoveContainerItem, Server_TakeContainerItem, Server_DepositContainerItem, Server_EquipFromContainer, Server_UnequipToContainer, Server_SplitContainerItem and Server_SplitItemFromContainer.
                  No just call the check before the function after the event, this inventory is only a framework so of course there will be some holes and features you will have to fill in on your own.
                  Last edited by OverRated_AU; 02-07-2017, 09:18 PM.

                  Comment


                    Originally posted by OverRated_AU View Post
                    No just call the check before the function after the event
                    Of course after the event. But all those names I wrote (Server_UseContainerItem, Server_MoveContainerItem, Server_TakeContainerItem, Server_DepositContainerItem, Server_EquipFromContainer, Server_UnequipToContainer, Server_SplitContainerItem and Server_SplitItemFromContainer) are exactly such events. So I'm not sure why you say no. I'm even not sure why you placed this in an inventory event (instead of the container events) as the character can never run away from it's controller that keeps the inventory component (that's modified by server events) but I think I have to take a look to the inventory events as well afterwards. Probably some "IsDeadAndWouldTinkerAtInventory" prevention?

                    Comment


                      Originally posted by Neutronux View Post
                      Of course after the event. But all those names I wrote (Server_UseContainerItem, Server_MoveContainerItem, Server_TakeContainerItem, Server_DepositContainerItem, Server_EquipFromContainer, Server_UnequipToContainer, Server_SplitContainerItem and Server_SplitItemFromContainer) are exactly such events. So I'm not sure why you say no. I'm even not sure why you placed this in an inventory event (instead of the container events) as the character can never run away from it's controller that keeps the inventory component (that's modified by server events) but I think I have to take a look to the inventory events as well afterwards. Probably some "IsDeadAndWouldTinkerAtInventory" prevention?

                      My inventory is setup similar to the ARPG inventory but its not the same asset, anyways my "UseInventoryItem" is used for all types of inventory's ranging from Containers to Sub-Inventory's which is why i have more variables on mine, and i was just giving you an example, there's more than one way to add extra security find the best way for your project!

                      Comment


                        Originally posted by OverRated_AU View Post
                        my "UseInventoryItem" is used for all types of inventory's ranging from Containers to Sub-Inventory's
                        Ok. But it's not the case for the ARPG inventory. Its ok if you give an example for something different... thanks. However if you take a look to that what I wrote then you should see that I suggested the same as you did... just at a place where it actually protects your containers in the original ARPG inventory. Placing that check with the same macro on the original ARPG at the event you posted in your screenshot would not protect your containers in the original ARPG inventory. So its a bit confusing if you say it have to be done different if you are talking about differnt things.


                        find the best way for your project!
                        Well I did and I still do... but you said it was wrong and you did not say why. We are talking of a marketplace framework. So we should talk about the same thing. We don't talk about extra security but basic security for multiplayer. I tend to replace those linetraces anyway as in my opinion this is great for FP but not optimal for TP but I would not suggest this as a solution for everybody who uses this framework. However... that said. You could create a framework cheat aware like you could create a framework threadsafe or not. Nobody said we would not add something ourself. Nobody expects a full game. Nobody wrotes that he gives up. But if you create something with multiplayer in mind such checks have to be implemented from scratch. Usually I'm not going to create my own events and come again later and think about some "Switch has authority" at a second run (where I have to rethink again what I thought last time when I created that function, event, actor, ...). At least I try to avoid that as much as possible. So I was asking if this was just a mistake of the creator or if it's expected and I oversee some further checks somewhere else probably. It seems there are some checks ... but called from the wrong side (client).
                        Last edited by Neutronux; 02-07-2017, 06:26 PM.

                        Comment


                          Just though I'd throw this up here for anyone who wants a quick reference to zooming by mouse wheel.

                          Click image for larger version

Name:	set zoom by mouse.PNG
Views:	1
Size:	198.9 KB
ID:	1122735

                          Comment


                            Originally posted by Neutronux View Post
                            Ok. But it's not the case for the ARPG inventory. Its ok if you give an example for something different... thanks. However if you take a look to that what I wrote then you should see that I suggested the same as you did... just at a place where it actually protects your containers in the original ARPG inventory. Placing that check with the same macro on the original ARPG at the event you posted in your screenshot would not protect your containers in the original ARPG inventory. So its a bit confusing if you say it have to be done different if you are talking about differnt things.

                            Well I did and I still do... but you said it was wrong and you did not say why. We are talking of a marketplace framework. So we should talk about the same thing. We don't talk about extra security but basic security for multiplayer. I tend to replace those linetraces anyway as in my opinion this is great for FP but not optimal for TP but I would not suggest this as a solution for everybody who uses this framework. However... that said. You could create a framework cheat aware like you could create a framework threadsafe or not. Nobody said we would not add something ourself. Nobody expects a full game. Nobody wrotes that he gives up. But if you create something with multiplayer in mind such checks have to be implemented from scratch. Usually I'm not going to create my own events and come again later and think about some "Switch has authority" at a second run (where I have to rethink again what I thought last time when I created that function, event, actor, ...). At least I try to avoid that as much as possible. So I was asking if this was just a mistake of the creator or if it's expected and I oversee some further checks somewhere else probably. It seems there are some checks ... but called from the wrong side (client).

                            What happen when a client is trying to move a item from there inventory to a container? what event is fired? asking me why i added it to UseInventoryItem when the answer is pretty clear? you also need to cover both ends not just moving items from a container i don't like your tone so ill leave it here good luck.

                            Ether way its not really easily hacked a client cant move away from the open container when the movement is handled on the server so your really overlooking the point.

                            Comment


                              Originally posted by OverRated_AU View Post
                              What happen when a client is trying to move a item from there inventory to a container? what event is fired?
                              If you do this via drag and drop then it's not the Server_UseInventoryItem so it's not that pretty clear at the first look. Fixing something after somebody else work is not that intuitive and clear as you might think. However I found out now that it is fired if you move via right-click instead. So there might be more surprises.


                              asking me why i added it to UseInventoryItem when the answer is pretty clear
                              The question was... why you said "no" as I wrote that this check have to be put to all those Server Container events. I don't expect an answer anymore.


                              you also need to cover both ends not just moving items from a container i don't like your tone so ill leave it here good luck.
                              I never said I would stop at that point. I asked why you said Server container events are the wrong place. It seems there is missing cheat protection on various places. So of course this have to be checked further.


                              Ether way its not really easily hacked a client cant move away from the open container when the movement is handled on the server so your really overlooking the point.
                              That was my main question. - Ok again... a open container does not tell the server to block its movement component. The client may move and the server is fine with that. The only reason why the container gets closed is because the Client tells the server that it should close (if it's a nice Client). If you put a "Switch Has Authority" before the "ServerCloseContainer" in the original inventory player controller before that check at the movement part then the event never gets called. And it's the same when you put it behind a "Is Local Controller" -> False?-> ServerCloseContainer branch. I'm not sure if it's that hard to cheat.

                              Comment


                                [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.

                                Comment

                                Working...
                                X