Inventory Pro - uGUI - Performance - Mobile support & More

Are you deleting any objects at run-time? This error is only caused when a destroyed object is accessed.

 

Hi,jorisshh.
I removed the item in Itemdatabase that was registered once.
When an item in the Itemdatabase is deleted even once, InventroPro has an error.

 

Hm.. the error you send me is a run-time error from the characterUI it doesn't really have anything to do with the item editor. Deleting items in the editor is perfectly fine?

Did you add custom scripts that affect the characterUI's categories in any way?

 

How can I tell what version of Inventory Pro I have imported in my game? I cannot remember when I last updated it.

 

A little hard to tell, but I always advise you to update to the latest version. Updates are much less painful then before (no more aggressive refactoring)

 

Then I have a request. I posted it several weeks ago as suggested feedback here. If others agree, it could use some upvotes.

 

Hi,jorisshh.
I tried to make the Itemdatabase again.
Then InventoryPro is no longer issued an error.
I thought that the item deleted is cause.
I did not change the other part.

 

Hehe just found out my old game is still living somewhere in the dark corners of the web

Helios - A Greek story based RPG game (my first attempt of a game)

http://forum.unity3d.com/threads/helios-alpha-0-14-download.175797/#post-2381732

(It was a failed attempt... )

 

Hi Jorisshh,

First let me say it is exciting to see an active game asset developer who knows what we need and keeps making their product better. Bravo!

I see a shirt (sprite?) in your demo that I dragged onto the shirt slot in the paper doll window. It's kinda hard to see with the character and shirt untextured, but did you apply (skin) the shirt mesh to the character? Right now I use ORK Framework to skin on the clothes during the game. (ORK is a mature RPG system, and I think an integration between ORK and IP would be logical and worth consideration). If I use IP to manage my inventory, I would very much want to be able to use it to skin clothes on the character by dragging clothes sprites onto the paper doll slots in the character window.

Also, would you consider an integration with cInput, which is a mature input solution that includes a handy GUI for players to remap keys real time in the game. Basically, all IP would need to do is let cInput open your windows.

 

If you open the Unity package in a hex editor you can see which version of the package you last downloaded:

"link":{"id":"15277","type":"content"},"unity_version":"5.1.0f3","pubdate":"12 Sep 2015","version":"1.5.3",

Here's how you can find where Unity places the Asset Store download:

http://forum.unity3d.com/threads/asset-store-download-folder.83620/

 

Thanks for the info, but that is kind of the problem. I have several projects that have your asset in it. I may "update" the "download" to the latest version, but that still doesn't tell me what version I have in each project. It may be days or weeks until I open a project and I don't know what version has been imported. So, my suggestion would allow the Unity IDE to report which version is imported into the currently open project. It makes it even more difficult for me when I have a Windows box at home, a Mac at home, a Windows box at work, and a Mac at work. I may have updated the latest download on a machine, but last worked on another machine without the latest download. And this may be on a project that has over a dozen assets imported. It becomes impossible to handle manually. It is nothing specific to your asset(s), but a problem across the board. That's why I would like the Asset Store to implement a common solution.

P.S. The more I work with Behavior Designer, the more I like it.

 

Ah, I see what you mean now. Yeah, there's no standard way to see which version on an already imported asset. With our assets I add the version number to the Start Window - maybe @jorisshh could do something similar with the Inventory Pro Main Editor window.

Great to hear

 

Well, it's not a unity-wide solution, but I've been meaning to make this, might as well add the Inventory Pro version

 

Looks lovely! Any game that is completed is not a failure. At least that is my motto.

 

* Cough -- Cough * I'll just leave this here; First test of Sci-fi UI in Unity

 

good afternoon . I noticed that the only weapons UFPS multieplayer synchronized. If you create other objects (resources , etc.) , when one player raises them at the other , they do not disappear . as there is no synchronization when a player throws objects . (Unusable, Consumble .....) Fix it yourself.

 

Hey Joris,

I was following along w/ the video tutorial 3 (added character window and such) and something very....strange happened.

