Universal Inventory System (API)

These are tools and utilities that make it easier to run games. This includes Lib: macro tokens dropped into MapTool to manage the game, a conversion file for CharacterTool to allow use in MapTool, or just about anything else you can think of -- except graphics with macros and anything specific to a particular campaign framework. Those are already covered by the Tilesets subforum and the Links and External Resources forum.

Moderators: dorpond, trevor, Azhrei, giliath, Gamerdude, jay, Mr.Ice

User avatar
PyroMancer2k
Dragon
Posts: 925
Joined: Thu Sep 11, 2008 2:04 pm

Universal Inventory System (API)

Post by PyroMancer2k »

UPDATED version 1.1
Do to request I have added user defined functions to the inventory system to make it easier to use. Now you can simply do function calls like other functions without all the bulking [macro():] commands. The old way still works and in the interest of saving time I left most of my examples still using the macro call method but it does effect anything cause it's calling the same macro just in a different way.

Also to help limit the need for changing of several macros when setting a new system I added 4 location macros which simply return the name of the variable where they inventory is stored. This allows for up to 4 different inventory properties to be used and more can easily be added if need be.

In the campaign I also added a Player Macro which has the 6 main macros a player needs on their token to get started. The most important is of course the new "Call Declare Inventory User Functions" macro which the player needs to run in order for the user defined functions to work.

I also updated the Setup description to reflect the changes.

Here are the new files which I also updated at the end of the post as well.
Campaign
http://rapidshare.com/files/228507059/U ... V1_1.cmpgn

Token
http://rapidshare.com/files/228507010/U ... y1_1.rptok
-----------------------------
When it comes to making a token for any system one of the biggest challenges is creating the inventory system. To help would be coders over come this problem of how to manage lots of items in a dynamic way along with keeping track of what items are equipped I have created what I refer to as the Universal Inventory System. I call it this because it is completely independent of any framework setup or token properties. The Lib:Token can be put into any game and after running the quick setup the system is ready for use.

Besides the setup macro it comes with simple item editor and character equip macros for a demonstration. But the key thing to the system is it has several macros which you use like functions to get information and set items. This way you don't need to worry about how it is manipulating the json objects behind the scenes. All you need to do is run the macro to get an Item and it will return a Json Object of that it's properties which you can then use in custom macros.

SETTING UP
Setting it up is very easy and only takes a few quick Steps. I've included a few screen shots from the various example Inventory setups I included in the campaign file as examples.

IMPORTANT: The setup uses user defined functions which will automatically load from the onCampaignLoad macro when a campaign is loaded that has the Lib:Token in it. However if you are just starting out and copy the Lib:Token into a current campaign you will need to run the "Call Declare Inventory User Functions" macro in order to set the functions. If you get lots of error messages saying undefined function this is the cause and running the macro should fix it.

1) The Lib:Token contains a few default macros for interacting with the Inventory system. You need to either copy the "Call Inventory Setup" over to the Token you wish to add an inventory to or copy it to Campaign macros and then you can run it on the token from there.

2) Before you run the "Call Inventory Setup" macro you need to make a quick edit to it. You will notice where the arguments should be is a function called "inventory.location1()" in the [macro():] call. This function calls a macro on the Lib:Token named "location1". The macro only contains one line setting the macro.return equal to the variable name that holds the inventory. Simply change the name here and all other macros that use it as a reference will be changed as well. The line in "location1" looks like the following.

Code: Select all

[macro.return = "Inventory"]
You may also notice that there is also macros for location2, location3, and location4. This way you can use more then one inventory and quickly change their location if need be or choose to add more.

3) Next you simply need to run the "Call Inventory Setup" the macro and you will be prompted to enter the types of items your inventory system can handle. The items are entered in list format with a comma separating each. Below is a screen shot of the setting up for some of the example inventory setups I included.
Image

4) The new prompt will allow you to enter a list of all the item properties or each type of item. The order is slightly important for a few reasons. The property located in the first slot will be used when some of the functions return a list of items by Name or whatever property you choose to enter first. Also when the functions return what properties an item has it will return that list in the same order.
Image

