Author Topic: Strange Quest Behavior  (Read 7370 times)

Offline Merle

  • Jr. Member
  • **
  • Posts: 90
Strange Quest Behavior
« on: February 09, 2009, 03:31:44 PM »
Okay, I'm officially working with OAUA now!

But I found some weird behavior coming from the Quest Stage event, and I don't think I've seen it in Vanilla UA.  (Hopefully using the code tags make them somewhat readable.)

Code: [Select]
Event happens if: Always Happens
Accept: Automatic
Which Quest: Quest 1
Stage: 1

What this should do is fire if Quest 1 has a value of 0, and only then. (Since the Quest Stage event is only supposed to happen when the Quest is actually at Stage - 1).  Except it's firing every single time the party enters the square with the event.  Each time, it increments the value of Quest 1 by 1 and chains to the sequence of Accept events.  The Quest goes from 1 to 2 to 3, etc.

So, let's change the event and see what it does.  We'll make sure it won't fire unless the party doesn't have Quest 1.

Code: [Select]
Event happens if: Party Doesn't Have Special item (Quest 1)
Accept: Automatic
Which Quest: Quest 1
Stage: 1

Now it works properly, but only because I'm checking to make sure the party hasn't started the quest first.  But if I have another quest stage on the same space...

Code: [Select]
Event happens if: Party Doesn't Have Special item (Quest 1)
Accept: Automatic
Which Quest: Quest 1
Stage: 1

Always chains to...

Event happens if: Always Happens
Accept: Automatic
Which Quest: Quest 1
Stage: 2


Now the first event fires (setting Quest 1 to 1) the first time the space is entered.  The second time the party enters that space, it chains to the second event and Quest 1 is set to 2. So far so good. But if I enter the square a third time, it chains to the second event again, and now Quest 1 is set to 3.

So I'm thinking it's just automatically increasing the Quest Stage, no matter what the current value is.  But if I do the event below, it works like it's supposed to and doesn't fire the event (because Quest 1 is set to 0 at the time).

Code: [Select]
Event happens if: Always Happens
Accept: Automatic
Which Quest: Quest 1
Stage: 2

 ??? Halp!

Offline ProphetSword

  • Mod Designer
  • Administrator
  • Hero Member
  • *****
  • Posts: 2849
  • FRUA Lives!
    • Lands of Adventure
Re: Strange Quest Behavior
« Reply #1 on: February 09, 2009, 10:33:08 PM »
That definitely shouldn't be happening, so you're right about that.

I'm curious to know if changes were made to UA in the worldhack that would cause this strange behavior, as I've never encountered it before.

But, also, if you haven't tried already, you should exit UA and then go back into it to be sure it happens consistently.  I've seen some weird things happen that shouldn't happen, but then they just turned out to be weird glitches that weren't repeatable once I left the game and came back.
LANDS OF ADVENTURE: An Old-School Style CRPG

More Information Here: http://landsadventure.blogspot.com/

Offline Merle

  • Jr. Member
  • **
  • Posts: 90
Re: Strange Quest Behavior
« Reply #2 on: February 10, 2009, 07:39:05 AM »
I was wondering if it was some bug from UA that I had forgotten about, but I couldn't replicated the problem in Vanilla UA.  I'm also glad that I'm not the only that hasn't seen this before.

I have now tried restarting UA, and the same thing happened.  I also made a brand new area in the same design and a brand new design, and the error repeated itself.

And one other bug I found: when setting Step Events for a dungeon, the selected zones will flip themselves if you leave the page without clicking OK.  For instance, if I have an event set to fire in zones #2 & #3, if I click Next, Prev, or edit an event on that page, then it sets the zones to #1, #4, #5, #6, #7 and #8.  And it does that for all the zones on all pages showing Step Events in the dungeon each time you leave the page (unless you leave the page by clicking OK).  So you have to make sure you set the zones exactly the way you want them, and click OK to save them that way... otherwise they will change.

Offline ProphetSword

  • Mod Designer
  • Administrator
  • Hero Member
  • *****
  • Posts: 2849
  • FRUA Lives!
    • Lands of Adventure
Re: Strange Quest Behavior
« Reply #3 on: February 10, 2009, 10:36:19 AM »
Wow, that really is odd.  Never seen either of those.

And it only happens with the OAUA worldhack installed?
LANDS OF ADVENTURE: An Old-School Style CRPG

More Information Here: http://landsadventure.blogspot.com/

Offline Merle

  • Jr. Member
  • **
  • Posts: 90
Re: Strange Quest Behavior
« Reply #4 on: February 10, 2009, 01:58:47 PM »
Yup, only with OAUA.  I did a fresh install of UA, upgraded it to 1.2, then installed OAUA on top of it.  If it's just me that's having this problem, I'll probably just try another installation and see what happens.

I should note I made one change to CKIT to remove the password check. However, I did go back and restore my old CKIT (naturally, I made a back-up before I changed it :) ) and both versions have the same problems.