My "player" (third person controller with slightly modified code) started hovering (or in other words is stuck in the air in the jumping animation) and the console is giving me the following null reference error:


NullReferenceException: (null)
UnityEditor.SerializedObject..ctor (UnityEngine.Object[] objs) (at C:/buildslave/unity/build/artifacts/generated/common/editor/SerializedPropertyBindings.gen.cs:72)
UnityEditor.Editor.GetSerializedObjectInternal () (at C:/buildslave/unity/build/artifacts/generated/common/editor/EditorBindings.gen.cs:151)
UnityEditor.Editor.get_serializedObject () (at C:/buildslave/unity/build/artifacts/generated/common/editor/EditorBindings.gen.cs:144)
Devdog.InventorySystem.Editors.InventoryEditorBase.OnEnable () (at Assets/InventorySystem/Scripts/Other/Editor/InventoryEditorBase.cs:18)
Devdog.InventorySystem.Editors.InventoryItemBaseEditor.OnEnable () (at Assets/InventorySystem/Scripts/Items/Editor/InventoryItemBaseEditor.cs:44)

The line of code it brought me to was
script = serializedObject.FindProperty("m_Script");
inside InventoryItemBaseEditor. I'm guessing it's unable to find that script, but unsure of why or where it should be located. I'm running 2.3 if that helps.

I'm not sure if the two are related (the null error somehow causing gravity to seemingly fail) but need some help eliminating this error so I can at the very least rule it out. Thanks much for any help you can provide.


***Edit*** Lookos like Inventory Player Range Helper is what's causing the floating character somehow. If I remove the component it works fine, but with it added I get mayhem. Something to do with raycasting?

***Further Edit***
I see what I did there, the floating character was caused by 2 Player Inventory Range Helpers having made its way onto my player prefab. I earlier tried hitting "fix" to autogenerate them, but it was putting the _Col object under the main hierarchy, so I nixed 'em and did it manually. One of them apparently stuck and I didn't notice >.<

**Final Edit**
Updated to 2.3 (downloaded it a while back but forgot to import...Unity also likes to crash during that process I found out >.<). Redid stuff from scratch (Unity crashing wiped everything out) and no error this time, so yay.

 

Nice, glad you fixed it . For future references, UnityEditor.SerializedObject is actually an editor bug, and can be fixed by restarting your Unity editor. Also, when running into some weird moments try the setup wizard, it gives useful information about faulty setups as well

 

Neon green, anyone ?

 

yes, I like the neon colors as I typically do a greyish or brownish background when menus popup. This would also look nice on black. But it would be hard to manage with a cartoonish background.

 

Well, the colors are fully customizable in the Unity editor, so you can give it any color you like. Even at run-time . I may add a window to allow the user to choose the UI window

 

Here's a more architectural/integration(usage?) question for you Joris,

For our combat/weapon system we're going to have ~12 weapon types, and depending on what's equipped the whole fighting style changes (very similar to Rune Factory, since our game is inspired by that/harvest moon series).

1) Me being the "classical" programmer, prior to purchasing Inventory Pro had a class hierarchy of something like CommonItem -> Weapon -> WeaponType. I've noticed with IP we don't really need to define classes like this (since equipment type can technically be used), however the programmer in me is still leaning towards classing it out (and going EquippibleInventoryItem -> Weapon -> WeaponType). While I know this can easily be done, is it advisable to do so? (Guess what I'm asking is what are the pros/cons to using just base IP vs custom classing it up).

The above may tie in with the following smaller questions (well more verification of assumptions, since I didn't find these answers elsewhere) concerning properties/stats.

2) Properties would be created for each stat/attribute that equipment/items can modify (health, attack power, defense, etc) and how much they increase said stat is set when creating the item. These need to be synced with whatever actor has the items equipped (since that actor will likely have their own values). If I understand, these are mostly for display purposes (but serve a dual purpose in holding the actual stat value for the equipment). Is that a correct understanding?

3) If so, are the base/max values when defining a property used for anything other than Player Character UI reporting (since different actors would have different values)? It would seem like I would want to start them all out at 0/0 and let code manage them. Or am I way off on the purpose of the base/max value?

4) Equipment stats seem to be just a way to automatically sum up a value across all pieces of equipment equipped (as mentioned during your videos). I noticed they have rarity and other things by default, so is there more to it than just summing up and showing stats, or is that the sole purpose of equipment stats?

Thanks much Joris. So far I'm very impressed with Inventory Pro and its capabilities!

 

I noticed that the only weapons UFPS multieplayer synchronized. If you create other objects (resources , etc.) , when one player raises them at the other , they do not disappear . as there is no synchronization when a player throws objects . (Unusable, Consumble .....) Fix it yourself.

 

Geez doesn't kill to have a little courtesy.

 

If you're a hardcore programmer, yeah I think so. For ease of use the Equippable item is a general purpose item that can be used for 'almost' anything. If however you like to add custom behavior (which you of course can), I'd say go for it , class it all out. (It would of course give the most freedom, plus in the last version you can easily change item types in the editor, so it won't really degrade the ease of use).

Each property can be converted to a stat when the setting 'Use in stats' is enabled on the property. These are then set on all players by default (using data providers, which grab the initial values for the stats; Let me know if you want to know more about this).

The stats currently don't really affect the player in any way, as this is different for every game. So essentially they are ready to be used by other developers. ( http://devdog.nl/documentation/changing-stats/ and http://devdog.nl/documentation/using-character-stats/ and

may be of use here ).

If you want to have each player start with a specific value set you can either create a custom data provider (kind of the hard way), or you could simply create a new script that initializes the stats on Start(). (Data providers aren't really documented, as they're really low level. However they are replaceable / addable, ( Default providers are in Modules/CharacterEquipment/StatDataProviders )).

Yep you're quite right, all players are initialized with the same starting values for a stat. As described above, an easy way is to start at 0/0 and handle it in your own code from there (Events can be used for callbacks to sync values if necessary)

[/QUOTE]
Right now stats are only summed up. Previously I had an extra component to handle the process of how stats should be 'summed' up / handled. However I removed this, as it made it unnecessarily complex. Right now stats are added through the InventoryItemUtility... which is a bit odd. I'll likely refactor this into the EquippableItemType, this way it can be overridden if necessary and wouldn't add any extra complexity.

 

Thanks for the quick reply.

As a quick reference, there's only 1 player character in our game, however NPCs and some mobs can equip items as well. PC and NPC/Monster stats will be different (NPCs should most of the time be less powerful than the player at equal levels, mobs varying depending on mob type and level).

Also below I marked stats with (game) to denote that they our our concept of character stats and not the Inventory Pro concept for stats (different domains, same word).

It sounds like there's two approaches I can take (are these accurate?);

1) Allow Inventory Pro to be the holder (or record of origin/ROO) of (game)stats and attributes (via properties) for all characters. NPCs will all have their own inventories, and mobs most likely will as well, though I may subclass this so mobs that don't equip things can be lighter objects. NPCs will have a UI for viewing their stats in info screen (though this will probably end up customizing a bit since there should only be 1 panel that is dynamically updated to show the desired NPCs stats).

What I'm not sure is if the stats exists on the UI window object, then it may not be desirable to have NPCs use this as they won't need their own unique UI window) in which case it would only be the player utilizing them.

The upside here is that variables aren't duplicated (and I don't need to muck with data providers).

The downsides are that:

A) intellisense support is gone and there are two chances per calling line for human typos (i.e. var myStat = myCharacterCollection.GetStat("cateegoryName", "staatName"); //typos intentional for demonstration.

B)If only the character can make use of them, it also creates inconsistencies and breaks the possibility for polymorphism for stats (instead of something like a method that takes 2 "Actor" objects which are both base classes of player and mobs and grabbing stats for them via actorX.Stats.DesiredStat, it would have to instead take two different objects as the way to access the stats is different).

2) Have the actual player and npc/mob classes (through a shared base class) be the ROO or (game)stats and either dig into data providers or write a script/events for the player that sync these to CharacterUI (not sure which would be better).

The upsides are the inverse of the downsides to #1, we get to keep intellisense and polymorphism.