5) Next up is the slots which you can equip. This list order doesn't really matter except that when you use the macros to call list of all slots it returns them in this order. Other then that you can simply enter whatever slots you want to keep track of.
Image

6) This step is one of the things that makes the inventory system so useful. You will be prompted which types of items can be equipped in each slot. Simply check which item types you wish to allow and it's even possible to choose all.
Image

7) Your almost done now. While the inventory system is technically setup at this point you need a way to interact with it so you can edit your items and equip character. Copy all the macros on Lib:Token in the section "Z: Calling Macros (Copy to Main Token)" onto your token macros or campaign macros. . Once this is done you will be able to experiment with your new inventory.

Here is a picture of the Dialog window for 2 of the setup examples I made. In the picture you'll note the Dialog windows have different names. This is because it is setup to use the name of the variable where the inventory is stored as the Dialog window name.
Image

Examples
I've included 4 example tokens in the campaign file to show how things work and give a starting point for those who wish to use it to make more of their own macros.

UPDATE: The examples of calling macros on all of the 4 example systems have been updated to include the new user defined functions. I left the old style macro and the new function call in them to show off how the two setups differ for those who wanna choose which to use.

I also changed it so they use the new location functions to refer to the variable where their inventory is thus reducing the need for editing should the inventory be moved.

Example 4E System
This token has the most macros on it because it is showing off all the macro calls for the system.

The first section is called "Example Data Calls". The macros in this section of the token are simply showing off what types of data are returned by the various call functions. All the arguments that are passed into them are directly coded into the macros but you can change them to see how it effects what returns. This is a good place to experiment to learn what to pass in and what comes out of the macro arguments.

Next are the Example Interfaces which are the basic interfaces that come with the system. They call macros on the Lib:Token so you can view how they are setup if your interested in creating your own.

Then there is the "Example Set Calls" section which are all the macros that allow you to set various things in inventory like which items are equipped, item's stats, and etc. These macros help show off the format so you can get a better idea of how to use them in your own macros.

Lastly is the Setup Inventory Macro which allows is standard for all setups. It allows you to edit the inventory layout.

Misc Fantasy System
This is a very basic setup which demonstrates you can use more refined groups like different weapon types as well as different armor types and still allow them to be selectable as equipment to a particular slot. For those wanting to have a more defined inventory instead of simple types like "Weapon" and "Armor".

Other then that and a simple Get Equipped Item macro being shown off there is not much to see.

Misc Military System
This setup also shows off the ability to refine items into more precise types while still having them equipable to chosen slots. Though it also shows an example of the inventory system being stored in "Gear" on the token properties instead of "Inventory" like the previous two.

Multiple Inventories
This setup shows how to do 2 inventory systems on a single token and how they can have different Item Types and Equipment Slots. This one also has 2 useful examples for doing usable items. The first example is Use Potion which allows you to select a potion you have and drink it. The other example is Used Equipped which simply uses the item that is equipped in that slot, which in the case of the example is ammo equipped in a quiver.


UPDATED version 1.1
Campaign
http://rapidshare.com/files/228507059/U ... V1_1.cmpgn

Token
http://rapidshare.com/files/228507010/U ... y1_1.rptok
Last edited by PyroMancer2k on Mon May 04, 2009 6:21 pm, edited 2 times in total.

User avatar
PyroMancer2k
Dragon
Posts: 925
Joined: Thu Sep 11, 2008 2:04 pm

Re: Universal Inventory System (API)

Post by PyroMancer2k »

RESERVED

User avatar
PyroMancer2k
Dragon
Posts: 925
Joined: Thu Sep 11, 2008 2:04 pm

Re: Universal Inventory System (API)

Post by PyroMancer2k »

MACROS/FUNCTIONS
First off for those of you that don't know user defined functions put their arguments into a Json Array which they pass into the macro. So you can choose to use either the [macro():] setup or the function calls. For the sake of ease though I only be covering the functions.

The [macro():] setup would still take the same number of arguments in the same order if you prefer to use that method though. Also the names of the macros are the same as functions without the "inventory." in front of it. I added this so as to clearly note that these functions were part of the inventory system and not MT or some other campaign framework. Also I know some of the names are long but I tried to make them as descriptive as possible.

