Improving $imported (7/23 Update: Start suggesting keys/values!)

[Galenmereth]

Versions should be done like this: Major.Feature.Minor

As in: 1.1.2 is Major version 1, Feature version 1, and Minor update 2.

A Major version bump means a redesign/restructuring that might break backwards compatibility. It is generally used when major parts of the script/software is rewritten or changed, enough so that it makes significant changes to the core fundamentals of the code.

A Feature version bump means the addition of a new feature, but generally without breaking backwards compatibility.

A Minor update version bump means fixing a bug, or updating the performance, or similar "non-feature" updates.

This is how versions are usually used, and I'd recommend scripters do the same

 

[sokita]

by any chance, this thing can be used as switch for scripts too, right? 

kinda, if this script is true, that script will canceled, set to false, and removed from array (or hash?).

So, if we can build a public library of known compatibility...

but, how about little snippet or short script? They need to be included in $imported too?

 

[PK8]

by any chance, this thing can be used as switch for scripts too, right? 

kinda, if this script is true, that script will canceled, set to false, and removed from array (or hash?).

In a way. One idea I had in mind for a key/value pair was to get scripters to use a key such as :enabled to determine whether a script was turned on or off. If someone were to set a script's :enabled key to false, it would hard disable the script. In order for that to work, the scripter would have to wrap their entire script around an if conditional, like this:
#==============================================================================# ** Begin $imported Enabled Check#==============================================================================if $imported[:yourscripthere][:enabled]# <Insert your entire script here>#==============================================================================# ** End $imported Enabled Check#==============================================================================endIt would still be up to the scripter to provide their own soft disable switch.Also, if the script were disabled by turning off :enabled in its own hash, it would still be considered imported but just not in an enabled state. Though if you just want a list of scripts that are enabled, you could perform a check for scripts that are both imported ($imported[key]) and enabled ($imported[key][:enabled]).

So, if we can build a public library of known compatibility...

but, how about little snippet or short script? They need to be included in $imported too?

Yes, those too. It's not required to use $imported, but it helps.
Edit: To anyone reading this topic, I have started another thread which is related to this one. What I'm proposing there (See: $imported[:SCRIPT_LIST]) would function as a companion to what I'm proposing here. Look at that thread for more information.

Also, if anybody would like to start suggesting key/value pairs (For example, :enabled) that could be used here, go right ahead!

 

[Zackwell]

10/10 would use if I were a scripter.

 

[Ultim]

It's pretty useful for comptability patches soo...No harm in improving it

 

[PK8]

7/24 Update: Old versions of my implementations of suggested pairs are in nested spoilers.

I guess I should finally get started on abruptly changing the topic and start suggesting key/value pairs we could use for our scripts. None of these listed below are set in stone, so anyone is welcome to agree or disagree with any of the proposed implementations of certain pairs. Let's get started.

Information

Script Name

Spoiler

:name => 'Your Script's Name'The name of the script being installed. Should be a string.

I'm not sure whether this key should be :name or :title.

Script ID

Spoiler

:id => YOUR_SCRIPT_IDThe ID of the script being installed. Can be a symbol or a string. Generally should be the same as your $imported key.

This may be redundant but it should allow scripters to search through the $imported[:SCRIPT_LIST] array for their IDs.

Version Number

Spoiler

:version => 'x.y.z'The script's version number. Should be a string.

Date (Last revised)

Spoiler

:date => 'YYYY-MM-DD'The script's last revision date. Should be a string. Must be written in ISO8601 format. There are good reasons why.

Author (Revision 1)

Spoiler

:author => ['Author 1', 'Author 2', ...]The script's author(s). Currently proposed to be an array consisting of strings to allow scripters to specify multiple authors.

:author => 'Author'

The script's author(s). Can be either a string or an array consisting of strings. The latter would denote multiple authors.


CompatibilityEnabled Script

Spoiler

:enabled => booleanThe script's enabled state. In order for this to be used effectively, the entire script (save for the import check and the header) should be wrapped in an if conditional that determines whether or not the script has been enabled.

if $imported[:yourscripthere][:enabled] <your script>endThe implementation and default value for the script will need some work and input put into it.

Aliased Methods (Revision 1)

Spoiler

:aliased => { :Class_Name => [[ld_method, :new_method], [ld_method_2, :new_method_2], [ld_method_3, :new_method_3], ...],  :Class_Name_2 => [[ld_method, :new_method], [ld_method_2, :new_method_2], [ld_method_3, :new_method_3], ...] }:aliased will consist of a hash. The nested hash's keys will be named after the Class/Module name. Their values will be consist of an array housing a list of arrays that contains two items: the original method name and the aliased method name. This is how it would look in a script.

