Community Core Script

The intention wasn't to limit anybody, but to create a set of default functions that we can rely on. Because the way it worked on previous RPG Makers, scripters always HAD to create a core script and force everybody to use it if they wanted to use any script from them.
They would then add every sort of basic functions to those core scripts and cause them to be incompatible with someone else's core, forcing people to choose only one scripter to pick their scripts from.


I never did any core script because I didn't want to force people into using 2 new scripts, but if we had a community core that were used by multiple scripters, I would just make my scripts use the functions from it.


In one way or another, you're already "limited" by the functions from the RGSS3 or "JGSS" in the case of MV and you'll need to keep all your scripts compatible with all there is on that.

This is still a horrible idea. 

First you wont have "multiple scripts" if you program properly, you will have one script that has all the script concatenated in it.  Second, if you are smart you'll provide two versions - minified and non minified for those who want to edit. Second "Core" is subjective to what you are doing, it is also suppose to me core functionality of your script, like common functions your script uses, common patterns and methodologies. It can also mean changing core aspects of the system - how ever since Javascript is not ruby and you cannot technically monkey patch or override functions (some one correct me if I am wrong, I don't work with prototypes ... ) so you wont have to (again in theory) have to worry is bobs scripts will screw over your scripts.

Second, to avoid that possibility you should scope your changes to "classes" for example

var ClassName = { functionName: function(){ ... }, functionNameTwo: function(param){ ... }};ClassName.functionName();And most of all you should never use "global variables" as it will mess with others peoples code, you should write immutable Javascript.

These are some ideas to get around your "core" script idea. 

Do you mean that there is no equivalent of Ruby's "alias" in Javascript?

Perhaps there are some common functions/patterns/methodologies that would be nice for all scripters?


Especially if the provided core scripts (ie: default project) is not written in a very flexible way.

There is :)

I dont think there is anything close to alias i javascript. if there is let me know I would be interested.

Also the one core methodology we need to all have is: immutability. Especially as it comes to people using these self executing javascript: (function() {}); Its less "secure" in terms of variables being mutated by other scripts them the concept of "classes" in ES5: var Class = { function() {}, ... }; In that example every thing is scoped inside the object.

By immutability, do you mean something like


1. I have an actor object


2. I pass the actor to a method


3. The method does something to the actor


4. the actor in the method has been changed, but the actor outside has not


?

 



Ok, yesterday I was trying to be nice. Now I can see that's not what you deserve. Do you know why we need a common core plugin? Victor Sant. Victor made many awesome features for games on Ace, as I'm sure you've seen, but his scripts downright sucked. Everything he did was overwrite other peoples stuff except his own. Every time Victor's core script was included in any project I've seen with other custom scripts, it broke something. With a community core script, we can expect most, if not all, scripts to be compatible with it. We can all suggest our own changes to it and then as it gets updated we can test it on multiple different projects with the help of others to ensure it's still in working condition.

I can also see, now, that you're quite a jerk. You directly claim that you are more experienced than Hudell in regards to javascript, and yet you don't even know you can alias and overwrite functions with the prototype. Is that a small part of Javascript? Maybe so. But for someone so experiences with it, you should know it like the back of your hand. You can writhe, squirm, and protest a community core script all you want, but it's the best chance we have to get MV coding standards before people just jump in and start to change things, and have horrible code that "just works". With the disappearance of Victor, I really though that MV had a chance at something nice and compatible, but I can clearly see that you don't intend to go by what is best for the community, and just want to be exactly like Victor, telling everyone else the incompatibilities are the other programmer's fault because your code is perfect and they broke yours. I'll be damned if I ever try to work with someone who programs like Victor again. 

I intend to have MV start with a set of community standards to keep everything as compatible as possible, and if you try to come in here and tell us that we shouldn't do that by insulting us and telling us "I'm better than you", then I'm sorry but the door out is to close the tab, because honestly we won't want anything to do with you. Everyone else is open to the idea of a community core because we can have well-made, common functions that benefit everyone and don't break everything.

/rant

Back onto the topic of a core script, 


 

One thing we could do is, within the community core script, segment our code. For example, in order to emulate the module structure from ruby, we'd something like this:

var Zale = Zale || {}; // Equivalent to Ruby's ||=Zale.PluginName = {};Zale.PluginName.value = 1;Zale.PluginName.awesomeFunction = function(arg1, arg2) { /* cool stuff here */ };So, what we can do in the core script is have different code sections for different purposes. That way if we have functions that are the same or similarly named, we have a better idea of what we're using and what it does. That can help resolve issues where you said you had 3 core scripts. We can make different sections for different purposes if we need to.

you got this from:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/call

Makes sense. I wont be writing my code this way, unless I need to. Good job on pointing this out. 

prototyping in javascript is something I try and avoid as much as I can.


Ya I now have 0 respect for you. Good were on the same page. Victor had some really good points and good coding standards for the time he was around in regards to how he wrote scripts. Immutability, modularity, documentation. This isn't hacking. This is programming. Yes we are writing scripts, but that doesn't mean we cannot have a sense of how to write them properly. Maybe if you would do some research you would see that self executing javascript is more dangerous for compatibility then "object based" that is where your classes are objects where the logic and the variables are encapsulated.