I'm going to go over the macros based on the same sections they are divided up on the Lib:Token which is based on what they return or if they set something.


Return Json Array Functions
  • inventory.returnEquipedSlotInfo(Inventory, Slot)
    This function returns a Json Array that contains the item type in index 0 and the item number in index 1.
    • Inventory - The name of the variable on token where the inventory is stored.
    • Slot - The name of equipment slot.
  • inventory.returnEquipSlots(Inventory)
    This function returns a Json Array that contains the names of all Equipment Slots.
    • Inventory - The name of the variable on token where the inventory is stored.
  • inventory.returnEquipSlotTypes(Inventory, Slot)
    This function returns a Json Array containing the Item Types that can be equiped in the slot.
    • Inventory - The name of the variable on token where the inventory is stored.
    • Slot - The name of equipment slot.
  • inventory.returnItemsOfType(Inventory, Type)
    This function returns a Json Array containing Json Objects for each item of that type.
    • Inventory - The name of the variable on token where the inventory is stored.
    • Type - The name of the type of item.
  • inventory.returnItemTypes(Inventory)
    This function returns a Json Array containing all the item types.
    • Inventory - The name of the variable on token where the inventory is stored.
  • inventory.returnPropertiesOfType(Inventory, Type)
    This function returns a Json Array containing all the Properties for an item type.
    • Inventory - The name of the variable on token where the inventory is stored.
    • Type - The name of the type of item.
Return Json Object Functions
  • inventory.returnEquipedItem(Inventory, Slot)

    This function returns a Json Object of the item that is equipped in a slot.
    • Inventory - The name of the variable on token where the inventory is stored.
    • Slot - The name of equipment slot.
  • inventory.returnItem(Inventory, Type, Number)
    This function returns a Json Object of the item of that type and number.
    • Inventory - The name of the variable on token where the inventory is stored.
    • Type - The name of the type of item.
    • Number - The item number based on items of that type

Returns String Functions
  • inventory.returnEquipedItemType(Inventory, Slot)
    This function returns the name of the type of item currently equipped in a slot.
    • Inventory - The name of the variable on token where the inventory is stored.
    • Slot - The name of equipment slot.
Returns List Functions
  • inventory.returnListOfItemsForSlot(Inventory, Slot)
    This function returns a List of all items that can be equipped in a slot.
    • Inventory - The name of the variable on token where the inventory is stored.
    • Slot - The name of equipment slot.
  • inventory.returnListOfItemsForType(Inventory, Type)
    This function returns a List of all items of a given type.
    • Inventory - The name of the variable on token where the inventory is stored.
    • Type - The name of the type of item.

Returns 0/1 Functions
  • inventory.returnEquipSlotsItemMatch(Inventory, Slot, Slot)
    This function checks to see if two slots contain the same item. It returns a 1 if true and 0 if false.
    • Inventory - The name of the variable on token where the inventory is stored.
    • Slot - The name of equipment slot.

Returns Number Functions
  • inventory.returnItemNumberForEquipSlot(Inventory, Slot)
    This function returns a number for an equipped item in a slot that represents the Index for the List of all possible items that can be equipped it that slot. This list can be obtained using the returnListOfItemsForSlot() function.
    • Inventory - The name of the variable on token where the inventory is stored.
    • Slot - The name of equipment slot.
  • inventory.returnItemsOfTypeLength(Inventory, Type)
    This function returns the number of items of a given type.
    • Inventory - The name of the variable on token where the inventory is stored.
    • Type - The name of the type of item.
Returns Inventory Location
All the location functions have no arguments. They simply return the name of a variable where inventory is located.
  • inventory.location1()
  • inventory.location2()
  • inventory.location3()
  • inventory.location4()