$imported[:username_yourscriptname] = { :aliased => { :Scene_Title => [ [:create_background, :un_ysn_create_background], [:create_foreground, :un_ysn_create_foreground], [:dispose_background, :un_ysn_dispose_background], [:dispose_foreground, :un_ysn_dispose_foreground] ], :Scene_Map => [ [:transition_speed, :un_ysn_transition_speed], [:fadeout_speed, :un_ysn_fadeout_speed], [:transition_speed, :un_ysn_transition_speed], ] }}I'm trying to decide whether the class/module names and methods should be written as symbols or as strings. What do you guys think?

:aliased => { :Class_Name => [[:new_method, ld_method], [:new_method_2, ld_method_2], [:new_method_3, ld_method_3], ...], :Class_Name_2 => [[:new_method, ld_method], [:new_method_2, ld_method_2], [:new_method_3, ld_method_3], ...] }

:aliased will consist of a hash. The nested hash's keys will be named after the Classes/Modules. Their values will be consist of an array housing a list of arrays that contains two items: the aliased method name and the original method name. It's arranged in this order to maintain consistency with alias_method. This is one way on how to include a list of aliased methods (an alternate method is below).

$imported[:username_yourscriptname] = { :aliased => { :Scene_Title => [ [:un_ysn_create_background, :create_background], [:un_ysn_create_foreground, :create_foreground], [:un_ysn_dispose_background, :dispose_background], [:un_ysn_dispose_foreground, :dispose_foreground] ], :Scene_Map => [ [:un_ysn_transition_speed, :transition_speed], [:un_ysn_fadeout_speed, :fadeout_speed], [:un_ysn_fadein_speed, :fadein_speed], ] }}An alternate means of implementing it would be to create an empty hash within your $imported key.

 :aliased => {}

And then adding this code below a group of alias_method/alias calls.

$imported[:yourscripthere][:aliased][:Class_Name] => [  [:new_method_1, :old_method_1],  [:new_method_2, :old_method_2],  [:new_method_3, :old_method_3],]

Overwritten Methods

Spoiler

verwritten => { :Class_Name => [:method_1, :method_2, :method_3, ...], :Class_Name_2 => [:method_1, :method_2, :method_3, ...] }verwritten will consist of a hash. The nested hash's keys will be named after the Classes/Modules. Their values will be consist of an array housing a list of symbols named after methods that were overwritten in the script.

Like Aliased Methods, I'm trying to decide whether these should be written as symbols or strings.

Defined Methods

Spoiler

:defined => { :Class_Name => [:method_1, :method_2, :method_3, ...], :Class_Name_2 => [:method_1, :method_2, :method_3, ...] }:defined will consist of a hash. The nested hash's keys will be named after the Class/Module name. Their values will be consist of an array housing a list of symbols named after methods that were defined in the script.

Like Aliased Methods, I'm trying to decide whether these should be written as symbols or strings. I'm trying to figure out how this would work for defined classes/modules.

MiscellaneousTags

Spoiler

:tags => [:item_1, :item_2, :item_3]Not quite as necessary as most of the other suggested key/value pairs. This allows scripters to further identify their scripts by freely attaching keywords to their $imported keys. An example of a tag could be a very quick description of what the script does. (Examples: :battlesystem, :easing, :eyecandy)

Trying to decide whether these should be written as symbols or strings.

CancelledScript Set (Revision 1)

Spoiler

:set => ['Set 1', 'Set 2', ...]Specify which set(s) the scripts may be a part of, if any. Currently proposed to be an array consisting of strings to allow scripters to specify multiple sets.

I'm sure this could use a little refining. I'm not sure whether the key should be named :set, :group, :engine, or :library. Is this necessary?

:set => 'Set'

Specify which set(s) the scripts may be a part of, if any. Can be either a string or an array consisting of strings. The latter would denote multiple sets.

I'm sure this could use a little refining. I'm not sure whether the key should be named :set, :group, :engine, or :library.


Two other key/value pairs I'd like to suggest (little thought was put into these so I'm not sure if these might actually be necessary) are:

• Something involving method branches.
• Licenses.

 

[Galenmereth]

One question: Where do we put all this "metadata" boilerplate without inconveniencing non-scripter users? Any recommendations?

 

