Quest Script readable by mere mortals?

For all talk about quests. Creating, testing, bugs, and development progress.
User avatar
JorisVanEijden
Posts: 49
Joined: Mon Aug 12, 2019 5:02 pm

Re: Quest Script readable by mere mortals?

Post by JorisVanEijden » Sun Sep 08, 2019 7:09 am

BansheeXYZ wrote:
Sun Sep 08, 2019 5:29 am
Here's Jay's quest in my format. Please poke holes in it if you can:

Code: Select all

Define Item(_alch_) as small.plant
This is not a name of an exisiting item. And how do you deal with artfiacts, magic items, gold amounts, randomization, item classes and subclasses?

Code: Select all

Define Person(_questgiver_) as male.questor
How do you define the social group, faction, named npcs, associated rumors and background info?

Code: Select all

Define Enemy(_grizzlybears_) as grizzly_bear every 00d00h14m indefinitely with 45% success
The time and success rate should belong to the spawning action, not the enemy definition.
What if I had eight places I wanted to spawn bears, define 8 different kinds of bear?

Code: Select all

Define Chance(_minions_) as 20% A 80% B
Why define this _minions_ here?
A "Task" like

Code: Select all

If Player isInside Place(_dungeon_) & Chance(20%)
would seem simpler.

Code: Select all

Create Enemy(_hermit_) at Place(_dungeon_)
The enemy is already created in definitions, so "Place" would seem the more logical command.

Code: Select all

If Player isInside Place(_dungeon_) & Chance(_minions_) isA
	Then Say Message(1024)
How can I reset this trigger from another task so that this one can fire again?

Code: Select all

If Player isInside Place(_dungeon_) & Chance(_minions_) isB & Enemy(_hermit_) isAlive & Time is08:00to18:00
	Then Spawn Enemy(_grizzlybears_) & Spawn Enemy(_giantbats_) & Spawn Enemy(_giantrats_) & Spawn Enemy(_spriggans_)
These long lines are very hard to read.

Code: Select all

If Person(_questgiver_) isClicked & Enemy(_healer_) isDead
If I click the questgiver somewhere at the beginning of the quest and some time later the enemy dies, is that when this task triggers?

Code: Select all

Then Say Message(1004) & End

Code: Select all

Then Say Message(1003) & End
How does this differentiate between a successfully completed and a failed expired quest?


Here's a short reference of the "Template" decompiler format that DFU adopted: https://www.dfworkshop.net/static_files ... -docs.html
And here's a description of the daggerfall classic format: https://en.uesp.net/wiki/Daggerfall:Quest_hacking_guide

BansheeXYZ
Posts: 500
Joined: Fri Oct 23, 2015 8:19 pm

Re: Quest Script readable by mere mortals?

Post by BansheeXYZ » Sun Sep 08, 2019 10:40 am

JorisVanEijden wrote:
Sun Sep 08, 2019 7:09 am
This is not a name of an exisiting item. And how do you deal with artfiacts, magic items, gold amounts, randomization, item classes and subclasses?
How do you define the social group, faction, named npcs, associated rumors and background info?
The item _alch_ in Jay's quest is never used in QBN and placed in world. I think it's only defined to be used in one of his QRC messages.

I've simply matched info given in the quests that I converted, and fleshed out a general structure and syntax based on looking at a few quests. A truly comprehensive design document would be quite a bit longer as there are many minor details and lesser used things needing added.
JorisVanEijden wrote:
Sun Sep 08, 2019 7:09 am

Code: Select all

Define Enemy(_grizzlybears_) as grizzly_bear every 00d00h14m indefinitely with 45% success
The time and success rate should belong to the spawning action, not the enemy definition.
What if I had eight places I wanted to spawn bears, define 8 different kinds of bear?
These long lines are very hard to read.
That doesn't sound like a real world example, and it also sounds like you'd be doing that anyway if you wanted to Unspawn specific spawn locations. At the same time, there's nothing stopping a parser from supporting both methods, or even custom linebreaking. As long as the syntax remains as I wrote it with If and Then, you know when they begin and end and you can write lines however you feel is more readable. Personally, lines would have to be very long to affect me. None of those lines are even longer than the longest line in this paragraph.
Why define this _minions_ here?A "Task" like