Set Inventory Functions
  • inventory.deleteItem(Inventory, Type, Number)
    This functions deletes an item from a given type based on it's number.
    • Inventory - The name of the variable on token where the inventory is stored.
    • Type - The name of the type of item.
    • Number - The item number based on items of that type
  • inventory.setEquipSlot(Inventory, Slot, Type, Number)
    This function sets which item is currently in the equipment slot.
    • Inventory - The name of the variable on token where the inventory is stored.
    • Slot - The name of equipment slot.
    • Type - The name of the type of item.
    • Number - The item number based on items of that type
  • inventory.setEquipSlotByItemNumber(Inventory, Slot, Number)
    This function sets the item currently equipped in slot using the number which refers to the index of the List for all items that can be equipped in that slot. This list can be obtained using the returnListOfItemsForSlot() function.
    • Inventory - The name of the variable on token where the inventory is stored.
    • Slot - The name of equipment slot.
    • Number - The item number based on List of all items that can be equipped in slot.
  • inventory.setEquipSlotToEquipSlot(Inventory, Slot, Slot)
    This function sets the item of first slot in the argument to the same item of second slot. This way both slots have the same item set as equipped.
    • Inventory - The name of the variable on token where the inventory is stored.
    • Slot - The name of equipment slot.
  • inventory.setItem(Inventory, Type, Number, Json Object)
    This function sets all properties for an Item. In the event there is no item in that spot it will add a new item.
    • Inventory - The name of the variable on token where the inventory is stored.
    • Type - The name of the type of item.
    • Number - The item number based on items of that type
    • Json Object - This is json object of the new item properties.
Last edited by PyroMancer2k on Sun May 03, 2009 4:17 am, edited 1 time in total.

User avatar
Natha
Dragon
Posts: 733
Joined: Sat Oct 11, 2008 3:37 am
Location: Limoges/Guéret, France
Contact:

Re: Universal Inventory System (API)

Post by Natha »

Impressive ! Excellent ! Thanks for sharing that.
ImageImageImageImage

User avatar
keithcurtis
Giant
Posts: 129
Joined: Fri Mar 02, 2007 3:18 am
Contact:

Re: Universal Inventory System (API)

Post by keithcurtis »

Amazing work!

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Universal Inventory System (API)

Post by Azhrei »

Very nice, Pyro!

A couple of questions:

1. You've got a note that the property name needs to be updated in a few places, primarily in the macros that will be copied to the individual tokens. May I suggest instead that all macros on the individual tokens simply invoke macros on the Lib: token and keep all of the property names there? For example, if the GM chooses to use "Inventory" as the property name, then they would put "Inventory" into a Lib: token property (such as "InventoryPropertyName") and the rest of the macros would use getLibProperty() to retrieve the name? The reason I'm suggesting this is to reduce the need to customize the individual macros.

2. Along the same lines as #1, I would suggest a separate PC token which is owned by all players that contains the macros that they should copy. This lets the player do some of the work so that the GM doesn't have the copy the macros themselves. And if a player wants to mess around with their macros, they can fix them again by themselves. ;)

