=References=

=References=

* [[RPG configuration|Configuration]]

* [[RPG configuration|Configuration and Definitions]]

* [[RPG script|Scripting]]

* [[RPG script|Scripting]]

* [[RPG_cutscene|Cutscenes]]

* [[RPG_cutscene|Cutscenes]]

* [[RPG gui|GUIs]]

* [[RPG gui|GUIs]]

=Tutorials=

=Tutorials=

* [[RPG editing|Editing tips]]

* [[RPG editing|Editing tips]]

* [[RPG tutorial|Tutorial]] (note: out of date)

* [[RPG tutorial|Tutorial]]

=Misc. pages=

=Misc. pages=

== Cutscenes ==

== Cutscenes ==

Cutscenes unlike definitions can contain things other than numbers in their names and aren't loaded into memory until they are needed. Cutscenes are always shippable and you as the creator should therefor make sure that the post script takes care of any changes of state that need to happen, additionally during cutscenes are the only time the player can be commanded via AI commands.

Cutscenes unlike definitions can contain things other than numbers in their names and aren't loaded into memory until they are needed. Cutscenes '''can always be skipped''' and you as the creator should therefor make sure that the post script takes care of any changes of state that need to happen, additionally during cutscenes are the only time the player can be commanded via AI commands.

There are two parts to the cutscene system, the first is directives for the camera and the second are 2D elements to be drawn on screen and their containers.

There are two parts to the cutscene system, the first is directives for the camera and the second are 2D elements to be drawn on screen and their containers.

The creator can define just about anything, from creatures, monsters, maps, containers, scripts, dialogue, cutscenes, HUDs, GUIs and particle effects. The definitions are sourced from the game's data directory and can be changed in real time during the game. It should be noted that unless things use these definitions as a template, any effects from ingame modifications will not persist across sessions. We therefor recommend that you only use those that accept references as any changes to them will persist unless you simply wish to test and fine tine some variables quickly and easily.

The creator can define just about anything, from creatures, monsters, maps, containers, scripts, dialogue, cutscenes, HUDs, GUIs and particle effects. The definitions are sourced from the game's data directory and can be changed in real time during the game. It should be noted that unless things use these definitions as a template, any effects from ingame modifications will not persist across sessions. We therefor recommend that you only use those that accept references as any changes to them will persist unless you simply wish to test and fine tine some variables quickly and easily.

Also note that all definitions must be defined in a separate text file named solely by a number with a .cfg extension. Any other .cfg files will throw warnings and the game will abort if there are any gaps.

Also note that all definitions must be defined in a separate text file named solely by a number with a .cfg extension. Any other .cfg files will throw warnings and the game will abort if there are any gaps. At least that is true for the hard-coded directories - you may add additional ones and use '''include''' to include their files in your scripts and definitions.

For example, there is a definition for a bear creature with 40 strength. I might increase this to 90 in game, but any existing bears will still have 40 strength. Likewise I could create a few new bears which would then have 90 strength. if I was to save and reload my game, any new bears will have 40 strength but those spawned with 90 strength will still exist and walk about.

For example, there is a definition for a bear creature with 40 strength. I might increase this to 90 in game, but any existing bears will still have 40 strength. Likewise I could create a few new bears which would then have 90 strength. if I was to save and reload my game, any new bears will have 40 strength but those spawned with 90 strength will still exist and walk about.

In case you're wondering why there is a hud_bottom and not a hud_up, the reason is that the screen coordinates are flipped and that the top left is therefor (0, 0), not the bottom left.

In case you're wondering why there is a hud_bottom and not a hud_up, the reason is that the screen coordinates are flipped and that the top left is therefor (0, 0), not the bottom left.

== Savegames ==

== Savegames ==