Quest help

[Khaz]

Hello.

I've a problem - 2 technically, but the other is a more minor one - that I've been trying to wrap my head around and think on how to proceed with it for a few hours now at least.
I use Modern Algebra's Quest Journal script where I have a quest that is done in the very first dungeon you end up in, which is made of 3 maps: The entrance and first half of the dungeon, followed by the second half of the dungeon and finally the boss room.
In the quest you're sent to rescue two people at the end of the dungeon and it has optional objectives to kill 5 Spiders and 5 Bats randomly encountered in the two halves of the dungeon before the boss room - although that could be a side quest of its own, but I digress.
I know you can do these kinda kill quests through the use of variables and having a counter on a map seeing how many you've won against, but my problem comes in the fact that because both the spiders and bats are encountered in both the first and second map of the dungeon, this means I couldn't have a variable counter on both maps ( well I can, but.. ), because in the event that the player would, say do the optional killing of the enemies in dungeon map 1 and you'd get a notification for the quest updating and having completed the killing of the enemies, then once you'd find your way to the second map, which would have the variable counter as well, then would it not ping you a second time about the player having defeated 5 of both spiders and bats and saying the quest was updated?
It might be a bit of a nitpick, but if that happens, then it kinda bothers me.

This leads me to the second, more minor problem:
I figured I could get around this through the use of Common Event and having a conditional branch variable counter ( If Spider/Bat kill variable is greater or equal than X, then quest updates ) and I found that in the conditional branches you also have an "If [Enemy] Appeared" option, but I notice that not only is the enemy option blank/un-named, but it has total of 8 of the same blank/unnamed choices, which confused me, as I'm not sure where could you set these.
The "Enemies" tab has plenty of (default) enemies, so the enemy choices shouldn't be blank, let alone left at just 8 and I have no idea where do you set them up at.

I guess technically I'd need the minor problem solved, so I could get the major problem solved.. I think.

TL;DR: Nitpick problems with having variable kill counter on 2 out of 3 dungeon maps and player shouldn't be double pinged if quest is completed on map 1 and moves to map 2. And "Enemy" tab in Conditional Branches is confusing me and I've no idea where to set them up at.

 

[Roninator2]

ping you a second time

