Mutable Items

[dbchest]

@Mako i gave this some thought and i cannot think of a good reason to incorporate it; if you are creating a common event to take place, then you are defining a set order of commands which will run in a specific sequence, so why would you take the long road of referencing the mutable item and asking it to mutate, when you can very easily perform the mutation via the "Change Items" event command? i use the same functions that event command uses to automate the mutation in the background, but if you are defining a common event then you can do it manually, you know?

this plugin was designed to allow item mutation to occur dynamically in the background.

 

[Mako]

I see what you are saying, and that is how I used to do things. Gets tedious, I thought having a script dynamically check your inventory to mutate specific items would make things easier for me. I was excited by the prospect. Maybe a bit of context would help you understand why I need this.

I have "realms" where items don't exist, when the player enters those realms his/her items are converted to what makes sense for that area. But this involves a one massive event that has to be added to every item..

 

[Joy Diamond]

Greetings Mako,

I have "realms" where items don't exist, when the player enters those realms his/her items are converted to what makes sense for that area. But this involves a one massive event that has to be added to every item..

What a wonderful game concept! And very nicely explained succinctly also.

It really would not be very simple to implement also.

The hardest part actually would be to coming to agreement on:

• How to architect this;

• Licensing of Architecture discussion & final plugin (for me MIT license would be the preference)

• The current license to Mutable Items (which these changes should be based off to make it easy) is:

Author's Notes
Free for use in both commercial and non-commercial projects.
Accreditation is not required but it is appreciated.

This is pretty much 100% compatible with the MIT license & with it's spirit.​

• To an extension to this would require:

• Asking dbchest if he is willing to convert to a formal MIT license;

• Having this license appear in the actual source code, in addition to in the forum post I linked to above.

