- 7
- Posts
- 7
- Years
- Age 33
- Seen Jul 11, 2016
Hello! I have no idea if this is the correct place, it isn't exactly script script.
So! I can't script, however I have found a way by using common events to record quest like data. It was a fairly complex system to create but after 3 days of constant work I managed to complete it in about 30 hours, of course I knew nothing on how to do this and had to find a solution for my project.
This stores a maximum of 10 quests, however is open for "easy editing" to add more than that.
This code uses variables 975-1000 to store data, and variables 1001+ to start storing quest data for simplicity.
This system uses 3 common events.
Can also be manipulated in ways by using the same structure to store information needed for other things like puzzles and password, providing you with limited slots. Like picking up an item will register in slot 1, and another in slot 2 and so forth. Being in the correct order then triggers your goal when active completing the puzzle. With further editing you can turn this into a password system however I'm sticking to what this thread is for.
Change the file View attachment CommonEvents.txt .txt to .rxdata and place inside a working, or new RGPXP game DATA folder and copy the common events over (preferably in the set event numbers unless you wish to change a few "call common" events designations within the common events itself.
Also change this file name from View attachment Map075.txt .txt to .rxdata, this file is a map that contains 3 events that will give you examples on how this works.
The left (Bulbasaur) event gives you several quests when accepted. The middle (Ivysaur) event lets you view the quest log and access the quest progress/description. The last (Venasaur) event completes the 3 quests, (without a reward and regardless if they where accepted) and removes the quest from your log.
What you need to do.
Adding a new quest into game.
Look at the quest handler and copy the first quest and past below it, changing the correct variables that suit it, there are 3 present so you can see how each one is different. See image below for underlined red stuff that you need to change.
Accepting a new quest. (See Bulbasaur event)
Add and set the control variable [978] to [x], [x] representing your quest number, this needs to happen before every new quest to accept, followed then by launching the common event "quest handler" (this searches for the appropriate quest and then proceeds to saving it, if slots are available.) The rest of the event needs an conditional branch (variable[978]=x), setting the event to A. This makes sure the quest is accepted before moving on preventing duplicate issues.
However in the quest handler under the appropriate quest variable condition you can in fact call all the quest needs from there without having to make additional self switches. After every phase of the quest is completed you can set the variable in that quest (in this case is [1001]which represents quest 1) to 2, or 3, or whatever the finishing variable is, the variable is normaly 0, meaning quest not given/accepted, and 1 meaning quest accepted but not complete. 10 will mean quest complete as of for now and ready to be handed in.
Handing in quest. (see Venasaur)
Set variable[978] to your quest you wish to hand in and then call common events "quest handler". This will search for your quest, check to see if the correct value in variable [1001] is present and finish the quest.
To view quest log(s) use the (Ivysaur) event.
This event calls "quest log". The quest log common event contains the "other half" of your quest data (phases and descriptions of quest). Only the beginning and end are implemented into "quest handler", and the rest for easy finding can be stored in "quest log". You can change this to put all quest data into the handler, by changing the "jump to label (quests) to call common event "quest handler".
-You can also add a +1variable to the Quest Count to keep track of your quests every time one is completed.
-The Quest handler also re-orders your quest to the appropriate slot, from top to bottom when one is completed, removing gaps. This is done by re-saving current variables to a lower slot and then deleting, proceeding to the next slot.
Have fun!
So! I can't script, however I have found a way by using common events to record quest like data. It was a fairly complex system to create but after 3 days of constant work I managed to complete it in about 30 hours, of course I knew nothing on how to do this and had to find a solution for my project.
This stores a maximum of 10 quests, however is open for "easy editing" to add more than that.
This code uses variables 975-1000 to store data, and variables 1001+ to start storing quest data for simplicity.
This system uses 3 common events.
Can also be manipulated in ways by using the same structure to store information needed for other things like puzzles and password, providing you with limited slots. Like picking up an item will register in slot 1, and another in slot 2 and so forth. Being in the correct order then triggers your goal when active completing the puzzle. With further editing you can turn this into a password system however I'm sticking to what this thread is for.
Change the file View attachment CommonEvents.txt .txt to .rxdata and place inside a working, or new RGPXP game DATA folder and copy the common events over (preferably in the set event numbers unless you wish to change a few "call common" events designations within the common events itself.
Also change this file name from View attachment Map075.txt .txt to .rxdata, this file is a map that contains 3 events that will give you examples on how this works.
The left (Bulbasaur) event gives you several quests when accepted. The middle (Ivysaur) event lets you view the quest log and access the quest progress/description. The last (Venasaur) event completes the 3 quests, (without a reward and regardless if they where accepted) and removes the quest from your log.
What you need to do.
Adding a new quest into game.
Look at the quest handler and copy the first quest and past below it, changing the correct variables that suit it, there are 3 present so you can see how each one is different. See image below for underlined red stuff that you need to change.
Accepting a new quest. (See Bulbasaur event)
Add and set the control variable [978] to [x], [x] representing your quest number, this needs to happen before every new quest to accept, followed then by launching the common event "quest handler" (this searches for the appropriate quest and then proceeds to saving it, if slots are available.) The rest of the event needs an conditional branch (variable[978]=x), setting the event to A. This makes sure the quest is accepted before moving on preventing duplicate issues.
However in the quest handler under the appropriate quest variable condition you can in fact call all the quest needs from there without having to make additional self switches. After every phase of the quest is completed you can set the variable in that quest (in this case is [1001]which represents quest 1) to 2, or 3, or whatever the finishing variable is, the variable is normaly 0, meaning quest not given/accepted, and 1 meaning quest accepted but not complete. 10 will mean quest complete as of for now and ready to be handed in.
Handing in quest. (see Venasaur)
Set variable[978] to your quest you wish to hand in and then call common events "quest handler". This will search for your quest, check to see if the correct value in variable [1001] is present and finish the quest.
To view quest log(s) use the (Ivysaur) event.
This event calls "quest log". The quest log common event contains the "other half" of your quest data (phases and descriptions of quest). Only the beginning and end are implemented into "quest handler", and the rest for easy finding can be stored in "quest log". You can change this to put all quest data into the handler, by changing the "jump to label (quests) to call common event "quest handler".
-You can also add a +1variable to the Quest Count to keep track of your quests every time one is completed.
-The Quest handler also re-orders your quest to the appropriate slot, from top to bottom when one is completed, removing gaps. This is done by re-saving current variables to a lower slot and then deleting, proceeding to the next slot.
Have fun!
Last edited:
