PC at _place_ do _task [Dungeon Exteriors]

For all talk about quest development - creation, testing, and quest system.
User avatar
Kamer
Posts: 583
Joined: Mon Mar 05, 2018 9:26 pm

PC at _place_ do _task [Dungeon Exteriors]

Post by Kamer »

My Quest Pack Warm ashes uses remote dungeon exteriors to work and the only way I can get the game to work with it, is by "setting" a task to run.

Code: Select all

Startup:
pc at _place_ set _event_

That is fine but with how that works is that only one location at a time can be set. No two locations can share a task when they are "Set".
To bypass this you would ahve something like:

Code: Select all

Startup:
pc at _place_ do _event_

However, this doesn't seem to work with remote dungeon exteriors. Is there anyways to bypass this and allow all remote dungeon types to share one task? The solution right now is using too many variables to do much with. Any help would be grateful.

User avatar
Interkarma
Posts: 7236
Joined: Sun Mar 22, 2015 1:51 am

Re: PC at _place_ do _task [Dungeon Exteriors]

Post by Interkarma »

Tasks are not like subroutines or events, they're more like individual threads. Once a task is set it will keep running until it is unset again or the quest ends.

Some actions like "pc at" work like a toggle. They will turn the target task on when player is at that location and off again when player is not at that location. A good example of this set/unset behaviour is the ghosts and wraiths in Daggerfall city at night. The task holding the "create foe" action switches on and off based on time of day and whether player is inside the city limits.

So what's happening when using multiple "pc at" conditions for the same target task is that one "pc at" condition might be trying to turn the task off while another one is trying to turn it on. Simply put, the "pc at" command isn't capable of setting a task then terminating.

I can't change behaviour of "pc at" as it's too embedded in the quest system to work in this specific way. But there are ways we can work around it, including adding a new variant of the action to help.

Would some variant of "pc at" to only set a task then stop checking be suitable? Maybe something like the below:

Code: Select all

pc at _place1_ set _event_ notoggle
The "notoggle" tag would suppress the toggle behaviour and cause action to terminate once the set fires. That should help you solve the problem, no?

User avatar
Jay_H
Posts: 4061
Joined: Tue Aug 25, 2015 1:54 am
Contact:

Re: PC at _place_ do _task [Dungeon Exteriors]

Post by Jay_H »

I believe that solution would cause the event to continue occurring elsewhere, beyond its intended limits. It looks like this would require the use of variables not implemented in DFU, such as all_dungeons.

A similar idea would be if I wanted an event to occur when I first enter any temple. I can currently designate a single temple in DFU, but not all temples, as a quest location.

User avatar
Kamer
Posts: 583
Joined: Mon Mar 05, 2018 9:26 pm

Re: PC at _place_ do _task [Dungeon Exteriors]

Post by Kamer »

Interkarma wrote: Thu May 31, 2018 9:10 pm Tasks are not like subroutines or events, they're more like individual threads. Once a task is set it will keep running until it is unset again or the quest ends.

Some actions like "pc at" work like a toggle. They will turn the target task on when player is at that location and off again when player is not at that location. A good example of this set/unset behaviour is the ghosts and wraiths in Daggerfall city at night. The task holding the "create foe" action switches on and off based on time of day and whether player is inside the city limits.

So what's happening when using multiple "pc at" conditions for the same target task is that one "pc at" condition might be trying to turn the task off while another one is trying to turn it on. Simply put, the "pc at" command isn't capable of setting a task then terminating.

I can't change behaviour of "pc at" as it's too embedded in the quest system to work in this specific way. But there are ways we can work around it, including adding a new variant of the action to help.

Would some variant of "pc at" to only set a task then stop checking be suitable? Maybe something like the below:

Code: Select all

pc at _place1_ set _event_ notoggle
The "notoggle" tag would suppress the toggle behaviour and cause action to terminate once the set fires. That should help you solve the problem, no?
Just got off from work. I'll see what I can do with this. Thanks for the feedback!