The downsides here being possible duplicate variables and extra code to maintain syncing (either through scripts/events or data providers).

It kind of sounds like that for my project #2 may be the best route to travel down as both intellisense and polymorphism are highly desireable, and the syncing code would only need to be done once (and unit tested for regression testing whenever there's an update to IP) so it's not that huge of a downside.

That's assuming that my above understanding is accurate (please tell me it is, lol).

So with that, the actual next question is are custom data providers the way to go, or scripts/events in your opinion? Or have I gone full on over-engineering mode here due to my current (but getting better) lack of deep understanding of Inventory Pro?

Thanks again!

 

For monsters you could use the item containers. the IItemContainer interface is a simple interface that holds an array of items, but has the additional effect that they can be used in combination with generators. Each generator searches for the IItemContainer and can fill them at run-time. Group generators may be quite useful to generate loot

A way to work around this would either be to add the custom data providers, which you can do this way:

The CharacterUI component calls it's SetDefaultDataProviders(), which initializes the providers, which is of course marked virtual. You can add your own data provider here, which has to implement the ICharacterStatDataProvider interface. In your own implementation you can append your own stats to the stats dictionary. A thing to note, the InventoryCharacterStat methods aren't currently marked virtual, but if this is something you need I have no problem marking them as virtual.

The 2nd option you have is to use the properties. Properties can be linked through ID, and contain the category and stat name, which would avoid typos. Properties can be serialized, so they'd be quite designer friendly as well, allowing developers to select the right stats in the inspector, and then use them to find the right stat.

As a final option, you could look into code generation or a static class with a bunch of properties / methods that grab stats (not the most elegant thing ever, but it would do the trick).

Spot on

I think you may be slightly over engineering . If you want type safety you could go with a static class that has a load of properties / methods that can simply grab the stats you're looking for. You'll only have to type it once and you'd be done. (Simplest would likely be to give each (game)stat user an interface, and use that interface abstraction in the static class' methods - Hope that made sense).

Like:

Code (CSharp):

1. public class MyMob : IInventoryStatUser
2. {
3.         public Dictionary<string, List<InventoryCharacterStat>> characterStats { get; protected set; } // < Comes from the IInventoryStatUser interface
4.  
5. }
6.  
7. public static class MyStatUtility
8. {
9.     public static GetHealth(IInventoryStatUser user)
10.     {
11.           // Get stat from user here...
12.     }
13. }

This way you'd still maintain intellisense for the most part.

All in all I think it would be easiest to duplicate the dictionary in the CharacterUI component (as well as the GetStat() method for convenience sake), and go from there. You'd still have stat control, while keeping things slim on the mobs. (An array might be more efficient if you got a lot of mobs running around).

 

Trying out some sci-fi UI elements for settings

 

@Joris - You have a talent for UI. More than me, that's for sure.

 

Thank you ^^, just playing around with different styles at the moment. Designing some FPS and RPG elements while keeping controller & keyboard input controls.

 

