Radish Trial 2 Quest Basics

From Nexus Mods Wiki
Revision as of 20:13, 14 May 2022 by Lindrole (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
The trial of the radishes is meant as a guided, self-learning tutorial without step-by-step instructions. Instead it focuses on exploratory learning by actively using the tools to solve increasingly challenging tasks.

See forum post for more information about the trials.

Trial 2 - Objectives

Now, that you got the tools working this trial will make you familiar with some basics of creating a new quest. This knowledge will be used in the following trials to extend the quest with more things

Your task is to:

  • make a new mini quest
  • it should contain at least one layer with static assets, e.g a campsite
  • there should be pickable loot or items
  • a trigger area should be used to trigger something, e.g. showing or hiding a layer
  • it should have a basic quest log (some steps with journal entries)

Some background Information

New Project Template

You should use the new-project template from the files section as a starting point for new projects. It contains a predefined directory structure for various types of content that can be created and used in a mod.

project structure

The included batch files are set up as a automatic build pipeline. The most important file at the beginning is the settings.bat in the root of the project folder. There are only a couple of settings that have to be setup at the beginning, mostly the MODNAME, string id-space and your local directories where the radish tools, the modkit and your game installation can be found.

Make sure these settings are setup correctly!

  • use the new project template downloadable from the files section as starting point to a new project
  • there is a HOWTO.create.new.project.txt in the root of the package, read it and follow the instructions
  • the MODNAME will be used as part of many names: that is directory names and in some cases even automatically generated in-game entity tags


Production settings

The settings.bat configuration is intended for the build pipeline (directory name conventions, etc.) but the quest encoders has its own settings, the ‘production settings’ defined in a yml file which is (one) required part of the quest definition. The quest production settings need to be in sync with the settings.bat.


Questgraph Editor and concurrent editing of Quest Definitions

Editing the production settings is only possible directly in the yml (after saving a new project with the questgraph editor). BUT editing quest definitions outside the editor while the definition is open in the editor is problematic:

Next time you will save the quest in the questgraph editor it will overwrite your changes - so make sure you save in editor and then update the yml. The editor will notice the changed definitions and offer you to reload from disk.

Be aware that reloading will always set the root segment to be displayed as this is the only segment guaranteed to exist in a valid definition. You can also enable an auto-reloading option in the menu: if there are no unsaved changes in the editor and it detects external changes it will reload the definitions automatically. If there are unsaved changes you will be prompted and have to confirm reloading (Example Video),

Aside from creating a new skeleton quest definition with production settings the Questgraph Editor is used to create the control flow of quests as a graph of quest blocks.

Questgraph Editor

(Nearly) everything else needs be defined outside of it in the yml quest definitions. Then you can use those “assets” (e.g. layers, communities, journal entries, etc.) IN the graph as options in the appropriate questblocks (e.g. journal entries in journal blocks, layers in show/hide layers, etc.).


Radish Quest UI

The radish quest ui is (mostly) used to define layers and their entity positions interactively in-game.

Radish Quest UI

Those in-game definitions are saved into the witcher scriptlog and must be incorporated into the “real” quest yml definitions for the encoders manually.


Tips radish quest ui

  • editing an encoded layer is not possible, but cloning an encoded layer into a new layer with the same name is. even though this cloning is not 100% exact (encoded layers support more settings than radui is able to decode), cloned layers allow interactive adjustments and logging which can afterwards be manually cherry-picked and integrated into the quest definition files.
  • while browsing entities of encoded layers the name of this read-only layer is displayed in a different color (orange)


Tips Questgraph Editor

  • the editor can create a new quest project definition (a skeleton quest yml definition). You should always save it into the projects “definition.quest” directory as this will be used by the build pipeline
  • the editor can be started with a parameter pointing it to a directory with a quest definitions. if a definition is found in the directory it will be loaded automatically. In the new project template package is a batch file named “launchQuestEditor” which starts the editor and loads the quest definition of the project automatically.
  • there is some help, even though it is only an overview, you should read the sections about Layers, Questgraphs and Journals (especially the Quest Journal).
  • you can mark and move quest blocks with the left mouse button, right button moves the graph plane, mouse wheel controls the zoom
  • connecting blocks only works from out-sockets of a block (click and keep left mouse button pressed) to in-sockets of other blocks (release button)
  • removing a connection works by moving the connection from an out-socket away (and releasing the button)
  • the editor is used to create/edit the questgraph. other definitions (e.g. layers, communities, entities, journals) have be to be defined directly wit a text editor in the yml quest definitions.
  • although layers (and other types) cannot be defined in the editor it does parse the definitions and will offer only the available parts (e.g) layers (and some of its entities) as parameters in the appropriate quest blocks
  • other manually defined elements from the yml quest definitions will be automatically available as selectable options in the editor in appropriate quest blocks, too (e.g. journal entries in journal blocks, communities, waypoints, scenepoints, …)
  • red borders around questblocks indicate errors, a mouse over tooltip will show the kind of the error
  • beware of concurrent editing of yml files and unsaved changes in the editor!


Tips Quest Definitions

  • the game is tracking quest progress by tracking questblock ids (among other things) in savegames. Regenerating a quest changes these ids everytime - so a savegame in which the quest already progressed has a VERY high chance not to work. Make sure you ALWAYS test a regenerated quest in a savegame where the quest did NOT start (even better a savegame where the quest mod was not yet installed!)
  • a quest is automatically started if the mod is installed and the dlc is enabled. this means the signal automatically starts in the quest-start block and continues according to the graph. It’s up to you to design the graph so it waits for something or what it does directly at startup.
  • it is a good idea and test to add a call block to a logging function to be able to see if the quest really started in the loaded savegame like this:
logging within a questgraph with logging function call
  • entities and layerentities are two different kind of definitions: layers are static entities put into the world. entities are entitytemplates that can be used as layer entities or be even more complex, e.g. actors to be spawned in game (which cannot be done with layer entities)
  • One common error is to use single backslashes in paths which may be interpreted as escaping of certain characters (e.g. a newline ). either use one slash (/) or two backslashes (\) in directory path definitions if they don’t seem to work
  • layerentity presets have a “simplified” settings table. start with using layerentity presets as in the example project, don’t define complex entities for this trial, there are more advanced trials coming
  • in theory you can put different aspects of quest definitions (e.g. production and questgraph) into the same file. this is strongly discouraged and in some cases even requires splitting: the questgraph editor requires production and structure (top level) types not to be mixed with other types in the same file.
Rule of thumb: every definition type (e.g. layers, communities, questgraph, ..) in a separate file and it will work out of the box


Tips build pipeline

Most important tip: make sure you don’t see any errors in the build log
  • a project needs to be generated at least once with the “full rebuild” option. this enables to create all required data files at once and is also a good option to recreate everything from scratch if something seems to be off in-game.
  • the full rebuild also automatically deletes older versions of installed mods/dlcs from this project
  • once the project was generated fully it is also possible to regenerate only specific parts of it (aka “patch” the deployed project). This is usually much faster. Experiment with regenerating only the quest files by starting the appropriate batch in the definitions.quest folder.
  • You can enable/disable an automatic start of the game after building by setting the appropriate var to 1 or 0 in the batch file you start.
  • You can have faster edit-encode-start-test cycles if you enable auto-loading of your last savegame by installing the modQuickStartupLastSave mod from the files section. Beware: this will disable the main menu! To re-enable main menu remove the mod again.
  • if you use a fresh savegame (no other quests done) the loading is much faster. so it’s a good idea to use that savegame for testing
  • you should NEVER modify any of the radish quest ui script files or in fact any of the game script files while working on your mod, if you need temporary script files put those into the “mod.scripts-tmp” dir. They will be deployed as a separate mod that can be easily removed afterwards
  • the “additional” directory is provided as an escape hatch: all of the encoder generated files will be cooked with wcc lite. The cooking works only with correctly encoded files. If you require any modeditor modified files that are not cookable by wcc lite in your mod you can put those into the additional directory. these files will be copied into the mod AFTER the wcc lite cooking step and before the packaging step. this escape hatch is not required for any of the trials, though
  • be careful: "production.id" in the prod.quest.yml file, have to be the same as the "MODNAME" in the setting.bat file