Again I want to say: very nice! This is an impressive piece of work and I look forward to trying it out. I'm going to work on building a macro system for thelevitator's homebrew system and I was planning to put the equipment lists into tables -- I may use this system instead. (Tables have the disadvantage of not being editable via macros, so I can't create any fancy front-ends for adding new gear. And I like your Lib: token approach since copying a single object copies all of the data as well.)

User avatar
Veggiesama
Dragon
Posts: 619
Joined: Wed Aug 29, 2007 1:18 am

Re: Universal Inventory System (API)

Post by Veggiesama »

Blutes, huh?

This is really quite a good idea. It's likely I will steal it for my SR4 framework, if it can do everything I want. I have been dreading writing up the logic for all the different equipment types in that game, so this looks like an ingenious solution.

EDIT: Looking into it with a little more, and it does win a couple of epic awards. Very high chance I'll use this later!

I did look at a few of the macros, though. Any chance you'll switch over to user-defined functions? They can be a little more precise than the clunky MACRO():args, macro.return deal.
Last edited by Veggiesama on Sat May 02, 2009 1:30 pm, edited 1 time in total.
My D&D 4e Campaign FrameworkMy Shadowrun 4e Campaign Framework
RPGA#: 5223846427 — Skype: Veggiesama — Fear the ferret.

Cweord
Great Wyrm
Posts: 1343
Joined: Sun Aug 12, 2007 10:49 am
Location: Midsomer Norton, (Near Bath), UK
Contact:

Re: Universal Inventory System (API)

Post by Cweord »

I'm using Json objects to store it all in mine.

Since I became a convert (after much fighting against it) I am using them for 90% of my Sr4 framework.
Cweord

This message has been spell checked by Freudcheck - any mistakes are purley a figment of your imagination.
-------
My Tokens Directory
http://gallery.rptools.net/v/contrib/Cw ... er_Tokens/

User avatar
PyroMancer2k
Dragon
Posts: 925
Joined: Thu Sep 11, 2008 2:04 pm

Re: Universal Inventory System (API)

Post by PyroMancer2k »

Azhrei wrote: 1. You've got a note that the property name needs to be updated in a few places, primarily in the macros that will be copied to the individual tokens. May I suggest instead that all macros on the individual tokens simply invoke macros on the Lib: token and keep all of the property names there? For example, if the GM chooses to use "Inventory" as the property name, then they would put "Inventory" into a Lib: token property (such as "InventoryPropertyName") and the rest of the macros would use getLibProperty() to retrieve the name? The reason I'm suggesting this is to reduce the need to customize the individual macros.
Yea I considered putting them on the Lib:Token but if it's stored on a variable there then the token would require it's own property set even if just for one property ;). And I wanted to minimize any impact it would have on an existing setup if it was imported. There is also the issue if it does allow the player to use multiple inventories on one token they can't simply have the variable named in one location.

It really only needs to be changed on the player tokens which call the macros on the Lib:Token. The rest of the tokens pass the value around. That being said I'll see what I can come up with I have an idea or two which I think might work.
Azhrei wrote: 2. Along the same lines as #1, I would suggest a separate PC token which is owned by all players that contains the macros that they should copy. This lets the player do some of the work so that the GM doesn't have the copy the macros themselves. And if a player wants to mess around with their macros, they can fix them again by themselves. ;)
Yea I can make another token for the players which simply has the macros they need to copy. Though they would still need the the Lib:Token to run any of them. :) And would you suggest it only have macros they need to copy? As it not really a Lib:Token itself?

The reason I ask is while some of the functions aren't really needed for player use many of the macros the players use call them via the getMacroLocation() so that you can change the name of the token if you wish.
Azhrei wrote: Again I want to say: very nice! This is an impressive piece of work and I look forward to trying it out. I'm going to work on building a macro system for thelevitator's homebrew system and I was planning to put the equipment lists into tables -- I may use this system instead. (Tables have the disadvantage of not being editable via macros, so I can't create any fancy front-ends for adding new gear. And I like your Lib: token approach since copying a single object copies all of the data as well.)
Thanks. If you or anyone else thinks of anymore ideas to help improve the system feel free to mention it.
Veggiesama wrote: I did look at a few of the macros, though. Any chance you'll switch over to user-defined functions? They can be a little more precise than the clunky MACRO():args, macro.return deal.
Yea I forgot about those. ;) I've been away from MT coding for a LONG time now and MT has so many new features I gotta "learn" how to do all the new stuff like those user defined functions. I remember reading about them but haven't really had time to test them out. I'll have look into them.
Cweord wrote:I'm using Json objects to store it all in mine.

Since I became a convert (after much fighting against it) I am using them for 90% of my Sr4 framework.
Yea I original resisted the Json change over but mostly because my token had an extensive Inventory system based on strProps with a much more primitive setup then this but it was still customizable via some macros. Granted it only tracked items and properties but didn't have equip slot support built it. That was all hard coded.

My token still uses that system now because a change would require major work. Plus the fact that Json objects were still new and time was becoming scarce I wasn't able to focus on any real change over.

Json objects seem to be the norm these days and because of that and the fact that they are rather powerful tool it would be perfect to use them in this setup. Most framework seems to simply pass around a Json of the item so they shouldn't have much trouble interacting with the inventory system.

NOTE TO ALL: I should be able to finish up the "macro" section of the main post done later tonight when I get back home. This section I plan to post as a tutorial on how to use the different macros so you know what Args to pass into them and what they return. For those wanting to play around now the return and set macros have comments at the top of them giving a description of what they do.

