RMRK is retiring.
Registration is disabled. The site will remain online, but eventually become a read-only archive. More information.

RMRK.net has nothing to do with Blockchains, Cryptocurrency or NFTs. We have been around since the early 2000s, but there is a new group using the RMRK name that deals with those things. We have nothing to do with them.
NFTs are a scam, and if somebody is trying to persuade you to buy or invest in crypto/blockchain/NFT content, please turn them down and save your money. See this video for more information.
Delete Account Please

0 Members and 1 Guest are viewing this topic.

**
fagmop
Rep:
Level 87
fagmop
(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.
« Last Edit: December 10, 2009, 01:13:54 AM by modern algebra »

*
Rep:
Level 97
2014 Most Unsung Member2014 Best RPG Maker User - Engine2013 Best RPG Maker User (Scripting)2012 Most Mature Member2012 Favorite Staff Member2012 Best RPG Maker User (Scripting)2012 Best MemberSecret Santa 2012 ParticipantProject of the Month winner for July 20092011 Best Use of Avatar and Signature Space2011 Best RPG Maker User (Scripting)2011 Most Mature Member2011 Favourite Staff Member2011 Best Veteran2010 Most Mature Member2010 Favourite Staff Member
Great Idea Kipe! :P
« Last Edit: September 11, 2009, 01:40:30 PM by modern algebra »

*
Full Metal Mod - He will pillage your women!
Rep:
Level 93
The RGSS Dude
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.)
"The wonderful thing about Tiggers
Is Tiggers are wonderful things
Their tops are made out of rubber
Their bottoms are made out of springs

They’re bouncy, trouncy, flouncy, pouncy
Fun, fun, fun, fun, fun!
But the most wonderful thing about Tiggers
Is I’m the only one, I’m the only one."

*
Rep:
Level 97
2014 Most Unsung Member2014 Best RPG Maker User - Engine2013 Best RPG Maker User (Scripting)2012 Most Mature Member2012 Favorite Staff Member2012 Best RPG Maker User (Scripting)2012 Best MemberSecret Santa 2012 ParticipantProject of the Month winner for July 20092011 Best Use of Avatar and Signature Space2011 Best RPG Maker User (Scripting)2011 Most Mature Member2011 Favourite Staff Member2011 Best Veteran2010 Most Mature Member2010 Favourite Staff Member
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.

********
Licks
Rep:
Level 91
Sexual Deviant
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

*
Rep:
Level 97
2014 Most Unsung Member2014 Best RPG Maker User - Engine2013 Best RPG Maker User (Scripting)2012 Most Mature Member2012 Favorite Staff Member2012 Best RPG Maker User (Scripting)2012 Best MemberSecret Santa 2012 ParticipantProject of the Month winner for July 20092011 Best Use of Avatar and Signature Space2011 Best RPG Maker User (Scripting)2011 Most Mature Member2011 Favourite Staff Member2011 Best Veteran2010 Most Mature Member2010 Favourite Staff Member
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.
« Last Edit: November 16, 2007, 05:29:24 AM by modern algebra »

********
Shadow Knight
Rep:
Level 91
Ruin that brick wall!
Project of the Month winner for October 2008
.....this makes it harder to make complicated event systems.
But if people can make it work, then guess that's not a problem.
Be kind, everyone you meet is fighting a hard battle.

*
? ? ? ? ? ? ? ? ? The nice kind of alien~
Rep:
Level 92
Martian - Occasionally kind
@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.