Instance Items

[Tsukihime]

This script introduces the concept of “instance items”. In order to understand what an instance item is, you need to first understand what a “template item” is.


All of your database items, weapons, and armors are called “template items”.


That is, they serve as templates for in-game items.


An instance item is simply an instance of a template. For example, you design weapon ID 1 in your database and call it a “Short Sword”. This is a template of a Short Sword; everytime you receive a Short Sword in-game, you receive a unique “instance” of this template. Two Short Swords in your inventory are treated as two individual entities that have nothing to do with each other besides both being based on the Short Sword template.


It is important to note that this script simply provides instance item functionality. Additional add-ons are required to provide various features such as equip levels, equip affixes, and so on.


Get it at Hime Works!

 

[Selchar]

As someone who has made several scripts using this, I'll say it's definitely easy to use. It's just a matter of deciding what to make unique for each equip and how to go about it without worrying about others from the same template!


Anyways, upon making another script as a test(Item Charges), I discovered that BattleTests from within the database doesn't work, or at least not when you have Enable_Items set to true. Based on the error and the cause, I'd hazard a guess and say it's because of having TOO Many unique items at once. There is lag at the start of battle, and when the item command is used.. which then results the crash with the following error.


Script 'Window_Base' line 74: RGSSError occurred.


faled to create bitmap


Just thought you should know.

 

[Tsukihime]

Yes, battle test is hardcoded to give 99 of all items, so if you have unique items, that might be thousands of things to draw.


I have no solution for this. This will become a problem for players as well, when you have too many items in your inventory.


It may be necessary to avoid drawing all items at once, but instead only drawing things that you will realistically encounter.

 

[Selchar]

Well, when it comes to battle test, you could modify the following code. Changing max_item_number(item) to a regular number less than 10 solved it, tho of course another problem arised, probably because it's looping through all of $data_items. I'm sure you can figure out the rest from there.

class Game_Party < Game_Unit  def setup_battle_test_items    $data_items.each do |item|      gain_item(item, max_item_number(item)) if item && !item.name.empty?    end  endend 

 

[Tsukihime]

Never noticed those methods. However, aside from battle test, we can see that this problem would occur in any game if a player decided to collect a million pieces of equipment. Not really sure how that would be dealt with...however the idea of only drawing whatever you will see, may be a reasonable solution. After all, if you have a million items, you won't care about the other 999980 if you can only see 20 at a time.


There is nothing preventing people from adding instance items to their inventory. The number itself doesn't really mean anything for instance items since I do not support stacks for instance items.

 

[Tsukihime]

Fixed bug with "change equipment" event command.

 

[Selchar]