EDIT: After taking a look at User Defined Functions they seem a much more elegant way to do things. Unfortunately it will require a bit of rewriting but I plan to change it over to that system. I'm also going to add a check to the front of all macros to make sure they notify the user if they don't have enough arguments. This is because the Default error message for arguments provide almost no help with debugging.

Here is an example of the debug pop that will appear if you don't pass enough arguments.
Image

User avatar
PyroMancer2k
Dragon
Posts: 925
Joined: Thu Sep 11, 2008 2:04 pm

Re: Universal Inventory System (API)

Post by PyroMancer2k »

UPDATE V1.1
I have updated the main post to reflect the new additions as well as added link to new files. But here is a quick list of changes.

1) Added User defined functions for all the macros to make the system easier to interface with.
2) Added prompts to help with debugging if a function is passed the incorrect number of arguments.
3) Added macro to get inventory variable name so it only requires changing in one macro and not all ones on player token.
4) Added examples of new functions in use in the previous call macros.
5) Added a player token in campaign which contains all the macros a player needs to put on their own token to use the system.

User avatar
Mathemagician
Dragon
Posts: 666
Joined: Tue May 22, 2007 2:27 pm

Re: Universal Inventory System (API)

Post by Mathemagician »

Yea I considered putting them on the Lib:Token but if it's stored on a variable there then the token would require it's own property set even if just for one property
I believe that if you use setProperty() and getProperty() you can "invent/hide" properties. This would allow you to store everything on a library token, and not force the users of your system to add the properties to their campaign properties.

User avatar
Veggiesama
Dragon
Posts: 619
Joined: Wed Aug 29, 2007 1:18 am

Re: Universal Inventory System (API)

Post by Veggiesama »

How tough would it be to use this API not only for inventory, but for character stats too?

For instance, could I make a skill "item type" called Climb, set its rating to 3 and associated attribute to Strength, then "equip" it to a character?

(or alternatively an Item Slot called "Climb", and a general-purpose skill item with rating 3, attribute "Strength", then equip that skill item to Climb?)

Hmm, this might be kind of a backwards way of going about it.
My D&D 4e Campaign FrameworkMy Shadowrun 4e Campaign Framework
RPGA#: 5223846427 — Skype: Veggiesama — Fear the ferret.

User avatar
PyroMancer2k
Dragon
Posts: 925
Joined: Thu Sep 11, 2008 2:04 pm

Re: Universal Inventory System (API)

Post by PyroMancer2k »

Veggiesama wrote:How tough would it be to use this API not only for inventory, but for character stats too?

For instance, could I make a skill "item type" called Climb, set its rating to 3 and associated attribute to Strength, then "equip" it to a character?

(or alternatively an Item Slot called "Climb", and a general-purpose skill item with rating 3, attribute "Strength", then equip that skill item to Climb?)

Hmm, this might be kind of a backwards way of going about it.
Well it really wasn't designed for that. It mostly only keeps track of Items by Type and what Slots there are along with what can be equipped in them. Any math outside of that is completely up to player or DM who are incorporating it into their game.

That being said doing Climb as an Item Type won't really work because Item Types don't have values themselves. You would have to make an Item of type "Climb" just like you would make a dagger of Item type Weapon. Then whatever that item was called you could equip it to strength. Next us the returnEquipedItem() function to get that item and a typical json.get() command to grab whatever variable you want.

Just for kicks I through one together using the inventory setup for a 4E skill system setup. Rather then uploading a token I simply copied the json. It's just the setup with no "items" in it.

Code: Select all