[TheoAllen]

Even though I agree these kind of concept. But adding alias and overwrite methods list seems overkill to me.

I have 4000 lines of code and I have to list them all including the new methods, I probably got bored before I released it into public. Write the instructions itself already took all of my power (exaggerating indeed).

 

[sokita]

How about using a mechanic outside the original script. I mean, scripters only need to write his/her data like name, version, and maybe compatibility keys, then the $imported mechanism (maybe a standalone script) will handle it. $imported mechanism scripts will deserve it's thread than updated every now and then (updated only when there are incompatibility within scripts, maybe). This is just a rough idea....

 

[Tsukihime]

All of those aliasing and things really should be something that's automated. It does not take much effort to scan a code file looking for aliases and defined/overwritten methods.


Anything that's newly defined, does not exist in the RTP codebase.


Anything that's overwritten, was already defined in the RTP codebase and is not aliased.


Unless there are significantly different ways for people to alias methods beyond `alias` and `alias_method`, it should not be an issue.


It becomes a bit more difficult for people that enjoy meta-programming.


If that is the plan, then great.


Otherwise, I doubt you will get much adoption there.

 

[PK8]

Fortunately, nothing that's being proposed here would be required to use. Everything there is completely optional to include in your script.

One question: Where do we put all this "metadata" boilerplate without inconveniencing non-scripter users? Any recommendations?

Unless the average user happens to have Script A installed onto their project that requires checking Script B's version with an if condition written like this...
if $imported[therUser_ScriptB] >= 1.5...and Script B happens to have implemented Expanded $imported, then there's nothing to worry about. Expanded $imported should have no effect on the average RM user.Also, we would be putting this above our scripts and below our headers. I'll ready a template once all of this gets finalized.

Even though I agree these kind of concept. But adding alias and overwrite methods list seems overkill to me.

I have 4000 lines of code and I have to list them all including the new methods, I probably got bored before I released it into public. Write the instructions itself already took all of my power (exaggerating indeed).

I agree that I might be going overboard with the aliased/overwritten. I'm hoping for something automated to come along too. Thankfully, you don't have to include those in your $imported key hash if you don't want to.

How about using a mechanic outside the original script. I mean, scripters only need to write his/her data like name, version, and maybe compatibility keys, then the $imported mechanism (maybe a standalone script) will handle it. $imported mechanism scripts will deserve it's thread than updated every now and then (updated only when there are incompatibility within scripts, maybe). This is just a rough idea....

You won't have to use everything I suggested so far. Everything you see there is completely optional to include. So if you want to just include the basics like the script name, the date, the author, the id, and the version; you could do that.

All of those aliasing and things really should be something that's automated. It does not take much effort to scan a code file looking for aliases and defined/overwritten methods.

Anything that's newly defined, does not exist in the RTP codebase.

Anything that's overwritten, was already defined in the RTP codebase and is not aliased.

Unless there are significantly different ways for people to alias methods beyond `alias` and `alias_method`, it should not be an issue.

It becomes a bit more difficult for people that enjoy meta-programming.

If that is the plan, then great.

Otherwise, I doubt you will get much adoption there.

Yeeeeeeeeeeeeah, you're right... ^^;
An alternate solution I was thinking one could do is give the :aliased key an empty hash, scroll down and then attach data below a line that uses alias/alias_method. Like this:

    alias_methodpk8_sce_active?, :active?)    $imported["PK8_Switchless_CE"][:aliased][:Game_CommonEvent] = [      [k8_sce_active?, :active?]    ] So should I ditch the Aliased/Overwritten/Defined keys?

 

[Galenmereth]

Sounds good PK8.

I feel like I should continue working on that script management GUI app I've been tinkering with. If we could automate all of this and also make script installing / managing easier for both scripters and RMers in general, then this would be a much easier job to implement in a more widespread manner.

 

[Tsukihime]

So should I ditch the Aliased/Overwritten/Defined keys?

There's nothing wrong with them. It's the kind of information that would make it easier to navigate your script, identify what you've changed, and so on.


I just don't expect anyone to do them manually.

 

[PK8]

There's nothing wrong with them. It's the kind of information that would make it easier to navigate your script, identify what you've changed, and so on.


I just don't expect anyone to do them manually.

I agree, actually.
I was thinking, once this gets finalized, I could start putting together a workshop thread where someone can submit their script to have their $imported key completely redone. That might be able to speed things up a bit in terms of getting this adopted.

 

[estriole]

