Zweshi

Thank you very much! Sure i'd be up for that, just let me know what is needed from my side Not awkward at all, software without a license is some bone chilling stuff :D You are correct that the package is meant to have a MIT license(will add this explicitly as soon as time allows, not sure how i missed it in the first place), the exception being the art/sound files which are CC0(these CC0 files have LICENSE.txt files in the directory structure pointing them out). Sounds like a fun project, best of luck! Let me know if the inventory system gives you any trouble and i will see what i can do to help. This tends to be my opinion as well, having worked with a lot of stock 3D modelling i have found that having more quality at the expense of performance is rarely a bad thing given that the ability to down scale is as accessible as it is. Thank you, happy to share!

@TRON Thank you, happy to share it! @Duion Thank you, Happy to hear you were on the hunt for something like this! Install is a tricky beast to get situated, the reasoning behind having to add exec lines is to not overwrite the standard init files as that becomes a liability for compatibility down the line if they are ever changed either with a new Torque release or by the end user. The keys i hear you on, i decided to use the keys i find to be the most logical for the operations rather then what was unbound by default, i do think i made the right call but i can see it being argued both ways. I definitely understand your point of view but i do think there is value to over engineer 3D assets in the context of a resource. A bit of extra quality provides a more impressive visual to a window shopper and clarity in node setups/rendering setups/source files provides example opportunities for the end user to emulate. Since at the end of the day the items are of a example nature it isn't all too important that they would function well and be space efficient in a full production environment. I have gone back and forth a lot over the years on which style i like the most out of these two types of inventory and they both have significant merits to them, but for this resource my intention is to stick with the style of "one item, one slot". Thank you for the feedback Duion, always happy to hear it! @XIXWYRMEXIX You're very welcome, Happy to hear i could save you some inventory dev time! :D

< Reserved >

Hello everyone, Isn't it high time that Torque3D had a easy to use, easy to maintain, and easy to expand upon inventory system? I think so too! And in that spirit here is a MMORPG style server to client inventory resource written in TorqueScript for stock Torque3D 3.10.1... probably works on any version of Torque but 3.10.1 is where it's been tested. Video showing off inventory functionality: llPf0IQMmDw Current Version: 1.0.0a Download: https://www.dropbox.com/s/p4x4e8qvwf9e4q5/MMO_Inventory.zip?dl=0 Installation: Instructions are found in the downloaded folder's base directory License: Code: MIT | Art/Sound files: CC0 General Notes: Networked with a "never trust the client" mindset Standardized images/bitmap arrays Standardized data variables for all the things Standardized "helper" functionality Using a flat database system Using object namespaces to reduce redundancies Written in just TorqueScript No .gui files, the gui elements are built to a targeted gui(standard is set to PlayGui) Data driven gui approach with full customization Plenty of example objects System Features: Base inventory Inventory Menu Currency panel Notify panel Examine panel Sound suite Select object behavior Network Optimizations: Full inventory data is only sent when player opens their inventory for the first time Split/drop/Move/pickup functions only send data for the affected slots client verifies data before a request is made reducing redundant server calls server is only called if/when actions are taken not for redundant tasks such as open/close states Inventory Item Types: Currency Stackable items Non-stackable items Equipable items Food items Inventory Item Functions(Menu System): Split stack Pickup item Move item Examine item Drop item A Word On Adding Content: One thing I've learnt over the years is that efficiency on the data layer is useless if it means the content layer suffers(learnt that the hard way), so with that in mind content additions are handles exclusively within a scope that a artist without code/scripting skills can master. A item addition requires a shape(.dae) used for world placement, a 2D inventory image(.png) of the item, and a datablock akin to a simple non-interactive spreadsheet. That is it, you do not need to even touch the codebase of the inventory system to fully interact with the content layer. A Word On System Customization: One of my biggest pet peeves is when developers build cool systems as external resources(for any engine or data system) that are very specifically engineered to do one thing very well but if you want to modify them at all you might as well re-engineer the worlds power grid first as that would probably be simpler. With that in mind i wrote this resource to be adaptable through the dankest of data driven approaches, for example: Want the inventory on the left side instead? No problem just change $InvBase_PnlPos and your done, more inventory slots and rows? Just change $Inv_Rows, $Inv_NumBtns and $Inv_InventoryMaxSize and your good to go. It's easy to change things and it should be easy. A Word On Data Management: You will notice that this resource uses a flat database as opposed to a more sophisticated separate database system for data handling. As i started this project i contemplated writing a database system to go with it and get some inter-server goodness going right of the bat for that sweet sweet efficiency. But limited time along with the fact that i was not gonna use the system myself made me lean towards a simpler solution, after all if you need a sophisticated database for your game then you probably already have a preference for a existing system. A Word On Client Login: This inventory system does not sport a client login system, instead it simply uses the client player name to connect the player to the server side inventory, this is what we in the industry call a complete lack of security bordering the absurd. This is by design though as i wanted to avoid writing a login system as at that point this resource would land in the security sphere which i'm not really comfortable with for a public resource like this. So keep this in mind for your multiplayer projects, you need to connect your login system to the inventory where appropriate. Feedback: If you decide to use this system for your project(s) and find some gaping flaw that i, in my infinite wisdom of course, overlooked completely i would very much appreciate if you would report back so i can break out the ol' shovel and get back in the trench to fix it. Lastly if you have any questions feel free to reach out to me either in this thread, on discord, or twitter and i will do my best to help you out. Twitter: Zweshi Discord: Zweshi#0840 All the best and happy inventorying! - Jonas