Improved setup_batte_test_items(which coincidentally no longer crashes if it's set back to max_items(items), tho still unwise to do so due to lag).

alias :th_instance_items_setup_battle_test_items :setup_battle_test_itemsdef setup_battle_test_items if TH::Instance_Items::Enable_Items $data_items.each do |item| next unless item break unless item.is_template? gain_item(item, 5) if item && !item.name.empty? end else th_instance_items_setup_battle_test_items endendRemoves item count for instance items only(since they will never stack).

#===============================================================================# Standard Item Window#===============================================================================class Window_ItemList < Window_Selectable  alias :th_instance_items_draw_item_number :draw_item_number  def draw_item_number(rect, item)    th_instance_items_draw_item_number(rect, item) if item.is_template?  endend#===============================================================================# Bubbles TMI Item Window#===============================================================================if $imported["Bubs_TMI_ItemScene"]class Window_TMI_ItemList < Window_ItemList  alias :th_instance_items_draw_item_number :draw_item_number  def draw_item_number(rect, item)    th_instance_items_draw_item_number(rect, item) if item.is_template?  endendend

And I'm sure this was obvious in retrospect, not compatible with your actor inventory scenes, and actor inventory trade scene. Those display both templates and instances.
Edit: Best I have for a fix with the Actor Inventory Scenes

class Window_ItemList < Window_Selectable  alias :th_instance_items_include? :include?  def include?(item)    return false if !item.nil? && $game_party.instance_enabled?(item) && item.is_template?    th_instance_items_include?(item)  endendclass Window_BattleItem < Window_ItemList  alias :th_instance_items_include? :include?  def include?(item)    return false if !item.nil? && $game_party.instance_enabled?(item) && item.is_template?    th_instance_items_include?(item)  endendend

 

[Tsukihime]

I am considering dropping the in-line "if $imported" compatibility checking in favor of separate compatibility patches. This requires users to determine whether they need additional patches, but it would allow me to avoid having a dozen different patches in a single script.


The issue with Actor Inventory is incompatibility between Instance Items and Core Inventory (which actor inventory uses), simply because the inventory script moves the entire inventory into its own entity, but instance items assumes the inventory is stored with the party.


The correct way to patch this would be to move the custom logic defined in Instance Items to match the way Core Inventory is written.


Initially I had considered just writing the instance items as a Core Inventory add-on, but then I don't know how compatible it is with other scripts.

 

[Tsukihime]

This is only relevant to scripters, but I have updated the framework with some methods that allow you to write more compatible code. Specifically, the issue concerns multiple scripts modifying "shared variables" such as an item's name or its parameters.

For example, suppose your game uses affixes, equip levels, and equip durabilities.

You start off with a weapon called Short Sword, which is level 1 and had 30/30 durability.

The script may display the name as

Short Sword Level 1 (30/30)Now, let's say you wanted to add a "Mighty" prefix to the name, resulting in

Mighty Short Sword Level 1 (30/30)

Now I go ahead and add the "of Chaos" suffix to the name...but now we have a problem. What should the name be?

Mighty Short Sword Level 1 (30/30) of ChaosMighty Short Sword of Chaos Level 1 (30/30)Mighty Short Sword Level 1 of Chaos (30/30)

My solution is to provide a standard way to modify data.In your own scripts, you simply tell the engine how to modify a name. It doesn't matter WHAT the name is originally; all it knows is that it takes a name and does something to it (add a suffix, level, durability, etc)

You then tell the engine to "build" the name, which will apply all of these changes in a specific order.

This allows you to always have the correct format of the name, because you will always start with the base name and apply changes one at a time in the same order.

A name might be a bad example, because you can argue that the level shouldn't be in the name itself (the windows should be updated), or the durability shouldn't be in the name (again, this concerns the view only, not the model), but then aren't you simply moving the problem away from the model, to the view? You're still going to have a dozen scripts all trying to change how the view looks, which is the same problem all over again.

 

[Kurotsuke]

I got this error after saving my file then using the shop . Script 'Game_Party' line 226: ArgumentError occurred. comparison of Fixnum with nil failed.

And also after battle, when receiving drops from enemies. Script'Game_Pary' line 251: ArgumentError occurred, comparison of Nilclass with 1 failed . . .

I got the error when using your script. . .Any help?

 

[Tsukihime]

Cannot reproduce.


Does it occur in a new project?


Check if it's a script compatibility issue.

 

[Kurotsuke]

In a new project it doesn't, So after a long trial and error. It was not compatible with Yanfly Engine Ace - Adjust Limits v1.00

 

[ShadowLurk]

In a new project it doesn't, So after a long trial and error. It was not compatible with Yanfly Engine Ace - Adjust Limits v1.00

Yanfly' Adjust Limit has a weird method implemented upon loading a saved game. He implements level check like this.

#-------------------------------------------------------------------------- # alias method: on_load_success #-------------------------------------------------------------------------- alias on_load_success_al on_load_success def on_load_success on_load_success_al perform_level_check end #-------------------------------------------------------------------------- # new method: perform_level_check #-------------------------------------------------------------------------- def perform_level_check for i in 1..$data_actors.size next if $game_actors.nil? $game_actors.check_levels end endThe problem is that $game_actos will initialize actor when it is not initialized (so as long as $data_actors exists for it, it will never return nil). Initializing them will also init their equips. This causes a problem, as the equip data has not been merged yet at that point of time. Most of the problems are found with custom data that does not exist in original data structure, they are not copied properly. It will also confuse Instance Items script, as the instance data becomes weird.

 

If you don't need level above 99, then you can comment out these lines above.

 

[parafusion]

Hello, I have recently started using RPG VX Ace and the first scripts I used were of YANFLY's works. From there, I started using Tsukihime's scripts as well. This particular script is extremely useful but for some reason, I find there is a heavy compatibility issue between the Instanced Item Script by Tsukihime and many of Yanfly's scripts. For example, after installing this script, my game will always crash after loading into a save file. The funny thing is that if I start a new game, the game will not crash until I save and load. I've tested that at least one script will cause a crash with the Instanced Item script.

ACE Equip Engine which will cause the error "line 606: TypeError occured. can't convert nil into Array.

Temporary removing the instanced item script will prevent this crash from reoccuring which is how I deduced that the scripts are incompatible.

I would greatly appreciate If anyone can share some insights as to the root cause of this.

Thank you so much in advance!

 

[ShadowLurk]

I've never experienced such crashes with Yanfly's Equip Engine, after ditching Yanfly's Adjust Limit. What is this line 606 you are speaking?

Perhaps you use Yanfly's Adjust Limit? If so, please read the post before you.

 

[parafusion]

Thanks for your quick reply. Line 606 is part of this method

#-------------------------------------------------------------------------- # new method: sealed_etypes #-------------------------------------------------------------------------- def sealed_etypes array = [] array |= self.actor.sealed_equip_type array |= self.class.sealed_equip_type for equip in equips next if equip.nil? array |= equip.sealed_equip_type end for state in states next if state.nil? array |= state.sealed_equip_type end return array endand 606 is       array |= equip.sealed_equip_type

I have indeed read your post regarding Adjust Limit, to which I have never used in my project. However, I suspect that the origin of the error is similar as the system error would never occur until a game is loaded.

 

[Tsukihime]

Yanfly's scripts only load note-tags immediately after loading the game database.

In my script, the instance database is loaded after a save file is loaded or a new game begins, and does a force "reload instance database" because your specific save file's database is likely not the same as another instance database.

As a result, those custom objects do not have any of their note-tags parsed, and that's why you get your errors.

I think the first time I encountered it I went ahead and patched it up, but when I continued to get reports for dozens of his scripts I just didn't bother anymore.

As for a fix, you can try this

module DataManager  def self.reload_instance_database    $data_weapons = load_data("Data/Weapons.rvdata2")    $data_armors = load_data("Data/Armors.rvdata2")    $data_items = load_data("Data/Items.rvdata2")    load_instance_database    load_notetags_aee  endend

Which forcefully loads up all the note-tags again.

 

[parafusion]

The fix is perfect, and everything is working once again! Thank you so much!

 

[Tsukihime]

A patch for Falcao's Manastones Enchantment has been added


http://himeworks.com/2015/01/instance-items-with-falcaos-manastone-enchantment/

 

[Murd]

I have an error line 570: can't clone NilClass. The error happens when I call shop screen command.

Please help, thank you!