Dialogue after battle abort?

[Ashton]

I'm scratching my head sore trying to figure out how to do this...

the scenario is the PC walks up to an NPC and talks, gets into a fight, then after a while the NPC says "let me live and I'll tell you the plan!" if the palyer chooses to have mercy, the battle ends and the NPC talks.

I've got the first part done, it's easy to trigger "Battle Processing" and then once in battle I used the troop page's "When enemy is at 20% or less HP" to show the choices. If the player chooses "Let him live!" then it throws the switch "Mercy" and it activates "Abort Battle"

Now is where I am stuck...

I tried just continuing the main event with a conditional "if switch "mercy" is on" but it never displays...

I tried a second event that parallel processes when switch "mercy" is turned on, again nothing...

I tried just using the "self switch A" to jump to another page if "mercy" is turned on...

So far I cant figure out any way to get the dialogue to happen after I "abort battle"... -_-*

 

[Andar]

please show screenshots of your event pages.


All three of your ideas should work when executed correctly, which basically means that you made some mistakes when trying them out, and we need to see exactly what you did in order to achieve your intentions.

 

[Ashton]

I also came up with a very round-about way of doing it. Throwing a switch before the battle to activate another event only IF the player is still lvl 1 (if the player chooses to let the NPC live, she stays lvl 1) which also failed... (the "control switch: BattleON" --- wasn't there in the previous versions)

Here's the image of all the event and the battle event too:

https://dl.dropboxusercontent.com/u/8499597/Events.png

Dont know if it's related but randomly during the event the bear and Ruxpin will both vanish prematurely (and if ruxpin vanishes the "show animation bind2" will just make the screen flash yellow instead of playing)

 

[Shaz]

Those images are FAR too small to see anything useful. Please try again - one screenshot per image will be more helpful.

 

[Andar]

Unfortunately your picture doesn't show all event pages, especially there is no event page displayed that even checks the mercy-switch you're having trouble with... (and it makes them better readable if you keep your screenshots in different images instead of combining them).


A few advices from things I've seen so far that might help you:


1) consider using nested conditions instead of your excessive use of exit event processing.


If you place the conditional branch for [Teddy] in inventory inside the (currently empty) true branch of [garlic] in inventory, then you don't need the exis event processing in the false branch of the garlic condition, and there is no way it would even be checked (which might happen in your current setup, and that might be one of the causes for your random errors).


2) try to use more conditions instead of conditional branches


You can only check for one item in the conditions, so ou need to add conditional branches - but it would help stream line the event and place different parts on different pages, making it a lot easier to handle.

 

[Ashton]

Those images are FAR too small to see anything useful. Please try again - one screenshot per image will be more helpful.

Odd, when I click on the link it lets me click the image to expand to full-size... might be because I'm logged into Dropbox...

Unfortunately your picture doesn't show all event pages, especially there is no event page displayed that even checks the mercy-switch you're having trouble with... (and it makes them better readable if you keep your screenshots in different images instead of combining them).

A few advices from things I've seen so far that might help you:

1) consider using nested conditions instead of your excessive use of exit event processing.

If you place the conditional branch for [Teddy] in inventory inside the (currently empty) true branch of [garlic] in inventory, then you don't need the exis event processing in the false branch of the garlic condition, and there is no way it would even be checked (which might happen in your current setup, and that might be one of the causes for your random errors).

2) try to use more conditions instead of conditional branches

You can only check for one item in the conditions, so ou need to add conditional branches - but it would help stream line the event and place different parts on different pages, making it a lot easier to handle.

I must have moved the mercy switch out to a new event and deleted it during all my testing. I'll make another one and post it when I do.