Code: Select all

If Player isInside Place(_dungeon_) & Chance(20%)
would seem simpler.
I think you're misreading the usage. The immediate task to "Calculate Chance" is going to roll a number between 1 and 5, and if it rolls a 1, Chance "isA" for the duration of the quest. Then when the player enters the dungeon, the conditions isInside and Chance isA are met, triggering the message telling the player that there are strangely no spawns. The story path that creates the spawns is in conflict with the one that doesn't, so they can't be separate chances or they'd both possibly trigger and it wouldn't make sense.

You could also make a quest that does 10% A 30% B 20% C 40% D, with 4 separate story arcs, A being the rarest to get. Or you could do 1% A 99% B and drop a rare item 1% of the time. This method would support both cases.
The enemy is already created in definitions, so "Place" would seem the more logical command.
That's fine.
How can I reset this trigger from another task so that this one can fire again?
If you give a classic quest that already does this, I can probably think of a way.
If Person(_questgiver_) isClicked & Enemy(_healer_) isDead[/code]If I click the questgiver somewhere at the beginning of the quest and some time later the enemy dies, is that when this task triggers?
Ah, so that's what clearclick tasks are for.

Seems like there are multiple ways to solve this. I'll have to mull it over.

Code: Select all

Then Say Message(1004) & End

Code: Select all

Then Say Message(1003) & End
How does this differentiate between a successfully completed and a failed expired quest?
Never got around to this, or how quests reward faction rep. Couldn't see any indicators on those tasks for how this happens.

Here's a short reference of the "Template" decompiler format that DFU adopted: https://www.dfworkshop.net/static_files ... -docs.html
And here's a description of the daggerfall classic format: https://en.uesp.net/wiki/Daggerfall:Quest_hacking_guide
Thanks, I'll read it all.

BansheeXYZ
Posts: 500
Joined: Fri Oct 23, 2015 8:19 pm

Re: Quest Script readable by mere mortals?

Post by BansheeXYZ » Mon Sep 09, 2019 12:54 am

This is what was missing from my method, I had no equivalent of clear. Instead of "Undo", I think it would be more versatile to just use "Make" and alter the state of something how we want.

Code: Select all

	If Enemy(_hermit_) isAlive & Person(_questgiver_) isClicked
		Then Make Person(_questgiver_) Unclicked
If there had been a message for dallying called 1005:

Code: Select all

	If Enemy(_hermit_) isAlive & Person(_questgiver_) isClicked
		Then Say Message(1005) & Make Person(_questgiver_) Unclicked
Note that the "is" prefix is not a requirement and would be ignored by the parser, it's just an optional thing I prefer to make "If" statements read like English.

NoobioDF
Posts: 52
Joined: Sat Jun 22, 2019 4:03 am

Re: Quest Script readable by mere mortals?

Post by NoobioDF » Thu Sep 19, 2019 4:05 am

Well, not to be a pain, but you really can't have to fruitful a discussion this way, since both the vocabulary and the syntax of both methods, the existing scripting language for quests, and the proposed one I think by Banshee, are not fully defined or recognized by all parties. So unless you spent the whole time teaching each other the whole methodology of each, you will remain often confused by each other. That doesn't mean it isn't a very honorable pursuit, I just think the problem conversing here is the different vocabulary and experience/context with that system.

Creation is an example in the original in-game method. You can think, well why doesn't that also Place. Well technically it does, but not in the obvious game world. Think of it this way, it is a reserved Creation for later use and placement. Often this is done to make modding possible. The Quest language actually is similar to a modding language. So Creation is like an engine thing only, where Placement slaps it in a place per either a Starting Quest or a called Quest. Your Quests are basically your enactors or placers.

So the Place command is meant to bring that hidden already created item into the main game world and place it at a definitive location.

