Hey guys, i have been thinking of doing a major refractor of JcInventory for a while now to essentially move the JcInventoryCore and the InventoryItem to C++ (im not sure if the market place can support c++ and blueprint so i would need to research that). JcInventory came out before C++ was allowed on the market place, and as we know now C++ assets can be sold as plug in’s.
What this would mean is that** C++ projects would be compatible with JcInventory**. The reason i ask however is that i think there is a bias in the UE4 market for blueprint only projects, and i wanted to get your opinions on this. JcInventory would still work the same in blueprints (add items, remove items, use items would all be exposed etc) and the UMG elements would be done in blueprints as well- but if a user wanted to add something to the JcItemStruct for example they would need to make the changes in C++ and that may be too much for some users.
the other option would be to make another market place release having C++ version and keeping the two separate. But im not fond of the idea as providing support for two solutions would be a lot of work!
hmm… well I’m guessing that for your own ongoing project you’re using C++ and your inv system in it and would prefer to only maintain the one going forward (The one you use). Which makes sense. Personally I don’t care if updates stop for the blueprint version. Support as well at this point. I know BP well enough to figure it out on my own. Same goes for updating it for later versions of ue4. So my opinion is I don’t mind if the BP version stops, support and updates. That said, whether its calsses exposed to BP with nodes or all C++ many purchasers are going to struggle. It would be easier on you if they just didnt buy it. The users that know C++ or at least know how to read and modify the code would still buy. (which is maybe what you want in the end).
Having spent some time modifying the JSON pluging to add missing JSON features to my BPs I don’t mind this method. But for more complex things I’d consider it kind of a waste of time and if I had to do it over and this was already a c++ exclusive or hybrid, I’d go with a different BP system in that case. Trying to figure out how to make it so that when an item is added to back pack to check the quick bar and remove it from there if its a quick item, would be too much time to make it worth it for example. Unless you were planning on being around to supply code for requested features, I really don’t think JCInventory (or any inv systems ) are robust enough to function long term for any project out of the box. Which means adding features.
**TLDR: **personally I’m fine if you switch it. I won’t be adding any new updates that you provide to my version (which is still the first version I got) since its already very modified and I can maintain the updates to BP as needed. I wouldnt mind a C++ version as well though for future use. I’m assuming if it switches (and both products arent maintained) purchasers would already have access to it. The BP version if no longer updated may be removed from market though, not sure what the process is for that kinda thing. Either way, support for both versions would be a burden for sure.
**@thankstipscom **My project is already using a C++ implementation, and its working very nicely. I would love to share this with the community but im just not really sure how. Regardless, i would like to do a refractor (jcinventory 2, if you like), and if people want to stick with blueprints then im happy to do that. I actually started a poll and the results of that will govern my thinking to be sure. Im weighing up the pros and cons still. I would like to be able to roll up updates that could actually be applied (Blueprints make that very hard) for instance. You kind of hit the nail on the head with your post, i guess the biggest issue would be hurting existing projects and thats something that i would never be comfortable with. My main motivation is to make JcInventory easier to use then it currently is based off everything i have learnt from developing for the community.
A posted the change log above! You should be able to grab it from the market place. I will be online often to help with any questions of course! I will also be updating documentation over the next week so heads up!
I get lots of errors when i move the folder “JCInventory” into my project content sub folder. For instance everything is not compiled, and fails to compile because of various errors. When i follow your video i cannot add the class properly (doesn’t show the panel left side), because the component has an error, and is read only.
Fix: A fix for above issue is to copy the JC folder into the content root folder.
Odd, thanks for the Fix unit23, i will work with epic to fix it. I guess it means that migrate may have issues in UE 4.9.
**Edit: **I just tried this and was not able to replicate the issue. Just unreal being odd on your side i hope . Remember to right click JcInventory then migrate into your content folder of your project.
For everyone else a tutorial can be found (a bit out of date but the migrate process is documented )
I am not sure if this is your problem, but sadly you can not safely migrate assets with other structure folder than the original, because you probably will get lot of errors. You need first to migrate the content with the same folder structure, eg: Content/JcInventory/… and then you can move the folder inside your project. After that , you must have a carnal fight with redirects and “dirty empty” folders everywhere that you cant delete .
Okay, thanks guys for pointing this folder issue out. This extension seems to work well with 4.9.1 too btw, and setting up items seems straight forward so far, just created a town portal item. Though i wonder about customizing the look, will check this later.
@Staggerlee - The new version looks a breeze to set up.
I did test it just now and noticed my one annoyance is still present, the whole offset when picking up an item thing. I went through the various classes, but was unable to find exactly where it’s being picked up, in order to find the offset to add when dragging.
Any pointers? I imagine it would just be a matter of finding the mouse position relative to the upper left corner of the item widget, and then adding that back in when attaching the widget to the mouse for dragging.
**@n00854180t **The issue with that implementation is that the object falls where the cursor is. So the offset is actually an intentional design choice. I did have a look at it, and decided there was no clean way to do it (it could be done however).
With the offset the dragging icon mimics the location space of where it will drop. That’s the basic idea.
if you want to look yourself look at the **JCItemSlot **widget, there look at OnDragDetected() and have a look at Create drag and drop widget. there will be a Enum set to TopLeft, change it to mouse down and remove the vector2D offset.
The same must be done to the JcPlayerEquiptSlot.
**unit23 **A town portal? Sweet! Your going to like my up and coming diablo style tutorial i think
@Staggerlee - so that looks like it works okay for my purposes, and I see what you mean about it causing an issue with dropping - it seems like I’ll need to record the offset and then reintroduce it on drop to get the correct slot to drop into.
In any case, I should be able to figure something out with the pointers you’ve given Thanks!
Edit: I think I’ve figured out what I need to do to make it work properly, but one thing I’m having trouble finding is a way to get the screen position of the item (top left) on MouseDown. If I can get that I can subtract the mouse screen position for an offset to use to figure out the appropriate grid index to drop onto.
Thanks for this fantastic inventory system. You have saved us a a ton of development time. Keep up the awesome work!
We’re utilizing this in our burglary sim, Klepto [recently greenlit on Steam]. Since our project contains VR support for Oculus and HTC Vive, we had to move the UI from screen to world. We’ve decided to place it within a mobile device carried by the player.
We’ve also incorporated a 3D item view (sorry, only have an older gif from the prototype).
Now I’m working on adding gamepad support. This was initially a bit overwhelming of a task but thanks to all the info included with each item slot, the integration is coming along nicely. So far, I’ve managed to get a good chunk of this completed. I should have the full support finished up by the end of the week.
Afterwards, I’ll finish up the 3D item viewer and get our finalized UI artwork added.
Whenever I try to compile the 4.9 version I get these 2 errors
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd: [2015.09.21-08.55.40:332] 0]LogInit:Display: LogBlueprint:Error: [compiler JCPlayerInventory] Error COMPILER ERROR: failed building connection with 'Only exactly matching structures are considered compatible.' at Pawn Equip Slot Change
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd: Using Interface JcPawnInterface_C
MainFrameActions: Packaging (Windows (64-bit)): UE4Editor-Cmd: [2015.09.21-08.55.40:332] 0]LogInit:Display: LogBlueprint:Error: [compiler JCBackPackItem] Error Invalid pin connection from ' Out Actors ' to ' Target Array '. You may have changed the type after the connections were made.
Confirmed bug with the 4.9 release, thanks Abxyxx. The fix is a odd one,
open JcBackPackItem and look at the event CreateOrFindBackpackContainer, remove the for each loop, then replace it with a new one doing the exact same thing.
open jcinventorycore, open function add item to slot, within the first comment ‘add item’ remove the make struct then add it back in again the same way.
remove slot details from JcPawnInterface > PawnEquipSlotChange, its there as a convenience anyway. use the index value to get the slot details. Why its an issue im afraid you will have to take up with epic.
¯_(ツ)_/¯
After i did this i had the market place version build, going to push out a update. let me know how you go!
NobleSpoon wow that looks really nice in 3D, well done! really honored to have helped you on your project and look forward to buying it and playing it!
Hi Staggerlee, weird , yesterday I implemented the 4.9 version on my 4.9.1 project version and I did’t have this compilation problem. should I have it? (sounds like I’m worried because i have not compile errors )
@Staggerlee - Found a simple way to get rid of the mouse offset problem, without drastically changing the system I’m going to clean it up and post screenshots in a bit so everyone can benefit.
I must say it improves the drag and drop feel quite a bit
How to fix mouse-offset in JC Inventory (4.9 is the only tested version):
1st:
Add a Vector2D variable called MouseDownOffset to JCInventoryCore.
In JCItemSlot -> OnDragDetected, find “Create Drag Drop Operation” and change the pivot to “Mouse Down” and break the connection to the “Make Vector 2D” node that goes to the Offset variable, like this.
And that’s it! Let me know if you have problems with it, but it’s quite straight forward.
Edit: @Staggerlee - Dunno if it’s really as clean as it could be what with having to store the offset in JCInventoryCore, but it works fine. My vote is to put this into your main, as it does feel much better/provide the user with a cleaner drag and drop experience.