Yeah, I was looking for a quick-and-dirty method of testing the event earlier on (I was changing a lot of stuff and ended up having to scrap saves so I made it easy to jump in and out of the event --- I'm very bad about working non-linearly on my game) I'll clean it up into nested IF statements

You mean have an "if garlic..." then "self-switch A" and on the next page (dependent on A being thrown) it checks "If Teddy..." and throws self-B, etc? 

 

[Andar]

You mean have an "if garlic..." then "self-switch A" and on the next page (dependent on A being thrown) it checks "If Teddy..." and throws self-B, etc?

NO, I mean the condition area top right.
There is a condition "item exists" - that isn't nice english, because it basically means "item in inventory". If you use that, you can remove the first conditional branch without needing any self-switch. just make one page without item condition "you don't have item XY", then make one page with the item condition, and only check the other items and later conditions by conditional branches there.


Same goes for "actor exists", that also means "Actor in party" - you don't need self switches to use multiple pages...

 

[Ashton]

I used nested conditions and removed the "exit event processing" in the else statement. That seems to have fixed it. I'm guessing that it was checking again for the items and when it didnt find them, it exited the event instead of continuing. It's now seeing the Mercy switch and showing the events following it.

Thank you

 

[Andar]

I'm guessing that it was checking again for the items and when it didnt find them, it exited the event instead of continuing.

Why are you guessing that? That's what that command is supposed to do, it says so in the name of the command. If it doesn't find the items, the entire event is exited and abandoned, not only the conditional branch - to end the conditional branch you don't need a command, that happens automatically...
If you're that confused about what event commands do, then I suggest going back to some basic tutorials before continuing to work on your project - you might want to follow the link in my signature for that.

 

[Ashton]

Why are you guessing that? That's what that command is supposed to do, it says so in the name of the command. If it doesn't find the items, the entire event is exited and abandoned, not only the conditional branch - to end the conditional branch you don't need a command, that happens automatically...

If you're that confused about what event commands do, then I suggest going back to some basic tutorials before continuing to work on your project - you might want to follow the link in my signature for that.

Because we already passed it. Why should it seemingly randomly ay line 20-or-so return to line 1? That's what's confused me. It should go 1-2-3-4-5-6-etc, not 1-2-3-1-4-5-1-6... Until the event ends, unless I call specifically on a label, it should not go back up in the list. (I'm guessing the Battle Processing caused it, which still break the logic and flow control of the event).

For the record, I am going over tutorials, I just learn best by doing (one reason I'm making a free game using redly available content - so I can learn the engine) I actually have learned a LOT and recommended to many others the "Tutorial Town" series (but it's so nerve-wracking when he spends half the episode going "um... hum... what to do next?" ) I apologize for n00bish questions like this, I will try to do more research and testing before posting them in the future unless all else fails.

 

[Andar]

Because we already passed it. Why should it seemingly randomly ay line 20-or-so return to line 1?

It doesn't return there, the event is always linear, no exceptions and no absolutely random jumps.
The question is how often is it started instead?


The trigger "player touch" means that the player doesn't need to do anything like action button, the event is automatically triggered when the player stands on that position (because of "below player", if it were same as player the player would have to collide during movement).


It should only be started once on entering the coordinates, but it contains a mix of waits, set move routes, battle processing and others that might break sequences and cause the event to be processed more than once if something goes wrong, and that is why you should nest conditions, especially when the items checked are later removed.


There are a few quirks in the engine that I assume are produced by memory leaks or pointer redirections (technical terms, a special form of bugs that are extremely difficult, almost impossible to find in a program unless you put in a lot of beta testing, and I'm speaking of the editor/game.exe, not your project), and you can only prevent them by carefull structuring of your events.


Just for your info:


the triggers autorun and parallel process always loop, restarting the event the next frame after being processed, that's where you have to be extremely carefull with exit event processing and need to use switches instead...

 

[Ashton]

It doesn't return there, the event is always linear, no exceptions and no absolutely random jumps.

The question is how often is it started instead?

The trigger "player touch" means that the player doesn't need to do anything like action button, the event is automatically triggered when the player stands on that position (because of "below player", if it were same as player the player would have to collide during movement).

It should only be started once on entering the coordinates, but it contains a mix of waits, set move routes, battle processing and others that might break sequences and cause the event to be processed more than once if something goes wrong, and that is why you should nest conditions, especially when the items checked are later removed.

There are a few quirks in the engine that I assume are produced by memory leaks or pointer redirections (technical terms, a special form of bugs that are extremely difficult, almost impossible to find in a program unless you put in a lot of beta testing, and I'm speaking of the editor/game.exe, not your project), and you can only prevent them by carefull structuring of your events.

Just for your info:

the triggers autorun and parallel process always loop, restarting the event the next frame after being processed, that's where you have to be extremely carefull with exit event processing and need to use switches instead...

The move-routs and such did not take the player over the event square again, or move from it at all during the event, unless it counted "entering battle" as going off the event... (which I can understand, but is not intuitive like the rest of the engine, so I didn't think of it)  

Yeah, I figured it was a memory glitch that, for instance, caused events to blink out of (visual) existence prematurely and subsequently cause animations not to play. (in my event the bear moves onto the hexagram and turns visible for like 5 actions but will randomly disappear after the first, second, third, etc action. Same for Ruxpin, that event also randomly disappears, which also causes the "chain2" animation not to play. (though oddly if I used ENTER instead of Z to progress it, the random disappearing happened less)

Yeah, I've learned to alway include a trigger to turn on a parallel process, and then to immediately turn it off when it's over. (and I've fallen prey to many broken PP loops when I'm testing a new event) Quite honestly, I'm not planning to use the "exit event processing" anymore since it seems, at best, to be hard to configure, and at worst buggy...

 

[Andar]

I'm not planning to use the "exit event processing" anymore since it seems, at best, to be hard to configure, and at worst buggy...

Not exactly - it is one of the commands (like parallel processes for that matter) that has specific uses where it is needed, but can cause a lot of confusion if it's used without knowing the details.
There are cases where it is needed and cannot be replaced (as there are places where parallel processes are neccessary), but if you use it too much or for cases where it isn't needed, then you run an above average risk of bugged sequences (or lagged maps in the case of PP).


We usually suggest that if people are unsure whether or not to use those elements, it's better if they don't use them or ask how to place them correctly.