Thank you for sharing
Very interested in purchasing this, as a novice in unreal I’m wondering before purchasing on 2 things, 1) I’ve see that you hold right click to look around, how would you disable this (is it easily done) and 2) would you be looking into creating a shop system or would I require starting my learning in unreal earlier than I had planned?
Sorry for my noob-esk pre-purchase questions, you’re work looks amazing.
There is a tutorial video FPS Controls w/ UI Mode Toggle in my signature that will toggle the UI so your movement is more fps like normally.
I will not be adding a shop system to the Inventory System, but regardless you will be required to learn unreal as you can’t really make a game without learning :).
Plenty of people have easily created their own shop systems and there are a few on the marketplace. All assets on the marketplace will require some level of understanding of unreal if you want to start making changes and adding new features.
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 @Pirate .
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.
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.
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.
Hi, I just got this pack and am having issues integrating it with my project (little more than the stock third person template)
I’m following https://www.youtube.com/watch?v=lqSvFgz0G40 but hit a wall very quickly: when I migrate the Components folder over, open the components, and re-compile them, I get these four errors:
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.
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.
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!
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).
Just though I’d throw this up here for anyone who wants a quick reference to zooming by mouse wheel.
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.
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.
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.
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.
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.
@Neutronux 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”.
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.