User avatar
Interkarma
Posts: 7236
Joined: Sun Mar 22, 2015 1:51 am

Re: PC at _place_ do _task [Dungeon Exteriors]

Post by Interkarma »

Jay_H wrote: Fri Jun 01, 2018 12:37 am A similar idea would be if I wanted an event to occur when I first enter any temple. I can currently designate a single temple in DFU, but not all temples, as a quest location.
I see what you're saying. This would be a rather easy action to create as well. Probably much easier than the Place and PcAt combo was.

Kamer, can you let me know if this would be more helpful in your case?

User avatar
Kamer
Posts: 583
Joined: Mon Mar 05, 2018 9:26 pm

Re: PC at _place_ do _task [Dungeon Exteriors]

Post by Kamer »

Normally it goes like this:

Startup:
pc at _place1_ set _event_
pc at _place2_ set _event_ <- Since this is the last one to set the _event_ task, this will be the only one that works even if the player gets to _place1_ first.

Then would the notoggle work for a situation like this?
pc at _place1_ set _event_ notoggle <- *
pc at _place2_ set _event_ notoggle

*So what you are saying both will be able to use the event toggle once it's checked and confirmed player is there?

User avatar
Interkarma
Posts: 7236
Joined: Sun Mar 22, 2015 1:51 am

Re: PC at _place_ do _task [Dungeon Exteriors]

Post by Interkarma »

Yeah, the idea is the "notoggle" would only set the target task then stop. I'm just brainstorming at this point. :)

Jay also had a good idea for a quest action that could trigger when player is at "any dungeon" or "any location" of a certain type. Would that be more helpful? He might have understood your needs better than I have.

User avatar
Kamer
Posts: 583
Joined: Mon Mar 05, 2018 9:26 pm

Re: PC at _place_ do _task [Dungeon Exteriors]

Post by Kamer »

Interkarma wrote: Fri Jun 01, 2018 1:12 am
Jay_H wrote: Fri Jun 01, 2018 12:37 am A similar idea would be if I wanted an event to occur when I first enter any temple. I can currently designate a single temple in DFU, but not all temples, as a quest location.
I see what you're saying. This would be a rather easy action to create as well. Probably much easier than the Place and PcAt combo was.

Kamer, can you let me know if this would be more helpful in your case?
With" PC at" command I have to select a random remote dungeon of ONE type.

ruin1
ruin2
ruin3
etc

Something like all_ruins exterior or something can work.

The issue is right now is that with every _ruin1_, it has to have it's own individual task like _task1_ _check1_ tripling the work and variable amounts.
If I could have just one that would define all dungeon exterior types, it would cut all that down to one basic task for what I need.

Like all_ruin exterior _task_ _check_, instead of needing to ahve individual task for reach randomly selected ruin since it would then be checked for all.

User avatar
Interkarma
Posts: 7236
Joined: Sun Mar 22, 2015 1:51 am

Re: PC at _place_ do _task [Dungeon Exteriors]

Post by Interkarma »

Yep, I think I'm on the same page now. Forget the "notoggle" idea. I'll cook up something like:

Code: Select all

pc at any exteriorType set aTask
This would turn target action on when player is at any exterior of that type, and off when they leave again.

Is that getting closer?

User avatar
Kamer
Posts: 583
Joined: Mon Mar 05, 2018 9:26 pm

Re: PC at _place_ do _task [Dungeon Exteriors]

Post by Kamer »

Bingo! This is perfect! This is going to cut down script lengths and hickups in game dramatically due to large quest files. (My siege quest system before getting trimmed had about over 1,000 lines with 90% of it being variables for each dungeon. )

The working version with current variables is about 780 lines and 97 variables/tasks.
Last edited by Kamer on Fri Jun 01, 2018 1:35 am, edited 1 time in total.

Post Reply