There's definitely some options there to mull over and is definitely some solid advise. I'm starting to lean more against keeping stats held in IP from a modularity perspective (i.e. using the Inventory Pro system to be the record of origin would strongly tie our entire stat system to the Inventory Pro system, and would make swapping out for another system should we ever need to do so [hopefully not, but sometimes it's needed] a compounding amount of work as more and more systems get tied into it). The (non-ui) stat related stuff should probably be able to function without Inventory Pro as a dependency for my project, because it's going to be a large scale project (if it was a smaller game I probably wouldn't care).

The static idea (while I agree isn't elegant but works, lol), even though providing some abstraction and mitigating the amount of work needed to swap stuff out still means if we ever had to drop Inventory Pro our stat based systems would all break.

I'm thinking I'd like to keep the two domains separated as much as possible, and customizing IP to bind to our stat system instead of the inverse seems like it's probably the best approach. How I do that I'm not entirely sure yet.

Using events/event handlers to notify IP of a stat change and update stuff on the IP end is definitely one (relatively simple)approach I see, but the downside there is I'm pretty sure we would lose the ability to modify stats from within Unity, since I don't think Unity handles properties like that (i.e. Public int AttackPower { get { return attackPower } set { stat = value; OnStatModified(); }} ).

Though that approach does have other advantages, since it can be used by any other systems that need to know when a stat has been changed, and keeps things nice and decoupled all around.

Heh, is my background as an enterprise solutions developer showing? >.<

 

Only slightly haha , it's a good thing though.

Perhaps, and this is just a thought it would be nice to do the following:

Create a new script that inherits from CharacterUI and create your own data providers.
In the data providers, create your own stat objects that inherit from the IP build in InventoryCharacterStat (methods aren't currently marked virtual, but I can change this, np / I'll make an interface out of it to abstract it completely).

Then, overwrite the GetStat() method in the CharacterUI which will grab the new stat objects from wherever you manage them.

This way the CharacterUI will only handle the grabbing of the stats, while you still have full control over them.

(And I'll make characterStats in the CharacterUI protected, to avoid going around the GetStat() method.)

Sound good ?

 

That does sound pretty good. While you do that I'll decrement the The Speedup Loop on my end.

 

haha, if only I knew what a speedup loop was sooner... ah well.

All done, the character collection now uses the IInventoryCharacterStat interface instead of the build in one. The SetDefaultDataProviders is already marked virtual, which can be overwritten to set your own providers.

And finally, a data provider can be created, like so:

Available in the next update

 

Wow, thanks much. I'll whip up some user stories for use in a future iteration. Much appreciated.

 

I had a few extra minutes, so I decided to go with a proper approach that I've been meaning to do for a while now.
You mentioned you wanted creatures to have stats as well. Considering that the whole stats system is already in place, it would be a waste to have to redo all of it... So, I've created a new InventoryStatsContainer type, which contains all stats and can be re-used on monsters, etc.

Of course the existing workflow will continue to work just fine, but now you can add stat containers to any object and use your own data providers to handle the creation. And finally, I've added some convenience methods like Add and Remove of stats, to allow you to add your own stats without using the data providers, in case you want to add 'conditional' stats, that wouldn't really fit in a data provider.

And of course, available in the next update

 

You're like a machine (I mean that in the good way )

 

I have an issue. I know that if I start a fresh scene things would work fine. But for some reason, they aren't working in my present scene.

The issue is that "Block UFPS Input" is checked, but not honored, for my inventory window. It is checked on other windows, like my character window, and works fine there. It is just a problem with the inventory window.

Any ideas how I can troubleshoot this issue? I am using an inventory window that is, I believe, still an unmodified version of the InventoryWindow from RPG_PrefabDropIns.

 

Hi Joris,

I was just wondering if you have had a chance to look into the ufps hotbar problem yet?

Thanks,
Mura

 

When will you release the Sci-Fi versions ? They look absolutely stunning and I'll become a new customer once you do.

 

Strange, they all use the same code paths. Are you manually triggering windows, or just using UIWindowInteractive to show / hide windows with the build-in editors?

 

I am not manually triggering windows. I am just pressing the 'I' key during runtime to toggle the inventory window.

 

Eehhrr... thinking real hard. Did I create a bitbucket task?

 

Very strange; Is the window perhaps instantiated at run-time?

 

I am not sure what you mean by that question. The window is configured in the editor. I don't explicitly instantiate it.

 

Aiming to finish it in 4-5 weeks, no promises though

 

Are you creating windows while the game is running, or are all windows available in the hierarchy (editor) before starting the game? Quite hard to figure out what's going wrong. Could you try creating a new window perhaps?

 

I am not creating the windows while the game is running. All the windows are available in the hierarchy before starting the game.

I am at work and the project is at home. I will try creating a new window and see what happens.

 

Not completely there yet, but I figured I'd share my progress

 

Looks great. So, I'm going to be plugging this asset into my pipeline soon. Will your future updates include any issues where I will have to start over? I want the updates you are working on now, but am ready to get started and plug the inventory in. If you think I may have to "restart" with future updates, then what's your ETA so I can see if I can wait or not.

Thanks!

Can't way to have NPCs with inventory upon death so my player can pick stuff up if they want.