So, yes, in many languages when you Create something you place it somewhere, but here, you are placing it not in the obvious game world. Supposedly this is a bit similar in TES5Edit for a reference. You don't want to truly delete the reference when you mod something in, because if you do, and then remove the mod, that reference now needs to be put back in since the original game when unmodded had it available. This all comes from the default game being the Master Mod or File if you will, and any subsequent change or mod coming after it. Only one record can survive, so that last one is used. Well, as long as the Master Reference remains hidden somewhere, like when inactivated and slapped 50 meters under the terrain, then when the mod is removed, it can be returned as in the original.

But again, that explains little to one who hasn't had to deal with this at all. One would have to know how mod order works, how TES5Edit works, and the difference between Deletion of a Reference, and the other term that I called for now Inactivate (but the actual term is different, but as usual I forget). And I'm not that knowledgeable on the subject of TES5Edit or modding of the Elder Scrolls series anyway.

But, so the scripting language is always more like a hack. It isn't as pure as say defining a variable in a Programming Language like C. And usually Quest Lines are either done in a certain order, so their order matters, or they are also determined by what Section or Paragraph they are in. So one Section is there to define temporarily certain things. And usually as long as it is just within a Quest or a Script, it only exists for that Quest's duration, or for that Script's duration. Why? Cuz it isn't really a full programming language, it is there to hack into the game engine, get something done while it exists, and get the hell done or expire, afterwards. It's results are still in the game, if they are made to trigger key in-game results. Like writing to the Log, or providing NPCs that become corpses that provide loot, etc.

So, it's actually a terrible mindset, but it is meant to be a shorthand. Shorthands often do several tasks at once easily, but they can be terribly hard to read without the inside knowledge of what they are meant to be doing, and what other helping functions in the game they use. Think of these Quest Scripts as this sort of shorthand. There is stuff not talked about which are rules and codelets they can call from the always existing game engine code, and they hack into these. They are like long specially worded Console commands, following a special format so that the Console or the game can translate what they mean and make them work.

Maybe that helps some. So the wording is obtuse because you aren't defining Global Variables that always exist. You are using things that the Quest Script may never define, but actually exist as always available code functions. You don't have to create a new function or subroutine, because those already exist, and the arcane example of how to create 1% chance, is simply a way to save another 99 places in an array in the main game engine or some other strange reasoning.

Anyway, that's how I would see it.

My problem in the few times I looked at Quest Scripts, and I have only spent under an hour looking at any, is the format into sections and what comes first versus later, which I'm sure matter. The rest of the examples given here, the old stuff doesn't look too obtuse to me, as long as I imagine it as only a script hack into other game engine stuff for quests.

So for me, laziness is the main issue, and lack of experience with the system is the resulting problem.

User avatar
Yagiza
Posts: 38
Joined: Wed Jul 31, 2019 5:16 pm

Use Prolog as Quest Script language?

Post by Yagiza » Thu Sep 19, 2019 11:28 am

Quest language, used by Template and DFU is a declarative language, just like Prolog. There are some open source Prolog implementations around.
Why, instead of inventing a new bicycle, just switch to Prolog as quest language?
I beleve, we can easily write a simple utility to convert Template quest source files to Prolog source files.

User avatar
JorisVanEijden
Posts: 49
Joined: Mon Aug 12, 2019 5:02 pm

Re: Use Prolog as Quest Script language?

Post by JorisVanEijden » Thu Sep 19, 2019 4:49 pm

Yagiza wrote:
Thu Sep 19, 2019 11:28 am
Quest language, used by Template and DFU is a declarative language, just like Prolog. There are some open source Prolog implementations around.
Why, instead of inventing a new bicycle, just switch to Prolog as quest language?
Even as horrible as the Template "language" is, I somehow doubt that quest-writers would prefer Prolog ;)
Yagiza wrote:
Thu Sep 19, 2019 11:28 am
I beleve, we can easily write a simple utility to convert Template quest source files to Prolog source files.
You need to go the other way, from Prolog to Template.

