[Poll] Opinion on core scripts

[Zalerinian]

Some of the most popular scripters all have their own set of core scripts that a lot of their other scripts require you to use. I'm looking for people's opinion on their usage and to get a list of advantages and disadvantages that may come of it. Do you think core scripts are fine to make and use, or do you hate them for some reason? Please answer the poll and comment on anything you wish to further detail.

I am open to any comments you have regarding these types of scripts, and am trying to determine if creating my own core script that others of mine require, so please be as detailed as possible.

 

[Tsukihime]

"Core" scripts are not much different from any other script.


For example, I have 7 core scripts. They came into existence because I wrote one script that required some overwrites to a few methods, and then I wrote another script that required the same overwrites. I definitely don't want to require both scripts in the project, so I just pulled out the common stuff and called it a "core" script, even if it contains 4 methods that do nothing at all.


Core scripts do not make your scripts less compatible with others' scripts: the script would already be incompatible. Having the core script just means you can potentially increase compatibility between other scripts that need to mess around with the same methods.

 

[TheoAllen]

Meanwhile, I consider that core script provides most of basic functions of scripter's script. Rather than putting same method again and again, I prefer to collect them all in a single script. So all you need to do is put my core script all above my custom scripts. I know that core script sometime provides incompatibility among other script. That is why I divide my core script in different sections. You may disable one of them just by set it to false.

I don't really like core script that modifies default script a lot. Such as changing menus, HUDs, and how default script works. Core script should do nothing to default core mechanic, at least that shown in screen.

 

[nio kasgami]

In fact I use a lot of Graphics script who use the SAME method so it is really annoying for me to have to rewrite some code who can be really a lot annoying for me to rewrite each time for a another script...

if we take a exemple for a lot of my script I use a custom particle script but i don't want to be forced to rewrite each time the same portion for like...10 scripts? it is a lost of time for me and the user.

so naturally each method or class who can be use in multiple script I put them in a big ''core''...but I prefer call this a technical compilation who save a lot of time for editing~

 

[Engr. Adiktuzmiko]

I do like Core scripts because:


1) It keeps things that are shared in one place instead of each of your scripts having those identical methods


2) If you need to edit something that will affect all that uses it, you just need to edit in 1 place


3) Easier modularity

 

[Tsukihime]

I do like Core scripts because:


1) It keeps things that are shared in one place instead of each of your scripts having those identical methods


2) If you need to edit something that will affect all that uses it, you just need to edit in 1 place


3) Easier modularity

Some people may, however, treat their core scripts like a huge dump of absolutely everything that needs to be shared in multiple scripts.


I can't call them modular at all.

 

[Archeia]

The only core script that I use is Yanfly's but that's because it has bug fixes and graphical enhancements; All of which you can disable.

If there's another script that uses a core script I just don't use it entirely. I like standalone stuff.

 

[TheoAllen]

Talking about Yanfly's core, I do not consider it as a core script if it's according to my definition. Since all of Yanfly's scripts doesn't require Yanfly core to works. And it's optional. Well, maybe my definition is more appropriate to define 'Basic Modules' than core.

 

[Tsukihime]

It is pretty hard to make sure that every script your write requires a core script, without making your core script unnecessarily complex.

 

[BadMinotaur]

I know that core script sometime provides incompatibility among other script. That is why I divide my core script in different sections. You may disable one of them just by set it to false.

I was wondering if a good compromise between this and those who don't like Core scripts is to just separate your most commonly-used scripts from the Core script, and list them as dependencies. That way if someone wants just one script and doesn't want the cavalcade of features in the Core, they just download whatever dependencies they need for the one and call it a day.

If you were getting really fancy, you might be able to build a web-app that generates a mashed-up script using only the scripts they want and the dependencies they rely upon. Might be a pain in the bum if they decide they want another script later, but it's something.

 

[Kes]

I use Yanfly's Core engine, Battle engine and Menu engine, all of which are required by other scripts so I assume qualify as 'core' scripts (though I note the post above about the Core Engine).  It doesn't bother me in the slightest, and at least I can be sure that everything in those 3 spheres is fully compatible.  If I configure something in one of these 3, I know that all the others will follow suit in an orderly way.  Saves me having to repeat configure, which only multiplies the chances of a typo or something messing things up.

 