for automated scripts... we can scan the $RGSS_SCRIPTS variable before it interpreted...

to detect alias, overwrite, etc. and basically even everything if we have strong regexp knowledge.

also... since scripts interpreted sequentially. maybe.... the automated scripts should be placed above all other custom scripts... it will scan the $RGSS_SCRIPTS variable. and grab all scripts imported settings (it will redefined again later in the real scripts... but that's won't change the order i guess... it will only rewrite the existing hash element..).

so if there's case like this:

Script A

Script B (require script C)

Script C (require script A)

we can throw error that the placement of the scripts is incorrect.

but if the case changed to:

Script A

Script B (require script C)

(We didn't install script C)

we can throw error that no Script C installed...

viable?

if we don't scan it at the top... then we won't be able to differ those two case above. since when scripts B interpreted. scripts C will not enter imported setting in both cases.

edit:

and instead of scanning each project run... we can write the imported hash result to a file.

then only rescan if there's some changes in the $RGSS_SCRIPTS. else load the file.

so it will only delay at the first run...

 

[Tsukihime]

The purpose of using a ruby hash is so that you know the order in which scripts were inserted.

 

[FenixFyreX]

@Tsuki - that only holds up for Ace, hashes are unordered in Ruby < 1.9...I think you mean the whole purpose of $imported[:SCRIPT_LIST] is to know what order the scripts are in?


@estriole - How do you propose we check if the file has changed without loading it in and checking agains $imported anyway? Maybe we could throw in a md5sum check to the file; that is secure, and (sorta) efficient? But then we are borderline making an import script, which $imported is used to deter to begin with..

 

[estriole]

@FenixFyrex: md5sum check is a nice idea...

what i'm saying before is only this though >>>

we could write the 'current' Scripts.rvdata2 with another filename at the end of process. and add some comparison with Scripts.rvdata2 at the start of process. if it's identical. then use the existing hash created in previous test play.

i'm not too good at explaining. so this might explain better:

first test play:

- since this is the first test play. nothing to compare with Scripts.rvdata. thus proceed to process.

- process to create the imported hash and write it in a file.

- create a backup copy of Scripts.rvdata2 (maybe name it PrevScripts.rvdata2).

second test play. (after modifying the scripts)

- compare PrevScripts.rvdata2 with Scripts.rvdata2 (there's some changes) so proceed to process.

- process to create the imported hash and overwrite it in last hash file.

- overwrite PrevScripts.rvdata2 with the current Scripts.rvdata2.

third test play (no modification done at all)

- compare PrevScripts.rvdata2 with Scripts.rvdata2 (there's no changes)... skip the process

- load the last hash file and proceed to game.

hope i explain it clearly.

 

[PK8]

I'm not sure if I misread your post but I feel like we'd still be running the risk of requiring things if we did that, which is something I feel should be avoided.

A few days ago, I came up with some new ideas for pairs. I also cancelled :set because I didn't put a lot of thought into it.

New ideas for keys are:
Script Description:description => 'Describe your script here'Provide a description of the script being installed. Should be a string.

Script URLs

:url => 'http://yourwebsite.com/0-your-script.htm' A list of addresses the end-user could turn to whenever they're looking for support or to update your scripts. Can be a string or an array consisting of strings.

Script Media

:media => 'http://yourwebsite.com/screenshot1.png'Originally intended to be two separate keys, :images and :videos, I decided to merge the two (unless people suggest otherwise). The value should be an address or a list of addresses the user could use to view screenshots and videos that demonstrates how to use the script as well as how it functions. Can be a string or an array consisting of strings.

Your Website(s)

:website => ['http://yourwebsite.com', 'http://youtube.com/user/username', 'http://facebook.com/username'] A list of addresses the end-user could use to reach you or one of your profile pages on social media. Can be a string or an array consisting of strings.

What do you guys think of these?

 

[??????]

I think some of the key/value [pairs are a great idea and would be happy to adopt such things for my own scripts; however, i also think some of the proposed k/v's are completely unnecessary.

Quite a few of them are information that would generally be contained within a script header, such as author, version, description etc.

Also, just an afterthought, but...

If we started adding all this extra data into the $imported variable, wouldn't it cause performance loss to some degree ?

I mean... Many people have already complained previously about having to use $imported and how $imported is just data 'lying around doing nothing'.

Really, if one was going to go into so much effort just to check is certain scripts are currently in the project, wouldn't a much better approach be something similar to victors module that checks imported scripts ?