Please send me a PM if you want to follow up more (that way we don't spam this thread).

• I *know* this sounds really really complicated for a simple plugin; however, it lays the proper foundation to build the plug in up later with multiple contributors.

Thanks,

Joy Diamond.

​

 

[dbchest]

@Mako okay, so what specifically do you need? a plugin command that you can use to force mutation?

 

[Mako]

Yes, that would be great!

 

[dbchest]

@Mako the last question i have for you is whether or not this custom plugin command forces mutation a single specified mutable item or does it force mutation on every item in the party's inventory?

edit
this plugin has been updated to version 1.2.0. see initial post for more information.

edit
i would like to add notification support of mutating items; does anyone have ideas of a good way to notify the player? i feel like using the message window could be cumbersome, but what do you guys think?

 

[Maliki79]

I think that notifications should be left to the devs to decide on.
That said, maybe there should be a lunatic mode like eval for when an item changes.
Then the devs could enter their own code for whatever messages or sounds or whatever they want.

 

[dbchest]

I think that notifications should be left to the devs to decide on.

that is obvious, but not all developers have programming knowledge and those developers would probably be grateful to have some basic options to choose from.

That said, maybe there should be a lunatic mode like eval for when an item changes.
Then the devs could enter their own code for whatever messages or sounds or whatever they want.

i have no idea what a lunatic mode is.

 

[Maliki79]

It's basically a term used by Yanfly to depict when users of his plugins can enter JS code to personalize effects. Typically, it's just a way to put a more user friendly eval system in his plugins.
So, unless you plan on making updates for the various message and sound systems people are using, a Lunatic mode eval might be your best shot.

 

[Mako]

@dbchest for my game the entire inventory, but that is a bit selfish. I think for the plugin's sake it is better for a single item, gives the user more control. I can put in the extra work...

 

[dbchest]

@Mako it is not a difficult thing to iterate over every item currently in the party's possession; i can incorporate plugin commands for both wide-scale mutation and individual mutation. i was thinking about this earlier and i have the functions planned out in my head; this should be able to be included; i will add it to the planned updates section of the first post so i do not forget.

 

[Clock Out]

Nice work here! I like to read code and thought I'd give a few suggestions.

Some lines run really long. A programing text editor will have a way to set a vertical line on the right side to indicate when to return. A common length is 80 columns per line but use whatever makes you happy. The goal is consistency.

The Game_MutableItem() constructor function is split for no apparent reason. The methods of Game_MutableItem.prototype are defined in an IIFE (Immediately Invoked Function Expression) but don't appear to access local variables in the IIFE. They can all be moved outside. Same with DataManager.isMutableItem().

Where reasonable, define methods before they're used for easier reading. The initMembers() method calls 3 functions lower in the code. So I have to scroll down to read those, then scroll back up.

It's curious that 4 methods are defined to get the values of the "private" properties _stepCount, _successRate, _nextId, and _id but are never used. As an aside I think underscored names are ugly and useless.

Use shorter variable names. Why can't _Game_Party_gainItem_gainMutableItem just be gainItem, originalGainItem, or oldGainItem?

Math.floor() and Math.ceil() are used but don't seem necessary. Math.ceil(0) will be 0 and Math.floor(100) will be 100. Math.floor(data.length) also seems unnecessary since the length property of strings and arrays are whole numbers.

Anywho, this is good stuff so keep up the good work.

 

[dbchest]

@Clock Out hey! thanks for your input. i will be upfront with you; i never took a formal programming class, so my plugins are a reflection of what i was able to teach myself through reading the default functionality. considering that, let me try to address some of your findings!

Some lines run really long. A programing text editor will have a way to set a vertical line on the right side to indicate when to return. A common length is 80 columns per line but use whatever makes you happy. The goal is consistency.

i use komodo edit as my JavaScript editor; when i first began writing plugins, i did try to conform to a certain number of characters per line, but nowadays i just ensure each line does not expend beyond the page; everything is good so long as i do not have to scroll. XD.

The Game_MutableItem() constructor function is split for no apparent reason. The methods of Game_MutableItem.prototype are defined in an IIFE (Immediately Invoked Function Expression) but don't appear to access local variables in the IIFE. They can all be moved outside. Same with DataManager.isMutableItem().

placing the constructors outside of the IIFE was something i saw done several times within some of Kadokawa's additional plugins and so i adapted it to my personal plugins because i did not see anything wrong with it; it is just a preference.

Where reasonable, define methods before they're used for easier reading. The initMembers() method calls 3 functions lower in the code. So I have to scroll down to read those, then scroll back up.

this is something i tend to struggle with from time to time, because i make an effort to follow a strict convention throughout all of my plugins, but it never works out the way i want it to universally, haha. most of the time i try to define functions directly below the function that referenced them, but there are other times i break this convention when i believe it promotes my vision of organization.

It's curious that 4 methods are defined to get the values of the "private" properties _stepCount, _successRate, _nextId, and _id but are never used. As an aside I think underscored names are ugly and useless.

i include access to private variables because i never know which project i may end up using this plugin for and where i might want to reference it from a separate plugin; as a general rule for myself, i include functions for providing access to those variables for this reason. as far as the underscore naming convention goes, that is another one of those things i see used often to help private instance variables stand out; just another practice that i adopted.

Use shorter variable names. Why can't _Game_Party_gainItem_gainMutableItem just be gainItem, originalGainItem, or oldGainItem?

those suggestions are very generic in my opinion, and to ensure maximum compatibility i try not to give my aliases a name that has a moderate chance of being duplicated by another plugin that aliases the same function.

Math.floor() and Math.ceil() are used but don't seem necessary. Math.ceil(0) will be 0 and Math.floor(100) will be 100. Math.floor(data.length) also seems unnecessary since the length property of strings and arrays are whole numbers.

i had to search online through mozilla's official JavaScript reference to find the method for generating a random number, and so i copied and pasted the practical example from there; i did not feel the need to shorthand it.

what do you think, bud?

 

[Indsh]

Plugin breaks when you try to equip an item whilst its running

 

[dbchest]

i was unable to recreate the fault; i used an event to change the party's equipment, adding an axe. then, i equipped it from my menu.

 

[Indsh]

Must be one of mine, hopefully i can sort it out. Got used to the idea!

 

[Clock Out]

placing the constructors outside of the IIFE was something i saw done several times within some of Kadokawa's additional plugins and so i adapted it to my personal plugins because i did not see anything wrong with it; it is just a preference.

Yeah, they do it for no reason too. That's not a good argument for why you should do it.

Here's how I see it. It's like you got a buddy with a beautiful workshop that he has divided up where one side is for working with wood and the other is for working metal. He's over on the metal side slapping dead tree carcasses together and he keeps having to cross the room to get his tools. So you say, partner, why not move the work closer to the tools? He's says, that's just my preference. Nothing wrong with it, mind. "Just because" isn't a good argument for working that way and at most it just confuses people from the outside looking in (me).

So I'm saying the implementation code for the constructor has no reason to be inside the IIFE for the same reason the tree carcass should be butchered on the side of the shop with the needed tools.

i include access to private variables because i never know which project i may end up using this plugin for and where i might want to reference it from a separate plugin; as a general rule for myself, i include functions for providing access to those variables for this reason. as far as the underscore naming convention goes, that is another one of those things i see used often to help private instance variables stand out; just another practice that i adopted.

Your practice is to never use the methods in the prototype methods and always use them for outside code. It's just that it doesn't make any sense because JavaScript can have "private instance variables." Why make pretend "private instance variables" and not the real kind?

those suggestions are very generic in my opinion, and to ensure maximum compatibility i try not to give my aliases a name that has a moderate chance of being duplicated by another plugin that aliases the same function.

The alias names are local to the IIFE. They can't conflict with the names other plugins use. The code is protecting something for no reason which is confusing.

i had to search online through mozilla's official JavaScript reference to find the method for generating a random number, and so i copied and pasted the practical example from there; i did not feel the need to shorthand it.

I find myself going to Mozilla's web docs time and time again for that exact piece of code! That's not what I'm talking about though.

var min = Math.ceil(0);

So this says declare a variable named min then assign to min the return value of a method that rounds 0 up. What do you get when you round 0 up? It's 0. So simply write:

var min = 0;

Similarly:

var max = Math.floor(100);

Says declare a variable named max and then assign to max the return value of a method that rounds 100 down. What do you get when rounding 100 down? 100. So this should simply be:

var max = 100;

Finally:

var max = Math.floor(data.length);

The length property will be a whole number. When rounding a whole number you get the exact same number back. If we had a length of 0 then rounding it down will return 0 and if we had 300 then rounded down it would be 300. Simply write:

var max = data.length;

The code is shortened by removing the needless rounding.

 

[dbchest]

Yeah, they do it for no reason too. That's not a good argument for why you should do it.

Here's how I see it. It's like you got a buddy with a beautiful workshop that he has divided up where one side is for working with wood and the other is for working metal. He's over on the metal side slapping dead tree carcasses together and he keeps having to cross the room to get his tools. So you say, partner, why not move the work closer to the tools? He's says, that's just my preference. Nothing wrong with it, mind. "Just because" isn't a good argument for working that way and at most it just confuses people from the outside looking in (me).

So I'm saying the implementation code for the constructor has no reason to be inside the IIFE for the same reason the tree carcass should be butchered on the side of the shop with the needed tools.

i am not actually in favor of one way or the other; i simply did not know better, but now that i am educated, this is definitely something i can work with to do better for future iterations of this plugin and others.

Your practice is to never use the methods in the prototype methods and always use them for outside code. It's just that it doesn't make any sense because JavaScript can have "private instance variables." Why make pretend "private instance variables" and not the real kind?

i see what you mean; whether or not to include public access to a variable is a decision that should be made when it is declared and based on its role in the plugin, and the functions then included should be consistent with those decisions.

The alias names are local to the IIFE. They can't conflict with the names other plugins use. The code is protecting something for no reason which is confusing.

ugh, haha. the joke is on me then. still, i do not know if i will alter my naming convention or not.

I find myself going to Mozilla's web docs time and time again for that exact piece of code! That's not what I'm talking about though.

var min = Math.ceil(0);

So this says declare a variable named min then assign to min the return value of a method that rounds 0 up. What do you get when you round 0 up? It's 0. So simply write:

var min = 0;

Similarly:

var max = Math.floor(100);

Says declare a variable named max and then assign to max the return value of a method that rounds 100 down. What do you get when rounding 100 down? 100. So this should simply be:

var max = 100;

Finally:

var max = Math.floor(data.length);

The length property will be a whole number. When rounding a whole number you get the exact same number back. If we had a length of 0 then rounding it down will return 0 and if we had 300 then rounded down it would be 300. Simply write:

var max = data.length;

The code is shortened by removing the needless rounding.

this was just laziness on my end; i copied and pasted the sample code from the mozilla reference and plugged values in where required. since you are roasting me for it, i will most likely clean this function when i update this plugin, haha!

@Clock Out i appreciate your busting my balls a little and helping to educate me. it will go a long way in the long run.

 

[Indsh]

Iv tried make edits to my core engine as a work around to the bug with no success, in those attempts I created a new project just to test this fault, in a new game changing the first weapon was fine but trying to remove the default Armor resulted in the same bug leading me to belive this is a Universal bug.

Has anybody actullyplay tested the plugin in what ever the normal conditions are for your game and @dbchest could you give this one another look.

So to recap on a completly new project with only this plugin running, removing default Amour will result in a crash.

 

[dbchest]

i will absolutely look into this for you @Indsh. thank you for bringing it to my attention once again.