[Zalerinian]

One of the issues I have with having common methods be remade in each script that uses them is that if the order they're placed has no effect (they can put them wherever they want without it crashing), if I update one common method from one script then most if not all scripts would require an update. Additionally, if a dev gets their scripts at different times, and an older script with an older version of the method is last, then the newer script won't be functioning properly as it doesn't have the updated method its code expects.

That's my main problem with remaking everything. It involves more work for the scripter, needing to find and update any script of theirs that uses a certain method, and then more issues for users and the forums because there is a possibility that they'll post questions regarding any errors, when the problem just ends up being things placed in a bad order.

 

[Tsukihime]

I was wondering if a good compromise between this and those who don't like Core scripts is to just separate your most commonly-used scripts from the Core script, and list them as dependencies. That way if someone wants just one script and doesn't want the cavalcade of features in the Core, they just download whatever dependencies they need for the one and call it a day.

If I'm understanding the problem correctly, you have someone that is saying "hey, I'm using this method in 3 out of 100 scripts, but I REALLY don't want to duplicate that method across each script, so I'm going to put this method in my core script that all 100 scripts require!"


While the intention makes sense (less code duplication), the solution is strange. Even moreso when the common method is overwriting a bunch of things.

 

[Mihel]

The only core script that I use is Yanfly's but that's because it has bug fixes and graphical enhancements; All of which you can disable.

If there's another script that uses a core script I just don't use it entirely. I like standalone stuff.

Isn't Yanfly Ace Core Engine a 'core' script just in name? Most of his script are completely independent from it, or just use one single method (group digit of the Numeric class).

 

[Knightmare]

I'm not a scripter by any means but know enough to edit already existing code to do what I want in most occasions (usually window sizing or fitting in more text.)  I have several core scripts in my projects and for the most part compatability seems high with a couple exceptions.  I would rather have standalones than having a bunch of core scripts mostly just because I like to have as few scripts as possible in my script editor because it just seems easier to manage that way (as far as me being the user.) 

But like I said I don't know too much about the inner workings to know if it's actually easier or more compatible with other scripts but if it is well written where it doesn't mess with anything esle and I can turn off features I don't want and legitimately does maker things easier all around (for user and scripter) then it's worth having them.  But if it decreases compatability with other scripts and systems and is not user friendly where I can turn things off that I don't want then I would rather not have them. 

If it makes things a lot easier on the scripter then I see it as more beneficial since they are the ones writing it for people to use which is of course nice of them to do.  If that's the case I can get over the minor issues I have with them. 

 

[estriole]

i myself like tend to make my script not require any other script if possible (except some that really need them).

so i don't like using the core script concept. but that just me...

my concept is... people just need to copy one script and that's it...

of course there's a problem arise too...

for example. once... i update my notetags grabbing method with new regexp. so it can support multi line.

i need to edit 3 of my scripts to use the new regexp format too...

 

[Napoleon]

I also have mixed feelings about core scripts. And you need a lot of scripts before a core script becomes even worth it.

I do like victors core script because it has so many useful methods that I'd like to use anyway.

What I personally do right now:

I have a core script and my other scripts check if the core version x or higher script is present. If not then they will add their own methods. But if the core script is present then no extra code will be added and the up2date method from the core script is used instead. Like (pseudo):

if not core script present(1.01+)  Class Fixnum   <some extra methods here>  endend

 

[Galenmereth]

@Napoleon: That solution is just way more prone to error and inconsistensies. I'd either require the core script outright, or keep all scripts up-to-date with the methods in place in each of them.

 

[Onomotopoeia]

Voted A, C, A.


I like seeing modules and classes streamlined, as much as possible. If one scripter has two or more scripts that share similar functionality in any sense, it would for sure be a valid candidate for a Core script module or class.

 

[whitesphere]

I don't see a problem with having Core scripts.  The only thing is to use good coding practices, so, if the Core script has a lot of unrelated functions, it might be best to break it into smaller scripts, each within its own Module.

Otherwise, the "core" script gets so large it becomes difficult to understand and edit as needed, even for the script developer.