{"ItemTypes":["Acrobatics","Arcana","Athletics","Bluff","Diplomacy","Dungeoneering","Endurance", "Heal","History","Insight","Intimidate","Nature","Perception","Religion","Stealth", "Streetwise","Thievery"],"Properties":{"Acrobatics":["Name","Bonus"],"Arcana":["Name","Bonus"],"Athletics":["Name","Bonus"],"Bluff":["Name","Bonus"],"Diplomacy":["Name","Bonus"],"Dungeoneering":["Name","Bonus"],"Endurance":["Name","Bonus"],"Heal":["Name","Bonus"],"History":["Name","Bonus"],"Insight":["Name","Bonus"],"Intimidate":["Name","Bonus"],"Nature":["Name","Bonus"],"Perception":["Name","Bonus"],"Religion":["Name","Bonus"],"Stealth":["Name","Bonus"],"Streetwise":["Name","Bonus"],"Thievery":["Name","Bonus"]},"EquipSlots":["Strength","Constitution","Dexterity","Intellegence","Wisdom","Charisma"],"EquipSlotTypes":{"Strength":["Athletics"],"Constitution":["Endurance"],"Dexterity":["Acrobatics","Stealth","Thievery"],"Intellegence":["Arcana","History","Religion"],"Wisdom":["Dungeoneering","Heal","Insight","Nature","Perception"],"Charisma":["Bluff","Diplomacy","Intimidate","Streetwise"]}}
It does of course potentially have issues since it wasn't really meant for this.

And since you brought it up I was kinda considering doing a skill setup in this style. But I didn't really want to say anything cause it's not that concrete. As in skill systems vary so much from game to game. How to store the skills especially since like 4E these days you need to keep track of where the skill bonuses are coming from and trained vs untrained skills. I hadn't begun to plan it out though i have several ideas most of which need testing just to see if MT can handle stuff curtain ways. Plus some skill bonuses only happen under curtain conditions like blooded. There is a whole bunch of problems with skills :P.

This system I actually been working on mostly planning out how the data structure works in my spare time. The only issue was finding the time to actually code it once I had the outline drawn up ;). Oh and bug testing... lots and lots of bug testing. So odds are I won't get to skill version of this for a bit. But you could use it as is for some kinda of crude skill system.

EDIT: Shortly after posting I got this idea. Have the Items in each skill have at least property of "Name" and "Bonus" so you could tell what that bonus was from. Then use the following commands to get a total.

Code: Select all

[JsonArrayOfItems = returnItemsOfType(inventory.location1(), "Arcana")]
[TotalBonus = 0]
[C(json.length(JsonArrayOfItems)), code: {
 [CurrentItem = json.get(JsonArrayOfItems, roll.count)]
 [TotalBonus = TotalBonus + json.get(CurrentItem, "Bonus")]
}]
The Total Bonus is [TotalBonus]
Disclaimer: I didn't actually test that code I just wrote it on the fly so it might be off but the basic concept is sound. ;)

You get all "items" for Arcana Type and then grab the value for each one's bonus and add up the total. Not really sure how slot equip would tie in unless you used the returnListOfItemsForSlot() or returnEquipSlotTypes() in some fashion.

User avatar
krellos
Cave Troll
Posts: 29
Joined: Tue May 26, 2009 9:55 pm
Location: West of Atlanta

Re: Universal Inventory System (API)

Post by krellos »

First of all, I must say that this is a great feature! In trying to adapt it to my homebrew system I am having some difficulty.

Must I perform the initail setup for each and every token I want to have an inventory?

Once 'Call Inventory Setup' was complete, I thought I would be able to use the Z: Calling macros to equip any token, through the Campaign window macros.

I was able to 'equip' one token, but when I tried to 'equip' a different token, I got a blank inventory basically.

Perhaps I am missing something...

User avatar
PyroMancer2k
Dragon
Posts: 925
Joined: Thu Sep 11, 2008 2:04 pm

Re: Universal Inventory System (API)

Post by PyroMancer2k »

krellos wrote: Must I perform the initail setup for each and every token I want to have an inventory?
Well yes and no. Once the inventory system is setup it is really only setup on that token. But you don't have to go through all the setup steps again on each token. You can either copy the token or open the token properties and copy the contents of that inventory value into the other tokens.

You can also take what it puts in that inventory and copy paste it into the campaign settings as the default value for that variable. That way any token you make will have it setup as default.

The main thing that the inventory setup does is create the structure of the Json Object. The macros then work under the assumption that curtain items or in curtain places in the Json Object which is why it needs to be "setup" correctly at first. It's kinda similar to how my Json Editor works which is actually what gave me the idea of this setup :).

Post Reply

Return to “Drop-In Macro Resources”