Offline Olivier Leroux

  • Administrator
  • Hero Member
  • *****
  • Posts: 2291
  • Yip, yip, yip!
Re: Strange Quest Behavior
« Reply #5 on: February 10, 2009, 06:51:09 PM »
If it's just me that's having this problem, I'll probably just try another installation and see what happens.

Nope, it's not just you. I tried to reproduce both issues you were talking about and unfortunately I succeeded (after a new and clean install of UA1.2, OAUA and the OA1.2-patch). I've also found another strange quest behaviour that occured to me in OAUA but not in FRUA when I moved the dungeon from OA to FR (this is a bit more particular than your problem but it might point to some general deficiencies...):

For my first attempts at an OA tutorial I did an introductory set-up that at a certain point removes the only party member (which is an NPC) and asks the player to select a PC instead. I did something similar for my current FRUA project too but with OAUA it's a bit more complicated since the training hall event is now part of the menu, not an actual event anymore. While in FRUA the player is forced to choose a PC (because otherwise the training hall event won't have the option to "Begin the Adventure") in OAUA it would be possible to continue with a non-existent party. Therefor I made an event chain to check if any of the 10 character classes are present in the party so that I could prevent a continuation of the game in case there aren't. I used 10 special items and named them after the character classes. If a class is in the party the party gets the item (by way of Utilities events). In FRUA that works: If no PC is chosen the party will have none of these items and the request to choose a character will be repeated. In OAUA it doesn't work: Even if no one's in the party for some reason the party still gets the "Barbarian" item (Special Item 5, I think).
 ???

[Edit: Oh, wait. I just realized testing this dungeon in FRUA might not make that much sense because it doesn't feature the same event conditions.  :-[ But even if the FRUA check is no real evidence, to me it seems likely this problem is somehow related to the odd quest behavior you discovered in OAUA.]
« Last Edit: February 10, 2009, 06:59:43 PM by Olivier Leroux »

Offline DesertScrb

  • Sr. Member
  • ****
  • Posts: 266
  • Another day, another dungeon.
    • Super Galactic Dreadnought blog
Re: Strange Quest Behavior
« Reply #6 on: February 11, 2009, 10:12:24 AM »
I think that OAUA requires another program to design adventures for, or at least something to replace UAShell, as the worldhack is not compatible with most editors under the shell program. 

Also, do you have the latest version of OAUA?  It's now been updated to version 1.2.

Offline Merle

  • Jr. Member
  • **
  • Posts: 90
Re: Strange Quest Behavior
« Reply #7 on: February 11, 2009, 11:21:39 AM »
I think that OAUA requires another program to design adventures for, or at least something to replace UAShell, as the worldhack is not compatible with most editors under the shell program. 

Also, do you have the latest version of OAUA?  It's now been updated to version 1.2.

I am running OAUA 1.2.  I remember seeing that outside program mentioned in a newsletter, but thought it was for an earlier version of OAUA.  The program isn't included with the OAUA download, and I don't remember seeing it in the documents.  But I will go back and find that UANL article again and see if that program will work.

Offline Olivier Leroux

  • Administrator
  • Hero Member
  • *****
  • Posts: 2291
  • Yip, yip, yip!
Re: Strange Quest Behavior
« Reply #8 on: February 11, 2009, 11:26:45 AM »
I think that OAUA requires another program to design adventures for, or at least something to replace UAShell, as the worldhack is not compatible with most editors under the shell program. 

Also, do you have the latest version of OAUA?  It's now been updated to version 1.2.

Yes, I did a fresh OAUA1.2  install, too. To my knowledge there's an editor called Kailung for some of the more complicated things but I believe it's not compulsory and it should be possible to design simple vanilla design with quest stages and such just with the UA editor...

Offline Darius

  • Jr. Member
  • **
  • Posts: 71
    • Darius' Unlimited Adventures Domain
Re: Strange Quest Behavior
« Reply #9 on: February 15, 2009, 07:34:02 AM »

Lots of things to hit on here -- first of all, welcome to OAUA Merle! 

1.  Quest Stages: The behavior you are seeing is unique to OAUA and was a conscious design change by the OAUA team.  Try setting your Quest Stage events to "Do Only Once" and see if you can get them to behave the way you'd like.  The point of it was, in FRUA, if you stepped on Quest 1 Stage 1 but already had Quest 1 Stage 2, that event wouldn't fire.  Experienced designers might not have problems with this, but for many folks it can be difficult to set up your designs in such a way as to get the Quest Stage events to fire when you really wanted them to. 

2.  The Step Zone events in the Global Editor is definitely a bug.  It was discovered shortly after OAUA 1.2 was released and Brian posted a hack to the mailing list to correct it.  The fix is included in 1.3, but if you want to get started on it right away, here's the fix:

Find 681AE in your diff.tbl, and change the second number from 75 to 74.

3.  Kailung is indeed an "outside" editor that was designed for use with OAUA.  We had a tremendous amount of difficulty getting the new event conditions to work within UA and for a while (until version 1.2), the only way to really take advantage of the new event conditions was with using Kailung.  But the problem was solved and with the release of version 1.2, you could do anything within UA that you can do with Kailung, with the slight exception of being able to copy / paste or loop event chains which is the only reason I use it now.  Kailung is the OAUA version of Brian's Scruadat, which is what I used as a supplemental editor in building many of my Ravenloft games.  The ability to copy/paste and loop events can help you to squeeze the most out of your geos, but it's not necessary at all.

I think that covers everything for now.  Thank you guys for downloading and working with OAUA!  We spent a lot of time putting it together, and it's great to see others enjoying it.

Darius

Offline Olivier Leroux

  • Administrator
  • Hero Member
  • *****
  • Posts: 2291
  • Yip, yip, yip!
Re: Strange Quest Behavior
« Reply #10 on: February 15, 2009, 10:14:43 AM »
Wow, that's awesome! So one of the supposed bugs was actually an additional option for designers and the other one corrected already, and on top of it the "outside" editor is not really needed anymore! I can't sufficiently express what a great job you're doing with OAUA.  :o

Any idea about the ghost barbarian in my non-existent party? Or is it just a way of punishing designers that stray too much off the path of sanity?  ;)