I would set up self switches. When you enter the second map and have a parallel process check to see if the variable is at 5. If it is (because you killed 5 in the other map, then turn the self switch on, if not then turn the second self switch on. If would only become complicate if the player went back to the previous map before killing 5 enemies. Because you would want this check to happen again if they returned to the second map and then had killed 5 enemies.
It evolves around doing the check, setting the self switch, when leaving check for variable and turn self switch off if needed.

it has total of 8 of the same blank/unnamed choices

where are you seeing this?

 

[gstv87]

this means I couldn't have a variable counter on both maps

variables are global.

what you should have (what *the quest manager* should have) is a handler of the battle win event, which will add 1 to that variable.

 

[Khaz]

@Roninator2 I will try the self-switch once I get home. Thank you for the suggestion.
As for the blank enemy names, I found it when you are setting up a conditional branch, on the 3rd tab there is the "Enemy" selection as well as two sub selections for it, namely "Appeared" and "State". For the "Enemy" you have a dropdown list for blank enemies and I've no idea what to do with those.
I can provide a screenshot later

@gstv87 I know. I can otherwise do that, but my concern is/was with the fact that if both of the maps have a variable counter keeping track of the wins, then if the player filled both variables to 5 ( spider and bat kill counters ) on map 1 and be informed about the quest objectives being completed, then upon entering map 2, they'd be pinged about the same thing a second time as the counter would check the counters again, as if it hadn't been before, but Roninator did give a suggestion for that.

 

[gstv87]

if both of the maps have a variable counter keeping track of the wins

why!
that's something the quest manager has to handle, not the map (and not *you*)

the quests should run parallel to, or above the map scene, not "under" it (affected by it)

 

[Khaz]

why!
that's something the quest manager has to handle, not the map (and not *you*)

the quests should run parallel to, or above the map scene, not "under" it (affected by it)

Pardon if I'm still being dumb with something, but the quest journal script doesn't have any way to handle variables (to my knowledge anyway) and therefore the quest script doesn't manage the kills, so wouldn't you need something like a parallel process on a map ( or common event as I had mentioned having attempted ) to trigger the quest update once the kills are reached? So in this case I figured I'd need either a parallel process on the map keeping track of the kill counts or common event with conditional branch that keeps track on the wins for the specific enemies variables.

Again, I apologize if I'm just being dumb and missing something on what you're saying

 

[gstv87]

the quest script doesn't manage the kills,

does it have any pre-made quests that deal with hunting monsters? or, collecting specific items?
or is it all about "go to place and talk to NPC"?

 

[Andar]

@gstv87 you are on a misconception here.
Quest journals like the script mentioned here are NOT quest managers - for a lot of reasons.

Quest Journals are the API and screens used to inform the player about the available quests, the status of each quest and so on. The commands given in the API can tell the journal how to change a status of the quest, but the quest itself needs to be handled outside of the journal.

The main reason for this is that if you combine quest management and journal management into a single script, you limit the game developer to those management option that the scripter thought of and included, AND you require the game developer to be able to read and write script code to handle that management data.

Because modern algebra's quest journal is only a quest journal, the management part of the quests can be handled by events and there is no need for scripting knowledge beyond the ability to use the journals script commands.
Even that is often too much for RM-users, because you need to write the quests down into the script code itself (ace doesn't have plugins or plugin commands) and this script is therefore considered one of the most complex to most RM-users, but it can be used without knowing how to program in ruby - which is another reason why the quest management part is moved to the eventing side instead of being included here.

 

[gstv87]

Quest Journals are the API and screens used to inform the player about the available quests

in that case, flip what I just said: you *have* to account for those variables, and *have* to introduce a detection of victory.

 

[Andar]

The quest journal can handle and display variables in the same way show text can handle and display variables.
and in both cases the control of these values is on the outside, done with the control variable commands and the conditional branches in eventing.

 

[Khaz]

Regarding detection of victory, Battle Processing has "If Win/Lose", but that wouldn't go into the battle events found in the Troops tab on the related enemy, would it? I mean yes, the "If Win/Lose" would, but the Battle Processing wouldn't be put there, right? I tried it with that and it didn't seem like the variable went up.
The thing with the Battle Processing commands "If Win/Lose" thing is that wouldn't you need "physical" events going about whom you'd then touch to initiate the battle and thus be able to use the "If Win/Lose" and be able to have the variable count the kill? Because the only way I could think of on how to go about counting the kills is through the Conditional Branches "If [Enemy] appeared, then...". In fact, let me provide a screenshot of that exact thing:

 

[bgillisp]

I handled this in my game by changing it from kill x of the monster to kill x stacks of monsters. Then I only had to add 1 to a variable when you defeated the entire group. But that also worked as I used visual encounters.

I think for random encounters you have to set it up so that when you get the quest it turns on a switch to say quest in progress. Then in every troop event that has that monster, you need the following condition for each and every occurance of the monster:

1st troop event: Start of battle:
-Add state immortal to the monster.

2nd troop event: If monster HP <= 0%
-Remove state immortal.
-Add one to the variable for the quest if the quest is in progress (use a conditional branch to check if the switch is on for the quest started).
-KO the monster.

That's the only way to get the engine to add one to a variable via events that I know of. Otherwise you'd have to program it in directly into the ruby code. Look for the command die, that is where you would add it.

 

[Khaz]

Your suggestion did it, @bgillisp and I've managed to get the quest working. The double pinging is still an issue, as I'm not quite sure I fully understand the way you mean to use the self-switches to prevent it from happening from what you described, @Roninator2 - but on the other hand, I managed to figure out what those 8 blank enemy names were for. It seems that command is meant to be used ( at least ) in the Troops tab in the Troop events, where once you set up conditional branch and go to the third tab, the enemies in the respective troops ( for example 2 Bats ), those blank names will fill up with the enemy names ( 1. Bat - 2. Bat etc. )

 

[Roninator2]

The double pinging is still an issue, as I'm not quite sure I fully understand the way you mean to use the self-switches to prevent it from happening

Map 1 Self switch A on
Map 1 - Kill 3 enemies
Transfer to Map 2.
Turn Map 1 self switch A off
Map 2 - check for enemies killed
No, only 3 not 5, Turn Map 2 self switch A on.

Kill enemies or not - need to plan both ways.
Transfer to Map 1, turn Map 2 self switch A off
Map 1 - Check for enemies killed
No, only 3 not 5, Turn Map 1 self switch A on.

Case choice 1, 2
case 1
Map 1 - Kill 2 more enemies.
variable at 5, quest moves to next step.
self switch B on for Map 1 and Map 2

case 2
transfer to Map 2. Turn Map 1 self switch A off
check for enemies.
No, only 3 not 5, Turn Map 2 self switch A on.
kill 2 more enemies
variable at 5, quest moves to next step.
self switch B on for Map 1 and Map 2

 

[Khaz]

Sorry for a bit later response. But aren't self switches specific to a respective event? Self switch for event A in Map 1 wouldn't be the same for self switch B in Map 2. Or I might be even more dumb right now. That said, I did still take from your instructions and did a small combination of a variable and instead of self switches, I used a switch.
Basically, there's 3 variables at play: Spider kill counter, Bat kill counter, and a third one that checks whether either of those two are finished.
I made it so that once either the spider kill counter goes up to (at least) 5 - which completes that kill counter - or the bat one, it adds a +1 to the third variable, that, once it reaches 2, activates a switch that lead both the Bat and Spider kill counter events to a blank page. I have this on both maps. The event that keeps check on the third variable also has a conditional branch that checks whether the switch is on or not, and if it's off, it turns on. Otherwise nothing happens. This effectively removes the double ping, should the player decide to finish those kill objectives on one map.

Thank you, @Roninator2 @gstv87 @Andar and @bgillisp for your responses on the thread and your help. The matter is solved now.

I provided explanation on what I did primarily should anyone in the future have a similar problem ( whether it be double pinging or making (kill) counters in general ), so hopefully it'd help someone else as well.

 

[Kes]

[closed]IgnoreMe[/closed]