Planet
navi homePPSaboutscreenshotsdownloaddevelopmentforum

source: code/trunk/doc/api/Groups.dox @ 7487

Last change on this file since 7487 was 7487, checked in by dafrick, 15 years ago

Forgot to actually commit largest doc part…

  • Property svn:eol-style set to native
File size: 26.1 KB
Line 
1/*
2 *   ORXONOX - the hottest 3D action shooter ever to exist
3 *                    > www.orxonox.net <
4 *
5 *
6 *   License notice:
7 *
8 *   This program is free software; you can redistribute it and/or
9 *   modify it under the terms of the GNU General Public License
10 *   as published by the Free Software Foundation; either version 2
11 *   of the License, or (at your option) any later version.
12 *
13 *   This program is distributed in the hope that it will be useful,
14 *   but WITHOUT ANY WARRANTY; without even the implied warranty of
15 *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
16 *   GNU General Public License for more details.
17 *
18 *   You should have received a copy of the GNU General Public License
19 *   along with this program; if not, write to the Free Software
20 *   Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
21 *
22 *   Author:
23 *      Fabian 'x3n' Landau
24 *   Co-authors:
25 *      Damian 'Mozork' Frick
26 *
27 */
28
29/**
30    @defgroup Util Util
31
32    The util library contains several functions, classes, and templates that can be used in different
33    parts of the Orxonox-code. They provide functionalities for mathematical use, string manipulation,
34    typeconversion, multi-types, error- and exception-handling, debug output, and many more.
35*/
36
37/**
38    @defgroup Core Core
39
40    The core library contains the framework of Orxonox - all important classes, functions, and macros
41    that are used to create and manage classes and objects. Almost all classes in Orxonox need at least
42    one of the core features.
43*/
44
45/**
46    @defgroup Class Class management
47    @ingroup Core
48*/
49
50/**
51    @defgroup Object Object management
52    @ingroup Core
53*/
54
55/**
56    @defgroup Command Command
57    @ingroup Core
58*/
59
60/**
61    @defgroup Config Config
62    @ingroup Core
63*/
64
65/**
66    @defgroup Input Input
67    @ingroup Core
68*/
69
70/**
71    @defgroup Management Management
72    @ingroup Core
73*/
74
75/**
76    @defgroup XML XML
77    @ingroup Core
78*/
79
80/**
81    @defgroup Network Network
82
83    The network library is used to connect clients and server, to synchronize objects and variables, and
84    to transmit network function calls. It contains the central @ref orxonox::Server "Server" and
85    @ref orxonox::Client "Client" classes as well as several functions and macros for
86    @ref orxonox::Synchronisable "synchronisable" classes.
87*/
88
89/**
90    @defgroup Tools Tools
91
92    The tools are a bunch of utilities that belong to the Orxonox library, but are independent of other
93    features.
94*/
95
96/**
97    @defgroup Orxonox Orxonox
98
99    The Orxonox library contains the central and most important classes of the game. Managers, interfaces,
100    base-classes, and more are located in Orxonox. More specialized classes that inherit of the base-classes
101    in Orxonox are often sourced out to the modules.
102*/
103
104/**
105    @defgroup Modules Modules
106
107    The modules are libraries that depend on the Orxonox library and that are loaded dynamically on runtime
108    (in contrast to statically loaded libraries like util and core). Each module contains some classes that
109    are usually connected to each other, but they are independent of other modules. However modules can still
110    link to other modules, but only in a hierarchical order, no circular dependencies.
111*/
112
113/**
114    @defgroup Designtools Designtools
115    @ingroup Modules
116*/
117
118/**
119    @defgroup Notifications Notifications
120    @ingroup Modules
121
122    @ref orxonox::Notification "Notifications" are short messages, that can be sent from anywhere in Orxonox and then are displayed on the screen to inform the user about some occurence he has to know about. Such an occurence could be, that he just shot and killed his Archnemesis Overlord3, that he just got a new Pickup or that he received a Quest and needs to have a look at the Quest-Menu.
123
124    @section NotificationsUsage Usage
125    Let's very briefly talk about what you have to do to either send @ref orxonox::Notification "Notifications" from some part of Orxonox or display Notifications on your screen.
126
127    @subsection NotifictionsSending Sending notifications
128    Sending a new @ref orxonox::Notification "Notification" from (almost) anywhere in Orxonox is fairly easy.
129    You first have to decide on a message, it shouldn't be too long but be long enough to get your point accross.
130    Then you have to decide on a sender. The sender is a string by which the different @ref orxonox::NotificationQueue "NotificationQueues" (the entities that display the @ref orxonox::Notification "Notifications") can decide whether they should display the @ref orxonox::Notification "Notification" or not. So the sender is some string that identifies a group of @ref orxonox::Notification "Notifications" that have something in common or some entity that is sending them. For example: All @ref orxonox::Notification "Notifications" sent by any part of the Questsystem have "questsystem" as sender and thus we could create a @ref orxonox::NotificationQueue "NotificationQueue" that only displays @ref orxonox::Notification "Notifications" from the Questsystem, but more to that later.
131    And lastly you have to decide to whom you want to send this @ref orxonox::Notification "Notification". You have to get the clientId of the intended recipient (e.g. trought a @ref orxonox::PlayerInfo "PlayerInfo") or you only send the @ref orxonox::Notification "Notification" locally, either by setting the clientId to Host::getPlayerID() or by setting the variable 'isLocal' to true, and setting clientId to what ever you want, since it will be ignored.
132    Once you have decided all that you can send the Notification by calling:
133    @code
134    NotificationManager::sendNotification(message, clientId, sender, isLocal); // isLocal = false can be ommitted since that is the default value.
135    @endcode
136
137    @subsection NotificationsDisplay Displaying notifications
138    Displaying @ref oroxnox::Notification "Notifications" is even easier, all you need to do is to load the NotificationLayer in the level, where you want @ref orxonox::Notification "Notifications" displayed. You can either do this manually by executing the following command in the console:
139    @code
140    showGUI NotificationLayer false true
141    @endcode
142    Or automatically, by adding a @ref orxonox::Script "Script" to the levelfile that does it for you:
143    @code
144    <Script code="showGUI NotificationLayer false true" needsGraphics="true" />
145    @endcode
146
147    If you want to change the way the @ref orxonox::Notification "Notifications" are displayed, you can enter the (at this point rather rudimentary) edit mode and add new @ref orxonox::NotificationQueue "NotificationQueues" or change position and properties of the existing ones, by executing the following command in the console:
148    @code
149    enterEditMode
150    @endcode
151
152    @section NotificationsTechincalDetails Technical details
153    The Notifications module has three major parts that interact with each other. First there is the @ref orxonox::NotificationQueue "NotificationQueue", this is the entity that (logically, not effectively) displays @ref orxonox::Notification "Notifications" according to some rules, then there is the NotificationLayer, which is the GUI which (actually) displays @ref orxonox::Notification "Notifications" by visualizing the @ref orxonox::NotificationQueue "NotificationQueues" and as a result also the @ref orxonox::Notification "Notifications", that are displayed by the respective @ref orxonox::NotificationQueue "NotificationQueues" and lastly there is the @ref orxonox::NotificationManager "NotificationManager", which connects these two.
154
155    @subsection NotificationLayer NotificationLayer
156    The NotificationLayer is a GUI sheet, that displays all the @ref orxonox::NotificationQueue "NotificationQueues" and their @ref orxonox::Notification "Notifications". In its normal mode of operation it is transparent to input, meaning that it only functions as a means of displaying, however if switched to edit mode the NotificationLayer no longer is transparent to input and allows for the adding, removal and modification of @ref orxonox::NotificationQueue "NotificationQueues".
157
158    @subsection NotificationQueue NotificationQueue
159    ...
160
161    @subsection NotificationManager NotificationManager
162    ...
163
164    @subsection Notification Notification
165    The @ref orxonox::Notification "Notification" class is more or less a data structure that groups the notification message and the sender, and possibly other future parameters together to form a comprehensive structure that we call Notification.
166
167    Additionally there is another important class of objects belonging to the Notifications module. The @ref orxonox::NotificationDispatcher "NotificationDispatchers".
168
169    @subsection NotificationDispatcher NotificationDispatcher
170    @ref orxonox::NotificationDispatcher "NotificationDispatchers" are entities that are instantiated in a level file (through XML) and that dispatch (or send) a specific @ref orxonox::Notification "Notification" upon having received a triggering event.
171
172    @defgroup NotificationDispatchers Dispatchers
173    @ingroup Notifications
174*/
175
176/**
177    @defgroup Objects Objects
178    @ingroup Modules
179*/
180
181/**
182    @defgroup Overlays Overlays
183    @ingroup Modules
184*/
185
186/**
187    @defgroup Pickup Pickup
188    @ingroup Modules
189
190    @defgroup PickupItems Items
191    @ingroup Pickup
192*/
193
194/**
195    @defgroup Pong Pong
196    @ingroup Modules
197*/
198
199/**
200    @defgroup Questsystem Questsystem
201    @ingroup Modules
202
203    The Questsystem is a module that enhances Orxonox with @ref orxonox::Quest "Quests". @ref orxonox::Quest "Quests" are objects that challenge the player that receives such an object to fulfill some specific task (e.g. Rescue a princess, fetch some rare metal alloy, destroy the evil pirates den, ...). Upon having fulfilled that task the player can be rewarded with some kind of reward. Quests can be hierarchically structured, meaning that to fulfill some @ref orxonox::Quest "Quest" you first have to fulfill all (or some, depending on the quest) sub-quests.
204
205    @section QuestsystemTechnicalDetails Technical details
206    The Questsystem essentially consists of the @ref orxonox::Quest "Quest" entity which is the quest itself (and sub- or helper-entities, such as @ref orxonox::QuestHint "QuestHint" (hints for quests) or @ref orxonox::QuestDescription "QuestDescription" (descriptions for quests and hints, to separate content from function)), the @ref orxonox::QuestEffect "QuestEffect" and @ref orxonox::QuestListener "QuestListener" entities which are the only tools for quests to have any influence on the game world. By enabling quests to have @ref orxonox::QuestEffect "QuestEffects" they are able to (for example) fail or complete other quests, activate hints, give rewards or even add a quest to a player. @ref orxonox::QuestListener "QuestListeners" on the other hand can be used by any object to react to a status change of a quest. The @ref orxonox::QuestEffectBeacon "QuestEffectBeacon" is the physical entity which finally makes quests available for the player in the game, by being able to invoke a @ref orxonox::QuestEffect "QuestEffect" on a player (under some conditions).
207    @image html questsystem.png
208
209    @section CreatingQuests Creating Quests
210
211    @subsection CreatingTheQuestHierarchy Creating the Quest-Hierarchy
212    To start you have to create a Quest-Hierarchy in the XML-Levelfile by hierarchically nesting your quests. There are two types of Quests you can use, the LocalQuest and the GlobalQuest.
213
214    @subsubsection LocalQuest LocalQuest
215    A @ref orxonox::LocalQuest "LocalQuest" is a @ref orxonox::Quest "Quest" which has different states for each player, that means each @ref orxonox::LocalQuest "LocalQuest" can be obtained and completed (or failed) by each player in parallel. A questId is some string that uniquely identifies the quest, this can either be a name or, to ensure uniqueness, you can use a GUID generator (<a href="http://www.google.com/search?q=guid+generator">google</a> or you can use this <a href="http://www.famkruithof.net/uuid/uuidgen">generator</a>). The advantage of GUID is, that you can be quite sure that your id is unique, the drawback is, that it provides less overview and can be quite confusing when looking at the level file. So make your own choice.
216
217    Creating a @ref orxonox::LocalQuest "LocalQuest" in XML goes as follows:
218    @code
219    <LocalQuest id="questId">
220        <QuestDescription title="Title" description="Description." /> //The description of the quest.
221        <subquests>
222            <Quest id ="questId1" /> //A list of n subquest, be aware, each of the <Quest /> tags must have a description and so on and so forth as well.
223            ...
224            <Quest id="questIdn" />
225        </subquests>
226        <hints>
227            <QuestHint id="hintId1" /> //A list of n QuestHints, see QuestHint for the full XML representation of those.
228            ...
229            <QuestHint id="hintIdn" />
230        </hints>
231        <fail-effects>
232            <QuestEffect /> //A list of QuestEffects, invoked when the Quest is failed, see QuestEffect for the full XML representation.
233            ...
234            <QuestEffect />
235        </fail-effects>
236        <complete-effects>
237            <QuestEffect /> //A list of QuestEffects, invoked when the Quest is completed, see QuestEffect for the full XML representation.
238            ...
239            <QuestEffect />
240        </complete-effects>
241    </LocalQuest>
242    @endcode
243
244    @subsubsection GlobalQuest GlobalQuest
245    @ref orxonox::GlobalQuest "GlobalQuests" are different, they can be obtained by every player but the changes made to the @ref orxonox::Quest "Quest" (e.g. completion of the quest) affect all owners of the quest. A short example: There are 3 Players, A, B and C. Player A obtains the quest, a while later player B obtains the quest and completes it. Since it is a @ref orxonox::GlobalQuest "GlobalQuest" it is completed for all players having obtained the Quest which means it is also completed for player A. Player C though, never having obtained the quest, can now never complete it.
246
247    Creating a @ref orxonox::GlobalQuest "GlobalQuest" in XML goes as follows:
248    @code
249    <GlobalQuest id="questId">
250        <QuestDescription title="Title" description="Description." /> //The description of the quest.
251        <subquests>
252            <Quest id ="questId1" /> //A list of n subquest, be aware, each of the <Quest /> tags must have a description and so on and so forth as well.
253            ...
254            <Quest id="questIdn" />
255        </subquests>
256        <hints>
257            <QuestHint id="hintId1" /> //A list of n QuestHints, see QuestHint for the full XML representation of those.
258            ...
259            <QuestHint id="hintIdn" />
260        </hints>
261        <fail-effects>
262            <QuestEffect /> //A list of QuestEffects, invoked on all players possessing this quest, when the Quest is failed, see QuestEffect for the full XML representation.
263            ...
264            <QuestEffect />
265        </fail-effects>
266        <complete-effects>
267            <QuestEffect /> //A list of QuestEffects, invoked on all players possessing this quest, when the Quest is completed, see QuestEffect for the full XML representation.
268            ...
269            <QuestEffect />
270        </complete-effects>
271        <reward-effects>
272            <QuestEffect /> //A list of QuestEffects, invoked on the player completing this quest. See QuestEffect for the full XML representation.
273            ...
274            <QuestEffect />
275        </reward-effects>
276    </GlobalQuest>
277    @endcode
278
279    As you may see that another difference between a @ref orxonox::GlobalQuest "GlobalQuest" and a @ref orxonox::LocalQuest "LocalQuest" is, that with a @ref orxonox::GlobalQuest "GlobalQuest" having @ref orxonox::AddReward "RewardEffects", the RewardEffects are only executed on the player completing the quest. Additionally @ref orxonox::CompleteQuest "CompleteEffects" are executed on all players having obtained the quest before it was completed, when it is completed., while with a @ref orxonox::LocalQuest "LocalQuest" each player that completes a quest, completes it for himself alone, but also gets the reward, regardless whether another player completed the quest before him.
280
281    @subsubsection QuestHint QuestHint
282    @ref orxonox::QuestHint "QuestHints" can be used to give a player useful information for @ref orxonox::Quest "Quests" he is working on completing. @ref orxonox::QuestHint "QuestHints" cannot have any side effects, but also have an identifier which follows the same form as in the @ref orxonox::Quest "Quests".
283
284    Creating a @ref orxonox::QuestHint "QuestHint" in XML goes as follows:
285    @code
286    <QuestHint id="hintId">
287        <QuestDesctription title="" description="" />
288    </QuestHint>
289    @endcode
290
291    @subsubsection QuestDescription QuestDescription
292    Each @ref orxonox::Quest "Quest" (and also each @ref orxonox::QuestHint "QuestHint") must have a @ref orxonox::QuestDescription "QuestDescription" consisting of a title and description, and for @ref orxonox::Quest "Quests" also messages for the event the quest is either failed or completed. Of course these are (as is the title and the description) optional.
293
294    Creating a @ref orxonox::QuestDescription "QuestDescription" in XML goes as follows:
295    @code
296    <QuestDescription title="Title" description="Description Text" failMessage="You fail." completeMessage="You win!" />
297    @endcode
298
299    @subsection CreatingSideEffects Creating side effects
300    @ref orxonox::Quest "Quests" can have side effects, in fact that is mostly what they are about. This means that they can have an influence on the game world. @ref orxonox::Quest "Quests" do that through two distinct devices, @ref orxonox::QuestEffect "QuestEffects" (active) and @ref orxonox::QuestListener "QuestListeners" (passive).
301
302    @subsubsection QuestEffect QuestEffect
303    A @ref orxonox::QuestEffect "QuestEffect" is the first (and probably most important) device for @ref orxonox::Quest "Quests" to have side effects. There are two entities that can have @ref orxonox::QuestEffect "QuestEffects": @ref orxonox::Quest "Quests" and @ref orxonox::QuestEffectBeacon "QuestEffectBeacons" (which will be explained later on). @ref orxonox::QuestEffect "QuestEffects", for example, can start a @ref orxonox::Quest "Quest" for a player, complete/fail @ref orxonox::Quest "Quests" for a player, add a @ref orxonox::QuestHint "QuestHint" or a @ref orxonox::Rewardable "Reward" to a player, and potentially much, much more.
304
305    These @ref orxonox::QuestEffect "QuestEffects" are implemented so far, but feel free to <a href="http://www.orxonox.net/wiki/DamianFrick">contact me</a> if you have suggestions for new @ref orxonox::QuestEffect "QuestEffects" or if you need help implementing a new one yourself.
306
307    @paragraph AddQuest AddQuest
308    This @ref orxonox::QuestEffect "QuestEffect" adds (respectively starts) a @ref orxonox::Quest "Quest" (identified by the given questId) to the player.
309    @code
310    <AddQuest questId="id" />  //Where id identifies the Quest that should be added.
311    @endcode
312
313    @paragraph FailQuest FailQuest
314    This @ref orxonox::QuestEffect "QuestEffect" fails a @ref orxonox::Quest "Quest" (identified by the given questId) for the player.
315    @code
316    <FailQuest questId="id" />  //Where id identifies the Quest that should be added.
317    @endcode
318
319    @paragraph CompleteQuest CompleteQuest
320    This @ref orxonox::QuestEffect "QuestEffect" completes a @ref orxonox::Quest "Quest" (identified by the given questId) for the player.
321    @code
322    <CompleteQuest questId="id" />  //Where id identifies the Quest that should be added.
323    @endcode
324
325    @paragraph AddQuestHint AddQuestHint
326    This @ref orxonox::QuestEffect "QuestEffect" adds a @ref orxonox::QuestHint "QuestHint" to a @ref orxonox::Quest "Quest" (identified by the given questId) of a player.
327    @code
328    <AddQuestHint hintId="id" />  //Where id identifies the QuestHint that should be added.
329    @endcode
330
331    @paragraph AddReward AddReward
332    This @ref orxonox::QuestEffect "QuestEffect" adds a @ref orxonox::Rewardable "Rewardable" (@ref orxonox::Rewardable "Rewardable" is an Interface which can be implemented by an object that its creator thinks should be able to be rewarded a player for completing (or failing for that matter) a @ref orxonox::Quest "Quest") to the player. @ref Pickup Pickups for example wold be good @ref orxonox::Rewardable "Rewardables".
333    @code
334    <AddReward>
335        <Rewardable /> //A list of Rewardable objects to be rewarded the player, see the specific Rewardables for their respective XML representations.
336        ...
337        <Rewardable />
338    </AddReward>
339    @endcode
340
341    @subsubsection QuestListener QuestListener
342    The @ref orxonox::QuestListener "QuestListener" is the second device you can use to create side effects. As opposed to @ref orxonox::QuestEffect "QuestEffects" (that are executed (or invoked) either as a result of failing or completing a Quest or by a @ref orxonox::QuestEffectBeacon "QuestEffectBeacon"), @ref orxonox::QuestListener "QuestListeners" are passive, meaning that they relay information regarding status changes of @ref orxonox::Quest "Quests" rather than enforcing status changes. @ref orxonox::QuestListener "QuestListeners" have a certain mode (all, start, complete or fail) and a @ref orxonox::Quest "Quest" which they belong to (resp. to which they react). You then can use @ref orxonox::QuestListener "QuestListeners" to make basically any object aware of when the status of the given @ref orxonox::Quest "Quest" changes (the way you defined through the mode) and take any action you may think of.
343
344    Here is an example of the usage of @ref orxonox::QuestListener "QuestListeners" in XML:
345    @code
346    <BaseObject> // The object that should react to the status change of a Quest.
347        <events>
348            <function> // Where function is the method of the object that schould be executed. Normally this would be visibility or activity.
349                <QuestListener questId="someQuestId" mode="someMode" /> // Where someQuestId is the identifier for the Quest the QuestListener is reacting to, and someMode is the kind of status change the QUestListener reacts to (all, start, complete or fail).
350            </function>
351        </events>
352    </BaseObject>
353    @endcode
354
355    I hope this example has made the usage of @ref orxonox::QuestListener "QuestListeners" a little clearer. The @ref orxonox::QuestListener "QuestListener" actually reacts exactly as any @ref orxonox::Trigger "Trigger" or @ref orxonox::EventListener "EventListener" would (although the @ref orxonox::QuestListener "QuestListener" is really neighter the one nor the other) which means you can use it in exactly the same way you would use one of the above, it just reacts to a different thing. Namely to the change in a @ref orxonox::Quest "Quests" status.
356
357    @subsection PuttingTheQuestsInTheGameWorld Putting the Quests in the game world
358    As of now we know how to create @ref orxonox::Quest "Quests" and @ref orxonox::QuestHint "QuestHints", we have a way for quests to add new quests, or even complete/fail other quests. We also have a way of reacting to a status change in a @ref orxonox::Quest "Quest". In short we know how quests can be created, how they can influence other quests and how we can react to changes in quests. But our @ref orxonox::Quest "Quests" have no ties (well, not really at least) to the game world as of yet, meaning, that the game world cannot influence quests. For this we have @ref orxonox::QuestEffectBeacon "QuestEffectBeacons".
359
360    @subsubsection QuestEffectBeacon QuestEffectBeacon
361    The @ref orxonox::QuestEffectBeacon "QuestEffectBeacon" is a @ref orxonox::StaticEntity "StaticEntity" and has the ability to (when triggered trough some circumstance) invoke a specified list of @ref orxonox::QuestEffect "QuestEffects" on the player triggering the @ref orxonox::QuestEffectBeacon "QuestEffectBeacon".
362
363    Creating a @ref orxonox::QuestEffectBeacon "QuestEffectBeacon" in XML goes as follows:
364    @code
365    <QuestEffectBeacon times=n> //Where 'n' is either a number >= 0, which means the QuestEffectBeacon can be executed n times. Or n = -1, which means the QuestEffectBeacon can be executed an infinite number of times.
366        <effects>
367            <QuestEffect /> //A list of QuestEffects, invoked when the QuestEffectBeacon is executed, see QuestEffect for the full XML representation.
368            ...
369            <QuestEffect />
370        </effects>
371        <events>
372            <execute>
373                <EventListener event=eventIdString />
374            </execute>
375        </events>
376        <attached>
377            <PlayerTrigger name=eventIdString /> //A PlayerTrigger triggering the execution of the QuestEffectBeacon.
378        </attached>
379    </QuestEffectBeacon>
380    @endcode
381
382    The @ref orxonox::QuestEffectBeacon "QuestEffectBeacon" can only be executed a defined number of times (where -1 times stands for an infinite number of times) and the @ref orxonox::QuestEffect "QuestEffects" are invoked whenever the method 'execute' is called, which is (indirectly through an @ref orxonox::EventListener "EventListener", because I wanted to attach the @ref orxonox::PlayerTrigger "PlayerTrigger" so that its position is always relative to the @ref orxonox::QuestEffectBeacon "QuestEffectBeacons" position) done by the @ref orxonox::PlayerTrigger "PlayerTrigger".
383
384    A @ref orxonox::PlayerTrigger "PlayerTrigger" is a special sort of @ref orxonox::Trigger "Trigger" that knows the player that triggered it and therefore can be asked who that was. This allows the @ref orxonox::QuestEffect "QuestEffects" to be executed on the right player.
385
386    @section SampleQuest Sample quest
387    To get your head around all of this and see some of the things mentioned here in action you might want to check out the "The Tale of Princess Aeryn"-Quest (Levelfile: princessaeryn.oxw) in the level-folder.
388*/
389
390/**
391    @defgroup QuestEffects Effects
392    @ingroup Questsystem
393
394    A @ref orxonox::QuestEffect "QuestEffect" is a device for @ref orxonox::Quest "Quests" to have side effects. There are two entities that can have @ref orxonox::QuestEffect "QuestEffects": @ref orxonox::Quest "Quests" and \ref orxonox::QuestEffectBeacon "QuestEffectBeacons". @ref orxonox::QuestEffect "QuestEffects", for example, can start a @ref orxonox::Quest "Quest" for a player, complete/fail @ref orxonox::Quest "Quests" for a player, add a @ref orxonox::QuestHint "QuestHint" or a @ref orxonox::Rewardable "Reward" to a player, and potentially much, much more.
395*/
396
397/**
398    @defgroup Weapons Weapons
399    @ingroup Modules
400*/
Note: See TracBrowser for help on using the repository browser.