I don't pretend to be more experienced then any one here as I have just learned something rathe interesting about aliasing methods in javascript via prototyping. Really seems like you are interested in only what W3Schools can teach you.

So if attacking me because I don't know about alias is your cup of tea, low blow buddy. Because I even asked " if you can alias a method in javascript, show me" and they did and I learned, and I googled and I was blown away.

you can try and have the community use YOUR standards, but thats like herding cats. So good luck with that. What are you gonna do, not accept scripts that don't follow a specific programming methodology set down by the almighty god that you pretend to be? Ya no. try agin. (Now that was me being a dick).

I am all for community standards, as long as people are educated on things like immutability. Now I don't use prototype or any thing related to in my work, so yes I am less experienced there. I also think its not a good idea to globally declare functions, variables and such. I believe they should be neatly scoped and extended via proper programming related concepts and libraries that are out there. 

People are going to create there own core scripts and there own this and there own that - deal with it People approach problems different. people program differently. deal with it. you cannot force a community to program a specific way or use specific libraries, functions or core ideologies. Sounds like you you want every one to march to beat of your drum, i march to beat of my experience and the idea that I am WILLING to learn about new concepts and ideas as I have demonstrated here.

So how about you get off your high horse, calm down and continue with the convo.

I would say a core script should only include new functions, not overwrite default functions unless 100% necessary, if a plugin was to overwrite default functions, it should be a separate plugin.

I got it from no such place. I took it and reworded it from one of my functioning plugins :p

And if you intend to really write useful plugins for the community, and not just your own benefit, you are gonna have to get used to dealing with prototypes. :)

I would generally go for a core script something more a general thing's humm .....maybe more likes GLUMP made 

a precolor setting core so this avoid to do numeric stuff.

it's lazy but it's convenient's

because #lazycoding

but I do love premade method who permit to us to get more easier some stuffs 

likes a method who permit to get the actor withouth having to call the $gameParty.actor_id example.

so likes instead we can do Core.get_actorid(id);

so we could get more easier and more cleanier; 

than the default ways

Perhaps we can start by getting rid of direct access to those objects.

You would need too yes. But only to register your script at the end of the day :D

you can write all of your logic out side of the concept of prototypes and what not and then when you register with the core scripting "framework" register it inside a prototype based function, should be like two lines of code to register the core of your logic.

I would say no as some people might want access, me for example to get the variable to set into a state so that the state is changed and not the variable. this assume you meant remove as in I cant even get the value. if you mean where I cant set, then yes do that.

Immutability.

I'm coming at all of this as a total noob with regards to RPGMaker, but the idea of having a github based code library that is open sourced and has lots of contributors is what i used to do for a living when I worked at Yahoo. I was on the YUI team which was a library of code similar to say jQuery that had open collaboration and lots of contributors. I don't think trying to enforce some standard for all folks will work - the net is just too diverse for that - but I think the idea of creating a sort of jQuery for RPGMaker would be a cool idea, and publishing it as an open library that anyone could contribute to is a powerful one. So perhaps separate the idea of enforcing some standard of coding on folks, and instead try to promote the idea of a nice open source library that is open to third party contributions, and you might get more support.

Just my 2 cents, but I've kinda been there and know it's not only possible it can lead to great things. Thousands of folks including big companies used our library, and primarily because it was open source and was a highly active project.

Well, just like you said you're a total noob to RPG Maker, so I'm assuming you weren't here for Ace's glory days. The reason we want to get a script/plugin that provides a lot of common functionality as one big thing for the community is that Ace had a big problem with having little to no standards. It ended up causing quite a few compatibility issues, and many headaches for the scripters as time went on. So this time, were trying to make sure that doesn't happen in the same way by providing common stuff to the programmers so they don't make it themselves in a less-than-compatible way, and end up causing issues for game developers, and therefore other programmers who have to fix these issues.

Honestly, we probably won't get it right the first time. That's the point of putting it on GitHub. We want it to be under constant criticism and to receive recommendations and improvements from the community that's using it. It's whole purpose, after all, is really to make their lives easier, so it would make no sense to release it and then shut out their ideas.

One of the best things that happened for MV was when they released the HTML5 demo on the preorder page. Through there we were eventually able to get a copy of the scripts for the game, and, while they were still incomplete and in development, they gave us enough of a view to have a first draft ready by the day MV gets released. That, and along with all the 37+ official plugins, my "team", I suppose, and I have probably around 20-25 plugins ready between us to be released on Day 1.

I may or may not have 12 now... ;)

If only documentation wasnt SOOOOO DAMMMMNNN BOOOORRRIIIINNNNNNGGGGG!!

Its not, its super fun :D I love writing documentation.

I have 14 core scripts to release day one. They are not trivial scripts though so they will mostly end up in my system and then gradually released :D

Wtf 14 core scripts...

Dude... Just... No... Over and over and over...

there not core in the sense that were all familiar with. They are core to my game, example: One publishes party information and weapons, amor, plot points and so on to a third party server using ajax. Another adds the ability to see a monster calculate who it wants to hit and how it might plan that. Another adds new stats, and another adds alchemy. For bonus: One Adds new HUD elements for concepts like reaction, defending and so on.

They are core to my game. Not core to the system. For actual core scripts I will use Yanflies because she actually does pretty good programming