User avatar
Yagiza
Posts: 38
Joined: Wed Jul 31, 2019 5:16 pm

Re: Use Prolog as Quest Script language?

Post by Yagiza » Fri Sep 20, 2019 6:26 am

JorisVanEijden wrote:
Thu Sep 19, 2019 4:49 pm
Even as horrible as the Template "language" is, I somehow doubt that quest-writers would prefer Prolog ;)
At least, it will provide much more features, than currently used X-Engine. We'll be able to write more complicated and really interesting quests.
Yagiza wrote:
Thu Sep 19, 2019 11:28 am
You need to go the other way, from Prolog to Template.
There is no such way. :lol:

User avatar
Ferital
Posts: 152
Joined: Thu Apr 05, 2018 8:01 am

Re: Use Prolog as Quest Script language?

Post by Ferital » Fri Sep 20, 2019 7:45 am

Yagiza wrote:
Fri Sep 20, 2019 6:26 am
JorisVanEijden wrote:
Thu Sep 19, 2019 4:49 pm
Even as horrible as the Template "language" is, I somehow doubt that quest-writers would prefer Prolog ;)
At least, it will provide much more features, than currently used X-Engine. We'll be able to write more complicated and really interesting quests.
Template might be difficult to deal with at first but this is what made Daggerfall classic quest system understandable and implementable in DFU. And as the entire DFU quest sytem is built on it, there is no reason to change this, especially now the game has reached alpha. However, if you find that Template lacks some potential useful new feature, you can propose such a one, as Template can certainly be expanded beyond what classic was capable of.

Switching to another scripting language in DFU will never happen as this would require to rewrite major portions of the current quest system which would lead, most likely, to countless bugs.
Yagiza wrote:
Fri Sep 20, 2019 6:26 am
JorisVanEijden wrote:
Thu Sep 19, 2019 4:49 pm
You need to go the other way, from Prolog to Template.
There is no such way. :lol:
Nor is there a way to translate Template to Prolog. If someone wants to write quests in another scripting language, he can, but he will need to write himself the tool to translate this language to Template.

User avatar
JorisVanEijden
Posts: 49
Joined: Mon Aug 12, 2019 5:02 pm

Re: Use Prolog as Quest Script language?

Post by JorisVanEijden » Fri Sep 20, 2019 11:10 am

I see two issues here:
1. People find the Template language difficult to read and write.
2. People want to add additional features to Template.

For the 1st issue people need to understand that writing a tool that translates whatever easy quest script language they come up with to Template is much much easier to do than rewriting the current quest engine (which is not X-Engine by the way) to read their script.

I really dislike Template so I'm all for an easier to read/use script, but it does have to compile to a format that DFU can understand. Which is either Template, or the serialized json variant of it used in the savegames.

The second issue can be solved by first describing what it is that cannot be done in Template, then describing how it could be made possible in Template in a backward compatible way, then discussing the viability with the community and then submitting a Pull Request which adds the feature to the current quest engine.

BansheeXYZ
Posts: 500
Joined: Fri Oct 23, 2015 8:19 pm

Re: Quest Script readable by mere mortals?

Post by BansheeXYZ » Sun Sep 22, 2019 3:28 pm

I like how terminology changes between sections. Clock becomes timer... Person becomes npc...

and what's with this "start up task" in A0C01Y01?

Code: Select all

--	Quest start-up:
	start timer _S.00_ 
	log 1010 step 0 
	pc at _qgiverhome_ set _S.05_
	create npc at _qgiverhome_ 
Translated:

Code: Select all

--	Quest start-up:
	Do this
	Do that
	If player goes inside this place WELL AFTER THE QUEST HAS STARTED, start this nameless task and mark as completed, which if you scroll down, is a single action to say something that can't directly go here for some reason.
	Do this 
In other words, I don't get why a conditional thing is in the start-up section, or why a message has to act as a trigger for the spawn code instead of what the game should already know directly (whether the player is inside or outside of a predefined place).

Post Reply