Offline Olivier Leroux

  • Administrator
  • Hero Member
  • *****
  • Posts: 2291
  • Yip, yip, yip!
Re: Strange Quest Behavior
« Reply #11 on: February 15, 2009, 10:20:28 AM »
Hm, if it's only about determining whether there's a pc in the party it would certainly be more convenient to just check on the four races instead of the ten classes, duh. So maybe you were right to punish that complicated event chain, I'm going to try how it works with a smaller one.  :-[

Offline Darius

  • Jr. Member
  • **
  • Posts: 71
    • Darius' Unlimited Adventures Domain
Re: Strange Quest Behavior
« Reply #12 on: February 15, 2009, 10:39:29 AM »

Hi Olivier,
I'm not sure about the ghost barbarian issue -- I'm curious how you've set up the event chains before I can take a guess at what might be going wrong.  I think possibly the Barbarian could be Class 0, and that may have something to do with it.  You're right though, it would be easier to check against the 4 races instead of the 10 classes, and it would help us narrow down what is happening.  I wonder if you'll have a ghost Race 0...

I have to correct my earlier statement about the diff.tbl -- that's the right hack, but I forgot that OAUA 1.2 works with a patcher program to update CKIT, so there's no diff.tbl.  You can either hack your OAUA version of CKIT to apply the Step Event fix, or you could create a diff.tbl in your .dsn folder that has just these two lines:

681AE 75 74
0

That would do the trick.  Then when 1.3 is released you can do away with the diff.tbl.

Darius

Offline ProphetSword

  • Mod Designer
  • Administrator
  • Hero Member
  • *****
  • Posts: 2849
  • FRUA Lives!
    • Lands of Adventure
Re: Strange Quest Behavior
« Reply #13 on: February 15, 2009, 03:19:39 PM »
1.  Quest Stages: The behavior you are seeing is unique to OAUA and was a conscious design change by the OAUA team.  Try setting your Quest Stage events to "Do Only Once" and see if you can get them to behave the way you'd like.  The point of it was, in FRUA, if you stepped on Quest 1 Stage 1 but already had Quest 1 Stage 2, that event wouldn't fire.  Experienced designers might not have problems with this, but for many folks it can be difficult to set up your designs in such a way as to get the Quest Stage events to fire when you really wanted them to. 

I'm not going to tell you how to do things, but I am going to question why this would be considered useful.

If a party already has "Quest 1-Stage 2," the only way that can happen is if they've already encountered "Quest 1-Stage 1" at some previous point in the adventure.

In standard UA, if you need something to fire when a quest is in progress, you can set an event to only fire if they have "Special Item = Quest 1."

The way it's done here, it totally breaks the Quest system, especially if you need to restart it for some reason.  The "Do Only Once" tag will completely ruin that.

You shouldn't take this as criticism...I'm just trying to understand the decision.  From the point of view of someone who completely grasps how the Quest system should work, this makes no sense.  I'm just trying to make sense of it.  So, I guess I'm asking for you to "break" my logic and help me see what the point of it was (because I'm sure there was some good reason that I can't quite grasp).
« Last Edit: February 15, 2009, 03:22:56 PM by ProphetSword »
LANDS OF ADVENTURE: An Old-School Style CRPG

More Information Here: http://landsadventure.blogspot.com/

Offline Darius

  • Jr. Member
  • **
  • Posts: 71
    • Darius' Unlimited Adventures Domain
Re: Strange Quest Behavior
« Reply #14 on: February 16, 2009, 01:23:14 AM »

Yep, as I said in my last post, experienced designers like you and I don't have trouble with the FRUA Quest system as written.  The OAUA Quest System isn't broken, it just operates differently, in a way that is easier -- and less prone to game-breaking Quest Stage bugs -- for less experienced designers.

What I apparently neglected to do was to describe the new system in the included documentation.  I'll see if I can add that in to make things clearer.