Delete Account Please

(RMRK+ Format is just something I have decided to invent. I am taking the name 'RMRK' in vain mostly because 'Modern Algebra Format' makes me sound like a prick and I can't think of a better name right now. If anyone has any suggestions, I am waiting, hoping for you to post. I will try to think of a more appropriate name for it, but for now)

Introduction

What is an RMRK+ Format Event System?

The major problem with creating Plug & Play systems in RMXP is that you almost always need to have the user of the system select which variables and switches are being used. This is a huge hassle for the user, who has to find everywhere that specific switch or variable is used in the event system and change it to the one he wants to use, since the maker of the event system cannot predict what switches and variables are already being used by the person who wants to use his system.

RMRK+ Format is designed to avoid that problem through two ways. (1) a series of guidelines for creating an efficient event system which reduces incompatibility, and (2) by maintaining a catalogue of variables and switches used in all previous RMRK+ Format Event Systems. In theory, this will mean that each and every RMRK+ Format System will be able to be plugged into any game without any hassle and without any incompatibility. This format should also function, to a smaller degree, as a guarantor for quality.

In short, RMRK+ Format is intended to ensure that any user will be able to plug in any RMRK+ Format event systems with minimal effort, and that it will be a quality event system.

Does this mean I can’t get my non-RMRK+ Format Event System moved into the database?

Not at all. RMRK+ Format will not be an enforced standard. All Event Systems are still welcome and the standards for having an event system moved in is still the same: http://rmrk.net/index.php/topic,19805.0.html.  What it does mean though, is that you are not able to advertise the system as RMRK+ Format, and you do not receive the benefits of RMRK+ Format.

The Requirements

An RMRK+ Format system has only four major requirements:

• You cannot use variables and switches reserved by other RMRK+ Format Event Systems
• The Event System must have a demo
• The Event System cannot be stolen from another Eventer. Permission to convert the system to RMRK+ Format must be granted by the original Eventer, and that Eventer must be given due credit
• The system must be of good quality. A system that is of poor quality (inefficient, likely to cause lag when combined with other systems, etc…), may be refused acknowledgement as RMRK+ Format

Reserved Variables, Switches, & Common Events

Let’s start by defining which variables, switches, and common events should be reserved. First, any variables a user is reasonably expected to use to create his/her own systems and to advance their game. Since we cannot be sure, for obvious reasons, what these are, we will try to be safe and reserve variables 1-500, switches 1-800, and common events 1-50 for the user.

Next, we should also reserve temporary variables. These would be variables which can be used by any RMRK+ Format system. This means that prior to running each frame of the event system, we cannot expect these to have values, and at the end of each frame, we cannot expect them to save values to be used at a later time. In short, these are variables which should be internal to the event system. Basically, any RMRK+ Format Event System should be able to access and use these variables without interfering with another RMRK Format Event System. For this reason, you should not use these temporary variables in any situation where you could reasonably expect another RMRK Format System to be running. We will reserve 20 variables to this purpose, and so 501-520 are reserved as Temporary Variables. It is less useful to reserve switches to this purpose and so we will not bother.

Now, we should also reserve common-use variables. These would be variables which can be expected to hold the same value in any RMRK+ Format event system that is being run at the same time. The most commonly used variables of this sort are: Player’s Map X, Player’s Map Y, Player’s Screen X, Player’s Screen Y, Map ID. In any system in which these are used, they should be set in the event before using, and they cannot be modified in any way after setting them (I.E. Do not operate on these variables). You can use them in a conditional, but do not modify the value contained by these variables after you set them.  Again, it is not worthwhile to reserve any switches for this purpose.

Now, as to using common events: You do not need to reserve common events for any common events which have a trigger upon a switch. The only common events it is necessary to reserve are ones which you call through the event command Call Common Event. This is simply because any common events triggered by a switch can be pasted into any slot and will still work. The only reason to reserve a common event is if it is called through event commands.

Reserving Variables, Switches, & Common Events

You can reserve variables, switches, & common events for your own system by posting in this topic when you begin making your system. They will remain reserved for one month. Upon completing and submitting your system, the variables, switches, and common events you used will be reserved permanently.

Reserved Variables Catalogue

1-500    ~ User variables
501-520 ~ Temporary Usage Variables
521-526 ~ Common Usage Variables (521 - Player's Map X; 522 - Player's Map Y; 523 - Player's Screen X; 524 - Player's Screen Y; 525 - Map ID; 526 - Gold)
527-546 ~ modern algebra's BlackJack (being converted)
547-558 ~ Kipe's Level Up Effects
559-       ~ Unreserved

Reserved Switches Catalogue

1-800     ~ User Switches
801        ~ General Information Switch - used to enclose large chunks of comments
802-805  ~ Kipe's Level Up Effects
806-       ~ Unreserved

Reserved Common Events Catalogue

1-50    ~ User Common Events
51-       ~ Unreserved

Submitting Event Systems

You can submit an event system by posting the link to the topic in the submission thread (to be made soon) or by PMing me. It will then be evaluated and if it fits the requirements, the variables and switches used will be added to the Reserved lists and the Event System will be added to the RMRK+ Format Index

FAQ

Won't it be annoying to debug a system like that, since you'd have to scroll for a long time in debugging mode to get to a switch/variable

You can press the L & R buttons in debug mode to go down and up ten at a time in the left window. By default, these would be Q & W.

Great Idea Kipe!

I'm not trying to sound like an ignorant prick. But isn't this just about how they started the SDK?

I remember when they came up with the idea. It was simply for compatibility. Kinda like this.

My point is, don't make this too complicated.

I hope this goes better than that went. (I, for one, saw no problem with the SDK, but never used it since nobody else wanted scripts that were SDK dependable.)

Well, it is kind of like the SDK. But the main stated problem with the SDK is that it reduces compatibility between SDK and non-SDK scripts. With events, I can't see that happening. Since all event systems prior to this don't have any real plug & play ability to them, if they use variables or switches it is expected that the user has to configure the system in order to use variables and switches that are free in his/her game. The fact is, without guidelines like this, there exists no actual plug & play compatibility between event systems which use variables, switches, or call common events. For that reason, it really cannot interfere with event systems that do not follow the guidelines, which avoids the major problem of the SDK as being an enforced standard.

As to making it more complicated, well, I have no intention of furthering the idea beyond what it is now.

I like this, unfortunatly, my event systems can't converted due to the way they are made. I have attempted and you can't just plug and play with them

Some need configuration. Especially if they have teleporting involved. Reserving maps would be too ridiculous. In essence, any script that does not use reserved variables, switches, or common events is RMRK+ Format, or can be. As long as the configuration is not ridiculously heavy, then it can qualify as a RMRK+ system.

.....this makes it harder to make complicated event systems.
But if people can make it work, then guess that's not a problem.

@Tsu:
I do not know how they started the SDK. It could very well be for increasing compatibility.
There is one major difference between this and the SDK.
This format is a convention. There is nothing you have to install into your own project.
This is about how you design your event system. With the SDK you deliberately have to install their script which alters the default scripts.
Still you could always have made your scripts work both with the SDK and without. Like I did with my antilag script

@Leventhan: I disagree.
I would at max 15 minutes spend on allocating space in the planning phase. (You might use a bit more time. I wouldn't know)
You might call it a bit tedious, but hard, nah. And considering the price in doing so. It is definitely worth it.
I would not say that it becomes easier making complicated event systems, but it should reduce the need for support due to the system clashing with another system. But neither does it become harder.
For me it becomes easier due to the fact that I don't have to use much energy on guessing which switches/variables won't be used by other systems.