[Orxonox-commit 3508] r8194 - in code/branches/dockingsystem: . data/levels data/overlays doc/api doc/api/groups src/libraries/core src/libraries/network src/modules/designtools src/modules/objects/triggers src/modules/overlays/hud src/modules/pickup src/modules/pong src/orxonox src/orxonox/gametypes
dafrick at orxonox.net
dafrick at orxonox.net
Wed Apr 6 12:07:29 CEST 2011
Author: dafrick
Date: 2011-04-06 12:07:29 +0200 (Wed, 06 Apr 2011)
New Revision: 8194
Added:
code/branches/dockingsystem/data/levels/lastTeamStanding.oxw
code/branches/dockingsystem/data/levels/lastTeamStandingII.oxw
code/branches/dockingsystem/data/overlays/lastTeamStandingHUD.oxo
code/branches/dockingsystem/doc/api/groups/
code/branches/dockingsystem/doc/api/groups/Notifications.dox
code/branches/dockingsystem/doc/api/groups/Pickup.dox
code/branches/dockingsystem/doc/api/groups/Questsystem.dox
code/branches/dockingsystem/doc/api/groups/Triggers.dox
code/branches/dockingsystem/src/modules/overlays/hud/LastTeamStandingInfos.cc
code/branches/dockingsystem/src/modules/overlays/hud/LastTeamStandingInfos.h
code/branches/dockingsystem/src/orxonox/gametypes/LastTeamStanding.cc
code/branches/dockingsystem/src/orxonox/gametypes/LastTeamStanding.h
Removed:
code/branches/dockingsystem/doc/api/groups/Notifications.dox
code/branches/dockingsystem/doc/api/groups/Pickup.dox
code/branches/dockingsystem/doc/api/groups/Questsystem.dox
code/branches/dockingsystem/doc/api/groups/Triggers.dox
Modified:
code/branches/dockingsystem/
code/branches/dockingsystem/data/levels/lastManStanding.oxw
code/branches/dockingsystem/data/overlays/lastManStandingHUD.oxo
code/branches/dockingsystem/doc/api/Groups.dox
code/branches/dockingsystem/src/libraries/core/Loader.cc
code/branches/dockingsystem/src/libraries/network/Host.cc
code/branches/dockingsystem/src/libraries/network/MasterServerComm.h
code/branches/dockingsystem/src/modules/designtools/ScreenshotManager.cc
code/branches/dockingsystem/src/modules/objects/triggers/MultiTrigger.cc
code/branches/dockingsystem/src/modules/objects/triggers/TriggerBase.h
code/branches/dockingsystem/src/modules/overlays/hud/CMakeLists.txt
code/branches/dockingsystem/src/modules/overlays/hud/GametypeStatus.cc
code/branches/dockingsystem/src/modules/overlays/hud/GametypeStatus.h
code/branches/dockingsystem/src/modules/pickup/Pickup.h
code/branches/dockingsystem/src/modules/pong/Pong.cc
code/branches/dockingsystem/src/modules/pong/Pong.h
code/branches/dockingsystem/src/modules/pong/PongAI.cc
code/branches/dockingsystem/src/modules/pong/PongAI.h
code/branches/dockingsystem/src/modules/pong/PongBall.cc
code/branches/dockingsystem/src/modules/pong/PongBall.h
code/branches/dockingsystem/src/modules/pong/PongBat.cc
code/branches/dockingsystem/src/modules/pong/PongBat.h
code/branches/dockingsystem/src/modules/pong/PongBot.cc
code/branches/dockingsystem/src/modules/pong/PongBot.h
code/branches/dockingsystem/src/modules/pong/PongCenterpoint.cc
code/branches/dockingsystem/src/modules/pong/PongCenterpoint.h
code/branches/dockingsystem/src/modules/pong/PongScore.cc
code/branches/dockingsystem/src/modules/pong/PongScore.h
code/branches/dockingsystem/src/orxonox/OrxonoxPrereqs.h
code/branches/dockingsystem/src/orxonox/gametypes/CMakeLists.txt
code/branches/dockingsystem/src/orxonox/gametypes/Gametype.h
Log:
Merging trunk into dockingsystem branch to be able to use the recent bugfix in MultiTrigger.
Property changes on: code/branches/dockingsystem
___________________________________________________________________
Modified: svn:mergeinfo
- /code/branches/ai:6592-7033
/code/branches/buildsystem:1874-2276,2278-2400
/code/branches/buildsystem2:2506-2658
/code/branches/buildsystem3:2662-2708
/code/branches/ceguilua:1802-1808
/code/branches/chat:6527-6797
/code/branches/chat2:6836-6910
/code/branches/console:5941-6104
/code/branches/consolecommands2:6451-7178
/code/branches/consolecommands3:7178-7283
/code/branches/core3:1572-1739
/code/branches/core4:3221-3224,3227,3234-3238,3242,3244-3250,3252-3254,3256,3259-3261,3264-3265,3268-3275,3277-3278,3280,3284-3285,3287,3289-3294,3305,3309-3310
/code/branches/core5:5768-5928,6009
/code/branches/data_cleanup:7537-7686
/code/branches/doc:7290-7400
/code/branches/dynamicmatch:6584-7030
/code/branches/fps:6591-7072
/code/branches/gamestate:6430-6572,6621-6661
/code/branches/gamestates2:6594-6745
/code/branches/gametypes:2826-3031
/code/branches/gcc43:1580
/code/branches/gui:1635-1723,2795-2894
/code/branches/hudelements:6584-6941
/code/branches/ingamemenu:6000-6023
/code/branches/input:1629-1636
/code/branches/ipv6:7293-7458
/code/branches/kicklib:7975-7977
/code/branches/lastmanstanding:7479-7644
/code/branches/libraries:5612-5692
/code/branches/libraries2:5703-5737
/code/branches/lod:6586-6911
/code/branches/lodfinal:2372-2411
/code/branches/map:2801-3086,3089
/code/branches/masterserver:7502-7738
/code/branches/menu:5941-6146,6148,7536-7687
/code/branches/miniprojects:2754-2824
/code/branches/netp2:2835-2988
/code/branches/netp3:2988-3082
/code/branches/netp6:3214-3302
/code/branches/network:2356
/code/branches/network2:6434-6465
/code/branches/network3:7196-7344
/code/branches/network4:7497-7755
/code/branches/network5:7757-7781
/code/branches/network64:2210-2355
/code/branches/notifications:7314-7401
/code/branches/objecthierarchy:1911-2085,2100,2110-2169
/code/branches/objecthierarchy2:2171-2479
/code/branches/overlay:2117-2385
/code/branches/particles:2829-3085
/code/branches/particles2:6050-6106,6109
/code/branches/pch:3113-3194
/code/branches/physics:1912-2055,2107-2439
/code/branches/physics_merge:2436-2457
/code/branches/pickup2:5942-6405
/code/branches/pickup3:6418-6523
/code/branches/pickup4:6594-6710
/code/branches/pickups:1926-2086,2127,2827-2915
/code/branches/pickups2:2107-2497,2915-3071
/code/branches/png2:7262-7263
/code/branches/ppspickups1:6552-6708
/code/branches/ppspickups2:6527-6532,6554-6709
/code/branches/ppspickups3:6757-6997
/code/branches/ppspickups4:7003-7089
/code/branches/presentation:2369-2652,2654-2660,7736-7786
/code/branches/presentation2:6106-6416,7787-7800
/code/branches/presentation3:6913-7162
/code/branches/questsystem:1894-2088
/code/branches/questsystem2:2107-2259
/code/branches/questsystem5:2776-2905
/code/branches/releasetodo:7614-7647
/code/branches/resource:3327-3366
/code/branches/resource2:3372-5694
/code/branches/rocket:6523-6950
/code/branches/rocket2:6953-6970
/code/branches/script_trigger:1295-1953,1955
/code/branches/skybox2:6559-6989
/code/branches/sound:2829-3010
/code/branches/sound3:5941-6102
/code/branches/steering:5949-6091
/code/branches/usability:7915-8078
/code/branches/weapon:1925-2094
/code/branches/weapon2:2107-2488
/code/branches/weapons:2897-3051
/code/branches/weaponsystem:2742-2890
+ /code/branches/ai:6592-7033
/code/branches/buildsystem:1874-2276,2278-2400
/code/branches/buildsystem2:2506-2658
/code/branches/buildsystem3:2662-2708
/code/branches/ceguilua:1802-1808
/code/branches/chat:6527-6797
/code/branches/chat2:6836-6910
/code/branches/console:5941-6104
/code/branches/consolecommands2:6451-7178
/code/branches/consolecommands3:7178-7283
/code/branches/core3:1572-1739
/code/branches/core4:3221-3224,3227,3234-3238,3242,3244-3250,3252-3254,3256,3259-3261,3264-3265,3268-3275,3277-3278,3280,3284-3285,3287,3289-3294,3305,3309-3310
/code/branches/core5:5768-5928,6009
/code/branches/data_cleanup:7537-7686
/code/branches/doc:7290-7400
/code/branches/dynamicmatch:6584-7030
/code/branches/fps:6591-7072
/code/branches/gamestate:6430-6572,6621-6661
/code/branches/gamestates2:6594-6745
/code/branches/gametypes:2826-3031
/code/branches/gcc43:1580
/code/branches/gui:1635-1723,2795-2894
/code/branches/hudelements:6584-6941
/code/branches/ingamemenu:6000-6023
/code/branches/input:1629-1636
/code/branches/ipv6:7293-7458
/code/branches/kicklib:7975-7977
/code/branches/lastmanstanding:7479-7644
/code/branches/lastmanstanding3:7903-8175
/code/branches/libraries:5612-5692
/code/branches/libraries2:5703-5737
/code/branches/lod:6586-6911
/code/branches/lodfinal:2372-2411
/code/branches/map:2801-3086,3089
/code/branches/masterserver:7502-7738
/code/branches/menu:5941-6146,6148,7536-7687
/code/branches/miniprojects:2754-2824
/code/branches/netp2:2835-2988
/code/branches/netp3:2988-3082
/code/branches/netp6:3214-3302
/code/branches/network:2356
/code/branches/network2:6434-6465
/code/branches/network3:7196-7344
/code/branches/network4:7497-7755
/code/branches/network5:7757-7781
/code/branches/network64:2210-2355
/code/branches/notifications:7314-7401
/code/branches/objecthierarchy:1911-2085,2100,2110-2169
/code/branches/objecthierarchy2:2171-2479
/code/branches/overlay:2117-2385
/code/branches/particles:2829-3085
/code/branches/particles2:6050-6106,6109
/code/branches/pch:3113-3194
/code/branches/physics:1912-2055,2107-2439
/code/branches/physics_merge:2436-2457
/code/branches/pickup2:5942-6405
/code/branches/pickup3:6418-6523
/code/branches/pickup4:6594-6710
/code/branches/pickups:1926-2086,2127,2827-2915
/code/branches/pickups2:2107-2497,2915-3071
/code/branches/png2:7262-7263
/code/branches/ppspickups1:6552-6708
/code/branches/ppspickups2:6527-6532,6554-6709
/code/branches/ppspickups3:6757-6997
/code/branches/ppspickups4:7003-7089
/code/branches/presentation:2369-2652,2654-2660,7736-7786
/code/branches/presentation2:6106-6416,7787-7800
/code/branches/presentation3:6913-7162
/code/branches/questsystem:1894-2088
/code/branches/questsystem2:2107-2259
/code/branches/questsystem5:2776-2905
/code/branches/releasetodo:7614-7647
/code/branches/resource:3327-3366
/code/branches/resource2:3372-5694
/code/branches/rocket:6523-6950
/code/branches/rocket2:6953-6970
/code/branches/script_trigger:1295-1953,1955
/code/branches/skybox2:6559-6989
/code/branches/sound:2829-3010
/code/branches/sound3:5941-6102
/code/branches/steering:5949-6091
/code/branches/tetris:8100-8107
/code/branches/usability:7915-8078
/code/branches/weapon:1925-2094
/code/branches/weapon2:2107-2488
/code/branches/weapons:2897-3051
/code/branches/weaponsystem:2742-2890
/code/trunk:8101-8193
Modified: code/branches/dockingsystem/data/levels/lastManStanding.oxw
===================================================================
--- code/branches/dockingsystem/data/levels/lastManStanding.oxw 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/data/levels/lastManStanding.oxw 2011-04-06 10:07:29 UTC (rev 8194)
@@ -1,3 +1,9 @@
+<LevelInfo
+ name = "Last Man Standing"
+ description = "Be the sole survivor."
+ tags = ""
+/>
+
<?lua
include("stats.oxo")
include("HUDTemplates3.oxo")
@@ -37,31 +43,25 @@
<Bot />
<!-- ------------ middle asteroid -------------- -->
- <StaticEntity position="0,20,0" collisionType=static>
- <attached>
- <Model position="0,0,0" scale=140 mesh="asteroid_UV.mesh" shadow=true />
- <!-- ParticleEmitter position="0,0,0" source="Orxonox/Steam" / -->
- </attached>
- <collisionShapes>
- <SphereCollisionShape radius="145" />
- </collisionShapes>
+ <StaticEntity position="0,0,0" collisionType=static>
+ <attached>
+ <MovableEntity position="0,20,0" rotationrate="-4.5" rotationaxis="0,1,0" >
+ <attached>
+ <Model position="0,0,0" scale=140 mesh="asteroid_UV.mesh" shadow=true />
+ <Model position="-160,40,28.4" scale=1 mesh="sphere.mesh" /><!--EasterEgg indicator-->
+ <PickupSpawner position="-160,40,17" triggerDistance="20" respawnTime="5" maxSpawnedItems="15"><!--EasterEgg-->
+ <pickup>
+ <InvisiblePickup template=hugeinvisiblepickup />
+ </pickup>
+ </PickupSpawner>
+ </attached>
+ </MovableEntity>
+ </attached>
+ <collisionShapes>
+ <SphereCollisionShape radius="145" />
+ </collisionShapes>
</StaticEntity>
- <PickupSpawner position="-160,65,10" triggerDistance="10" respawnTime="5" maxSpawnedItems="10"><!--EasterEgg-->
- <pickup>
- <InvisiblePickup template=mediuminvisiblepickup />
- </pickup>
- </PickupSpawner>
- <PickupSpawner position="-160,60,17" triggerDistance="10" respawnTime="5" maxSpawnedItems="10"><!--EasterEgg-->
- <pickup>
- <InvisiblePickup template=hugeinvisiblepickup />
- </pickup>
- </PickupSpawner>
- <StaticEntity position="-160,60,28.4"><!--EasterEgg-Indicator-->
- <attached>
- <Model position="0,0,0" scale=1 mesh="sphere.mesh" />
- </attached>
- </StaticEntity>
<!-- ---------------asteroid dome----------------- -->
<?lua
@@ -137,7 +137,7 @@
</StaticEntity>
-<?lua end ?>
+<?lua end ?><!-- ---------------asteroid dome END------------------->
</Scene>
</Level>
Copied: code/branches/dockingsystem/data/levels/lastTeamStanding.oxw (from rev 8193, code/trunk/data/levels/lastTeamStanding.oxw)
===================================================================
--- code/branches/dockingsystem/data/levels/lastTeamStanding.oxw (rev 0)
+++ code/branches/dockingsystem/data/levels/lastTeamStanding.oxw 2011-04-06 10:07:29 UTC (rev 8194)
@@ -0,0 +1,142 @@
+<LevelInfo
+ name = "Last Team Standing"
+ description = "Survive as a team."
+ tags = "singleplayer"
+/>
+<?lua
+ include("stats.oxo")
+ include("HUDTemplates3.oxo")
+ include("templates/lodInformation.oxt")
+ include("lastTeamStandingHUD.oxo")
+ include("templates/spaceshipAssff.oxt")
+ include("templates/spaceshipPirate.oxt")
+ include("templates/pickupRepresentationTemplates.oxt")
+?>
+
+<Level
+ name = "Last Team Standing"
+ description = "testmap for gametype last team standing"
+ gametype = "LastTeamStanding"
+>
+ <templates>
+ <Template link=lodtemplate_default />
+ </templates>
+
+ <Scene
+ ambientlight = "0.8, 0.8, 0.8"
+ skybox = "Orxonox/skypanoramagen1"
+ >
+
+ <?lua
+ include("includes/pickups.oxi")
+ ?>
+
+<Bot />
+
+<!-- ------------ middle asteroid -------------- -->
+ <StaticEntity position="0,20,0" collisionType=static>
+ <attached>
+ <Model position="0,0,0" scale=140 mesh="asteroid_UV.mesh" shadow=true />
+ <!-- ParticleEmitter position="0,0,0" source="Orxonox/Steam" / -->
+ </attached>
+ <collisionShapes>
+ <SphereCollisionShape radius="145" />
+ </collisionShapes>
+ </StaticEntity>
+
+ <PickupSpawner position="-160,65,10" triggerDistance="10" respawnTime="5" maxSpawnedItems="10"><!--EasterEgg-->
+ <pickup>
+ <InvisiblePickup template=mediuminvisiblepickup />
+ </pickup>
+ </PickupSpawner>
+ <PickupSpawner position="-160,60,17" triggerDistance="10" respawnTime="5" maxSpawnedItems="10"><!--EasterEgg-->
+ <pickup>
+ <InvisiblePickup template=hugeinvisiblepickup />
+ </pickup>
+ </PickupSpawner>
+ <StaticEntity position="-160,60,28.4"><!--EasterEgg-Indicator-->
+ <attached>
+ <Model position="0,0,0" scale=1 mesh="sphere.mesh" />
+ </attached>
+ </StaticEntity>
+
+<!-- ---------------asteroid dome----------------- -->
+<?lua
+max = 16
+for i = 0, max, 1
+do
+ y = math.sin(i/max*6)*750
+ z = math.cos(i/max*6)*750
+ j = 1
+ ?>
+
+ <TeamSpawnPoint team="<?lua print( math.mod(i,4)) ?>" position="<?lua print(y*1.4+z*0.2) ?>,0,<?lua print(z*1.4-y*0.2) ?>" direction="0,0,0" spawnclass=SpaceShip pawndesign=spaceshipassff />
+
+ <StaticEntity position="<?lua print(y) ?>,0,<?lua print(z) ?>" scale="<?lua print(j * 2) ?>" collisionType=static >
+ <attached>
+ <Model position="0,0,0" scale=15 mesh="ast<?lua print( math.mod(i,6) + 1) ?>.mesh">
+ </Model>
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape halfExtents="<?lua print(j * 2) ?>,100,<?lua print(j * 2) ?>" position = "0,0,0" />
+ </collisionShapes>
+ </StaticEntity>
+
+ <StaticEntity position="<?lua print(y) ?>,100,<?lua print(z) ?>" scale="<?lua print(j * 2) ?>" collisionType=static >
+ <attached>
+ <Model position="0,0,0" scale=15 mesh="ast<?lua print( math.mod(i+3,6) + 1) ?>.mesh">
+ </Model>
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape halfExtents="45,100,45" position = "0,0,0" />
+ </collisionShapes>
+ </StaticEntity>
+
+ <StaticEntity position="<?lua print(y) ?>,200,<?lua print(z) ?>" scale="<?lua print(j * 2) ?>" collisionType=static >
+ <attached>
+ <Model position="0,0,0" scale=15 mesh="ast<?lua print( math.mod(i*5,6) + 1) ?>.mesh">
+ </Model>
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape halfExtents="45,100,45" position = "0,0,0" />
+ </collisionShapes>
+ </StaticEntity>
+
+ <StaticEntity position="<?lua print(y) ?>,-100,<?lua print(z) ?>" scale="<?lua print(j * 2) ?>" collisionType=static >
+ <attached>
+ <Model position="0,0,0" scale=15 mesh="ast<?lua print( math.mod(i*13+1,6) + 1) ?>.mesh">
+ </Model>
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape halfExtents="45,100,45" position = "0,0,0" />
+ </collisionShapes>
+ </StaticEntity>
+
+ <StaticEntity position="<?lua print(y) ?>,-200,<?lua print(z) ?>" scale="<?lua print(j * 2) ?>" collisionType=static >
+ <attached>
+ <Model position="0,0,0" scale=15 mesh="ast<?lua print( math.mod(i*17,6) + 1) ?>.mesh">
+ </Model>
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape halfExtents="45,100,45" position = "0,0,0" />
+ </collisionShapes>
+ </StaticEntity>
+
+<!-- ---------Top Asteroid----------- -->
+ <StaticEntity position="<?lua print(y) ?>,300,<?lua print(z) ?>" scale="<?lua print(j * 2.1) ?>" pitch="90" roll="180" yaw="<?lua print(-90+i*360/max) ?>" collisionType=static >
+ <attached>
+ <Model position="0,0,0" scale=25 mesh="ast6.mesh">
+ </Model>
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape halfExtents="50,140,30" position="0,0,0"/>
+ </collisionShapes>
+ </StaticEntity>
+
+
+<?lua end ?>
+
+ </Scene>
+</Level>
+
+
Copied: code/branches/dockingsystem/data/levels/lastTeamStandingII.oxw (from rev 8193, code/trunk/data/levels/lastTeamStandingII.oxw)
===================================================================
--- code/branches/dockingsystem/data/levels/lastTeamStandingII.oxw (rev 0)
+++ code/branches/dockingsystem/data/levels/lastTeamStandingII.oxw 2011-04-06 10:07:29 UTC (rev 8194)
@@ -0,0 +1,417 @@
+<LevelInfo
+ name = "On the fly"
+ description = "Survive as a team."
+ tags = ""
+/>
+<?lua
+ include("stats.oxo")
+ include("HUDTemplates3.oxo")
+ include("templates/lodInformation.oxt")
+ include("lastTeamStandingHUD.oxo")
+ include("templates/spaceshipAssff.oxt")
+ include("templates/spaceshipPirate.oxt")
+ include("templates/pickupRepresentationTemplates.oxt")
+?>
+
+<Level
+ name = "On the fly"
+ description = "testmap for gametype last team standing"
+ gametype = "LastTeamStanding"
+>
+ <templates>
+ <Template link=lodtemplate_default />
+ </templates>
+
+ <Scene
+ ambientlight = "0.8, 0.8, 0.8"
+ skybox = "Orxonox/skypanoramagen1"
+ >
+<!-- TODO:
+1. make collisionshapes bulletproof: -> attach movable entity with dynamic collisionshape within a static collisionshape
+2. add forcefields -> there should be several "streams" through the level
+3. add teamspawnpoints (different spaceships?) (where should the spawnpoints be placed?)
+-->
+<!--Bot / -->
+
+<!-------------------- Box: TopLayer + BottomLayer + 4 invisible Walls --------------------->
+ <StaticEntity position="0,0,0" direction="0,0,0" collisionType=static mass=100000 >
+ <attached>
+ <Model position="0,-400,0" mesh="cube_orange.mesh" scale3D="1000,10,1000" />
+ <Model position="0,-420,0" mesh="cube_orange.mesh" scale3D="1000,10,1000" /><!-- Second Model in order to avoid graphic errors-->
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape position="0,-400,0" halfExtents="1500,10,1500" />
+ </collisionShapes>
+ </StaticEntity>
+
+ <StaticEntity position="0,0,0" direction="0,0,0" collisionType=static mass=100000 >
+ <attached>
+ <Model position="0,400,0" mesh="cube_orange.mesh" scale3D="1000,10,1000" />
+ <Model position="0,420,0" mesh="cube_orange.mesh" scale3D="1000,10,1000" />
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape position="0,400,0" halfExtents="1000,10,1000" />
+ </collisionShapes>
+ </StaticEntity>
+
+ <StaticEntity position="0,0,0" direction="0,0,0" collisionType=static mass=100000 >
+ <attached>
+ <!--Model position="1000,0,0" mesh="cube_green.mesh" scale3D="10,400,1000" /-->
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape position="1000,0,0" halfExtents="10,400,1000" />
+ </collisionShapes>
+ </StaticEntity>
+
+
+ <StaticEntity position="0,0,0" direction="0,0,0" collisionType=static mass=100000 >
+ <attached>
+ <!-- Model position="-1000,0,0" mesh="cube_green.mesh" scale3D="10,400,1000" / -->
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape position="-1000,0,0" halfExtents="10,400,1000" />
+ </collisionShapes>
+ </StaticEntity>
+
+
+ <StaticEntity position="0,0,0" direction="0,0,0" collisionType=static mass=100000 >
+ <attached>
+ <Model position="0,0,1000" mesh="cube_green.mesh" scale3D="1000,400,10" />
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape position="0,0,1000" halfExtents="1000,400,10" />
+ </collisionShapes>
+ </StaticEntity>
+
+
+ <StaticEntity position="0,0,0" direction="0,0,0" collisionType=static mass=100000 >
+ <attached>
+ <Model position="0,0,-1000" mesh="cube_green.mesh" scale3D="1000,400,10" />
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape position="0,0,-1000" halfExtents="1000,400,10" />
+ </collisionShapes>
+ </StaticEntity>
+<!-- END of CUBE-->
+<!-------------- Centered Thin Gate -------------->
+
+ <StaticEntity position="0,0,0" direction="0,0,0" collisionType=static mass=100000 >
+ <attached>
+ <Model position="0,-1200,0" mesh="hs-w01.mesh" scale3D="300,400,900" pitch="90" roll="0" yaw="0"/>
+ <!--Model position="121,0,-80" mesh="cube.mesh" scale3D="18,400,18" />
+ <Model position="-121,0,-80" mesh="cube.mesh" scale3D="18,400,18" /-->
+ <Model position="0,0,-80" scale=150 mesh="sphere.mesh" />
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape position="121,0,-80" halfExtents="18,400,18" />
+ <BoxCollisionShape position="-121,0,-80" halfExtents="18,400,18" />
+ <SphereCollisionShape position="0,0,-80" radius="150" />
+ </collisionShapes>
+ </StaticEntity>
+
+ <ForceField position="0,270,-80" direction="-3,-4,-3" diameter=150 velocity=2000 length=900 />
+ <MovableEntity position="0,270,-80" direction="-3,-4,-3">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0.7,0.4,0.1" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0.7,0.4,0.1" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+<!-- to bulk gate, left -->
+ <ForceField position="0,-275,-80" direction="3,0,2" diameter=150 velocity=2000 length=900 />
+ <MovableEntity position="0,-275,-80" direction="3,0,2">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0.7,0.4,0.1" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0.7,0.4,0.1" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+
+
+<!-------------- Bulk Gate -------------->
+ <StaticEntity position="300,0,500" direction="0,0,0" collisionType=static mass=100000 >
+ <attached>
+ <Model position="0,-100,0" mesh="hs-w01.mesh" scale3D="500,400,600" pitch="270" roll="0" yaw="0"/>
+ <!--Model position="205,-105,20" mesh="cube.mesh" scale3D="135,280,60" />
+ <Model position="-205,-105,20" mesh="cube.mesh" scale3D="135,280,60" />
+ <Model position="0,235,0" mesh="cube.mesh" scale3D="180,35,35" />
+ <Model position="0,-344,-18" mesh="cube.mesh" scale3D="210,38,36" /-->
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape position="205,-105,20" halfExtents="135,280,60" />
+ <BoxCollisionShape position="-205,-105,20" halfExtents="135,280,60" />
+ <BoxCollisionShape position="0,235,0" halfExtents="180,35,35" />
+ <BoxCollisionShape position="0,-344,-18" halfExtents="210,38,36" />
+ </collisionShapes>
+ </StaticEntity>
+<!-- back to thin gate -->
+ <ForceField position="300,0,650" direction="1,1.5,-4" diameter=150 velocity=2000 length=900 />
+ <MovableEntity position="300,0,650" direction="1,1.5,-4">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0.7,0.4,0.1" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0.7,0.4,0.1" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+<!-- to thin gate -->
+ <ForceField position="300,300,500" direction="-1,0,-2" diameter=100 velocity=1500 length=900 />
+ <MovableEntity position="300,300,500" direction="-1,0,-2">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0.7,0.4,0.1" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0.7,0.4,0.1" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+<!-- alternative stream -->
+ <ForceField position="830,-300,830" direction="-1,0,0" diameter=150 velocity=2000 length=900 />
+ <MovableEntity position="830,-300,830" direction="-1,0,0">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0.5,0,0" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0.5,0,0" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+<!-- alternative stream II-->
+ <ForceField position="830,350,830" direction="0,0,-1" diameter=150 velocity=2000 length=900 />
+ <MovableEntity position="830,350,830" direction="0,0,-1">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0,0,0.5" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0,0,0.5" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+
+
+<!-------------- Bar -------------->
+ <StaticEntity position="-495,0,-495" direction="0,0,0" collisionType=static mass=100000 >
+ <attached>
+ <Model position="0,0,0" mesh="CuboidBody.mesh" scale3D="20,720,20" pitch="90" roll="45" yaw="0"/>
+ <!--Model position="0,0,0" mesh="cube.mesh" scale3D="19,719,19" pitch="90" roll="45" yaw="0"/-->
+ </attached>
+
+ <collisionShapes>
+ <BoxCollisionShape position="0,0,0" halfExtents="20,720,20" pitch="90" roll="45" yaw="0"/>
+ </collisionShapes>
+ </StaticEntity>
+<!-- "lift" -->
+ <ForceField position="-700,-300,-700" direction="0,1,0" diameter=100 velocity=2000 length=400 />
+ <MovableEntity position="-700,-300,-700" direction="0,1,0">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0.7,0.4,0.1" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0.7,0.4,0.1" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+<!-- to thin gate, low -->
+ <ForceField position="0,60,-830" direction="0,-1,2" diameter=150 velocity=2000 length=900 />
+ <MovableEntity position="0,60,-830" direction="0,-1,2">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0.7,0.4,0.1" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0.7,0.4,0.1" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+<!-- alternative stream -->
+ <ForceField position="-830,-350,-830" direction="2,0,0" diameter=100 velocity=2000 length=900 />
+ <MovableEntity position="-830,-350,-830" direction="2,0,0">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0.5,0,0" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0.5,0,0" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+<!-- alternative stream II-->
+ <ForceField position="-870,350,-830" direction="0,0,1" diameter=150 velocity=2000 length=900 />
+ <MovableEntity position="-870,350,-830" direction="0,0,1">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0,0,0.5" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0,0,0.5" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+
+<!-------------- 2 Side-Bars -------------->
+ <StaticEntity position="0,0,-1000" direction="0,0,0" collisionType=static mass=100000 >
+ <attached>
+ <Model position="0,0,0" mesh="CuboidBody.mesh" scale3D="20,405,20" pitch="0" roll="10" yaw="0"/>
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape position="0,0,0" halfExtents="20,400,20" pitch="0" roll="0" yaw="0"/>
+ </collisionShapes>
+ </StaticEntity>
+ <StaticEntity position="-1000,0,0" direction="0,0,0" collisionType=static mass=100000 >
+ <attached>
+ <Model position="0,0,0" mesh="CuboidBody.mesh" scale3D="20,405,20" pitch="7" roll="0" yaw="0"/>
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape position="0,0,0" halfExtents="20,400,20" pitch="0" roll="0" yaw="0"/>
+ </collisionShapes>
+ </StaticEntity>
+<!-- to solar panels -->
+ <ForceField position="-850,-300,-200" direction="1,0,2" diameter=150 velocity=2000 length=900 />
+ <MovableEntity position="-850,-300,-200" direction="1,0,2">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0.7,0.4,0.1" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0.7,0.4,0.1" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+<!-- along the bar -->
+ <ForceField position="-900,50,-100" direction="1,0,-1" diameter=150 velocity=2000 length=900 />
+ <MovableEntity position="-900,50,-100" direction="1,0,-1">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0.7,0.4,0.1" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0.7,0.4,0.1" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+
+<!-------------- 3 Solar Panels --------------->
+
+<?lua
+for i = 1, 3, 1
+do
+ x = i/4*1000
+ z = i/4*500
+?>
+ <StaticEntity position="<?lua print(-1000+x) ?>,-310,<?lua print(z) ?>" direction="0,0,0" collisionType=static mass=100000 >
+ <attached>
+ <Model position="0,0,0" mesh="SolarPanel.mesh" scale3D="60,80,30" pitch="0" roll="0" yaw="120"/>
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape position="0,300,0" halfExtents="155,460,3" pitch="0" roll="0" yaw="120"/>
+ </collisionShapes>
+ </StaticEntity>
+<?lua end ?>
+
+ <ForceField position="-600,100,400" direction="0,-1,-3" diameter=100 velocity=2000 length=900 />
+ <MovableEntity position="-600,100,400" direction="0,-1,-3">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0.7,0.4,0.1" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0.7,0.4,0.1" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+<!-- alternative stream -->
+ <ForceField position="-830,-100,830" direction="0,0,-1" diameter=100 velocity=2000 length=900 />
+ <MovableEntity position="-830,-100,830" direction="0,0,-1">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0.5,0,0" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0.5,0,0" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+<!-- alternative stream II -->
+ <ForceField position="-830,350,830" direction="1,0,0" diameter=100 velocity=2000 length=900 />
+ <MovableEntity position="-830,350,830" direction="1,0,0">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0,0,0.5" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0,0,0.5" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+<!-- along the panels -->
+ <ForceField position="-830,250,250" direction="3,0,2" diameter=100 velocity=2000 length=900 />
+ <MovableEntity position="-830,250,250" direction="3,0,2">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0.7,0.4,0.1" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0.7,0.4,0.1" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+
+<!-------------- Thin Gate -------------->
+
+ <StaticEntity position="500,0,-500" direction="1,0,-1" collisionType=static mass=100000 >
+ <attached>
+ <Model position="0,-1200,0" mesh="hs-w01.mesh" scale3D="300,400,900" pitch="90" roll="0" yaw="0"/>
+ <Model position="0,100,-80" scale=150 mesh="sphere.mesh" />
+ </attached>
+ <collisionShapes>
+ <BoxCollisionShape position="121,0,-80" halfExtents="18,400,18" />
+ <BoxCollisionShape position="-121,0,-80" halfExtents="18,400,18" />
+ <SphereCollisionShape position="0,100,-80" radius="150" />
+ </collisionShapes>
+ </StaticEntity>
+<!-- to thin gate middle -->
+ <ForceField position="550,350,-550" direction="-3.3,0,3" diameter=100 velocity=2000 length=900 />
+ <MovableEntity position="550,350,-550" direction="-3.3,0,3">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0.7,0.4,0.1" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0.7,0.4,0.1" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+<!-- across the field -->
+ <ForceField position="550,-350,-550" direction="-3,0,1" diameter=100 velocity=2000 length=900 />
+ <MovableEntity position="550,-350,-550" direction="-3,0,1">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0.7,0.4,0.1" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0.7,0.4,0.1" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+<!-- alternative stream -->
+ <ForceField position="830,-350,-830" direction="0,0,1" diameter=100 velocity=2000 length=900 />
+ <MovableEntity position="830,-350,-830" direction="0,0,1">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0.5,0,0" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0.5,0,0" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+<!-- alternative stream II -->
+ <ForceField position="830,350,-830" direction="-1,0,0" diameter=100 velocity=2000 length=900 />
+ <MovableEntity position="830,350,-830" direction="-1,0,0">
+ <attached>
+ <Billboard position="0,0,0" material="Flares/ringflare2" colour="0,0,0.5" scale=1/>
+ <?lua for i=0,4,1 do ?>
+ <Billboard position="0,0,<?lua print(i*(-100)) ?>" material="Examples/Flare" colour="0,0,0.5" scale=1/>
+ <?lua end ?>
+ </attached>
+ </MovableEntity>
+
+<!---------------- Spawnpoints ------------------>
+ <TeamSpawnPoint team=0 position="845,350,-835" direction="-1,0,0" spawnclass=SpaceShip pawndesign=spaceshipassff />
+ <TeamSpawnPoint team=0 position="845,-350,-835" direction="0,0,1" spawnclass=SpaceShip pawndesign=spaceshipassff />
+ <TeamSpawnPoint team=0 position="835,350,-845" direction="-1,0,0" spawnclass=SpaceShip pawndesign=spaceshipassff />
+ <TeamSpawnPoint team=0 position="835,-350,-845" direction="0,0,1" spawnclass=SpaceShip pawndesign=spaceshipassff />
+
+ <TeamSpawnPoint team=1 position="-845,350,835" direction="1,0,0" spawnclass=SpaceShip pawndesign=spaceshipassff />
+ <TeamSpawnPoint team=1 position="-845,-100,835" direction="0,0,-1" spawnclass=SpaceShip pawndesign=spaceshipassff />
+ <TeamSpawnPoint team=1 position="-835,350,845" direction="1,0,0" spawnclass=SpaceShip pawndesign=spaceshipassff />
+ <TeamSpawnPoint team=1 position="-835,-100,845" direction="0,0,-1" spawnclass=SpaceShip pawndesign=spaceshipassff />
+
+ <TeamSpawnPoint team=2 position="-870,350,-835" direction="0,0,1" spawnclass=SpaceShip pawndesign=spaceshipassff />
+ <TeamSpawnPoint team=2 position="-840,-350,-835" direction="1,0,0" spawnclass=SpaceShip pawndesign=spaceshipassff />
+ <TeamSpawnPoint team=2 position="-865,350,-840" direction="0,0,1" spawnclass=SpaceShip pawndesign=spaceshipassff />
+ <TeamSpawnPoint team=2 position="-835,-350,-840" direction="1,0,0" spawnclass=SpaceShip pawndesign=spaceshipassff />
+
+ <TeamSpawnPoint team=3 position="835,350,845" direction="0,0,-1" spawnclass=SpaceShip pawndesign=spaceshipassff />
+ <TeamSpawnPoint team=3 position="835,-300,845" direction="-1,0,0" spawnclass=SpaceShip pawndesign=spaceshipassff />
+ <TeamSpawnPoint team=3 position="845,350,835" direction="0,0,-1" spawnclass=SpaceShip pawndesign=spaceshipassff />
+ <TeamSpawnPoint team=3 position="845,-300,835" direction="-1,0,0" spawnclass=SpaceShip pawndesign=spaceshipassff />
+<Bot />
+
+ </Scene>
+</Level>
+
Modified: code/branches/dockingsystem/data/overlays/lastManStandingHUD.oxo
===================================================================
--- code/branches/dockingsystem/data/overlays/lastManStandingHUD.oxo 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/data/overlays/lastManStandingHUD.oxo 2011-04-06 10:07:29 UTC (rev 8194)
@@ -64,7 +64,7 @@
showplayers = true
/>
- <OverlayText
+ <!--OverlayText
position = "0.02, 0.07"
pickpoint = "0.0, 0.0"
font = "ShareTechMono"
@@ -92,7 +92,7 @@
colour = "1.0, 1.0, 1.0, 1.0"
align = "left"
caption = "|"
- />
+ /-->
</OverlayGroup>
</Template>
Copied: code/branches/dockingsystem/data/overlays/lastTeamStandingHUD.oxo (from rev 8193, code/trunk/data/overlays/lastTeamStandingHUD.oxo)
===================================================================
--- code/branches/dockingsystem/data/overlays/lastTeamStandingHUD.oxo (rev 0)
+++ code/branches/dockingsystem/data/overlays/lastTeamStandingHUD.oxo 2011-04-06 10:07:29 UTC (rev 8194)
@@ -0,0 +1,58 @@
+<Template name="lastTeamStandingHUD">
+ <OverlayGroup name="lastTeamStandingHUD" scale = "1, 1">
+
+<GametypeFadingMessage
+ name = "fadingmessage"
+ position = "0.5, 0.01"
+ font = "VeraMono"
+ textsize = 0.04
+ colour = "1.0, 1.0, 0.5, 1.0"
+ align = "center"
+ />
+
+ <OverlayText
+ position = "0.02, 0.02"
+ pickpoint = "0.0, 0.0"
+ font = "ShareTechMono"
+ textsize = 0.04
+ colour = "1.0, 1.0, 1.0, 1.0"
+ align = "left"
+ caption = "Lives: "
+ />
+
+ <LastTeamStandingInfos
+ position = "0.14, 0.02"
+ pickpoint = "0.0, 0.0"
+ font = "ShareTechMono"
+ textsize = 0.04
+ colour = "1.0, 1.0, 1.0, 1.0"
+ align = "left"
+
+ showlives = true
+ showteams = false
+ />
+
+ <OverlayText
+ position = "0.02, 0.055"
+ pickpoint = "0.0, 0.0"
+ font = "ShareTechMono"
+ textsize = 0.04
+ colour = "1.0, 1.0, 1.0, 1.0"
+ align = "left"
+ caption = "Teams: "
+ />
+
+ <LastTeamStandingInfos
+ position = "0.14, 0.055"
+ pickpoint = "0.0, 0.0"
+ font = "ShareTechMono"
+ textsize = 0.04
+ colour = "1.0, 1.0, 1.0, 1.0"
+ align = "left"
+
+ showlives = false
+ showteams = true
+ />
+
+ </OverlayGroup>
+</Template>
Modified: code/branches/dockingsystem/doc/api/Groups.dox
===================================================================
--- code/branches/dockingsystem/doc/api/Groups.dox 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/doc/api/Groups.dox 2011-04-06 10:07:29 UTC (rev 8194)
@@ -118,66 +118,6 @@
/**
@defgroup Notifications Notifications
@ingroup Modules
-
- @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.
-
- @section NotificationsUsage Usage
- 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.
-
- @subsection NotifictionsSending Sending notifications
- Sending a new @ref orxonox::Notification "Notification" from (almost) anywhere in Orxonox is fairly easy.
- You first have to decide on a message, it shouldn't be too long but be long enough to get your point accross.
- 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.
- 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. trough 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.
- Once you have decided all that you can send the Notification by calling:
- @code
- NotificationManager::sendNotification(message, clientId, sender, isLocal); // isLocal = false can be ommitted since that is the default value.
- @endcode
-
- @subsection NotificationsDisplay Displaying notifications
- Displaying @ref orxonox::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:
- @code
- showGUI NotificationLayer false true
- @endcode
- Or automatically, by adding a @ref orxonox::Script "Script" to the levelfile that does it for you:
- @code
- <Script code="showGUI NotificationLayer false true" needsGraphics="true" />
- @endcode
-
- 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:
- @code
- enterEditMode
- @endcode
-
- @section NotificationsTechincalDetails Technical details
- 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.
-
- @subsection NotificationQueue NotificationQueue
- The @ref orxonox::NotificationQueue "NotificationQueue" is the entity, that (as said earlier) logically displays @ref orxonox::Notification "Notifications". Furthermore a @ref orxonox::NotificationQueue "NotificationQueue" displays only a subset of all the @ref orxonox::Notification "Notifications". The parameters that reduce the range of displayed @ref orxonox::Notification "Notifications" are:
- - @b senders The senders, the set of targets of a @ref orxonox::NotificationQueue "NotificationQueue" is the set of senders a @ref orxonox::NotificationQueue "NotificationQueue" displays @ref orxonox::Notification "Notifications" from. E.g. If one would set the senders to "questsystem" then only @ref orxonox::Notification "Notifications" from the Questsystem would be displayed in that particular queue. If you set senders to "all" then all Notifications will be displayed. Different senders can be concatinated with commas.
- - @b size The size specifies how many @ref orxonox::Notification "Notifications" are displayed at the most, if there are more @ref orxonox::Notification "Notifications" that could be displayed, then only the most recent are displayed.
- - @b displayTime The display time specifies how long a @ref orxonox::Notification "Notification" is displayed at the most.
-
- @subsection NotificationLayer NotificationLayer
- 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". For every @ref orxonox::NotificationQueue "NotificationQueue" there is the equivalent representation in the NotificationLayer. So @ref orxonox::NotificationQueue "NotificationQueues" are not each represented by a GUI sheet, but thely all belong to one and the same GUI sheet, the NotificationLayer.
-
- @subsection NotificationManager NotificationManager
- The @ref orxonox::NotificationManager "NotificationManager" is (hence the name) the managing entity in this setting. It is responsible for the registering and unregistering of @ref orxonox::NotificationListener "NotificationListeners" (which the @ref orxonox::NotificationQueue "NotificationQueue" is) and also informs them about changes related to @ref orxonox::Notification "Notifications". It is also responsible for the creation and destruction of @ref orxonox::NotificationQueue "NotificationQueues" through the NotificationLayer and is also the point of approach for the NotificationLayer to get information it needs to display the queues. Finally the @ref orxonox::NotificationManager "NotificationManager" is responsible for sending (and in the process creating) @ref orxonox::Notification "Notifications" and is a means for the @ref orxonox::NotificationQueue "NotificationQueues" to get the information they need about @ref orxonox::Notification "Notifications".
-
- @subsection Notification Notification
- 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.
-
- Additionally there is another important class of objects belonging to the Notifications module. The @ref orxonox::NotificationDispatcher "NotificationDispatchers".
-
- @subsection NotificationDispatcher NotificationDispatcher
- @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.
-
- @defgroup NotificationDispatchers Dispatchers
- @ingroup Notifications
-
- @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.
-
- At this point there are two @ref orxonox::NotificationDispatcher "NotificationDispatchers", the @ref orxonox::SimpleNotification "SimpleNotification", which just displays a specified message, and the @ref orxonox::CommandNotification "CommandNotification" which displays a message with a binding for a specified command in it.
*/
/**
@@ -192,81 +132,6 @@
@defgroup Triggers Triggers
@ingroup Objects
-
- Triggers are objects which react to certain events. They can be combined and used as simple overlay logic in levels.
-
- @defgroup NormalTrigger Trigger
- @ingroup Triggers
-
- @defgroup MultiTrigger MultiTrigger
- @ingroup Triggers
-
- @ref orxonox::MultiTrigger "MultiTriggers" are (as they are @ref orxonox::TriggerBase "Triggers") objects which react to certain events. They offer all the functionality that the common @ref orxonox::Trigger "Triggers" do with one significant difference. The common @ref orxonox::Trigger "Trigger" has just one state, it can either be <em>triggered</em> or <em>not triggered</em>, it doesn't discriminate between who's triggering (or not triggering) it. A @ref orxonox::MultiTrigger "MultiTrigger", on the other hand, has a distinct state (<em>triggered</em> or <em>not triggered</em>) for each entity that is defined as being able to trigger said @ref orxonox::MultiTrigger "MultiTrigger".
-
- This difference becomes significant, when, for example, you want a @ref orxonox::DistanceTrigger "DistanceTrigger" to trigger a @ref orxonox::QuestEffectBeacon "QuestEffectBeacon" to hand out a @ref orxonox::Quest "Quest" to any @ref orxonox::Pawn "Pawn" that enters its range. With a simple @ref orxonox::DistanceTrigger "DistanceTrigger" (as opposed to the more complex @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger") the first @ref orxonox::Pawn "Pawn" to be in range would trigger it an receive the @ref orxonox::Quest "Quest", however if a second @ref orxonox::Pawn "Pawn" would enter the range, while the first @ref orxonox::Pawn "Pawn" still is in the range nothing would happen and even after the first @ref orxonox::Pawn "Pawn" left nothing would happen, since the whole time the @ref orxonox::DistanceTrigger "DistanceTrigger" would just be triggered. In contrast with a @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" the first @ref orxonox::Pawn "Pawn" would enter the range and the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" would have the state <em>triggered</em> for this exact @ref orxonox::Pawn "Pawn" (but for none else) and thus the @ref orxonox::Pawn "Pawn" would receive the @ref orxonox::Quest "Quest" and when the second @ref orxonox::Pawn "Pawn" enters the range the state of the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" for that second @ref orxonox::Pawn "Pawn" would change to <em>triggered</em> and it would receive the @ref orxonox::Quest "Quest" as well.
-
- @section WhenToUseMultiTriggers When to use MultiTriggers
- Consequentially you would use @ref orxonox::MultiTrigger "MultiTriggers" (instead of common @ref orxonox::Trigger "Triggers"), when it is important that the trigger has different states for each triggering entity and when that fact is essential in the concept of the object that reacts to the triggering. However you should not just use @ref orxonox::MultiTrigger "MultiTrigger" instead of @ref orxonox::Trigger "Trigger", when in doubt, because @ref orxonox::MultiTrigger "MultiTrigger" produces significantly more overhead than @ref orxonox::Trigger "Trigger" due to the added complexity.
-
- @section HowToUseMultiTriggers How to use MultiTriggers
- ...
-
- @section MultiTriggerTechnicalDetails Technical Details
- A common @ref orxonox::Trigger "Trigger" is an object that can either be <em>active</em> or <em>inactive</em>, with a specified behavior how to switch between the two. A @ref orxonox::MultiTrigger "MultiTrigger" generalizes that behavior for multiple objects triggering the trigger. A @ref orxonox::MultiTrigger "MultiTrigger" can be <em>active</em> or <em>inactive</em> for any object triggering it, with the state for each object being completely independent of the state for all other objects. Each time a switch occurs an @ref orxonox::Event "Event" is fired, with a @ref orxonox::MultiTriggerContainer "MultiTriggerContainer" as the originator, containing a pointer to the @ref orxonox::MultiTrigger "MultiTrigger" that caused the @ref orxonox::Event "Event" and a pointer to the object that caused the trigger to change it's activity. This way the entity that reacts to the @ref orxonox::MultiTrigger "MultiTrigger" triggering receives the information it needs about the entity that triggered the @ref orxonox::MultiTrigger "MultiTrigger".
-
- Also, just as with all triggers, @ref orxonox::MultiTrigger "MultiTriggers" can be nested (event with triggers other than @ref orxonox::MultiTrigger "MultiTriggers").
- @code
- <MultiTrigger switch="true" delay="2">
- <DistanceMultiTrigger position="100,0,0" distance="80" />
- <EventTrigger ... />
- </Trigger>
- @endcode
-
- @ref orxonox::MultiTrigger "MultiTriggers" also allow for additional complexity which can be added through the choice of the parameters (some of which are also present in the common @ref orxonox::Trigger "Trigger") explained (briefly) below.
- But first it is important to understand a small implementational detail. There is a distinction between the @ref orxonox::MultiTrigger "MultiTrigger" being triggered (there is the state <em>triggered</em> for that) and the @ref orxonox::MultiTrigger "MultiTrigger" being active (for that is the state <em>activity</em>). From the outside only the <em>activity</em> is visible (and has above been referred to as <em>triggered</em> for the sake of comprehensibility). The state <em>triggered</em> tells us whether the trigger is actually triggered, but it could pretend (for some reason, some of which we will see shortly) to be <em>triggered</em> to the outside, while it in fact isn't (but it would then be <em>active</em>). The standard behavior is, that the <em>activity</em> changes, when the @ref orxonox::MultiTrigger "MultiTrigger" transits from being triggered to not being triggered or the other way around. So to the inside a @ref orxonox::MultiTrigger "MultiTrigger" being <em>active</em> is synonymous to the @ref orxonox::MultiTrigger "MultiTrigger" being <em>triggered</em> to the outside.
-
- The parameters of the @ref orxonox::MultiTrigger "MultiTrigger" are:
- - @b delay The delay is the time in seconds, that the trigger waits until it reacts (i.e. changes it's state) to the triggering condition being fulfilled. Internally this is handled by a state queue coupled with a counter, for each state that is delayed. The state becomes <em>active</em> when the counter runs out. This allows the @ref orxonox::MultiTrigger "MultiTrigger" to work even if the delay changes at runtime. However if the delay changes it only affects newly arriving states not the ones already in the queue. The default is <code>0</code>.
- - @b switch Switch is a boolean, if <code>true</code> the @ref orxonox::MultiTrigger "MultiTrigger" is in <em>switch-mode</em>, meaning, that the <em>activity</em> changes only when the trigger is triggered, not when it is un-triggered (Just like a light switch does). This means, that in <em>switch-mode</em> the <em>activity</em> only changes, when the trigger changes from not being triggered to being triggered but not the other way around. The default is <code>false</code>.
- - @b stayActive Stay active is also a boolean, if <code>true</code> the @ref orxonox::MultiTrigger "MultiTrigger" stays active after it has been activated as many times as specified by the parameter <em>activations</em>. In essence this means, that after the last time it is activated it cannot be deactivated. The default is <code>false</code>.
- - @b activations Activations is the number of times the @ref orxonox::MultiTrigger "MultiTrigger" can be activated until the trigger can't be triggered anymore. The default is <code>-1</code>, which denotes infinity.
- - @b invert Invert is a boolean, if <code>true</code> the @ref orxonox::MultiTrigger "MultiTrigger" is in <em>invert-mode</em>, meaning, that if the triggering condition is fulfilled the @ref orxonox::MultiTrigger "MultiTrigger" will have the state <em>not triggered</em> and and if the condition is not fulfilled it will have the state <em>triggered</em>. In short it inverts the behavior of the @ref orxonox::MultiTrigger "MultiTrigger". The default is <code>false</code>.
- - @b simultaneousTriggerers The number of simultaneous triggerers limits the number of objects that are allowed to trigger the @ref orxonox::MultiTrigger "MultiTrigger" at the same time. Or more precisely, the number of distinct objects the @ref orxonox::MultiTrigger "MultiTrigger" has positive <em>triggered</em> states for, at each point in time. The default is <code>-1</code>, which denotes infinity.
- - @b mode The mode describes how the @ref orxonox::MultiTrigger "MultiTrigger" acts in relation to all the triggers (its children), that are appended to it. There are 3 modes: <em>and</em>, meaning that the @ref orxonox::MultiTrigger "MultiTrigger" can only be triggered if all the appended triggers are active. <em>or</em>, meaning that the @ref orxonox::MultiTrigger "MultiTrigger" can only be triggered if at least one of the appended triggers is active. And <em>xor</em>, meaning that the @ref orxonox::MultiTrigger "MultiTrigger" can only be triggered if one and only one appended trigger is active. Note, that I wrote 'can only be active', that implies, that there is an additional condition to the <em>activity</em> of the @ref orxonox::MultiTrigger "MultiTrigger" and that is the fulfillment of the triggering condition (the @ref orxonox::MultiTrigger "MultiTrigger" class itself doesn't have one, but all derived classes should). Also bear in mind, that the <em>activity</em> of a @ref orxonox::MultiTrigger "MultiTrigger" is still coupled to the object that triggered it. The default is <em>and</em>.
- - @b broadcast Broadcast is a boolean, if <code>true</code> the @ref orxonox::MultiTrigger "MultiTrigger" is in <em>broadcast-mode</em>, meaning, that all trigger events that are caused by no originator (originator is <code>NULL</code>) are broadcast as having come from every possible originator, or more precisely as having come from all objects that are specified targets of this @ref orxonox::MultiTrigger "MultiTrigger". The default is <code>false</code>.
- - @b target The target describes the kind of objects that are allowed to trigger this @ref orxonox::MultiTrigger "MultiTrigger". The parameter has to be set to the class name of the class that is allowed to trigger the @ref orxonox::MultiTrigger "MultiTrigger". The default is <code>Pawn</code>.
-
- @subsection Sub-typesOfMultiTriggers Sub-types of MultiTriggers
-
- @subsubsection EventMultiTrigger EventMultiTrigger
- An @ref orxonox::EventMultiTrigger "EventMultiTrigger" can either be used to broadcast an @ref orxonox::Event "Event" that does not come from a @ref orxonox::MultiTrigger "MultiTrigger" to all entities that are targets of the @ref orxonox::EventMultiTrigger "EventMultiTrigger" or, more in line with its prototype the @ref orxonox::EventTrigger "EventTrigger", to be triggered for an entity when an @ref orxonox::Event "Event" that was caused by an entity of the same type is captured.
-
- A common usage could look like this:
- @code
- <EventMultiTrigger invert="true" delay="1">
- <events>
- <trigger>
- <MultiTrigger ... />
- <Trigger ... />
- </trigger>
- </events>
- </EventMultiTrigger>
- @endcode
-
- @subsubsection DistanceMultiTrigger DistanceMultiTrigger
- A @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" is the MultiTrigger equivalent of the @ref orxonox::DistanceTrigger "DistanceTrigger" and works just the same way. It triggers (now separately for each object triggering it, since it's a @ref orxonox::MultiTrigger "MultiTrigger") whenever an object that is a target of the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" is in the specified range.
-
- Two additional parameters can be specified for the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" are the <em>distance</em>, which defines the maximum distance at which an object still triggers the @ref orxonox:: "DistanceMultiTrigger", and the <em>targetname</em>. Setting the <em>targename</em> puts the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" in <em>single-target mode</em>. In this mode the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" can only be triggered by objects that have a @ref orxonox::DistanceTriggerBeacon "DistanceTriggerBeacon" with the name specified by <em>targetname</em> directly attached. For the <em>single-target mode</em> to work the target of the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" has to be set to <code>DistanceTriggerBeacon</code>.
-
- A common usage (without @ref orxonox::DistanceTriggerBeacon "DistanceTriggerBeacon") would look like this:
- @code
- <DistanceMultiTrigger position="0,0,0" switch="true" target="Pawn" distance="20" />
- @endcode
-
- With @ref orxonox::DistanceTriggerBeacon "DistanceTriggerBeacon" it would look like this:
- @code
- <DistanceMultiTrigger position="0,0,0" target="DistanceMultiTrigger" targetname="beacon1" distance="30" />
- @endcode
*/
/**
@@ -277,425 +142,21 @@
/**
@defgroup Pickup Pickup
@ingroup Modules
-
- The Pickup module adds a special type of object to Orxonox, the so-called @ref orxonox::Pickupable "Pickupables". @ref orxonox::Pickupable "Pickupables" are objects that can be picked up (by virtually any entity, but commonly by the @ref orxonox::Pawn "Pawn") and have some kind of effect on the entity that picked the @ref orxonox::Pickupable "Pickupable" up.
-
- @section IncludingPickups Including pickups in a level
- @ref orxonox::Pickupable "Pickupables" are designed so that they can be included in levels fairly easily, while also ensuring, that the pickup itself (its game-logic component) and how it is represented (e.g. in the PickupInventory (the GUI that displays @ref orxonox::Pickupable "Pickupables") or in the game) are neatly seperated.
- To be able to use @ref orxonox::Pickupable "Pickupables" in a level one must understand some basic concepts.
- - @ref orxonox::Pickupable "Pickupables" are entities which (by itself) have no physical (or graphical) dimension. The simply represent the effect they will have on a @ref orxonox::PickupCarrier "PickupCarrier" (the entity that can pick up @ref orxonox::Pickupable "Pickupables", @ref orxonox::Pawn "Pawn" for example inherits from @ref orxonox::PickupSpawner "PickupSpawner" and thus is able to pick up and carry @ref orxonox::Pickupable "Pickupables"), when used and the mechanism that leads to that.
- - The physical (or graphical) dimension of a pickup is called a @ref orxonox::PickupRepresentation "PickupRepresentation".
- - The @ref orxonox::PickupRepresentation "PickupRepresentation" of a @ref orxonox::Pickupable "Pickupable" and the @ref orxonox::Pickupable "Pickupable" itself are linked to each other, in such a way that a @ref orxonox::PickupRepresentation "PickupRepresentation" can only represent one type of @ref orxonox::Pickupable "Pickupable".
- - A type of @ref orxonox::Pickupable "Pickupable" is a specific pickup class (inheriting from @ref orxonox::Pickupable "Pickupable") with specific values for all its relevant parameters. This means, that a pickup of the same class with the same values for all parameters except for one is a different type of pickup and will therefore have a different @ref orxonox::PickupRepresentation "PickupRepresentation". Which parameters are the ones relevant to destinguish between two types of pickups can be defined in the class description of the specific pickup.
- - The entity that actually gives a @ref orxonox::Pickupable "Pickupable" to a @ref orxonox::PickupCarrier "PickupCarrier" is called a @ref orxonox::PickupSpawner "PickupSpawner". A @ref orxonox::PickupSpawner "PickupSpawner" creates (based on some parameters) @ref orxonox::Pickupable "Pickupables" which then is picked up by the @ref orxonox::PickupCarrier "PickupCarrier", that caused the @ref orxonox::PickupSpawner "PickupSpawner" to spawn a new pickup. How the spawner looks in the game is defined by the @ref orxonox::PickupRepresentation "PickupRepresentation" of the @ref orxonox::Pickupable "Pickupable" it spawns.
-
- @subsection UsingPredifinedPickups Using predefined pickups
- There is a file called <code>pickupRepresentationTemplates.oxt</code> in <code>levels/templates</code>, which holds the templates for the @ref orxonox::PickupRepresentation "PickupRepresentations" and also templates for @ref orxonox::Pickupable "Pickupables". The templates for the @ref orxonox::PickupRepresentation "PickupRepresentations" define the @ref orxonox::StaticEntity "StaticEntities" that are attached to the @ref orxonox::PickupSpawner "PickupSpawners" to make them look like the @ref orxonox::Pickupable "Pickupable" they are spawning. The templates for the @ref orxonox::Pickupable "Pickupables" can be added just for ease of use.
- If you want to use pickups you will have to include this file in your level file, somewhere above the Level-tag.
- @code
- <?lua
- include("templates/pickupRepresentationTemplates.oxt")
- ?>
- ...
- <Level>
- ...
- @endcode
- There is another file called <code>pickups.oxi</code> in <code>level/includes</code> which creates all @ref orxonox::PickupRepresentation "PickupRepresentations" needed for the @ref orxonox::Pickupable "Pickupable" supplied by the <code>pickupRepresentationTemplates.oxt</code> file. This file will have to be included as well. It has to be somewhere after the opening Scene-tag and your first use of a pickup.
- @code
- <Scene>
- ...
- <?lua
- include("includes/pickups.oxi")
- ?>
- @endcode
- After that all the predefined pickups specified in those two files can be used just by creating a @ref orxonox::PickupSpawner "PickupSpawner" for them in the respective level.
- For example:
- @code
- <PickupSpawner position="-100,0,-100" respawnTime="30" maxSpawnedItems="10">
- <pickup>
- <HealthPickup
- health = 10
- healthType = "limited"
- activationType = "immediate"
- durationType = "once"
- />
- </pickup>
- </PickupSpawner>
- @endcode
- Please be aware, that the @ref orxonox::Pickupable "Pickupable" specified for the @ref orxonox::PickupSpawner "PickupSpawner", has to be exactly the same (including all parameters) to the one specified in the <code>pickups.oxi</code> file.
- To make things simpler, one could just use the templates specified in the <code>pickupRepresentationTemplates.oxt</code> file. Which, following the previous example, would look like this:
- @code
- <PickupSpawner position="-100,0,-100" respawnTime="30" maxSpawnedItems="10">
- <pickup>
- <HealthPickup template="smallhealthpickup" />
- </pickup>
- </PickupSpawner>
- @endcode
-
- @subsection UnsingNon-PredefinedPickups Using non-predefined pickups
- To include a type of pickup (which, as we remember, is the class of the @ref orxonox::Pickupable "Pickupable" with specific values for all the relevant parameters) in a level file, you can just create a new @ref orxonox::PickupSpawner "PickupSpawner" and specify the @ref orxonox::Pickupable "Pickupable".
- @code
- <PickupSpawner position="-100,0,-100" respawnTime="30" maxSpawnedItems="10">
- <pickup>
- <HealthPickup
- health = 33
- healthType = "limited"
- activationType = "immediate"
- durationType = "once"
- />
- </pickup>
- </PickupSpawner>
- @endcode
- As can be seen in the <code>pickupRepresentationTemplates.oxt</code> file and the <code>pickups.oxi</code> file there is no @ref orxonox::PickupRepresentation "PickupRepresentation" defined for this type of pickup. Thus the default representation will be used.
-
- To create an appropriate @ref orxonox::PickupRepresentation "PickupRepresentation" for the inserted pickup above, you can just create a @ref orxonox::PickupRepresentation "PickupRepresentation" within the scene (Within the Scene-tags).
- @code
- <PickupRepresentation
- name = "My new health pickup"
- description = "This is an awesome new health pickup."
- spawnerTemplate = "mediumhealthpickupRepresentation"
- inventoryRepresentation = "MediumHealth"
- >
- <pickup>
- <HealthPickup
- health = 33
- healthType = "limited"
- activationType = "immediate"
- durationType = "once"
- />
- </pickup>
- </PickupRepresentation>
- @endcode
- Notice, that the type of pickup specified for the @ref orxonox::PickupRepresentation "PickupRepresentation", naturally, needs to be the same (this is the way they can be connected). Also, we just used an existing <em>spawnerTemplate</em>, to make things simpler.
-
- The next step is to create a <em>spawnerRepresentation</em> uniquely for our new type of pickup. Lets call it <code>newhealthpickupRepresentation</code>. Thus the parameter <em>spawnerTemplate</em> of the @ref orxonox::PickupRepresentation "PickupRepresentation" has to be changed to that value.
- @code
- spawnerTemplate = "newhealthpickupRepresentation"
- @endcode
- The <em>spawnerTemplate</em> defines how the @ref orxonox::PickupSpawner "PickupSpawner" is displayed in a level.
- In our example case it could look like this:
- @code
- <Template name=newhealthpickupRepresentation>
- <PickupRepresentation>
- <spawner-representation>
- <StaticEntity>
- <attached>
- -- Here you can put all the objects which define the look of the spawner. --
- </attached>
- </StaticEntity>
- </spawner-representation>
- </PickupRepresentation>
- </Template>
- @endcode
- Please refer to the <code>pickupRepresentationTemplates.oxt</code> for more examples.
-
- The @ref orxonox::PickupRepresentation "PickupRepresentation" also needs another parameter the <em>inventoryRepresentation</em>. This parameter defined how the @ref orxonox::Pickupable "Pickupable" is displayed in the PickupInventory (a menu to browse the currently equipped pickups).
- @code
- inventoryRepresentation = "MediumHealth"
- @endcode
- This is the name of an image defined in the PickupInventory imageset (<code>PickupInventory.imageset</code>), which can be found in <code>data_extern/gui/imagesets</code>.
-
- This is all that has to be done. Now you have a new pickup type with an appropriate @ref orxonox::PickupRepresentation "PickupRepresentation" for your use. If you feel that your pickup is useful in general, please don't hesitate to create a template for the pickup and add your pickup to the <code>pickupRepresentationTemplates.oxt</code> file and the <code>pickups.oxi</code> file, so that anyone who wants to use it can do so quite easily.
-
- There is also an additional way to create new types of pickups to be used in a level (without having to do any coding). There is a @ref orxonox::Pickupable "Pickupable" called the @ref orxonox::PickupCollection "PickupCollection", which is just a collection (hence the name) of @ref orxonox::Pickupable "Pickupables" (more precisely of @ref orxonox::CollectiblePickup "CollectiblePickups"), behaving as if it was just one @ref orxonox::Pickupable "Pickupable".
- A @ref orxonox::PickupCollection "PickupCollection" can be created as follows:
- @code
- <PickupCollection>
- <pickupables>
- -- some pickups you want to have in your collection, e.g. --
- <HealthPickup template=smallhealthpickup />
- <HealthPickup health=50 healthRate=5 durationType=continuous activationType=immediate healthType=limited />
- </pickupables>
- </PickupCollection>
- @endcode
- Of which types of pickups a collection is made up is entirely up to the one creating the @ref orxonox::PickupCollection "PickupCollection", they can be mixed freely.
-
- @section CreatingAPickup Creating a new pickup
- Things have been fairly straightforward so far. Creating a @ref orxonox::Pickupable "Pickupable" form scratch isn't as easy. Therefore I'm just going to supply you with a recipe, or a set of steps you have to take, without which your pickup won't work and point out some common pitfalls.
-
- @subsection CreatingAPickupClass Creating the class
- For a new @ref orxonox::Pickupable "Pickupable" you need to create a new class in <code>>modules/pickup/items</code>. Your class needs to be derived from another pickup class, normally this would either be @ref orxonox::Pickupable "Pickupable", @ref orxonox::CollectiblePickup "CollectiblePickup" or @ref orxonox::Pickup "Pickup". @ref orxonox::Pickupable "Pickupable" is (as mentioned earlier) the base class of all things that can be picked up, thus of all pickups. @ref orxonox::CollectiblePickup "CollectiblePickup" is a (directly) derived class of @ref orxonox::Pickupable "Pickupable" and provides the additional functionality of enabling your pickup to be used in a @ref orxonox::PickupCollection "PickupCollection". However you are probably going to want to derive your class form @ref orxonox::Pickup "Pickup", because it is a @ref orxonox::CollectiblePickup "CollectiblePickup" and provides some useful methods. So have a look at @ref orxonox::Pickup "Pickup".
- Once you have created your new pickup class you have to insert it in the <code>PickupPrereqs.h</code> file in the <code>modules/pickup</code> folder and in the <code>CMakeList.txt</code> file in the <code>modules/pickup/items</code> folder. Also have a look at other pickups to make sure you include all the necessary files in your class.
-
- @subsection ChoosingTheCarriers Coosing the carriers
- You also have to choose the entities that are allowed to pick your pickup up. After you have chosen the entity that carries your pickup, you need to do the following.
- - The enity that carries your pickup needs to be derived from the @ref orxonox::PickupCarrier "PickupCarrier" interface. And you need to implement the @ref orxonox::PickupCarrier "PickupCarriers'" virtual functions <code>getCarrierChildren()</code> and <code>getCarrierParent()</code>. These tow methods are needed, because all pickups are initially picked up by a @ref orxonox::Pawn "Pawn" and then handed down to the entity that effectively carries them. With the above mentioned two function just that is accomplished. A hierarchical structure is established with one parent and a set of children, where the @ref orxonox::Pawn "Pawn" is the root node of this hierarchical structure, the only entity with no parent.
- - Once you have done that you will also want to specify in your pickup which carriers can pick it up, this is done via the <code>addTarget()</code> function. So you have to make sure the target is added whenever one of your pickups is created (so, most conveniently somewhere in the constructor), with the following command.
- @code
- this->addTarget(ClassIdentifier<MyCarrierClass>::getIdentifier());
- @endcode
-
- @subsection CreatingTheInnerWorkings Creating the inner workings of your pickup
- Now that we have the skeleton of a pickup and we have defined which carriers are allowed to pick our pickup up we are going to take a look at all the methods we can (or sometimes have to) overload from @ref orxonox::Pickupable "Pickupable", for our pickup to work properly. But first I will introduce some more concepts to make the need for these methods more obvious.
- - Since one pickup class can by itself be many pickup types, we need a way to find out whether a particular instance of a pickup is of the same type as another instance of a pickup. To that end the @ref orxonox::PickupIdentifier "PickupIdentifier" was created. The @ref orxonox::PickupIdentifier "PickupIdentifier" accounts for the type of class your pickup is of and also for the parameters (and their values) that distinguish different types of pickups of the same class. Much of the functionality of the pickup module relies on this identifier being correct, thus it is very important to initialize it correctly. (We will see, how that is done in a short while.)
- - Every @ref orxonox::Pickupable "Pickupable" has at least two states which are very important. The first is, whether the @ref orxonox::Pickupable "Pickupable" is currently in use or not and the second is whether the pickup is currently picked up or not.
-
- Let's have a look at the important methods.
- - <b>changedUsed()</b> The <code>changedUsed()</code> method is called whenever the state of the @ref orxonox::Pickupable "Pickupable" transits from being used to not being used or the other way around. Which means this method is probably the most important method you have at your fingertips, since it enables you to apply the effect of your pickup when it gets used and remove the effect as soon as it is no longer in use.
- - <b>changedPickedUp()</b> The <code>changedPickedUp()</code> method is called whenever the state of the @ref orxonox::Pickupable "Pickupable" changes from being picked up to not being picked up or the other way around. For example if you want your pickup to be used as soon as it is picked up, this is the method you have to overload to achieve that behavior (or just let your pickup be derived from @ref orxonox::Pickup "Pickup", which implements exactly that behavior, if the <em>activationType</em> is set to <em>immediate</em>). You don't have to concern yourself with destroying the pickup or creating a spawner when it changes to not picked up, since that is already implemented with the @ref orxonox::Pickupable "Pickupable" and @ref orxonox::PickupCarrier "PickupCarrier" classes. If you want a different behavior, however, once again, this is the method.
- - <b>changedCarrier()</b> The <code>changedCarrier()</code> method is called whenever the carrier of the @ref orxonox::Pickupable "Pickupable" changes. And by that I don't mean the class that is allowed to carry the pickup, but the object that actually carries (or carried) the pickup. Please do not overload this class to implement behavior for picked up -> not picked up transitions, use <code>changedPickedUp()</code> for that. For most pickup classes this method doesn't need to be overloaded. Where it is used, however is in the @ref orxonox::PickupCollection "PickupCollection" class, where the new carrier needed to be communicated to all pickups the collection consists of, whenever the carrier was changed.
-
- Please be aware, that these three methods are methods registered with @ref Super.h "Super", meaning, that whenever overloading them, don't forget to call <code>SUPER(MyClass, myMethod);</code>.
- Also when implementing the above methods you should think of what should happen in unexpected situations, e.g. when your pickup is unused manually and set to used again.
- Additionally you should use the <code>destroy()</code> method of Pickupable instead of the method provided by @ref orxonox::OrxonoxClass "OrxonoxClass", meaning <code>Pickupable::destroy()</code> instead of plain <code>destroy()</code>.
-
- - <b>clone()</b> The <code>clone()</code> method creates a new pickup of the same type as the pickup it is cloned from. So the cloned pickup is not exactly the same, as it doesn't necessarily completely reflect the status of the pickup it is cloned from, but it reflects all the parameters and their values, that distinguish different types of this pickup class. It needs to be implemented by every pickup class. And it is best if this is done in a very specific way. Below is shown how:
- @code
- void MyPickup::clone(OrxonoxClass*& item)
- {
- if(item == NULL)
- item = new MyPickup(this);
-
- SUPER(MyPickup, clone, item);
-
- MyPickup* pickup = dynamic_cast<MyPickup*>(item);
- // Here you should set all the important parameters (that distinguish the different types of this pickup), e.g.
- pickup->setSomeParameter(this->getSomeParameter());
- // You must also initialize the identifier of the new pickup, this is normally done in a member function called in
- pickup->initializeIdentifier();
- }
- @endcode
- - <b>initializeIdentifier()</b> The <code>initializeIdentifier()</code> method initializes (or more simply put, creates) the @ref orxonox::PickupIdentifier "PickupIdentifier" of the instance of your pickup. Since the important values of the parameters are not yet available in the constructor of your pickup this <code>initializeIdentifier()</code> method must be called as soon as they are available, which normally is in the <code>XMLPort()</code> method, and the <code>clone()</code> method, as seen above. In the <code>initializeIdentifier()</code> method you need to register each parameter that is important for the type of your pickup to its identifier, this is normally done as follows:
- @code
- void Pickup::initializeIdentifier(void)
- {
- // If the get method returns a string.
- std::string val1 = this->getSomeParameter();
- std::string type1 = "someParameter";
- this->pickupIdentifier_->addParameter(type1, val1);
- // If the get method doesn't return a string
- std::stringstream stream;
- stream << this->getSomeOtherParameter();
- std::string type2 = "someOtherParameter";
- std::string val2 = stream.str();
- this->pickupIdentifier_->addParameter(type2, val2);
- }
- @endcode
-
- Be aware, this only works for parameters that are simple enough, meaning with pointers for example it will, naturally, not work, and other ways must be found (this is for example done in @ref orxonox::PickupCollection "PickupCollection" with a derived class of the @ref orxonox::PickupIdentifier "PickupIdentifier", the @ref orxonox::PickupCollectionIdentifier "PickupCollectionIdentifier") or in the @ref orxonox::DronePickup "DronePickup" class by using a @ref orxonox::Template "Template".
- - <b>createSpawner()</b> The <code>createSpawner()</code> method needs to be implemented by any pickup directly inheriting from @ref orxonox::Pickupable "Pickupable" (or directly from @ref orxonox::CollectiblePickup "CollectiblePickup"), so if you inherit from @ref orxonox::Pickup "Pickup", you don't need to implement this. It is used to create a @ref orxonox::PickupSpawner "PickupSpawner", when the pickup is dropped. A standard implementation would look like this.
- @code
- bool MyPickup::createSpawner(void)
- {
- new DroppedPickup(this, this, this->getCarrier());
- return true;
- }
- @endcode
-
- @section PickupTechnicalDetails Technical details
-
- @image html pickupmodule.png
-
- @defgroup PickupItems Items
- @ingroup Pickup
-
- The actual pickups can be found here.
*/
/**
@defgroup Pong Pong
@ingroup Modules
+
+ Pong is a minigame.
*/
/**
@defgroup Questsystem Questsystem
@ingroup Modules
-
- 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.
-
- @section QuestsystemTechnicalDetails Technical details
- 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).
- @image html questsystem.png
-
- @section CreatingQuests Creating Quests
-
- @subsection CreatingTheQuestHierarchy Creating the Quest-Hierarchy
- 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.
-
- @subsubsection LocalQuest LocalQuest
- 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.
-
- Creating a @ref orxonox::LocalQuest "LocalQuest" in XML goes as follows:
- @code
- <LocalQuest id="questId">
- <QuestDescription title="Title" description="Description." /> //The description of the quest.
- <subquests>
- <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.
- ...
- <Quest id="questIdn" />
- </subquests>
- <hints>
- <QuestHint id="hintId1" /> //A list of n QuestHints, see QuestHint for the full XML representation of those.
- ...
- <QuestHint id="hintIdn" />
- </hints>
- <fail-effects>
- <QuestEffect /> //A list of QuestEffects, invoked when the Quest is failed, see QuestEffect for the full XML representation.
- ...
- <QuestEffect />
- </fail-effects>
- <complete-effects>
- <QuestEffect /> //A list of QuestEffects, invoked when the Quest is completed, see QuestEffect for the full XML representation.
- ...
- <QuestEffect />
- </complete-effects>
- </LocalQuest>
- @endcode
-
- @subsubsection GlobalQuest GlobalQuest
- @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.
-
- Creating a @ref orxonox::GlobalQuest "GlobalQuest" in XML goes as follows:
- @code
- <GlobalQuest id="questId">
- <QuestDescription title="Title" description="Description." /> //The description of the quest.
- <subquests>
- <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.
- ...
- <Quest id="questIdn" />
- </subquests>
- <hints>
- <QuestHint id="hintId1" /> //A list of n QuestHints, see QuestHint for the full XML representation of those.
- ...
- <QuestHint id="hintIdn" />
- </hints>
- <fail-effects>
- <QuestEffect /> //A list of QuestEffects, invoked on all players possessing this quest, when the Quest is failed, see QuestEffect for the full XML representation.
- ...
- <QuestEffect />
- </fail-effects>
- <complete-effects>
- <QuestEffect /> //A list of QuestEffects, invoked on all players possessing this quest, when the Quest is completed, see QuestEffect for the full XML representation.
- ...
- <QuestEffect />
- </complete-effects>
- <reward-effects>
- <QuestEffect /> //A list of QuestEffects, invoked on the player completing this quest. See QuestEffect for the full XML representation.
- ...
- <QuestEffect />
- </reward-effects>
- </GlobalQuest>
- @endcode
-
- 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.
-
- @subsubsection QuestHint QuestHint
- @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".
-
- Creating a @ref orxonox::QuestHint "QuestHint" in XML goes as follows:
- @code
- <QuestHint id="hintId">
- <QuestDesctription title="" description="" />
- </QuestHint>
- @endcode
-
- @subsubsection QuestDescription QuestDescription
- 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.
-
- Creating a @ref orxonox::QuestDescription "QuestDescription" in XML goes as follows:
- @code
- <QuestDescription title="Title" description="Description Text" failMessage="You fail." completeMessage="You win!" />
- @endcode
-
- @subsection CreatingSideEffects Creating side effects
- @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).
-
- @subsubsection QuestEffect QuestEffect
- 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.
-
- 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.
-
- @paragraph AddQuest AddQuest
- This @ref orxonox::QuestEffect "QuestEffect" adds (respectively starts) a @ref orxonox::Quest "Quest" (identified by the given questId) to the player.
- @code
- <AddQuest questId="id" /> //Where id identifies the Quest that should be added.
- @endcode
-
- @paragraph FailQuest FailQuest
- This @ref orxonox::QuestEffect "QuestEffect" fails a @ref orxonox::Quest "Quest" (identified by the given questId) for the player.
- @code
- <FailQuest questId="id" /> //Where id identifies the Quest that should be added.
- @endcode
-
- @paragraph CompleteQuest CompleteQuest
- This @ref orxonox::QuestEffect "QuestEffect" completes a @ref orxonox::Quest "Quest" (identified by the given questId) for the player.
- @code
- <CompleteQuest questId="id" /> //Where id identifies the Quest that should be added.
- @endcode
-
- @paragraph AddQuestHint AddQuestHint
- 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.
- @code
- <AddQuestHint hintId="id" /> //Where id identifies the QuestHint that should be added.
- @endcode
-
- @paragraph AddReward AddReward
- 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".
- @code
- <AddReward>
- <Rewardable /> //A list of Rewardable objects to be rewarded the player, see the specific Rewardables for their respective XML representations.
- ...
- <Rewardable />
- </AddReward>
- @endcode
-
- @subsubsection QuestListener QuestListener
- 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.
-
- Here is an example of the usage of @ref orxonox::QuestListener "QuestListeners" in XML:
- @code
- <BaseObject> // The object that should react to the status change of a Quest.
- <events>
- <function> // Where function is the method of the object that schould be executed. Normally this would be visibility or activity.
- <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).
- </function>
- </events>
- </BaseObject>
- @endcode
-
- 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.
-
- @subsection PuttingTheQuestsInTheGameWorld Putting the Quests in the game world
- 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".
-
- @subsubsection QuestEffectBeacon QuestEffectBeacon
- 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".
-
- Creating a @ref orxonox::QuestEffectBeacon "QuestEffectBeacon" in XML goes as follows:
- @code
- <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.
- <effects>
- <QuestEffect /> //A list of QuestEffects, invoked when the QuestEffectBeacon is executed, see QuestEffect for the full XML representation.
- ...
- <QuestEffect />
- </effects>
- <events>
- <execute>
- <EventListener event=eventIdString />
- </execute>
- </events>
- <attached>
- <PlayerTrigger name=eventIdString /> //A PlayerTrigger triggering the execution of the QuestEffectBeacon.
- </attached>
- </QuestEffectBeacon>
- @endcode
-
- 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".
-
- 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.
-
- @section SampleQuest Sample quest
- 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.
*/
/**
- @defgroup QuestEffects Effects
- @ingroup Questsystem
-
- 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.
-*/
-
-/**
@defgroup Weapons Weapons
@ingroup Modules
*/
Deleted: code/branches/dockingsystem/doc/api/groups/Notifications.dox
===================================================================
--- code/trunk/doc/api/groups/Notifications.dox 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/doc/api/groups/Notifications.dox 2011-04-06 10:07:29 UTC (rev 8194)
@@ -1,64 +0,0 @@
-/**
- @addtogroup Notifications Notifications
- @ingroup Modules
-
- @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.
-
- @section NotificationsUsage Usage
- 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.
-
- @subsection NotifictionsSending Sending notifications
- Sending a new @ref orxonox::Notification "Notification" from (almost) anywhere in Orxonox is fairly easy.
- You first have to decide on a message, it shouldn't be too long but be long enough to get your point accross.
- 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.
- 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. trough 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.
- Once you have decided all that you can send the Notification by calling:
- @code
- NotificationManager::sendNotification(message, clientId, sender, isLocal); // isLocal = false can be ommitted since that is the default value.
- @endcode
-
- @subsection NotificationsDisplay Displaying notifications
- Displaying @ref orxonox::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:
- @code
- showGUI NotificationLayer false true
- @endcode
- Or automatically, by adding a @ref orxonox::Script "Script" to the levelfile that does it for you:
- @code
- <Script code="showGUI NotificationLayer false true" needsGraphics="true" />
- @endcode
-
- 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:
- @code
- enterEditMode
- @endcode
-
- @section NotificationsTechincalDetails Technical details
- 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.
-
- @subsection NotificationQueue NotificationQueue
- The @ref orxonox::NotificationQueue "NotificationQueue" is the entity, that (as said earlier) logically displays @ref orxonox::Notification "Notifications". Furthermore a @ref orxonox::NotificationQueue "NotificationQueue" displays only a subset of all the @ref orxonox::Notification "Notifications". The parameters that reduce the range of displayed @ref orxonox::Notification "Notifications" are:
- - @b senders The senders, the set of targets of a @ref orxonox::NotificationQueue "NotificationQueue" is the set of senders a @ref orxonox::NotificationQueue "NotificationQueue" displays @ref orxonox::Notification "Notifications" from. E.g. If one would set the senders to "questsystem" then only @ref orxonox::Notification "Notifications" from the Questsystem would be displayed in that particular queue. If you set senders to "all" then all Notifications will be displayed. Different senders can be concatinated with commas.
- - @b size The size specifies how many @ref orxonox::Notification "Notifications" are displayed at the most, if there are more @ref orxonox::Notification "Notifications" that could be displayed, then only the most recent are displayed.
- - @b displayTime The display time specifies how long a @ref orxonox::Notification "Notification" is displayed at the most.
-
- @subsection NotificationLayer NotificationLayer
- 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". For every @ref orxonox::NotificationQueue "NotificationQueue" there is the equivalent representation in the NotificationLayer. So @ref orxonox::NotificationQueue "NotificationQueues" are not each represented by a GUI sheet, but thely all belong to one and the same GUI sheet, the NotificationLayer.
-
- @subsection NotificationManager NotificationManager
- The @ref orxonox::NotificationManager "NotificationManager" is (hence the name) the managing entity in this setting. It is responsible for the registering and unregistering of @ref orxonox::NotificationListener "NotificationListeners" (which the @ref orxonox::NotificationQueue "NotificationQueue" is) and also informs them about changes related to @ref orxonox::Notification "Notifications". It is also responsible for the creation and destruction of @ref orxonox::NotificationQueue "NotificationQueues" through the NotificationLayer and is also the point of approach for the NotificationLayer to get information it needs to display the queues. Finally the @ref orxonox::NotificationManager "NotificationManager" is responsible for sending (and in the process creating) @ref orxonox::Notification "Notifications" and is a means for the @ref orxonox::NotificationQueue "NotificationQueues" to get the information they need about @ref orxonox::Notification "Notifications".
-
- @subsection Notification Notification
- 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.
-
- Additionally there is another important class of objects belonging to the Notifications module. The @ref orxonox::NotificationDispatcher "NotificationDispatchers".
-
- @subsection NotificationDispatcher NotificationDispatcher
- @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.
-
- @defgroup NotificationDispatchers Dispatchers
- @ingroup Notifications
-
- @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.
-
- At this point there are two @ref orxonox::NotificationDispatcher "NotificationDispatchers", the @ref orxonox::SimpleNotification "SimpleNotification", which just displays a specified message, and the @ref orxonox::CommandNotification "CommandNotification" which displays a message with a binding for a specified command in it.
-*/
Copied: code/branches/dockingsystem/doc/api/groups/Notifications.dox (from rev 8193, code/trunk/doc/api/groups/Notifications.dox)
===================================================================
--- code/branches/dockingsystem/doc/api/groups/Notifications.dox (rev 0)
+++ code/branches/dockingsystem/doc/api/groups/Notifications.dox 2011-04-06 10:07:29 UTC (rev 8194)
@@ -0,0 +1,64 @@
+/**
+ @addtogroup Notifications Notifications
+ @ingroup Modules
+
+ @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.
+
+ @section NotificationsUsage Usage
+ 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.
+
+ @subsection NotifictionsSending Sending notifications
+ Sending a new @ref orxonox::Notification "Notification" from (almost) anywhere in Orxonox is fairly easy.
+ You first have to decide on a message, it shouldn't be too long but be long enough to get your point accross.
+ 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.
+ 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. trough 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.
+ Once you have decided all that you can send the Notification by calling:
+ @code
+ NotificationManager::sendNotification(message, clientId, sender, isLocal); // isLocal = false can be ommitted since that is the default value.
+ @endcode
+
+ @subsection NotificationsDisplay Displaying notifications
+ Displaying @ref orxonox::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:
+ @code
+ showGUI NotificationLayer false true
+ @endcode
+ Or automatically, by adding a @ref orxonox::Script "Script" to the levelfile that does it for you:
+ @code
+ <Script code="showGUI NotificationLayer false true" needsGraphics="true" />
+ @endcode
+
+ 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:
+ @code
+ enterEditMode
+ @endcode
+
+ @section NotificationsTechincalDetails Technical details
+ 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.
+
+ @subsection NotificationQueue NotificationQueue
+ The @ref orxonox::NotificationQueue "NotificationQueue" is the entity, that (as said earlier) logically displays @ref orxonox::Notification "Notifications". Furthermore a @ref orxonox::NotificationQueue "NotificationQueue" displays only a subset of all the @ref orxonox::Notification "Notifications". The parameters that reduce the range of displayed @ref orxonox::Notification "Notifications" are:
+ - @b senders The senders, the set of targets of a @ref orxonox::NotificationQueue "NotificationQueue" is the set of senders a @ref orxonox::NotificationQueue "NotificationQueue" displays @ref orxonox::Notification "Notifications" from. E.g. If one would set the senders to "questsystem" then only @ref orxonox::Notification "Notifications" from the Questsystem would be displayed in that particular queue. If you set senders to "all" then all Notifications will be displayed. Different senders can be concatinated with commas.
+ - @b size The size specifies how many @ref orxonox::Notification "Notifications" are displayed at the most, if there are more @ref orxonox::Notification "Notifications" that could be displayed, then only the most recent are displayed.
+ - @b displayTime The display time specifies how long a @ref orxonox::Notification "Notification" is displayed at the most.
+
+ @subsection NotificationLayer NotificationLayer
+ 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". For every @ref orxonox::NotificationQueue "NotificationQueue" there is the equivalent representation in the NotificationLayer. So @ref orxonox::NotificationQueue "NotificationQueues" are not each represented by a GUI sheet, but thely all belong to one and the same GUI sheet, the NotificationLayer.
+
+ @subsection NotificationManager NotificationManager
+ The @ref orxonox::NotificationManager "NotificationManager" is (hence the name) the managing entity in this setting. It is responsible for the registering and unregistering of @ref orxonox::NotificationListener "NotificationListeners" (which the @ref orxonox::NotificationQueue "NotificationQueue" is) and also informs them about changes related to @ref orxonox::Notification "Notifications". It is also responsible for the creation and destruction of @ref orxonox::NotificationQueue "NotificationQueues" through the NotificationLayer and is also the point of approach for the NotificationLayer to get information it needs to display the queues. Finally the @ref orxonox::NotificationManager "NotificationManager" is responsible for sending (and in the process creating) @ref orxonox::Notification "Notifications" and is a means for the @ref orxonox::NotificationQueue "NotificationQueues" to get the information they need about @ref orxonox::Notification "Notifications".
+
+ @subsection Notification Notification
+ 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.
+
+ Additionally there is another important class of objects belonging to the Notifications module. The @ref orxonox::NotificationDispatcher "NotificationDispatchers".
+
+ @subsection NotificationDispatcher NotificationDispatcher
+ @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.
+
+ @defgroup NotificationDispatchers Dispatchers
+ @ingroup Notifications
+
+ @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.
+
+ At this point there are two @ref orxonox::NotificationDispatcher "NotificationDispatchers", the @ref orxonox::SimpleNotification "SimpleNotification", which just displays a specified message, and the @ref orxonox::CommandNotification "CommandNotification" which displays a message with a binding for a specified command in it.
+*/
Deleted: code/branches/dockingsystem/doc/api/groups/Pickup.dox
===================================================================
--- code/trunk/doc/api/groups/Pickup.dox 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/doc/api/groups/Pickup.dox 2011-04-06 10:07:29 UTC (rev 8194)
@@ -1,219 +0,0 @@
-/**
- @addtogroup Pickup Pickup
- @ingroup Modules
-
- The Pickup module adds a special type of object to Orxonox, the so-called @ref orxonox::Pickupable "Pickupables". @ref orxonox::Pickupable "Pickupables" are objects that can be picked up (by virtually any entity, but commonly by the @ref orxonox::Pawn "Pawn") and have some kind of effect on the entity that picked the @ref orxonox::Pickupable "Pickupable" up.
-
- @section IncludingPickups Including pickups in a level
- @ref orxonox::Pickupable "Pickupables" are designed so that they can be included in levels fairly easily, while also ensuring, that the pickup itself (its game-logic component) and how it is represented (e.g. in the PickupInventory (the GUI that displays @ref orxonox::Pickupable "Pickupables") or in the game) are neatly seperated.
- To be able to use @ref orxonox::Pickupable "Pickupables" in a level one must understand some basic concepts.
- - @ref orxonox::Pickupable "Pickupables" are entities which (by itself) have no physical (or graphical) dimension. The simply represent the effect they will have on a @ref orxonox::PickupCarrier "PickupCarrier" (the entity that can pick up @ref orxonox::Pickupable "Pickupables", @ref orxonox::Pawn "Pawn" for example inherits from @ref orxonox::PickupSpawner "PickupSpawner" and thus is able to pick up and carry @ref orxonox::Pickupable "Pickupables"), when used and the mechanism that leads to that.
- - The physical (or graphical) dimension of a pickup is called a @ref orxonox::PickupRepresentation "PickupRepresentation".
- - The @ref orxonox::PickupRepresentation "PickupRepresentation" of a @ref orxonox::Pickupable "Pickupable" and the @ref orxonox::Pickupable "Pickupable" itself are linked to each other, in such a way that a @ref orxonox::PickupRepresentation "PickupRepresentation" can only represent one type of @ref orxonox::Pickupable "Pickupable".
- - A type of @ref orxonox::Pickupable "Pickupable" is a specific pickup class (inheriting from @ref orxonox::Pickupable "Pickupable") with specific values for all its relevant parameters. This means, that a pickup of the same class with the same values for all parameters except for one is a different type of pickup and will therefore have a different @ref orxonox::PickupRepresentation "PickupRepresentation". Which parameters are the ones relevant to destinguish between two types of pickups can be defined in the class description of the specific pickup.
- - The entity that actually gives a @ref orxonox::Pickupable "Pickupable" to a @ref orxonox::PickupCarrier "PickupCarrier" is called a @ref orxonox::PickupSpawner "PickupSpawner". A @ref orxonox::PickupSpawner "PickupSpawner" creates (based on some parameters) @ref orxonox::Pickupable "Pickupables" which then is picked up by the @ref orxonox::PickupCarrier "PickupCarrier", that caused the @ref orxonox::PickupSpawner "PickupSpawner" to spawn a new pickup. How the spawner looks in the game is defined by the @ref orxonox::PickupRepresentation "PickupRepresentation" of the @ref orxonox::Pickupable "Pickupable" it spawns.
-
- @subsection UsingPredifinedPickups Using predefined pickups
- There is a file called <code>pickupRepresentationTemplates.oxt</code> in <code>levels/templates</code>, which holds the templates for the @ref orxonox::PickupRepresentation "PickupRepresentations" and also templates for @ref orxonox::Pickupable "Pickupables". The templates for the @ref orxonox::PickupRepresentation "PickupRepresentations" define the @ref orxonox::StaticEntity "StaticEntities" that are attached to the @ref orxonox::PickupSpawner "PickupSpawners" to make them look like the @ref orxonox::Pickupable "Pickupable" they are spawning. The templates for the @ref orxonox::Pickupable "Pickupables" can be added just for ease of use.
- If you want to use pickups you will have to include this file in your level file, somewhere above the Level-tag.
- @code
- <?lua
- include("templates/pickupRepresentationTemplates.oxt")
- ?>
- ...
- <Level>
- ...
- @endcode
- There is another file called <code>pickups.oxi</code> in <code>level/includes</code> which creates all @ref orxonox::PickupRepresentation "PickupRepresentations" needed for the @ref orxonox::Pickupable "Pickupable" supplied by the <code>pickupRepresentationTemplates.oxt</code> file. This file will have to be included as well. It has to be somewhere after the opening Scene-tag and your first use of a pickup.
- @code
- <Scene>
- ...
- <?lua
- include("includes/pickups.oxi")
- ?>
- @endcode
- After that all the predefined pickups specified in those two files can be used just by creating a @ref orxonox::PickupSpawner "PickupSpawner" for them in the respective level.
- For example:
- @code
- <PickupSpawner position="-100,0,-100" respawnTime="30" maxSpawnedItems="10">
- <pickup>
- <HealthPickup
- health = 10
- healthType = "limited"
- activationType = "immediate"
- durationType = "once"
- />
- </pickup>
- </PickupSpawner>
- @endcode
- Please be aware, that the @ref orxonox::Pickupable "Pickupable" specified for the @ref orxonox::PickupSpawner "PickupSpawner", has to be exactly the same (including all parameters) to the one specified in the <code>pickups.oxi</code> file.
- To make things simpler, one could just use the templates specified in the <code>pickupRepresentationTemplates.oxt</code> file. Which, following the previous example, would look like this:
- @code
- <PickupSpawner position="-100,0,-100" respawnTime="30" maxSpawnedItems="10">
- <pickup>
- <HealthPickup template="smallhealthpickup" />
- </pickup>
- </PickupSpawner>
- @endcode
-
- @subsection UnsingNon-PredefinedPickups Using non-predefined pickups
- To include a type of pickup (which, as we remember, is the class of the @ref orxonox::Pickupable "Pickupable" with specific values for all the relevant parameters) in a level file, you can just create a new @ref orxonox::PickupSpawner "PickupSpawner" and specify the @ref orxonox::Pickupable "Pickupable".
- @code
- <PickupSpawner position="-100,0,-100" respawnTime="30" maxSpawnedItems="10">
- <pickup>
- <HealthPickup
- health = 33
- healthType = "limited"
- activationType = "immediate"
- durationType = "once"
- />
- </pickup>
- </PickupSpawner>
- @endcode
- As can be seen in the <code>pickupRepresentationTemplates.oxt</code> file and the <code>pickups.oxi</code> file there is no @ref orxonox::PickupRepresentation "PickupRepresentation" defined for this type of pickup. Thus the default representation will be used.
-
- To create an appropriate @ref orxonox::PickupRepresentation "PickupRepresentation" for the inserted pickup above, you can just create a @ref orxonox::PickupRepresentation "PickupRepresentation" within the scene (Within the Scene-tags).
- @code
- <PickupRepresentation
- name = "My new health pickup"
- description = "This is an awesome new health pickup."
- spawnerTemplate = "mediumhealthpickupRepresentation"
- inventoryRepresentation = "MediumHealth"
- >
- <pickup>
- <HealthPickup
- health = 33
- healthType = "limited"
- activationType = "immediate"
- durationType = "once"
- />
- </pickup>
- </PickupRepresentation>
- @endcode
- Notice, that the type of pickup specified for the @ref orxonox::PickupRepresentation "PickupRepresentation", naturally, needs to be the same (this is the way they can be connected). Also, we just used an existing <em>spawnerTemplate</em>, to make things simpler.
-
- The next step is to create a <em>spawnerRepresentation</em> uniquely for our new type of pickup. Lets call it <code>newhealthpickupRepresentation</code>. Thus the parameter <em>spawnerTemplate</em> of the @ref orxonox::PickupRepresentation "PickupRepresentation" has to be changed to that value.
- @code
- spawnerTemplate = "newhealthpickupRepresentation"
- @endcode
- The <em>spawnerTemplate</em> defines how the @ref orxonox::PickupSpawner "PickupSpawner" is displayed in a level.
- In our example case it could look like this:
- @code
- <Template name=newhealthpickupRepresentation>
- <PickupRepresentation>
- <spawner-representation>
- <StaticEntity>
- <attached>
- -- Here you can put all the objects which define the look of the spawner. --
- </attached>
- </StaticEntity>
- </spawner-representation>
- </PickupRepresentation>
- </Template>
- @endcode
- Please refer to the <code>pickupRepresentationTemplates.oxt</code> for more examples.
-
- The @ref orxonox::PickupRepresentation "PickupRepresentation" also needs another parameter the <em>inventoryRepresentation</em>. This parameter defined how the @ref orxonox::Pickupable "Pickupable" is displayed in the PickupInventory (a menu to browse the currently equipped pickups).
- @code
- inventoryRepresentation = "MediumHealth"
- @endcode
- This is the name of an image defined in the PickupInventory imageset (<code>PickupInventory.imageset</code>), which can be found in <code>data_extern/gui/imagesets</code>.
-
- This is all that has to be done. Now you have a new pickup type with an appropriate @ref orxonox::PickupRepresentation "PickupRepresentation" for your use. If you feel that your pickup is useful in general, please don't hesitate to create a template for the pickup and add your pickup to the <code>pickupRepresentationTemplates.oxt</code> file and the <code>pickups.oxi</code> file, so that anyone who wants to use it can do so quite easily.
-
- There is also an additional way to create new types of pickups to be used in a level (without having to do any coding). There is a @ref orxonox::Pickupable "Pickupable" called the @ref orxonox::PickupCollection "PickupCollection", which is just a collection (hence the name) of @ref orxonox::Pickupable "Pickupables" (more precisely of @ref orxonox::CollectiblePickup "CollectiblePickups"), behaving as if it was just one @ref orxonox::Pickupable "Pickupable".
- A @ref orxonox::PickupCollection "PickupCollection" can be created as follows:
- @code
- <PickupCollection>
- <pickupables>
- -- some pickups you want to have in your collection, e.g. --
- <HealthPickup template=smallhealthpickup />
- <HealthPickup health=50 healthRate=5 durationType=continuous activationType=immediate healthType=limited />
- </pickupables>
- </PickupCollection>
- @endcode
- Of which types of pickups a collection is made up is entirely up to the one creating the @ref orxonox::PickupCollection "PickupCollection", they can be mixed freely.
-
- @section CreatingAPickup Creating a new pickup
- Things have been fairly straightforward so far. Creating a @ref orxonox::Pickupable "Pickupable" form scratch isn't as easy. Therefore I'm just going to supply you with a recipe, or a set of steps you have to take, without which your pickup won't work and point out some common pitfalls.
-
- @subsection CreatingAPickupClass Creating the class
- For a new @ref orxonox::Pickupable "Pickupable" you need to create a new class in <code>>modules/pickup/items</code>. Your class needs to be derived from another pickup class, normally this would either be @ref orxonox::Pickupable "Pickupable", @ref orxonox::CollectiblePickup "CollectiblePickup" or @ref orxonox::Pickup "Pickup". @ref orxonox::Pickupable "Pickupable" is (as mentioned earlier) the base class of all things that can be picked up, thus of all pickups. @ref orxonox::CollectiblePickup "CollectiblePickup" is a (directly) derived class of @ref orxonox::Pickupable "Pickupable" and provides the additional functionality of enabling your pickup to be used in a @ref orxonox::PickupCollection "PickupCollection". However you are probably going to want to derive your class form @ref orxonox::Pickup "Pickup", because it is a @ref orxonox::CollectiblePickup "CollectiblePickup" and provides some useful methods. So have a look at @ref orxonox::Pickup "Pickup".
- Once you have created your new pickup class you have to insert it in the <code>PickupPrereqs.h</code> file in the <code>modules/pickup</code> folder and in the <code>CMakeList.txt</code> file in the <code>modules/pickup/items</code> folder. Also have a look at other pickups to make sure you include all the necessary files in your class.
-
- @subsection ChoosingTheCarriers Coosing the carriers
- You also have to choose the entities that are allowed to pick your pickup up. After you have chosen the entity that carries your pickup, you need to do the following.
- - The enity that carries your pickup needs to be derived from the @ref orxonox::PickupCarrier "PickupCarrier" interface. And you need to implement the @ref orxonox::PickupCarrier "PickupCarriers'" virtual functions <code>getCarrierChildren()</code> and <code>getCarrierParent()</code>. These tow methods are needed, because all pickups are initially picked up by a @ref orxonox::Pawn "Pawn" and then handed down to the entity that effectively carries them. With the above mentioned two function just that is accomplished. A hierarchical structure is established with one parent and a set of children, where the @ref orxonox::Pawn "Pawn" is the root node of this hierarchical structure, the only entity with no parent.
- - Once you have done that you will also want to specify in your pickup which carriers can pick it up, this is done via the <code>addTarget()</code> function. So you have to make sure the target is added whenever one of your pickups is created (so, most conveniently somewhere in the constructor), with the following command.
- @code
- this->addTarget(ClassIdentifier<MyCarrierClass>::getIdentifier());
- @endcode
-
- @subsection CreatingTheInnerWorkings Creating the inner workings of your pickup
- Now that we have the skeleton of a pickup and we have defined which carriers are allowed to pick our pickup up we are going to take a look at all the methods we can (or sometimes have to) overload from @ref orxonox::Pickupable "Pickupable", for our pickup to work properly. But first I will introduce some more concepts to make the need for these methods more obvious.
- - Since one pickup class can by itself be many pickup types, we need a way to find out whether a particular instance of a pickup is of the same type as another instance of a pickup. To that end the @ref orxonox::PickupIdentifier "PickupIdentifier" was created. The @ref orxonox::PickupIdentifier "PickupIdentifier" accounts for the type of class your pickup is of and also for the parameters (and their values) that distinguish different types of pickups of the same class. Much of the functionality of the pickup module relies on this identifier being correct, thus it is very important to initialize it correctly. (We will see, how that is done in a short while.)
- - Every @ref orxonox::Pickupable "Pickupable" has at least two states which are very important. The first is, whether the @ref orxonox::Pickupable "Pickupable" is currently in use or not and the second is whether the pickup is currently picked up or not.
-
- Let's have a look at the important methods.
- - <b>changedUsed()</b> The <code>changedUsed()</code> method is called whenever the state of the @ref orxonox::Pickupable "Pickupable" transits from being used to not being used or the other way around. Which means this method is probably the most important method you have at your fingertips, since it enables you to apply the effect of your pickup when it gets used and remove the effect as soon as it is no longer in use.
- - <b>changedPickedUp()</b> The <code>changedPickedUp()</code> method is called whenever the state of the @ref orxonox::Pickupable "Pickupable" changes from being picked up to not being picked up or the other way around. For example if you want your pickup to be used as soon as it is picked up, this is the method you have to overload to achieve that behavior (or just let your pickup be derived from @ref orxonox::Pickup "Pickup", which implements exactly that behavior, if the <em>activationType</em> is set to <em>immediate</em>). You don't have to concern yourself with destroying the pickup or creating a spawner when it changes to not picked up, since that is already implemented with the @ref orxonox::Pickupable "Pickupable" and @ref orxonox::PickupCarrier "PickupCarrier" classes. If you want a different behavior, however, once again, this is the method.
- - <b>changedCarrier()</b> The <code>changedCarrier()</code> method is called whenever the carrier of the @ref orxonox::Pickupable "Pickupable" changes. And by that I don't mean the class that is allowed to carry the pickup, but the object that actually carries (or carried) the pickup. Please do not overload this class to implement behavior for picked up -> not picked up transitions, use <code>changedPickedUp()</code> for that. For most pickup classes this method doesn't need to be overloaded. Where it is used, however is in the @ref orxonox::PickupCollection "PickupCollection" class, where the new carrier needed to be communicated to all pickups the collection consists of, whenever the carrier was changed.
-
- Please be aware, that these three methods are methods registered with @ref Super.h "Super", meaning, that whenever overloading them, don't forget to call <code>SUPER(MyClass, myMethod);</code>.
- Also when implementing the above methods you should think of what should happen in unexpected situations, e.g. when your pickup is unused manually and set to used again.
- Additionally you should use the <code>destroy()</code> method of Pickupable instead of the method provided by @ref orxonox::OrxonoxClass "OrxonoxClass", meaning <code>Pickupable::destroy()</code> instead of plain <code>destroy()</code>.
-
- - <b>clone()</b> The <code>clone()</code> method creates a new pickup of the same type as the pickup it is cloned from. So the cloned pickup is not exactly the same, as it doesn't necessarily completely reflect the status of the pickup it is cloned from, but it reflects all the parameters and their values, that distinguish different types of this pickup class. It needs to be implemented by every pickup class. And it is best if this is done in a very specific way. Below is shown how:
- @code
- void MyPickup::clone(OrxonoxClass*& item)
- {
- if(item == NULL)
- item = new MyPickup(this);
-
- SUPER(MyPickup, clone, item);
-
- MyPickup* pickup = dynamic_cast<MyPickup*>(item);
- // Here you should set all the important parameters (that distinguish the different types of this pickup), e.g.
- pickup->setSomeParameter(this->getSomeParameter());
- // You must also initialize the identifier of the new pickup, this is normally done in a member function called in
- pickup->initializeIdentifier();
- }
- @endcode
- - <b>initializeIdentifier()</b> The <code>initializeIdentifier()</code> method initializes (or more simply put, creates) the @ref orxonox::PickupIdentifier "PickupIdentifier" of the instance of your pickup. Since the important values of the parameters are not yet available in the constructor of your pickup this <code>initializeIdentifier()</code> method must be called as soon as they are available, which normally is in the <code>XMLPort()</code> method, and the <code>clone()</code> method, as seen above. In the <code>initializeIdentifier()</code> method you need to register each parameter that is important for the type of your pickup to its identifier, this is normally done as follows:
- @code
- void Pickup::initializeIdentifier(void)
- {
- // If the get method returns a string.
- std::string val1 = this->getSomeParameter();
- std::string type1 = "someParameter";
- this->pickupIdentifier_->addParameter(type1, val1);
- // If the get method doesn't return a string
- std::stringstream stream;
- stream << this->getSomeOtherParameter();
- std::string type2 = "someOtherParameter";
- std::string val2 = stream.str();
- this->pickupIdentifier_->addParameter(type2, val2);
- }
- @endcode
-
- Be aware, this only works for parameters that are simple enough, meaning with pointers for example it will, naturally, not work, and other ways must be found (this is for example done in @ref orxonox::PickupCollection "PickupCollection" with a derived class of the @ref orxonox::PickupIdentifier "PickupIdentifier", the @ref orxonox::PickupCollectionIdentifier "PickupCollectionIdentifier") or in the @ref orxonox::DronePickup "DronePickup" class by using a @ref orxonox::Template "Template".
- - <b>createSpawner()</b> The <code>createSpawner()</code> method needs to be implemented by any pickup directly inheriting from @ref orxonox::Pickupable "Pickupable" (or directly from @ref orxonox::CollectiblePickup "CollectiblePickup"), so if you inherit from @ref orxonox::Pickup "Pickup", you don't need to implement this. It is used to create a @ref orxonox::PickupSpawner "PickupSpawner", when the pickup is dropped. A standard implementation would look like this.
- @code
- bool MyPickup::createSpawner(void)
- {
- new DroppedPickup(this, this, this->getCarrier());
- return true;
- }
- @endcode
-
- @section PickupTechnicalDetails Technical details
-
- @image html pickupmodule.png
-*/
-
-/**
- @defgroup PickupItems Items
- @ingroup Pickup
-
- The actual pickups can be found here.
-*/
\ No newline at end of file
Copied: code/branches/dockingsystem/doc/api/groups/Pickup.dox (from rev 8193, code/trunk/doc/api/groups/Pickup.dox)
===================================================================
--- code/branches/dockingsystem/doc/api/groups/Pickup.dox (rev 0)
+++ code/branches/dockingsystem/doc/api/groups/Pickup.dox 2011-04-06 10:07:29 UTC (rev 8194)
@@ -0,0 +1,219 @@
+/**
+ @addtogroup Pickup Pickup
+ @ingroup Modules
+
+ The Pickup module adds a special type of object to Orxonox, the so-called @ref orxonox::Pickupable "Pickupables". @ref orxonox::Pickupable "Pickupables" are objects that can be picked up (by virtually any entity, but commonly by the @ref orxonox::Pawn "Pawn") and have some kind of effect on the entity that picked the @ref orxonox::Pickupable "Pickupable" up.
+
+ @section IncludingPickups Including pickups in a level
+ @ref orxonox::Pickupable "Pickupables" are designed so that they can be included in levels fairly easily, while also ensuring, that the pickup itself (its game-logic component) and how it is represented (e.g. in the PickupInventory (the GUI that displays @ref orxonox::Pickupable "Pickupables") or in the game) are neatly seperated.
+ To be able to use @ref orxonox::Pickupable "Pickupables" in a level one must understand some basic concepts.
+ - @ref orxonox::Pickupable "Pickupables" are entities which (by itself) have no physical (or graphical) dimension. The simply represent the effect they will have on a @ref orxonox::PickupCarrier "PickupCarrier" (the entity that can pick up @ref orxonox::Pickupable "Pickupables", @ref orxonox::Pawn "Pawn" for example inherits from @ref orxonox::PickupSpawner "PickupSpawner" and thus is able to pick up and carry @ref orxonox::Pickupable "Pickupables"), when used and the mechanism that leads to that.
+ - The physical (or graphical) dimension of a pickup is called a @ref orxonox::PickupRepresentation "PickupRepresentation".
+ - The @ref orxonox::PickupRepresentation "PickupRepresentation" of a @ref orxonox::Pickupable "Pickupable" and the @ref orxonox::Pickupable "Pickupable" itself are linked to each other, in such a way that a @ref orxonox::PickupRepresentation "PickupRepresentation" can only represent one type of @ref orxonox::Pickupable "Pickupable".
+ - A type of @ref orxonox::Pickupable "Pickupable" is a specific pickup class (inheriting from @ref orxonox::Pickupable "Pickupable") with specific values for all its relevant parameters. This means, that a pickup of the same class with the same values for all parameters except for one is a different type of pickup and will therefore have a different @ref orxonox::PickupRepresentation "PickupRepresentation". Which parameters are the ones relevant to destinguish between two types of pickups can be defined in the class description of the specific pickup.
+ - The entity that actually gives a @ref orxonox::Pickupable "Pickupable" to a @ref orxonox::PickupCarrier "PickupCarrier" is called a @ref orxonox::PickupSpawner "PickupSpawner". A @ref orxonox::PickupSpawner "PickupSpawner" creates (based on some parameters) @ref orxonox::Pickupable "Pickupables" which then is picked up by the @ref orxonox::PickupCarrier "PickupCarrier", that caused the @ref orxonox::PickupSpawner "PickupSpawner" to spawn a new pickup. How the spawner looks in the game is defined by the @ref orxonox::PickupRepresentation "PickupRepresentation" of the @ref orxonox::Pickupable "Pickupable" it spawns.
+
+ @subsection UsingPredifinedPickups Using predefined pickups
+ There is a file called <code>pickupRepresentationTemplates.oxt</code> in <code>levels/templates</code>, which holds the templates for the @ref orxonox::PickupRepresentation "PickupRepresentations" and also templates for @ref orxonox::Pickupable "Pickupables". The templates for the @ref orxonox::PickupRepresentation "PickupRepresentations" define the @ref orxonox::StaticEntity "StaticEntities" that are attached to the @ref orxonox::PickupSpawner "PickupSpawners" to make them look like the @ref orxonox::Pickupable "Pickupable" they are spawning. The templates for the @ref orxonox::Pickupable "Pickupables" can be added just for ease of use.
+ If you want to use pickups you will have to include this file in your level file, somewhere above the Level-tag.
+ @code
+ <?lua
+ include("templates/pickupRepresentationTemplates.oxt")
+ ?>
+ ...
+ <Level>
+ ...
+ @endcode
+ There is another file called <code>pickups.oxi</code> in <code>level/includes</code> which creates all @ref orxonox::PickupRepresentation "PickupRepresentations" needed for the @ref orxonox::Pickupable "Pickupable" supplied by the <code>pickupRepresentationTemplates.oxt</code> file. This file will have to be included as well. It has to be somewhere after the opening Scene-tag and your first use of a pickup.
+ @code
+ <Scene>
+ ...
+ <?lua
+ include("includes/pickups.oxi")
+ ?>
+ @endcode
+ After that all the predefined pickups specified in those two files can be used just by creating a @ref orxonox::PickupSpawner "PickupSpawner" for them in the respective level.
+ For example:
+ @code
+ <PickupSpawner position="-100,0,-100" respawnTime="30" maxSpawnedItems="10">
+ <pickup>
+ <HealthPickup
+ health = 10
+ healthType = "limited"
+ activationType = "immediate"
+ durationType = "once"
+ />
+ </pickup>
+ </PickupSpawner>
+ @endcode
+ Please be aware, that the @ref orxonox::Pickupable "Pickupable" specified for the @ref orxonox::PickupSpawner "PickupSpawner", has to be exactly the same (including all parameters) to the one specified in the <code>pickups.oxi</code> file.
+ To make things simpler, one could just use the templates specified in the <code>pickupRepresentationTemplates.oxt</code> file. Which, following the previous example, would look like this:
+ @code
+ <PickupSpawner position="-100,0,-100" respawnTime="30" maxSpawnedItems="10">
+ <pickup>
+ <HealthPickup template="smallhealthpickup" />
+ </pickup>
+ </PickupSpawner>
+ @endcode
+
+ @subsection UnsingNon-PredefinedPickups Using non-predefined pickups
+ To include a type of pickup (which, as we remember, is the class of the @ref orxonox::Pickupable "Pickupable" with specific values for all the relevant parameters) in a level file, you can just create a new @ref orxonox::PickupSpawner "PickupSpawner" and specify the @ref orxonox::Pickupable "Pickupable".
+ @code
+ <PickupSpawner position="-100,0,-100" respawnTime="30" maxSpawnedItems="10">
+ <pickup>
+ <HealthPickup
+ health = 33
+ healthType = "limited"
+ activationType = "immediate"
+ durationType = "once"
+ />
+ </pickup>
+ </PickupSpawner>
+ @endcode
+ As can be seen in the <code>pickupRepresentationTemplates.oxt</code> file and the <code>pickups.oxi</code> file there is no @ref orxonox::PickupRepresentation "PickupRepresentation" defined for this type of pickup. Thus the default representation will be used.
+
+ To create an appropriate @ref orxonox::PickupRepresentation "PickupRepresentation" for the inserted pickup above, you can just create a @ref orxonox::PickupRepresentation "PickupRepresentation" within the scene (Within the Scene-tags).
+ @code
+ <PickupRepresentation
+ name = "My new health pickup"
+ description = "This is an awesome new health pickup."
+ spawnerTemplate = "mediumhealthpickupRepresentation"
+ inventoryRepresentation = "MediumHealth"
+ >
+ <pickup>
+ <HealthPickup
+ health = 33
+ healthType = "limited"
+ activationType = "immediate"
+ durationType = "once"
+ />
+ </pickup>
+ </PickupRepresentation>
+ @endcode
+ Notice, that the type of pickup specified for the @ref orxonox::PickupRepresentation "PickupRepresentation", naturally, needs to be the same (this is the way they can be connected). Also, we just used an existing <em>spawnerTemplate</em>, to make things simpler.
+
+ The next step is to create a <em>spawnerRepresentation</em> uniquely for our new type of pickup. Lets call it <code>newhealthpickupRepresentation</code>. Thus the parameter <em>spawnerTemplate</em> of the @ref orxonox::PickupRepresentation "PickupRepresentation" has to be changed to that value.
+ @code
+ spawnerTemplate = "newhealthpickupRepresentation"
+ @endcode
+ The <em>spawnerTemplate</em> defines how the @ref orxonox::PickupSpawner "PickupSpawner" is displayed in a level.
+ In our example case it could look like this:
+ @code
+ <Template name=newhealthpickupRepresentation>
+ <PickupRepresentation>
+ <spawner-representation>
+ <StaticEntity>
+ <attached>
+ -- Here you can put all the objects which define the look of the spawner. --
+ </attached>
+ </StaticEntity>
+ </spawner-representation>
+ </PickupRepresentation>
+ </Template>
+ @endcode
+ Please refer to the <code>pickupRepresentationTemplates.oxt</code> for more examples.
+
+ The @ref orxonox::PickupRepresentation "PickupRepresentation" also needs another parameter the <em>inventoryRepresentation</em>. This parameter defined how the @ref orxonox::Pickupable "Pickupable" is displayed in the PickupInventory (a menu to browse the currently equipped pickups).
+ @code
+ inventoryRepresentation = "MediumHealth"
+ @endcode
+ This is the name of an image defined in the PickupInventory imageset (<code>PickupInventory.imageset</code>), which can be found in <code>data_extern/gui/imagesets</code>.
+
+ This is all that has to be done. Now you have a new pickup type with an appropriate @ref orxonox::PickupRepresentation "PickupRepresentation" for your use. If you feel that your pickup is useful in general, please don't hesitate to create a template for the pickup and add your pickup to the <code>pickupRepresentationTemplates.oxt</code> file and the <code>pickups.oxi</code> file, so that anyone who wants to use it can do so quite easily.
+
+ There is also an additional way to create new types of pickups to be used in a level (without having to do any coding). There is a @ref orxonox::Pickupable "Pickupable" called the @ref orxonox::PickupCollection "PickupCollection", which is just a collection (hence the name) of @ref orxonox::Pickupable "Pickupables" (more precisely of @ref orxonox::CollectiblePickup "CollectiblePickups"), behaving as if it was just one @ref orxonox::Pickupable "Pickupable".
+ A @ref orxonox::PickupCollection "PickupCollection" can be created as follows:
+ @code
+ <PickupCollection>
+ <pickupables>
+ -- some pickups you want to have in your collection, e.g. --
+ <HealthPickup template=smallhealthpickup />
+ <HealthPickup health=50 healthRate=5 durationType=continuous activationType=immediate healthType=limited />
+ </pickupables>
+ </PickupCollection>
+ @endcode
+ Of which types of pickups a collection is made up is entirely up to the one creating the @ref orxonox::PickupCollection "PickupCollection", they can be mixed freely.
+
+ @section CreatingAPickup Creating a new pickup
+ Things have been fairly straightforward so far. Creating a @ref orxonox::Pickupable "Pickupable" form scratch isn't as easy. Therefore I'm just going to supply you with a recipe, or a set of steps you have to take, without which your pickup won't work and point out some common pitfalls.
+
+ @subsection CreatingAPickupClass Creating the class
+ For a new @ref orxonox::Pickupable "Pickupable" you need to create a new class in <code>>modules/pickup/items</code>. Your class needs to be derived from another pickup class, normally this would either be @ref orxonox::Pickupable "Pickupable", @ref orxonox::CollectiblePickup "CollectiblePickup" or @ref orxonox::Pickup "Pickup". @ref orxonox::Pickupable "Pickupable" is (as mentioned earlier) the base class of all things that can be picked up, thus of all pickups. @ref orxonox::CollectiblePickup "CollectiblePickup" is a (directly) derived class of @ref orxonox::Pickupable "Pickupable" and provides the additional functionality of enabling your pickup to be used in a @ref orxonox::PickupCollection "PickupCollection". However you are probably going to want to derive your class form @ref orxonox::Pickup "Pickup", because it is a @ref orxonox::CollectiblePickup "CollectiblePickup" and provides some useful methods. So have a look at @ref orxonox::Pickup "Pickup".
+ Once you have created your new pickup class you have to insert it in the <code>PickupPrereqs.h</code> file in the <code>modules/pickup</code> folder and in the <code>CMakeList.txt</code> file in the <code>modules/pickup/items</code> folder. Also have a look at other pickups to make sure you include all the necessary files in your class.
+
+ @subsection ChoosingTheCarriers Coosing the carriers
+ You also have to choose the entities that are allowed to pick your pickup up. After you have chosen the entity that carries your pickup, you need to do the following.
+ - The enity that carries your pickup needs to be derived from the @ref orxonox::PickupCarrier "PickupCarrier" interface. And you need to implement the @ref orxonox::PickupCarrier "PickupCarriers'" virtual functions <code>getCarrierChildren()</code> and <code>getCarrierParent()</code>. These tow methods are needed, because all pickups are initially picked up by a @ref orxonox::Pawn "Pawn" and then handed down to the entity that effectively carries them. With the above mentioned two function just that is accomplished. A hierarchical structure is established with one parent and a set of children, where the @ref orxonox::Pawn "Pawn" is the root node of this hierarchical structure, the only entity with no parent.
+ - Once you have done that you will also want to specify in your pickup which carriers can pick it up, this is done via the <code>addTarget()</code> function. So you have to make sure the target is added whenever one of your pickups is created (so, most conveniently somewhere in the constructor), with the following command.
+ @code
+ this->addTarget(ClassIdentifier<MyCarrierClass>::getIdentifier());
+ @endcode
+
+ @subsection CreatingTheInnerWorkings Creating the inner workings of your pickup
+ Now that we have the skeleton of a pickup and we have defined which carriers are allowed to pick our pickup up we are going to take a look at all the methods we can (or sometimes have to) overload from @ref orxonox::Pickupable "Pickupable", for our pickup to work properly. But first I will introduce some more concepts to make the need for these methods more obvious.
+ - Since one pickup class can by itself be many pickup types, we need a way to find out whether a particular instance of a pickup is of the same type as another instance of a pickup. To that end the @ref orxonox::PickupIdentifier "PickupIdentifier" was created. The @ref orxonox::PickupIdentifier "PickupIdentifier" accounts for the type of class your pickup is of and also for the parameters (and their values) that distinguish different types of pickups of the same class. Much of the functionality of the pickup module relies on this identifier being correct, thus it is very important to initialize it correctly. (We will see, how that is done in a short while.)
+ - Every @ref orxonox::Pickupable "Pickupable" has at least two states which are very important. The first is, whether the @ref orxonox::Pickupable "Pickupable" is currently in use or not and the second is whether the pickup is currently picked up or not.
+
+ Let's have a look at the important methods.
+ - <b>changedUsed()</b> The <code>changedUsed()</code> method is called whenever the state of the @ref orxonox::Pickupable "Pickupable" transits from being used to not being used or the other way around. Which means this method is probably the most important method you have at your fingertips, since it enables you to apply the effect of your pickup when it gets used and remove the effect as soon as it is no longer in use.
+ - <b>changedPickedUp()</b> The <code>changedPickedUp()</code> method is called whenever the state of the @ref orxonox::Pickupable "Pickupable" changes from being picked up to not being picked up or the other way around. For example if you want your pickup to be used as soon as it is picked up, this is the method you have to overload to achieve that behavior (or just let your pickup be derived from @ref orxonox::Pickup "Pickup", which implements exactly that behavior, if the <em>activationType</em> is set to <em>immediate</em>). You don't have to concern yourself with destroying the pickup or creating a spawner when it changes to not picked up, since that is already implemented with the @ref orxonox::Pickupable "Pickupable" and @ref orxonox::PickupCarrier "PickupCarrier" classes. If you want a different behavior, however, once again, this is the method.
+ - <b>changedCarrier()</b> The <code>changedCarrier()</code> method is called whenever the carrier of the @ref orxonox::Pickupable "Pickupable" changes. And by that I don't mean the class that is allowed to carry the pickup, but the object that actually carries (or carried) the pickup. Please do not overload this class to implement behavior for picked up -> not picked up transitions, use <code>changedPickedUp()</code> for that. For most pickup classes this method doesn't need to be overloaded. Where it is used, however is in the @ref orxonox::PickupCollection "PickupCollection" class, where the new carrier needed to be communicated to all pickups the collection consists of, whenever the carrier was changed.
+
+ Please be aware, that these three methods are methods registered with @ref Super.h "Super", meaning, that whenever overloading them, don't forget to call <code>SUPER(MyClass, myMethod);</code>.
+ Also when implementing the above methods you should think of what should happen in unexpected situations, e.g. when your pickup is unused manually and set to used again.
+ Additionally you should use the <code>destroy()</code> method of Pickupable instead of the method provided by @ref orxonox::OrxonoxClass "OrxonoxClass", meaning <code>Pickupable::destroy()</code> instead of plain <code>destroy()</code>.
+
+ - <b>clone()</b> The <code>clone()</code> method creates a new pickup of the same type as the pickup it is cloned from. So the cloned pickup is not exactly the same, as it doesn't necessarily completely reflect the status of the pickup it is cloned from, but it reflects all the parameters and their values, that distinguish different types of this pickup class. It needs to be implemented by every pickup class. And it is best if this is done in a very specific way. Below is shown how:
+ @code
+ void MyPickup::clone(OrxonoxClass*& item)
+ {
+ if(item == NULL)
+ item = new MyPickup(this);
+
+ SUPER(MyPickup, clone, item);
+
+ MyPickup* pickup = dynamic_cast<MyPickup*>(item);
+ // Here you should set all the important parameters (that distinguish the different types of this pickup), e.g.
+ pickup->setSomeParameter(this->getSomeParameter());
+ // You must also initialize the identifier of the new pickup, this is normally done in a member function called in
+ pickup->initializeIdentifier();
+ }
+ @endcode
+ - <b>initializeIdentifier()</b> The <code>initializeIdentifier()</code> method initializes (or more simply put, creates) the @ref orxonox::PickupIdentifier "PickupIdentifier" of the instance of your pickup. Since the important values of the parameters are not yet available in the constructor of your pickup this <code>initializeIdentifier()</code> method must be called as soon as they are available, which normally is in the <code>XMLPort()</code> method, and the <code>clone()</code> method, as seen above. In the <code>initializeIdentifier()</code> method you need to register each parameter that is important for the type of your pickup to its identifier, this is normally done as follows:
+ @code
+ void Pickup::initializeIdentifier(void)
+ {
+ // If the get method returns a string.
+ std::string val1 = this->getSomeParameter();
+ std::string type1 = "someParameter";
+ this->pickupIdentifier_->addParameter(type1, val1);
+ // If the get method doesn't return a string
+ std::stringstream stream;
+ stream << this->getSomeOtherParameter();
+ std::string type2 = "someOtherParameter";
+ std::string val2 = stream.str();
+ this->pickupIdentifier_->addParameter(type2, val2);
+ }
+ @endcode
+
+ Be aware, this only works for parameters that are simple enough, meaning with pointers for example it will, naturally, not work, and other ways must be found (this is for example done in @ref orxonox::PickupCollection "PickupCollection" with a derived class of the @ref orxonox::PickupIdentifier "PickupIdentifier", the @ref orxonox::PickupCollectionIdentifier "PickupCollectionIdentifier") or in the @ref orxonox::DronePickup "DronePickup" class by using a @ref orxonox::Template "Template".
+ - <b>createSpawner()</b> The <code>createSpawner()</code> method needs to be implemented by any pickup directly inheriting from @ref orxonox::Pickupable "Pickupable" (or directly from @ref orxonox::CollectiblePickup "CollectiblePickup"), so if you inherit from @ref orxonox::Pickup "Pickup", you don't need to implement this. It is used to create a @ref orxonox::PickupSpawner "PickupSpawner", when the pickup is dropped. A standard implementation would look like this.
+ @code
+ bool MyPickup::createSpawner(void)
+ {
+ new DroppedPickup(this, this, this->getCarrier());
+ return true;
+ }
+ @endcode
+
+ @section PickupTechnicalDetails Technical details
+
+ @image html pickupmodule.png
+*/
+
+/**
+ @defgroup PickupItems Items
+ @ingroup Pickup
+
+ The actual pickups can be found here.
+*/
\ No newline at end of file
Deleted: code/branches/dockingsystem/doc/api/groups/Questsystem.dox
===================================================================
--- code/trunk/doc/api/groups/Questsystem.dox 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/doc/api/groups/Questsystem.dox 2011-04-06 10:07:29 UTC (rev 8194)
@@ -1,197 +0,0 @@
-/**
- @addtogroup Questsystem Questsystem
- @ingroup Modules
-
- 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.
-
- @section QuestsystemTechnicalDetails Technical details
- 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).
- @image html questsystem.png
-
- @section CreatingQuests Creating Quests
-
- @subsection CreatingTheQuestHierarchy Creating the Quest-Hierarchy
- 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.
-
- @subsubsection LocalQuest LocalQuest
- 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.
-
- Creating a @ref orxonox::LocalQuest "LocalQuest" in XML goes as follows:
- @code
- <LocalQuest id="questId">
- <QuestDescription title="Title" description="Description." /> //The description of the quest.
- <subquests>
- <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.
- ...
- <Quest id="questIdn" />
- </subquests>
- <hints>
- <QuestHint id="hintId1" /> //A list of n QuestHints, see QuestHint for the full XML representation of those.
- ...
- <QuestHint id="hintIdn" />
- </hints>
- <fail-effects>
- <QuestEffect /> //A list of QuestEffects, invoked when the Quest is failed, see QuestEffect for the full XML representation.
- ...
- <QuestEffect />
- </fail-effects>
- <complete-effects>
- <QuestEffect /> //A list of QuestEffects, invoked when the Quest is completed, see QuestEffect for the full XML representation.
- ...
- <QuestEffect />
- </complete-effects>
- </LocalQuest>
- @endcode
-
- @subsubsection GlobalQuest GlobalQuest
- @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.
-
- Creating a @ref orxonox::GlobalQuest "GlobalQuest" in XML goes as follows:
- @code
- <GlobalQuest id="questId">
- <QuestDescription title="Title" description="Description." /> //The description of the quest.
- <subquests>
- <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.
- ...
- <Quest id="questIdn" />
- </subquests>
- <hints>
- <QuestHint id="hintId1" /> //A list of n QuestHints, see QuestHint for the full XML representation of those.
- ...
- <QuestHint id="hintIdn" />
- </hints>
- <fail-effects>
- <QuestEffect /> //A list of QuestEffects, invoked on all players possessing this quest, when the Quest is failed, see QuestEffect for the full XML representation.
- ...
- <QuestEffect />
- </fail-effects>
- <complete-effects>
- <QuestEffect /> //A list of QuestEffects, invoked on all players possessing this quest, when the Quest is completed, see QuestEffect for the full XML representation.
- ...
- <QuestEffect />
- </complete-effects>
- <reward-effects>
- <QuestEffect /> //A list of QuestEffects, invoked on the player completing this quest. See QuestEffect for the full XML representation.
- ...
- <QuestEffect />
- </reward-effects>
- </GlobalQuest>
- @endcode
-
- 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.
-
- @subsubsection QuestHint QuestHint
- @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".
-
- Creating a @ref orxonox::QuestHint "QuestHint" in XML goes as follows:
- @code
- <QuestHint id="hintId">
- <QuestDesctription title="" description="" />
- </QuestHint>
- @endcode
-
- @subsubsection QuestDescription QuestDescription
- 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.
-
- Creating a @ref orxonox::QuestDescription "QuestDescription" in XML goes as follows:
- @code
- <QuestDescription title="Title" description="Description Text" failMessage="You fail." completeMessage="You win!" />
- @endcode
-
- @subsection CreatingSideEffects Creating side effects
- @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).
-
- @subsubsection QuestEffect QuestEffect
- 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.
-
- 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.
-
- @paragraph AddQuest AddQuest
- This @ref orxonox::QuestEffect "QuestEffect" adds (respectively starts) a @ref orxonox::Quest "Quest" (identified by the given questId) to the player.
- @code
- <AddQuest questId="id" /> //Where id identifies the Quest that should be added.
- @endcode
-
- @paragraph FailQuest FailQuest
- This @ref orxonox::QuestEffect "QuestEffect" fails a @ref orxonox::Quest "Quest" (identified by the given questId) for the player.
- @code
- <FailQuest questId="id" /> //Where id identifies the Quest that should be added.
- @endcode
-
- @paragraph CompleteQuest CompleteQuest
- This @ref orxonox::QuestEffect "QuestEffect" completes a @ref orxonox::Quest "Quest" (identified by the given questId) for the player.
- @code
- <CompleteQuest questId="id" /> //Where id identifies the Quest that should be added.
- @endcode
-
- @paragraph AddQuestHint AddQuestHint
- 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.
- @code
- <AddQuestHint hintId="id" /> //Where id identifies the QuestHint that should be added.
- @endcode
-
- @paragraph AddReward AddReward
- 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".
- @code
- <AddReward>
- <Rewardable /> //A list of Rewardable objects to be rewarded the player, see the specific Rewardables for their respective XML representations.
- ...
- <Rewardable />
- </AddReward>
- @endcode
-
- @subsubsection QuestListener QuestListener
- 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.
-
- Here is an example of the usage of @ref orxonox::QuestListener "QuestListeners" in XML:
- @code
- <BaseObject> // The object that should react to the status change of a Quest.
- <events>
- <function> // Where function is the method of the object that schould be executed. Normally this would be visibility or activity.
- <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).
- </function>
- </events>
- </BaseObject>
- @endcode
-
- 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.
-
- @subsection PuttingTheQuestsInTheGameWorld Putting the Quests in the game world
- 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".
-
- @subsubsection QuestEffectBeacon QuestEffectBeacon
- 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".
-
- Creating a @ref orxonox::QuestEffectBeacon "QuestEffectBeacon" in XML goes as follows:
- @code
- <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.
- <effects>
- <QuestEffect /> //A list of QuestEffects, invoked when the QuestEffectBeacon is executed, see QuestEffect for the full XML representation.
- ...
- <QuestEffect />
- </effects>
- <events>
- <execute>
- <EventListener event=eventIdString />
- </execute>
- </events>
- <attached>
- <PlayerTrigger name=eventIdString /> //A PlayerTrigger triggering the execution of the QuestEffectBeacon.
- </attached>
- </QuestEffectBeacon>
- @endcode
-
- 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".
-
- 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.
-
- @section SampleQuest Sample quest
- 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.
-*/
-
-/**
- @defgroup QuestEffects Effects
- @ingroup Questsystem
-
- 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.
-*/
Copied: code/branches/dockingsystem/doc/api/groups/Questsystem.dox (from rev 8193, code/trunk/doc/api/groups/Questsystem.dox)
===================================================================
--- code/branches/dockingsystem/doc/api/groups/Questsystem.dox (rev 0)
+++ code/branches/dockingsystem/doc/api/groups/Questsystem.dox 2011-04-06 10:07:29 UTC (rev 8194)
@@ -0,0 +1,197 @@
+/**
+ @addtogroup Questsystem Questsystem
+ @ingroup Modules
+
+ 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.
+
+ @section QuestsystemTechnicalDetails Technical details
+ 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).
+ @image html questsystem.png
+
+ @section CreatingQuests Creating Quests
+
+ @subsection CreatingTheQuestHierarchy Creating the Quest-Hierarchy
+ 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.
+
+ @subsubsection LocalQuest LocalQuest
+ 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.
+
+ Creating a @ref orxonox::LocalQuest "LocalQuest" in XML goes as follows:
+ @code
+ <LocalQuest id="questId">
+ <QuestDescription title="Title" description="Description." /> //The description of the quest.
+ <subquests>
+ <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.
+ ...
+ <Quest id="questIdn" />
+ </subquests>
+ <hints>
+ <QuestHint id="hintId1" /> //A list of n QuestHints, see QuestHint for the full XML representation of those.
+ ...
+ <QuestHint id="hintIdn" />
+ </hints>
+ <fail-effects>
+ <QuestEffect /> //A list of QuestEffects, invoked when the Quest is failed, see QuestEffect for the full XML representation.
+ ...
+ <QuestEffect />
+ </fail-effects>
+ <complete-effects>
+ <QuestEffect /> //A list of QuestEffects, invoked when the Quest is completed, see QuestEffect for the full XML representation.
+ ...
+ <QuestEffect />
+ </complete-effects>
+ </LocalQuest>
+ @endcode
+
+ @subsubsection GlobalQuest GlobalQuest
+ @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.
+
+ Creating a @ref orxonox::GlobalQuest "GlobalQuest" in XML goes as follows:
+ @code
+ <GlobalQuest id="questId">
+ <QuestDescription title="Title" description="Description." /> //The description of the quest.
+ <subquests>
+ <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.
+ ...
+ <Quest id="questIdn" />
+ </subquests>
+ <hints>
+ <QuestHint id="hintId1" /> //A list of n QuestHints, see QuestHint for the full XML representation of those.
+ ...
+ <QuestHint id="hintIdn" />
+ </hints>
+ <fail-effects>
+ <QuestEffect /> //A list of QuestEffects, invoked on all players possessing this quest, when the Quest is failed, see QuestEffect for the full XML representation.
+ ...
+ <QuestEffect />
+ </fail-effects>
+ <complete-effects>
+ <QuestEffect /> //A list of QuestEffects, invoked on all players possessing this quest, when the Quest is completed, see QuestEffect for the full XML representation.
+ ...
+ <QuestEffect />
+ </complete-effects>
+ <reward-effects>
+ <QuestEffect /> //A list of QuestEffects, invoked on the player completing this quest. See QuestEffect for the full XML representation.
+ ...
+ <QuestEffect />
+ </reward-effects>
+ </GlobalQuest>
+ @endcode
+
+ 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.
+
+ @subsubsection QuestHint QuestHint
+ @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".
+
+ Creating a @ref orxonox::QuestHint "QuestHint" in XML goes as follows:
+ @code
+ <QuestHint id="hintId">
+ <QuestDesctription title="" description="" />
+ </QuestHint>
+ @endcode
+
+ @subsubsection QuestDescription QuestDescription
+ 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.
+
+ Creating a @ref orxonox::QuestDescription "QuestDescription" in XML goes as follows:
+ @code
+ <QuestDescription title="Title" description="Description Text" failMessage="You fail." completeMessage="You win!" />
+ @endcode
+
+ @subsection CreatingSideEffects Creating side effects
+ @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).
+
+ @subsubsection QuestEffect QuestEffect
+ 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.
+
+ 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.
+
+ @paragraph AddQuest AddQuest
+ This @ref orxonox::QuestEffect "QuestEffect" adds (respectively starts) a @ref orxonox::Quest "Quest" (identified by the given questId) to the player.
+ @code
+ <AddQuest questId="id" /> //Where id identifies the Quest that should be added.
+ @endcode
+
+ @paragraph FailQuest FailQuest
+ This @ref orxonox::QuestEffect "QuestEffect" fails a @ref orxonox::Quest "Quest" (identified by the given questId) for the player.
+ @code
+ <FailQuest questId="id" /> //Where id identifies the Quest that should be added.
+ @endcode
+
+ @paragraph CompleteQuest CompleteQuest
+ This @ref orxonox::QuestEffect "QuestEffect" completes a @ref orxonox::Quest "Quest" (identified by the given questId) for the player.
+ @code
+ <CompleteQuest questId="id" /> //Where id identifies the Quest that should be added.
+ @endcode
+
+ @paragraph AddQuestHint AddQuestHint
+ 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.
+ @code
+ <AddQuestHint hintId="id" /> //Where id identifies the QuestHint that should be added.
+ @endcode
+
+ @paragraph AddReward AddReward
+ 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".
+ @code
+ <AddReward>
+ <Rewardable /> //A list of Rewardable objects to be rewarded the player, see the specific Rewardables for their respective XML representations.
+ ...
+ <Rewardable />
+ </AddReward>
+ @endcode
+
+ @subsubsection QuestListener QuestListener
+ 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.
+
+ Here is an example of the usage of @ref orxonox::QuestListener "QuestListeners" in XML:
+ @code
+ <BaseObject> // The object that should react to the status change of a Quest.
+ <events>
+ <function> // Where function is the method of the object that schould be executed. Normally this would be visibility or activity.
+ <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).
+ </function>
+ </events>
+ </BaseObject>
+ @endcode
+
+ 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.
+
+ @subsection PuttingTheQuestsInTheGameWorld Putting the Quests in the game world
+ 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".
+
+ @subsubsection QuestEffectBeacon QuestEffectBeacon
+ 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".
+
+ Creating a @ref orxonox::QuestEffectBeacon "QuestEffectBeacon" in XML goes as follows:
+ @code
+ <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.
+ <effects>
+ <QuestEffect /> //A list of QuestEffects, invoked when the QuestEffectBeacon is executed, see QuestEffect for the full XML representation.
+ ...
+ <QuestEffect />
+ </effects>
+ <events>
+ <execute>
+ <EventListener event=eventIdString />
+ </execute>
+ </events>
+ <attached>
+ <PlayerTrigger name=eventIdString /> //A PlayerTrigger triggering the execution of the QuestEffectBeacon.
+ </attached>
+ </QuestEffectBeacon>
+ @endcode
+
+ 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".
+
+ 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.
+
+ @section SampleQuest Sample quest
+ 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.
+*/
+
+/**
+ @defgroup QuestEffects Effects
+ @ingroup Questsystem
+
+ 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.
+*/
Deleted: code/branches/dockingsystem/doc/api/groups/Triggers.dox
===================================================================
--- code/trunk/doc/api/groups/Triggers.dox 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/doc/api/groups/Triggers.dox 2011-04-06 10:07:29 UTC (rev 8194)
@@ -1,79 +0,0 @@
-/**
- @addtogroup Triggers Triggers
- @ingroup Objects
-
- Triggers are objects which react to certain events. They can be combined and used as simple overlay logic in levels.
-
- @defgroup NormalTrigger Trigger
- @ingroup Triggers
-
- @defgroup MultiTrigger MultiTrigger
- @ingroup Triggers
-
- @ref orxonox::MultiTrigger "MultiTriggers" are (as they are @ref orxonox::TriggerBase "Triggers") objects which react to certain events. They offer all the functionality that the common @ref orxonox::Trigger "Triggers" do with one significant difference. The common @ref orxonox::Trigger "Trigger" has just one state, it can either be <em>triggered</em> or <em>not triggered</em>, it doesn't discriminate between who's triggering (or not triggering) it. A @ref orxonox::MultiTrigger "MultiTrigger", on the other hand, has a distinct state (<em>triggered</em> or <em>not triggered</em>) for each entity that is defined as being able to trigger said @ref orxonox::MultiTrigger "MultiTrigger".
-
- This difference becomes significant, when, for example, you want a @ref orxonox::DistanceTrigger "DistanceTrigger" to trigger a @ref orxonox::QuestEffectBeacon "QuestEffectBeacon" to hand out a @ref orxonox::Quest "Quest" to any @ref orxonox::Pawn "Pawn" that enters its range. With a simple @ref orxonox::DistanceTrigger "DistanceTrigger" (as opposed to the more complex @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger") the first @ref orxonox::Pawn "Pawn" to be in range would trigger it an receive the @ref orxonox::Quest "Quest", however if a second @ref orxonox::Pawn "Pawn" would enter the range, while the first @ref orxonox::Pawn "Pawn" still is in the range nothing would happen and even after the first @ref orxonox::Pawn "Pawn" left nothing would happen, since the whole time the @ref orxonox::DistanceTrigger "DistanceTrigger" would just be triggered. In contrast with a @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" the first @ref orxonox::Pawn "Pawn" would enter the range and the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" would have the state <em>triggered</em> for this exact @ref orxonox::Pawn "Pawn" (but for none else) and thus the @ref orxonox::Pawn "Pawn" would receive the @ref orxonox::Quest "Quest" and when the second @ref orxonox::Pawn "Pawn" enters the range the state of the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" for that second @ref orxonox::Pawn "Pawn" would change to <em>triggered</em> and it would receive the @ref orxonox::Quest "Quest" as well.
-
- @section WhenToUseMultiTriggers When to use MultiTriggers
- Consequentially you would use @ref orxonox::MultiTrigger "MultiTriggers" (instead of common @ref orxonox::Trigger "Triggers"), when it is important that the trigger has different states for each triggering entity and when that fact is essential in the concept of the object that reacts to the triggering. However you should not just use @ref orxonox::MultiTrigger "MultiTrigger" instead of @ref orxonox::Trigger "Trigger", when in doubt, because @ref orxonox::MultiTrigger "MultiTrigger" produces significantly more overhead than @ref orxonox::Trigger "Trigger" due to the added complexity.
-
- @section HowToUseMultiTriggers How to use MultiTriggers
- ...
-
- @section MultiTriggerTechnicalDetails Technical Details
- A common @ref orxonox::Trigger "Trigger" is an object that can either be <em>active</em> or <em>inactive</em>, with a specified behavior how to switch between the two. A @ref orxonox::MultiTrigger "MultiTrigger" generalizes that behavior for multiple objects triggering the trigger. A @ref orxonox::MultiTrigger "MultiTrigger" can be <em>active</em> or <em>inactive</em> for any object triggering it, with the state for each object being completely independent of the state for all other objects. Each time a switch occurs an @ref orxonox::Event "Event" is fired, with a @ref orxonox::MultiTriggerContainer "MultiTriggerContainer" as the originator, containing a pointer to the @ref orxonox::MultiTrigger "MultiTrigger" that caused the @ref orxonox::Event "Event" and a pointer to the object that caused the trigger to change it's activity. This way the entity that reacts to the @ref orxonox::MultiTrigger "MultiTrigger" triggering receives the information it needs about the entity that triggered the @ref orxonox::MultiTrigger "MultiTrigger".
-
- Also, just as with all triggers, @ref orxonox::MultiTrigger "MultiTriggers" can be nested (event with triggers other than @ref orxonox::MultiTrigger "MultiTriggers").
- @code
- <MultiTrigger switch="true" delay="2">
- <DistanceMultiTrigger position="100,0,0" distance="80" />
- <EventTrigger ... />
- </Trigger>
- @endcode
-
- @ref orxonox::MultiTrigger "MultiTriggers" also allow for additional complexity which can be added through the choice of the parameters (some of which are also present in the common @ref orxonox::Trigger "Trigger") explained (briefly) below.
- But first it is important to understand a small implementational detail. There is a distinction between the @ref orxonox::MultiTrigger "MultiTrigger" being triggered (there is the state <em>triggered</em> for that) and the @ref orxonox::MultiTrigger "MultiTrigger" being active (for that is the state <em>activity</em>). From the outside only the <em>activity</em> is visible (and has above been referred to as <em>triggered</em> for the sake of comprehensibility). The state <em>triggered</em> tells us whether the trigger is actually triggered, but it could pretend (for some reason, some of which we will see shortly) to be <em>triggered</em> to the outside, while it in fact isn't (but it would then be <em>active</em>). The standard behavior is, that the <em>activity</em> changes, when the @ref orxonox::MultiTrigger "MultiTrigger" transits from being triggered to not being triggered or the other way around. So to the inside a @ref orxonox::MultiTrigger "MultiTrigger" being <em>active</em> is synonymous to the @ref orxonox::MultiTrigger "MultiTrigger" being <em>triggered</em> to the outside.
-
- The parameters of the @ref orxonox::MultiTrigger "MultiTrigger" are:
- - @b delay The delay is the time in seconds, that the trigger waits until it reacts (i.e. changes it's state) to the triggering condition being fulfilled. Internally this is handled by a state queue coupled with a counter, for each state that is delayed. The state becomes <em>active</em> when the counter runs out. This allows the @ref orxonox::MultiTrigger "MultiTrigger" to work even if the delay changes at runtime. However if the delay changes it only affects newly arriving states not the ones already in the queue. The default is <code>0</code>.
- - @b switch Switch is a boolean, if <code>true</code> the @ref orxonox::MultiTrigger "MultiTrigger" is in <em>switch-mode</em>, meaning, that the <em>activity</em> changes only when the trigger is triggered, not when it is un-triggered (Just like a light switch does). This means, that in <em>switch-mode</em> the <em>activity</em> only changes, when the trigger changes from not being triggered to being triggered but not the other way around. The default is <code>false</code>.
- - @b stayActive Stay active is also a boolean, if <code>true</code> the @ref orxonox::MultiTrigger "MultiTrigger" stays active after it has been activated as many times as specified by the parameter <em>activations</em>. In essence this means, that after the last time it is activated it cannot be deactivated. The default is <code>false</code>.
- - @b activations Activations is the number of times the @ref orxonox::MultiTrigger "MultiTrigger" can be activated until the trigger can't be triggered anymore. The default is <code>-1</code>, which denotes infinity.
- - @b invert Invert is a boolean, if <code>true</code> the @ref orxonox::MultiTrigger "MultiTrigger" is in <em>invert-mode</em>, meaning, that if the triggering condition is fulfilled the @ref orxonox::MultiTrigger "MultiTrigger" will have the state <em>not triggered</em> and and if the condition is not fulfilled it will have the state <em>triggered</em>. In short it inverts the behavior of the @ref orxonox::MultiTrigger "MultiTrigger". The default is <code>false</code>.
- - @b simultaneousTriggerers The number of simultaneous triggerers limits the number of objects that are allowed to trigger the @ref orxonox::MultiTrigger "MultiTrigger" at the same time. Or more precisely, the number of distinct objects the @ref orxonox::MultiTrigger "MultiTrigger" has positive <em>triggered</em> states for, at each point in time. The default is <code>-1</code>, which denotes infinity.
- - @b mode The mode describes how the @ref orxonox::MultiTrigger "MultiTrigger" acts in relation to all the triggers (its children), that are appended to it. There are 3 modes: <em>and</em>, meaning that the @ref orxonox::MultiTrigger "MultiTrigger" can only be triggered if all the appended triggers are active. <em>or</em>, meaning that the @ref orxonox::MultiTrigger "MultiTrigger" can only be triggered if at least one of the appended triggers is active. And <em>xor</em>, meaning that the @ref orxonox::MultiTrigger "MultiTrigger" can only be triggered if one and only one appended trigger is active. Note, that I wrote 'can only be active', that implies, that there is an additional condition to the <em>activity</em> of the @ref orxonox::MultiTrigger "MultiTrigger" and that is the fulfillment of the triggering condition (the @ref orxonox::MultiTrigger "MultiTrigger" class itself doesn't have one, but all derived classes should). Also bear in mind, that the <em>activity</em> of a @ref orxonox::MultiTrigger "MultiTrigger" is still coupled to the object that triggered it. The default is <em>and</em>.
- - @b broadcast Broadcast is a boolean, if <code>true</code> the @ref orxonox::MultiTrigger "MultiTrigger" is in <em>broadcast-mode</em>, meaning, that all trigger events that are caused by no originator (originator is <code>NULL</code>) are broadcast as having come from every possible originator, or more precisely as having come from all objects that are specified targets of this @ref orxonox::MultiTrigger "MultiTrigger". The default is <code>false</code>.
- - @b target The target describes the kind of objects that are allowed to trigger this @ref orxonox::MultiTrigger "MultiTrigger". The parameter has to be set to the class name of the class that is allowed to trigger the @ref orxonox::MultiTrigger "MultiTrigger". The default is <code>Pawn</code>.
-
- @subsection Sub-typesOfMultiTriggers Sub-types of MultiTriggers
-
- @subsubsection EventMultiTrigger EventMultiTrigger
- An @ref orxonox::EventMultiTrigger "EventMultiTrigger" can either be used to broadcast an @ref orxonox::Event "Event" that does not come from a @ref orxonox::MultiTrigger "MultiTrigger" to all entities that are targets of the @ref orxonox::EventMultiTrigger "EventMultiTrigger" or, more in line with its prototype the @ref orxonox::EventTrigger "EventTrigger", to be triggered for an entity when an @ref orxonox::Event "Event" that was caused by an entity of the same type is captured.
-
- A common usage could look like this:
- @code
- <EventMultiTrigger invert="true" delay="1">
- <events>
- <trigger>
- <MultiTrigger ... />
- <Trigger ... />
- </trigger>
- </events>
- </EventMultiTrigger>
- @endcode
-
- @subsubsection DistanceMultiTrigger DistanceMultiTrigger
- A @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" is the MultiTrigger equivalent of the @ref orxonox::DistanceTrigger "DistanceTrigger" and works just the same way. It triggers (now separately for each object triggering it, since it's a @ref orxonox::MultiTrigger "MultiTrigger") whenever an object that is a target of the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" is in the specified range.
-
- Two additional parameters can be specified for the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" are the <em>distance</em>, which defines the maximum distance at which an object still triggers the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger", and the <em>targetname</em>. Setting the <em>targename</em> puts the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" in <em>single-target mode</em>. In this mode the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" can only be triggered by objects that have a @ref orxonox::DistanceTriggerBeacon "DistanceTriggerBeacon" with the name specified by <em>targetname</em> directly attached. For the <em>single-target mode</em> to work the target of the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" has to be set to <code>DistanceTriggerBeacon</code>.
-
- A common usage (without @ref orxonox::DistanceTriggerBeacon "DistanceTriggerBeacon") would look like this:
- @code
- <DistanceMultiTrigger position="0,0,0" switch="true" target="Pawn" distance="20" />
- @endcode
-
- With @ref orxonox::DistanceTriggerBeacon "DistanceTriggerBeacon" it would look like this:
- @code
- <DistanceMultiTrigger position="0,0,0" target="DistanceMultiTrigger" targetname="beacon1" distance="30" />
- @endcode
-*/
Copied: code/branches/dockingsystem/doc/api/groups/Triggers.dox (from rev 8193, code/trunk/doc/api/groups/Triggers.dox)
===================================================================
--- code/branches/dockingsystem/doc/api/groups/Triggers.dox (rev 0)
+++ code/branches/dockingsystem/doc/api/groups/Triggers.dox 2011-04-06 10:07:29 UTC (rev 8194)
@@ -0,0 +1,79 @@
+/**
+ @addtogroup Triggers Triggers
+ @ingroup Objects
+
+ Triggers are objects which react to certain events. They can be combined and used as simple overlay logic in levels.
+
+ @defgroup NormalTrigger Trigger
+ @ingroup Triggers
+
+ @defgroup MultiTrigger MultiTrigger
+ @ingroup Triggers
+
+ @ref orxonox::MultiTrigger "MultiTriggers" are (as they are @ref orxonox::TriggerBase "Triggers") objects which react to certain events. They offer all the functionality that the common @ref orxonox::Trigger "Triggers" do with one significant difference. The common @ref orxonox::Trigger "Trigger" has just one state, it can either be <em>triggered</em> or <em>not triggered</em>, it doesn't discriminate between who's triggering (or not triggering) it. A @ref orxonox::MultiTrigger "MultiTrigger", on the other hand, has a distinct state (<em>triggered</em> or <em>not triggered</em>) for each entity that is defined as being able to trigger said @ref orxonox::MultiTrigger "MultiTrigger".
+
+ This difference becomes significant, when, for example, you want a @ref orxonox::DistanceTrigger "DistanceTrigger" to trigger a @ref orxonox::QuestEffectBeacon "QuestEffectBeacon" to hand out a @ref orxonox::Quest "Quest" to any @ref orxonox::Pawn "Pawn" that enters its range. With a simple @ref orxonox::DistanceTrigger "DistanceTrigger" (as opposed to the more complex @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger") the first @ref orxonox::Pawn "Pawn" to be in range would trigger it an receive the @ref orxonox::Quest "Quest", however if a second @ref orxonox::Pawn "Pawn" would enter the range, while the first @ref orxonox::Pawn "Pawn" still is in the range nothing would happen and even after the first @ref orxonox::Pawn "Pawn" left nothing would happen, since the whole time the @ref orxonox::DistanceTrigger "DistanceTrigger" would just be triggered. In contrast with a @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" the first @ref orxonox::Pawn "Pawn" would enter the range and the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" would have the state <em>triggered</em> for this exact @ref orxonox::Pawn "Pawn" (but for none else) and thus the @ref orxonox::Pawn "Pawn" would receive the @ref orxonox::Quest "Quest" and when the second @ref orxonox::Pawn "Pawn" enters the range the state of the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" for that second @ref orxonox::Pawn "Pawn" would change to <em>triggered</em> and it would receive the @ref orxonox::Quest "Quest" as well.
+
+ @section WhenToUseMultiTriggers When to use MultiTriggers
+ Consequentially you would use @ref orxonox::MultiTrigger "MultiTriggers" (instead of common @ref orxonox::Trigger "Triggers"), when it is important that the trigger has different states for each triggering entity and when that fact is essential in the concept of the object that reacts to the triggering. However you should not just use @ref orxonox::MultiTrigger "MultiTrigger" instead of @ref orxonox::Trigger "Trigger", when in doubt, because @ref orxonox::MultiTrigger "MultiTrigger" produces significantly more overhead than @ref orxonox::Trigger "Trigger" due to the added complexity.
+
+ @section HowToUseMultiTriggers How to use MultiTriggers
+ ...
+
+ @section MultiTriggerTechnicalDetails Technical Details
+ A common @ref orxonox::Trigger "Trigger" is an object that can either be <em>active</em> or <em>inactive</em>, with a specified behavior how to switch between the two. A @ref orxonox::MultiTrigger "MultiTrigger" generalizes that behavior for multiple objects triggering the trigger. A @ref orxonox::MultiTrigger "MultiTrigger" can be <em>active</em> or <em>inactive</em> for any object triggering it, with the state for each object being completely independent of the state for all other objects. Each time a switch occurs an @ref orxonox::Event "Event" is fired, with a @ref orxonox::MultiTriggerContainer "MultiTriggerContainer" as the originator, containing a pointer to the @ref orxonox::MultiTrigger "MultiTrigger" that caused the @ref orxonox::Event "Event" and a pointer to the object that caused the trigger to change it's activity. This way the entity that reacts to the @ref orxonox::MultiTrigger "MultiTrigger" triggering receives the information it needs about the entity that triggered the @ref orxonox::MultiTrigger "MultiTrigger".
+
+ Also, just as with all triggers, @ref orxonox::MultiTrigger "MultiTriggers" can be nested (event with triggers other than @ref orxonox::MultiTrigger "MultiTriggers").
+ @code
+ <MultiTrigger switch="true" delay="2">
+ <DistanceMultiTrigger position="100,0,0" distance="80" />
+ <EventTrigger ... />
+ </Trigger>
+ @endcode
+
+ @ref orxonox::MultiTrigger "MultiTriggers" also allow for additional complexity which can be added through the choice of the parameters (some of which are also present in the common @ref orxonox::Trigger "Trigger") explained (briefly) below.
+ But first it is important to understand a small implementational detail. There is a distinction between the @ref orxonox::MultiTrigger "MultiTrigger" being triggered (there is the state <em>triggered</em> for that) and the @ref orxonox::MultiTrigger "MultiTrigger" being active (for that is the state <em>activity</em>). From the outside only the <em>activity</em> is visible (and has above been referred to as <em>triggered</em> for the sake of comprehensibility). The state <em>triggered</em> tells us whether the trigger is actually triggered, but it could pretend (for some reason, some of which we will see shortly) to be <em>triggered</em> to the outside, while it in fact isn't (but it would then be <em>active</em>). The standard behavior is, that the <em>activity</em> changes, when the @ref orxonox::MultiTrigger "MultiTrigger" transits from being triggered to not being triggered or the other way around. So to the inside a @ref orxonox::MultiTrigger "MultiTrigger" being <em>active</em> is synonymous to the @ref orxonox::MultiTrigger "MultiTrigger" being <em>triggered</em> to the outside.
+
+ The parameters of the @ref orxonox::MultiTrigger "MultiTrigger" are:
+ - @b delay The delay is the time in seconds, that the trigger waits until it reacts (i.e. changes it's state) to the triggering condition being fulfilled. Internally this is handled by a state queue coupled with a counter, for each state that is delayed. The state becomes <em>active</em> when the counter runs out. This allows the @ref orxonox::MultiTrigger "MultiTrigger" to work even if the delay changes at runtime. However if the delay changes it only affects newly arriving states not the ones already in the queue. The default is <code>0</code>.
+ - @b switch Switch is a boolean, if <code>true</code> the @ref orxonox::MultiTrigger "MultiTrigger" is in <em>switch-mode</em>, meaning, that the <em>activity</em> changes only when the trigger is triggered, not when it is un-triggered (Just like a light switch does). This means, that in <em>switch-mode</em> the <em>activity</em> only changes, when the trigger changes from not being triggered to being triggered but not the other way around. The default is <code>false</code>.
+ - @b stayActive Stay active is also a boolean, if <code>true</code> the @ref orxonox::MultiTrigger "MultiTrigger" stays active after it has been activated as many times as specified by the parameter <em>activations</em>. In essence this means, that after the last time it is activated it cannot be deactivated. The default is <code>false</code>.
+ - @b activations Activations is the number of times the @ref orxonox::MultiTrigger "MultiTrigger" can be activated until the trigger can't be triggered anymore. The default is <code>-1</code>, which denotes infinity.
+ - @b invert Invert is a boolean, if <code>true</code> the @ref orxonox::MultiTrigger "MultiTrigger" is in <em>invert-mode</em>, meaning, that if the triggering condition is fulfilled the @ref orxonox::MultiTrigger "MultiTrigger" will have the state <em>not triggered</em> and and if the condition is not fulfilled it will have the state <em>triggered</em>. In short it inverts the behavior of the @ref orxonox::MultiTrigger "MultiTrigger". The default is <code>false</code>.
+ - @b simultaneousTriggerers The number of simultaneous triggerers limits the number of objects that are allowed to trigger the @ref orxonox::MultiTrigger "MultiTrigger" at the same time. Or more precisely, the number of distinct objects the @ref orxonox::MultiTrigger "MultiTrigger" has positive <em>triggered</em> states for, at each point in time. The default is <code>-1</code>, which denotes infinity.
+ - @b mode The mode describes how the @ref orxonox::MultiTrigger "MultiTrigger" acts in relation to all the triggers (its children), that are appended to it. There are 3 modes: <em>and</em>, meaning that the @ref orxonox::MultiTrigger "MultiTrigger" can only be triggered if all the appended triggers are active. <em>or</em>, meaning that the @ref orxonox::MultiTrigger "MultiTrigger" can only be triggered if at least one of the appended triggers is active. And <em>xor</em>, meaning that the @ref orxonox::MultiTrigger "MultiTrigger" can only be triggered if one and only one appended trigger is active. Note, that I wrote 'can only be active', that implies, that there is an additional condition to the <em>activity</em> of the @ref orxonox::MultiTrigger "MultiTrigger" and that is the fulfillment of the triggering condition (the @ref orxonox::MultiTrigger "MultiTrigger" class itself doesn't have one, but all derived classes should). Also bear in mind, that the <em>activity</em> of a @ref orxonox::MultiTrigger "MultiTrigger" is still coupled to the object that triggered it. The default is <em>and</em>.
+ - @b broadcast Broadcast is a boolean, if <code>true</code> the @ref orxonox::MultiTrigger "MultiTrigger" is in <em>broadcast-mode</em>, meaning, that all trigger events that are caused by no originator (originator is <code>NULL</code>) are broadcast as having come from every possible originator, or more precisely as having come from all objects that are specified targets of this @ref orxonox::MultiTrigger "MultiTrigger". The default is <code>false</code>.
+ - @b target The target describes the kind of objects that are allowed to trigger this @ref orxonox::MultiTrigger "MultiTrigger". The parameter has to be set to the class name of the class that is allowed to trigger the @ref orxonox::MultiTrigger "MultiTrigger". The default is <code>Pawn</code>.
+
+ @subsection Sub-typesOfMultiTriggers Sub-types of MultiTriggers
+
+ @subsubsection EventMultiTrigger EventMultiTrigger
+ An @ref orxonox::EventMultiTrigger "EventMultiTrigger" can either be used to broadcast an @ref orxonox::Event "Event" that does not come from a @ref orxonox::MultiTrigger "MultiTrigger" to all entities that are targets of the @ref orxonox::EventMultiTrigger "EventMultiTrigger" or, more in line with its prototype the @ref orxonox::EventTrigger "EventTrigger", to be triggered for an entity when an @ref orxonox::Event "Event" that was caused by an entity of the same type is captured.
+
+ A common usage could look like this:
+ @code
+ <EventMultiTrigger invert="true" delay="1">
+ <events>
+ <trigger>
+ <MultiTrigger ... />
+ <Trigger ... />
+ </trigger>
+ </events>
+ </EventMultiTrigger>
+ @endcode
+
+ @subsubsection DistanceMultiTrigger DistanceMultiTrigger
+ A @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" is the MultiTrigger equivalent of the @ref orxonox::DistanceTrigger "DistanceTrigger" and works just the same way. It triggers (now separately for each object triggering it, since it's a @ref orxonox::MultiTrigger "MultiTrigger") whenever an object that is a target of the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" is in the specified range.
+
+ Two additional parameters can be specified for the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" are the <em>distance</em>, which defines the maximum distance at which an object still triggers the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger", and the <em>targetname</em>. Setting the <em>targename</em> puts the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" in <em>single-target mode</em>. In this mode the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" can only be triggered by objects that have a @ref orxonox::DistanceTriggerBeacon "DistanceTriggerBeacon" with the name specified by <em>targetname</em> directly attached. For the <em>single-target mode</em> to work the target of the @ref orxonox::DistanceMultiTrigger "DistanceMultiTrigger" has to be set to <code>DistanceTriggerBeacon</code>.
+
+ A common usage (without @ref orxonox::DistanceTriggerBeacon "DistanceTriggerBeacon") would look like this:
+ @code
+ <DistanceMultiTrigger position="0,0,0" switch="true" target="Pawn" distance="20" />
+ @endcode
+
+ With @ref orxonox::DistanceTriggerBeacon "DistanceTriggerBeacon" it would look like this:
+ @code
+ <DistanceMultiTrigger position="0,0,0" target="DistanceMultiTrigger" targetname="beacon1" distance="30" />
+ @endcode
+*/
Modified: code/branches/dockingsystem/src/libraries/core/Loader.cc
===================================================================
--- code/branches/dockingsystem/src/libraries/core/Loader.cc 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/libraries/core/Loader.cc 2011-04-06 10:07:29 UTC (rev 8194)
@@ -143,6 +143,8 @@
A ClassTreeMask, which defines which types of classes are loaded and which aren't.
@param verbose
Whether the loader is verbose (prints its progress in a low output level) or not.
+ @param bRemoveLuaTags
+ If true lua tags are just ignored and removed. The default is false.
@return
Returns true if successful.
*/
Modified: code/branches/dockingsystem/src/libraries/network/Host.cc
===================================================================
--- code/branches/dockingsystem/src/libraries/network/Host.cc 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/libraries/network/Host.cc 2011-04-06 10:07:29 UTC (rev 8194)
@@ -74,6 +74,7 @@
* This function is used to add an enetpacket to be sent to another peer
* @param packet Packet to be added
* @param clientID ID of the client the packet should be sent to
+ * @param channelID ID of the channel.
* @return success?
*/
void Host::addPacket(ENetPacket *packet, int clientID, uint8_t channelID)
Modified: code/branches/dockingsystem/src/libraries/network/MasterServerComm.h
===================================================================
--- code/branches/dockingsystem/src/libraries/network/MasterServerComm.h 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/libraries/network/MasterServerComm.h 2011-04-06 10:07:29 UTC (rev 8194)
@@ -88,6 +88,7 @@
int sendRequest( std::string data );
/** \param callback The callback function to call with data received.
+ * \param delayms Delay in milliseconds.
* \return 0 for success, other for error
*
* Poll the master server for new data and act accordingly */
Modified: code/branches/dockingsystem/src/modules/designtools/ScreenshotManager.cc
===================================================================
--- code/branches/dockingsystem/src/modules/designtools/ScreenshotManager.cc 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/designtools/ScreenshotManager.cc 2011-04-06 10:07:29 UTC (rev 8194)
@@ -60,10 +60,6 @@
/**
@brief
Creates a screenshot with the given camera.
- @param camera
- Pointer to the camera "looking at" the scene of interest
- @param fileName
- the filename of the screenshot file.
*/
void ScreenshotManager::makeScreenshot() const
{
Modified: code/branches/dockingsystem/src/modules/objects/triggers/MultiTrigger.cc
===================================================================
--- code/branches/dockingsystem/src/modules/objects/triggers/MultiTrigger.cc 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/objects/triggers/MultiTrigger.cc 2011-04-06 10:07:29 UTC (rev 8194)
@@ -115,7 +115,7 @@
this->broadcast(false);
}
- // Check if the object is active (this is NOT MultiTrigger::isActive()!)
+ // Check if the object is active (this is NOT MultiTrigger::isActive()!), it is whether the MultiTrigger actually does anything, ever.
if (!this->BaseObject::isActive())
return;
@@ -204,7 +204,7 @@
if(bActive == true)
{
// If the MultiTrigger has not exceeded its remaining activations.
- if(this->remainingActivations_ > 0)
+ if(this->hasRemainingActivations())
{
this->active_.insert(state->originator);
if(this->remainingActivations_ != INF_s)
@@ -217,7 +217,7 @@
else
{
// If the MultiTrigger doesn't stay active or hasn't' exceeded its remaining activations.
- if(!this->getStayActive() || this->remainingActivations_ > 0)
+ if(!this->getStayActive() || this->hasRemainingActivations())
this->active_.erase(state->originator);
else
bFire = false;
Modified: code/branches/dockingsystem/src/modules/objects/triggers/TriggerBase.h
===================================================================
--- code/branches/dockingsystem/src/modules/objects/triggers/TriggerBase.h 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/objects/triggers/TriggerBase.h 2011-04-06 10:07:29 UTC (rev 8194)
@@ -184,6 +184,9 @@
*/
inline void setActivations(int activations)
{ if(activations >= 0 || activations == INF_s) this->remainingActivations_ = activations; }
+
+ inline bool hasRemainingActivations(void)
+ { return this->remainingActivations_ == INF_s || this->remainingActivations_ > 0; }
/**
@brief Adds the parent of a MultiTrigger.
Modified: code/branches/dockingsystem/src/modules/overlays/hud/CMakeLists.txt
===================================================================
--- code/branches/dockingsystem/src/modules/overlays/hud/CMakeLists.txt 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/overlays/hud/CMakeLists.txt 2011-04-06 10:07:29 UTC (rev 8194)
@@ -16,4 +16,5 @@
GametypeFadingMessage.cc
LastManStandingInfos.cc
PauseNotice.cc
+ LastTeamStandingInfos.cc
)
Modified: code/branches/dockingsystem/src/modules/overlays/hud/GametypeStatus.cc
===================================================================
--- code/branches/dockingsystem/src/modules/overlays/hud/GametypeStatus.cc 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/overlays/hud/GametypeStatus.cc 2011-04-06 10:07:29 UTC (rev 8194)
@@ -35,6 +35,7 @@
#include "infos/PlayerInfo.h"
#include "worldentities/ControllableEntity.h"
#include "worldentities/pawns/Spectator.h"
+//#include "gametypes/Gametype.h"
namespace orxonox
{
@@ -49,8 +50,10 @@
{
RegisterObject(GametypeStatus);
+ //this->game_ = 0;
this->owner_ = 0;
this->bNoCaption_ = false;
+ //this->bForcedSpawn_ = false;
ModifyConsoleCommand(__CC_GametypeStatus_name, __CC_displayCaption_name).setObject(this);
}
@@ -66,6 +69,11 @@
if (this->owner_ && this->owner_->getGametypeInfo() && this->owner_->getControllableEntity())
{
+ //if (this->game_)
+ // this->bForcedSpawn_ = this->game_->getForceSpawn();
+ //else
+ // this->bForcedSpawn_ = false;
+
const GametypeInfo* gtinfo = this->owner_->getGametypeInfo();
ControllableEntity* ce = this->owner_->getControllableEntity();
@@ -86,7 +94,7 @@
{
if (gtinfo->isStartCountdownRunning())
this->setCaption(multi_cast<std::string>(static_cast<int>(ceil(gtinfo->getStartCountdown()))));
- else if (ce->isA(Class(Spectator)))
+ else if (ce->isA(Class(Spectator))/*&&(!bForcedSpawn_)*/)
this->setCaption("Press [Fire] to respawn");
else
this->setCaption("");
@@ -100,7 +108,7 @@
void GametypeStatus::changedOwner()
{
SUPER(GametypeStatus, changedOwner);
-
+ //this->game_ = orxonox_cast<Gametype*>(this->getOwner());
this->owner_ = orxonox_cast<PlayerInfo*>(this->getOwner());
}
Modified: code/branches/dockingsystem/src/modules/overlays/hud/GametypeStatus.h
===================================================================
--- code/branches/dockingsystem/src/modules/overlays/hud/GametypeStatus.h 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/overlays/hud/GametypeStatus.h 2011-04-06 10:07:29 UTC (rev 8194)
@@ -48,8 +48,10 @@
void setDisplayCaption(bool bValue); //!< Toggles whether the gametype status is displayed.
private:
+ //Gametype* game_;
PlayerInfo* owner_;
bool bNoCaption_;
+ //bool bForcedSpawn_;
};
}
Copied: code/branches/dockingsystem/src/modules/overlays/hud/LastTeamStandingInfos.cc (from rev 8193, code/trunk/src/modules/overlays/hud/LastTeamStandingInfos.cc)
===================================================================
--- code/branches/dockingsystem/src/modules/overlays/hud/LastTeamStandingInfos.cc (rev 0)
+++ code/branches/dockingsystem/src/modules/overlays/hud/LastTeamStandingInfos.cc 2011-04-06 10:07:29 UTC (rev 8194)
@@ -0,0 +1,97 @@
+/*
+ * ORXONOX - the hottest 3D action shooter ever to exist
+ * > www.orxonox.net <
+ *
+ *
+ * License notice:
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Author:
+ * Johannes Ritz
+ * Co-authors:
+ *
+ *
+ */
+
+#include "LastTeamStandingInfos.h"
+
+#include "core/CoreIncludes.h"
+#include "core/XMLPort.h"
+#include "util/Convert.h"
+#include "gametypes/LastTeamStanding.h"
+#include "infos/PlayerInfo.h"
+
+namespace orxonox
+{
+ CreateFactory(LastTeamStandingInfos);
+
+ LastTeamStandingInfos::LastTeamStandingInfos(BaseObject* creator) : OverlayText(creator)
+ {
+ RegisterObject(LastTeamStandingInfos);
+
+ this->lts_ = 0;
+ this->player_ = 0;
+ this->bShowLives_ = false;
+ this->bShowTeams_ = false;
+ }
+
+ LastTeamStandingInfos::~LastTeamStandingInfos()
+ {
+ }
+
+ void LastTeamStandingInfos::XMLPort(Element& xmlelement, XMLPort::Mode mode)
+ {
+ SUPER(LastTeamStandingInfos, XMLPort, xmlelement, mode);
+
+ XMLPortParam(LastTeamStandingInfos, "showlives", setShowLives, getShowLives, xmlelement, mode).defaultValues(false);
+ XMLPortParam(LastTeamStandingInfos, "showTeams", setShowTeams, getShowTeams, xmlelement, mode).defaultValues(false);
+ }
+
+ void LastTeamStandingInfos::tick(float dt)
+ {
+ SUPER(LastTeamStandingInfos, tick, dt);
+
+ if (this->player_ && this->lts_)
+ {
+ if (this->bShowLives_)
+ {
+ const std::string& lives = multi_cast<std::string>(this->lts_->playerGetLives(this->player_));
+ this->setCaption(lives);
+ }
+ else if(this->bShowTeams_)
+ {
+ const std::string& Teams = multi_cast<std::string>(this->lts_->getNumTeamsAlive());
+ this->setCaption(Teams);
+ }
+ }
+ }
+
+ void LastTeamStandingInfos::changedOwner()
+ {
+ SUPER(LastTeamStandingInfos, changedOwner);
+
+ if (this->getOwner() && this->getOwner()->getGametype())
+ {
+ this->player_ = orxonox_cast<PlayerInfo*>(this->getOwner());
+ this->lts_ = orxonox_cast<LastTeamStanding*>(this->getOwner()->getGametype().get());
+ }
+ else
+ {
+ this->player_ = 0;
+ this->lts_ = 0;
+ }
+ }
+}
Copied: code/branches/dockingsystem/src/modules/overlays/hud/LastTeamStandingInfos.h (from rev 8193, code/trunk/src/modules/overlays/hud/LastTeamStandingInfos.h)
===================================================================
--- code/branches/dockingsystem/src/modules/overlays/hud/LastTeamStandingInfos.h (rev 0)
+++ code/branches/dockingsystem/src/modules/overlays/hud/LastTeamStandingInfos.h 2011-04-06 10:07:29 UTC (rev 8194)
@@ -0,0 +1,66 @@
+/*
+ * ORXONOX - the hottest 3D action shooter ever to exist
+ * > www.orxonox.net <
+ *
+ *
+ * License notice:
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Author:
+ * Johannes Ritz
+ * Co-authors:
+ *
+ *
+ */
+
+#ifndef _LastTeamStandingInfos_H__
+#define _LastTeamStandingInfos_H__
+
+#include "overlays/OverlaysPrereqs.h"
+
+#include "tools/interfaces/Tickable.h"
+#include "overlays/OverlayText.h"
+
+namespace orxonox
+{
+ class _OverlaysExport LastTeamStandingInfos : public OverlayText, public Tickable
+ {
+ public:
+ LastTeamStandingInfos(BaseObject* creator);
+ virtual ~LastTeamStandingInfos();
+
+ virtual void tick(float dt);
+ virtual void XMLPort(Element& xmlelement, XMLPort::Mode mode);
+ virtual void changedOwner();
+
+ inline void setShowLives(bool value)
+ { this->bShowLives_ = value; }
+ inline bool getShowLives() const
+ { return this->bShowLives_; }
+
+ inline void setShowTeams(bool value)
+ { this->bShowTeams_ = value; }
+ inline bool getShowTeams() const
+ { return this->bShowTeams_; }
+
+ private:
+ LastTeamStanding* lts_;
+ PlayerInfo* player_;
+ bool bShowLives_;
+ bool bShowTeams_;
+ };
+}
+#endif /* _LastTeamStandingInfos_H__ */
Modified: code/branches/dockingsystem/src/modules/pickup/Pickup.h
===================================================================
--- code/branches/dockingsystem/src/modules/pickup/Pickup.h 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/pickup/Pickup.h 2011-04-06 10:07:29 UTC (rev 8194)
@@ -80,7 +80,7 @@
@brief
The Pickup class offers (useful) base functionality for a wide range of pickups.
- Pickups ingeriting from this class can choose an activation type and a duration type.
+ Pickups inheriting from this class can choose an activation type and a duration type.
- The <b>activationType</b> deals with what happens to the Pickup as soon as it is picked up. It can either be set to <em>immediate</em>, which means that the Pickup is activated/used immediately upon being picked up. Or to <em>onUse</em>, which means, that the Pickup will be activated/used if some outside entity (most commonly the player through the PickupInventory) decides to use it. Default is <em>immediate</em>.
- The <b>durationType</b> deals with whether the Pickup has a continuous effect or whether its effect is focused on a singular instant. It can either be set to <em>once</em>, which means, that the Pickup just has an effect (at a singular instant in time) and is done once that effect has been applied. Or to <em>continuous</em>, which means that the effect of the Pickup unfolds over some timespan. Default is <em>once</em>.
Modified: code/branches/dockingsystem/src/modules/pong/Pong.cc
===================================================================
--- code/branches/dockingsystem/src/modules/pong/Pong.cc 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/pong/Pong.cc 2011-04-06 10:07:29 UTC (rev 8194)
@@ -26,11 +26,19 @@
*
*/
+/**
+ @file Pong.cc
+ @brief Implementation of the Pong class.
+*/
+
#include "Pong.h"
#include "core/CoreIncludes.h"
#include "core/EventIncludes.h"
#include "core/command/Executor.h"
+
+#include "gamestates/GSLevel.h"
+
#include "PongCenterpoint.h"
#include "PongBall.h"
#include "PongBat.h"
@@ -39,11 +47,16 @@
namespace orxonox
{
+ // Events to allow to react to scoring of a player, in the level-file.
CreateEventName(PongCenterpoint, right);
CreateEventName(PongCenterpoint, left);
CreateUnloadableFactory(Pong);
+ /**
+ @brief
+ Constructor. Registers and initializes the object.
+ */
Pong::Pong(BaseObject* creator) : Deathmatch(creator)
{
RegisterObject(Pong);
@@ -55,29 +68,40 @@
this->setHUDTemplate("PongHUD");
+ // Pre-set the timer, but don't start it yet.
this->starttimer_.setTimer(1.0, false, createExecutor(createFunctor(&Pong::startBall, this)));
this->starttimer_.stopTimer();
+ // Set the type of Bots for this particular Gametype.
this->botclass_ = Class(PongBot);
}
+ /**
+ @brief
+ Destructor. Cleans up, if initialized.
+ */
Pong::~Pong()
{
if (this->isInitialized())
this->cleanup();
}
+ /**
+ @brief
+ Cleans up the Gametype by destroying the ball and the bats.
+ */
void Pong::cleanup()
{
- if (this->ball_)
+ if (this->ball_ != NULL) // Destroy the ball, if present.
{
this->ball_->destroy();
this->ball_ = 0;
}
+ // Destroy both bats, if present.
for (size_t i = 0; i < 2; ++i)
{
- if (this->bat_[0])
+ if (this->bat_[0] != NULL)
{
this->bat_[0]->destroy();
this->bat_[0] = 0;
@@ -85,16 +109,22 @@
}
}
+ /**
+ @brief
+ Starts the Pong minigame.
+ */
void Pong::start()
{
- if (this->center_)
+ if (this->center_ != NULL) // There needs to be a PongCenterpoint, i.e. the area the game takes place.
{
- if (!this->ball_)
+ if (this->ball_ == NULL) // If there is no ball, create a new ball.
{
this->ball_ = new PongBall(this->center_);
+ // Apply the template for the ball specified by the centerpoint.
this->ball_->addTemplate(this->center_->getBalltemplate());
}
+ // Attach the ball to the centerpoint and set the parameters as specified in the centerpoint, the ball is attached to.
this->center_->attach(this->ball_);
this->ball_->setPosition(0, 0, 0);
this->ball_->setFieldDimension(this->center_->getFieldDimension());
@@ -102,17 +132,17 @@
this->ball_->setAccelerationFactor(this->center_->getBallAccelerationFactor());
this->ball_->setBatLength(this->center_->getBatLength());
- if (!this->bat_[0])
+ // If one of the bats is missing, create it. Apply the template for the bats as specified in the centerpoint.
+ for (size_t i = 0; i < 2; ++i)
{
- this->bat_[0] = new PongBat(this->center_);
- this->bat_[0]->addTemplate(this->center_->getBattemplate());
+ if (this->bat_[i] == NULL)
+ {
+ this->bat_[i] = new PongBat(this->center_);
+ this->bat_[i]->addTemplate(this->center_->getBattemplate());
+ }
}
- if (!this->bat_[1])
- {
- this->bat_[1] = new PongBat(this->center_);
- this->bat_[1]->addTemplate(this->center_->getBattemplate());
- }
+ // Attach the bats to the centerpoint and set the parameters as specified in the centerpoint, the bats are attached to.
this->center_->attach(this->bat_[0]);
this->center_->attach(this->bat_[1]);
this->bat_[0]->setPosition(-this->center_->getFieldDimension().x / 2, 0, 0);
@@ -126,31 +156,46 @@
this->bat_[0]->setLength(this->center_->getBatLength());
this->bat_[1]->setLength(this->center_->getBatLength());
+ // Set the bats for the ball.
this->ball_->setBats(this->bat_);
}
- else
+ else // If no centerpoint was specified, an error is thrown and the level is exited.
{
COUT(1) << "Error: No Centerpoint specified." << std::endl;
+ GSLevel::startMainMenu();
+ return;
}
+ // Start the timer. After it has expired the ball is started.
this->starttimer_.startTimer();
-
+ // Set variable to temporarily force the player to spawn.
bool temp = this->bForceSpawn_;
this->bForceSpawn_ = true;
+ // Call start for the parent class.
Deathmatch::start();
+ // Reset the variable.
this->bForceSpawn_ = temp;
}
+ /**
+ @brief
+ Ends the Pong minigame.
+ */
void Pong::end()
{
this->cleanup();
+ // Call end for the parent class.
Deathmatch::end();
}
+ /**
+ @brief
+ Spawns players, and fills the rest up with bots.
+ */
void Pong::spawnPlayersIfRequested()
{
// first spawn human players to assign always the left bat to the player in singleplayer
@@ -163,44 +208,63 @@
this->spawnPlayer(it->first);
}
+ /**
+ @brief
+ Spawns the input player.
+ @param player
+ The player to be spawned.
+ */
void Pong::spawnPlayer(PlayerInfo* player)
{
- if (!this->bat_[0]->getPlayer())
+ assert(player);
+
+ // If the first (left) bat has no player.
+ if (this->bat_[0]->getPlayer() == NULL)
{
player->startControl(this->bat_[0]);
this->players_[player].state_ = PlayerState::Alive;
}
- else if (!this->bat_[1]->getPlayer())
+ // If the second (right) bat has no player.
+ else if (this->bat_[1]->getPlayer() == NULL)
{
player->startControl(this->bat_[1]);
this->players_[player].state_ = PlayerState::Alive;
}
+ // If both bats are taken.
else
return;
- if (player && player->getController() && player->getController()->isA(Class(PongAI)))
+ // If the player is an AI, it receives a pointer to the ball.
+ if (player->getController() != NULL && player->getController()->isA(Class(PongAI)))
{
PongAI* ai = orxonox_cast<PongAI*>(player->getController());
ai->setPongBall(this->ball_);
}
}
+ /**
+ @brief
+ Is called when the player scored.
+ */
void Pong::playerScored(PlayerInfo* player)
{
Deathmatch::playerScored(player);
- if (this->center_)
+ if (this->center_ != NULL) // If there is a centerpoint.
{
+ // Fire an event for the player that has scored, to be able to react to it in the level, e.g. by displaying fireworks.
if (player == this->getRightPlayer())
this->center_->fireEvent(FireEventName(PongCenterpoint, right));
else if (player == this->getLeftPlayer())
this->center_->fireEvent(FireEventName(PongCenterpoint, left));
- if (player)
+ // Also announce, that the player has scored.
+ if (player != NULL)
this->gtinfo_->sendAnnounceMessage(player->getName() + " scored");
}
- if (this->ball_)
+ // If there is a ball present, reset its position, velocity and acceleration.
+ if (this->ball_ != NULL)
{
this->ball_->setPosition(Vector3::ZERO);
this->ball_->setVelocity(Vector3::ZERO);
@@ -208,32 +272,50 @@
this->ball_->setSpeed(0);
}
- if (this->bat_[0] && this->bat_[1])
+ // If there are bats reset them to the middle position.
+ if (this->bat_[0] != NULL && this->bat_[1] != NULL)
{
this->bat_[0]->setPosition(-this->center_->getFieldDimension().x / 2, 0, 0);
this->bat_[1]->setPosition( this->center_->getFieldDimension().x / 2, 0, 0);
}
+ // Restart the timer to start the ball.
this->starttimer_.startTimer();
}
+ /**
+ @brief
+ Starts the ball with some default speed.
+ */
void Pong::startBall()
{
- if (this->ball_ && this->center_)
+ if (this->ball_ != NULL && this->center_ != NULL)
this->ball_->setSpeed(this->center_->getBallSpeed());
}
+ /**
+ @brief
+ Get the left player.
+ @return
+ Returns a pointer to the player playing on the left. If there is no left player, NULL is returned.
+ */
PlayerInfo* Pong::getLeftPlayer() const
{
- if (this->bat_ && this->bat_[0])
+ if (this->bat_ != NULL && this->bat_[0] != NULL)
return this->bat_[0]->getPlayer();
else
return 0;
}
+ /**
+ @brief
+ Get the right player.
+ @return
+ Returns a pointer to the player playing on the right. If there is no right player, NULL is returned.
+ */
PlayerInfo* Pong::getRightPlayer() const
{
- if (this->bat_ && this->bat_[1])
+ if (this->bat_ != NULL && this->bat_[1] != NULL)
return this->bat_[1]->getPlayer();
else
return 0;
Modified: code/branches/dockingsystem/src/modules/pong/Pong.h
===================================================================
--- code/branches/dockingsystem/src/modules/pong/Pong.h 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/pong/Pong.h 2011-04-06 10:07:29 UTC (rev 8194)
@@ -26,45 +26,73 @@
*
*/
+/**
+ @file Pong.h
+ @brief Declaration of the Pong class.
+ @ingroup Pong
+*/
+
#ifndef _Pong_H__
#define _Pong_H__
#include "pong/PongPrereqs.h"
#include "tools/Timer.h"
+
#include "gametypes/Deathmatch.h"
namespace orxonox
{
+
+ /**
+ @brief
+ Implements a Pong minigame (<a href="http://en.wikipedia.org/wiki/Pong">Wikipedia::Pong</a>).
+ It connects the different entities present in a game of Pong.
+
+ - The @ref orxonox::PongCenterpoint "PongCenterpoint" is the playing field for the Pong minigame, it allows for configuration of the minigame, e.g. by setting the size of the playing field, or the length of the @ref orxonox::PongBat "PongBats". The playing field is always in the x,y-plane, the x-axis being the horizontal and the z-axis being the vertical axis.<br />
+ The Pong class redistributes the important parameters defined in @ref orxonox::PongCenterpoint "PongCenterpoint" to the other entities, that need to know them, e.g. the @ref orxonox::PongBall "PongBall" and the @ref orxonox::PongBat "PongBats".<br />
+ The @ref orxonox::PongCenterpoint "PongCenterpoint" needs to exist in a level with the @ref orxonox::Gametype "Gametype" <em>Pong</em>.
+ - The @ref orxonox::PongBall "PongBall" is the ball both players play with. The @ref orxonox::PongBall "PongBall" both implements the movement of the ball, as well as the influence of the boundaries and consequently, also the bouncing (off the upper and lower delimiters, and as off the @ref orxonox::PongBat "PongBats") of the ball and the effects of the failure of a player to catch the ball (i.e. the scoring of the other player).
+ - The two @ref orxonox::PongBat "PongBats" are the entities through which the players can actively participate in the game, by controlling them. The @ref orxonox::PongBat "PongBat" class manages the movement (and restrictions thereof) and the influence of the players on the bats.
+
+ @author
+ Fabian 'x3n' Landau
+
+ @ingroup Pong
+ */
class _PongExport Pong : public Deathmatch
{
public:
- Pong(BaseObject* creator);
- virtual ~Pong();
+ Pong(BaseObject* creator); //!< Constructor. Registers and initializes the object.
+ virtual ~Pong(); //!< Destructor. Cleans up, if initialized.
- virtual void start();
- virtual void end();
+ virtual void start(); //!< Starts the Pong minigame.
+ virtual void end(); ///!< Ends the Pong minigame.
- virtual void spawnPlayer(PlayerInfo* player);
+ virtual void spawnPlayer(PlayerInfo* player); //!< Spawns the input player.
- virtual void playerScored(PlayerInfo* player);
+ virtual void playerScored(PlayerInfo* player); //!< Is called when the player scored.
+ /**
+ @brief Set the PongCenterpoint (the playing field).
+ @param center A pointer to the PongCenterpoint to be set.
+ */
void setCenterpoint(PongCenterpoint* center)
{ this->center_ = center; }
- PlayerInfo* getLeftPlayer() const;
- PlayerInfo* getRightPlayer() const;
+ PlayerInfo* getLeftPlayer() const; //!< Get the left player.
+ PlayerInfo* getRightPlayer() const; //!< Get the right player.
protected:
- virtual void spawnPlayersIfRequested();
+ virtual void spawnPlayersIfRequested(); //!< Spawns players, and fills the rest up with bots.
- void startBall();
- void cleanup();
+ void startBall(); //!< Starts the ball with some default speed.
+ void cleanup(); //!< Cleans up the Gametype by destroying the ball and the bats.
- WeakPtr<PongCenterpoint> center_;
- WeakPtr<PongBall> ball_;
- WeakPtr<PongBat> bat_[2];
- Timer starttimer_;
+ WeakPtr<PongCenterpoint> center_; //!< The playing field.
+ WeakPtr<PongBall> ball_; //!< The Pong ball.
+ WeakPtr<PongBat> bat_[2]; //!< The two bats.
+ Timer starttimer_; //!< A timer to delay the start of the game.
};
}
Modified: code/branches/dockingsystem/src/modules/pong/PongAI.cc
===================================================================
--- code/branches/dockingsystem/src/modules/pong/PongAI.cc 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/pong/PongAI.cc 2011-04-06 10:07:29 UTC (rev 8194)
@@ -26,12 +26,19 @@
*
*/
+/**
+ @file PongAI.cc
+ @brief Implementation of the PongAI class.
+*/
+
#include "PongAI.h"
#include "core/CoreIncludes.h"
#include "core/ConfigValueIncludes.h"
#include "tools/Timer.h"
+
#include "worldentities/ControllableEntity.h"
+
#include "PongBall.h"
namespace orxonox
@@ -40,6 +47,10 @@
const static float MAX_REACTION_TIME = 0.4f;
+ /**
+ @brief
+ Constructor. Registers and initializes the object.
+ */
PongAI::PongAI(BaseObject* creator) : Controller(creator)
{
RegisterObject(PongAI);
@@ -58,20 +69,37 @@
this->setConfigValues();
}
+ /**
+ @brief
+ Destructor. Cleans up the list fo reaction timers.
+ */
PongAI::~PongAI()
{
for (std::list<std::pair<Timer*, char> >::iterator it = this->reactionTimers_.begin(); it != this->reactionTimers_.end(); ++it)
it->first->destroy();
}
+ /**
+ @brief
+ Sets config values.
+ */
void PongAI::setConfigValues()
{
+ // Sets the strength of the PongAi as a config value.
SetConfigValue(strength_, 0.5).description("A value from 0 to 1 where 0 is weak and 1 is strong.");
}
+ /**
+ @brief
+ Is called each tick.
+ Implements the behavior of the PongAI (i.e. its intelligence).
+ @param dt
+ The time that has elapsed since the last tick.
+ */
void PongAI::tick(float dt)
{
- if (!this->ball_ || !this->getControllableEntity())
+ // If either the ball, or the controllable entity (i.e. the bat) don't exist (or aren't set).
+ if (this->ball_ == NULL || this->getControllableEntity() == NULL)
return;
Vector3 mypos = this->getControllableEntity()->getPosition();
@@ -108,7 +136,7 @@
// The ball is approaching
if (this->ballDirection_.x != 1)
{
- // The ball just startet to approach, initialize all values
+ // The ball just started to approach, initialize all values
this->ballDirection_.x = 1;
this->ballDirection_.y = sgn(ballvel.z);
this->ballEndPosition_ = 0;
@@ -157,7 +185,7 @@
if (move != 0 && this->oldMove_ != 0 && move != this->oldMove_ && !delay)
{
// We had to correct our position because we moved too far
- // (and delay ist false, so we're not in the wrong place because of a new end-position prediction)
+ // (and delay is false, so we're not in the wrong place because of a new end-position prediction)
if (fabs(mypos.z - this->ballEndPosition_) < 0.5 * this->ball_->getBatLength() * this->ball_->getFieldDimension().y)
{
// We're not at the right position, but we still hit the ball, so just stay there to avoid oscillation
@@ -172,6 +200,12 @@
this->getControllableEntity()->moveFrontBack(this->movement_);
}
+ /**
+ @brief
+ Calculates the random offset, that accounts for random errors the AI makes in order to be beatable.
+ The higher the strength of the AI, the smaller the (expected value of the) error.
+ The result of this method is stored in this->randomOffset_.
+ */
void PongAI::calculateRandomOffset()
{
// Calculate the exponent for the position-formula
@@ -183,7 +217,7 @@
float position = pow(rnd(), exp); // exp > 1 -> position is more likely a small number
// exp < 1 -> position is more likely a large number
- // The position shouln't be larger than 0.5 (50% of the bat-length from the middle is the end)
+ // The position shouldn't be larger than 0.5 (50% of the bat-length from the middle is the end)
position *= 0.48f;
// Both sides are equally probable
@@ -193,6 +227,11 @@
this->randomOffset_ = position * this->ball_->getBatLength() * this->ball_->getFieldDimension().y;
}
+ /**
+ @brief
+ Calculate the end position the ball will be in.
+ The result of this calculation is stored in this->ballEndPosition_.
+ */
void PongAI::calculateBallEndPosition()
{
Vector3 position = this->ball_->getPosition();
@@ -294,6 +333,15 @@
}
}
+ /**
+ @brief
+ Determine the movement the AI will undertake. (Either -1, 0 or 1)
+ The result of this calculation is stored in this->movement_;
+ @param direction
+ The current direction of movement.
+ @param bUseDelay
+ The time by which this move is delayed. (Again, to make the AI less efficient)
+ */
void PongAI::move(char direction, bool bUseDelay)
{
// The current direction is either what we're doing right now (movement_) or what is last in the queue
@@ -320,6 +368,10 @@
}
}
+ /**
+ @brief
+ Is called, when a delayed move takes effect.
+ */
void PongAI::delayedMove()
{
// Get the new movement direction from the timer list
Modified: code/branches/dockingsystem/src/modules/pong/PongAI.h
===================================================================
--- code/branches/dockingsystem/src/modules/pong/PongAI.h 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/pong/PongAI.h 2011-04-06 10:07:29 UTC (rev 8194)
@@ -26,49 +26,71 @@
*
*/
+/**
+ @file PongAI.h
+ @brief Declaration of the PongAI class.
+ @ingroup Pong
+*/
+
#ifndef _PongAI_H__
#define _PongAI_H__
#include "pong/PongPrereqs.h"
#include <list>
+
#include "util/Math.h"
#include "tools/interfaces/Tickable.h"
+
#include "controllers/Controller.h"
namespace orxonox
{
+
+ /**
+ @brief
+ The PongAI is an artificial intelligence for the @ref orxonox::Pong "Pong" gametype.
+
+ @author
+ Fabian 'x3n' Landau
+
+ @ingroup Pong
+ */
class _PongExport PongAI : public Controller, public Tickable
{
public:
- PongAI(BaseObject* creator);
+ PongAI(BaseObject* creator); //!< Constructor. Registers and initializes the object.
virtual ~PongAI();
void setConfigValues();
- virtual void tick(float dt);
+ virtual void tick(float dt); //!< Implements the behavior of the PongAI (i.e. its intelligence).
+ /**
+ @brief Set the ball for the AI.
+ @param ball A pointer to the ball.
+ */
void setPongBall(PongBall* ball)
{ this->ball_ = ball; }
protected:
- void calculateRandomOffset();
- void calculateBallEndPosition();
- void move(char direction, bool bUseDelay);
- void delayedMove();
+ void calculateRandomOffset(); //!< Calculates the random offset, that accounts for random errors the AI makes in order to be beatable.
+ void calculateBallEndPosition(); //!< Calculate the end position the ball will be in.
+ void move(char direction, bool bUseDelay); //!< Determine the movement the AI will undertake.
+ void delayedMove(); //!< Is called, when a delayed move takes effect.
- PongBall* ball_;
- Vector2 ballDirection_;
- float ballEndPosition_;
- float randomOffset_;
- bool bChangedRandomOffset_;
- float relHysteresisOffset_;
- float strength_;
+ PongBall* ball_; //!< A pointer to the ball.
+ Vector2 ballDirection_; //!< Vector to store the (x,z) direction in which the ball is flying.
+ float ballEndPosition_; //!< The calculated end position of the ball.
+ float randomOffset_; //!< A random offset to introduce random errors (weighted by the strength of the AI) into the AI's behavior.
+ bool bChangedRandomOffset_; //!< Helper boolean, to change the random offset more often.
+ float relHysteresisOffset_; //!< A hysteresis offset.
+ float strength_; //!< The strength of the AI. Ranging from 0 to 1.
- std::list<std::pair<Timer*, char> > reactionTimers_;
- char movement_;
- char oldMove_;
- bool bOscillationAvoidanceActive_;
+ std::list<std::pair<Timer*, char> > reactionTimers_; //!< A list of reaction timers and the directions that take effect when their timer expires.
+ char movement_; //!< The planned movement.
+ char oldMove_; //!< The previous movement.
+ bool bOscillationAvoidanceActive_; //!< Boolean, to avoid oscillations.
};
}
Modified: code/branches/dockingsystem/src/modules/pong/PongBall.cc
===================================================================
--- code/branches/dockingsystem/src/modules/pong/PongBall.cc 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/pong/PongBall.cc 2011-04-06 10:07:29 UTC (rev 8194)
@@ -26,11 +26,18 @@
*
*/
+/**
+ @file PongBall.cc
+ @brief Implementation of the PongBall class.
+*/
+
#include "PongBall.h"
#include "core/CoreIncludes.h"
#include "core/GameMode.h"
+
#include "gametypes/Gametype.h"
+
#include "PongBat.h"
namespace orxonox
@@ -39,6 +46,10 @@
const float PongBall::MAX_REL_Z_VELOCITY = 1.5;
+ /**
+ @brief
+ Constructor. Registers and initializes the object.
+ */
PongBall::PongBall(BaseObject* creator)
: MovableEntity(creator)
{
@@ -56,6 +67,10 @@
this->registerVariables();
}
+ /**
+ @brief
+ Destructor.
+ */
PongBall::~PongBall()
{
if (this->isInitialized())
@@ -67,6 +82,10 @@
}
}
+ /**
+ @brief
+ Register variables to synchronize over the network.
+ */
void PongBall::registerVariables()
{
registerVariable( this->fieldWidth_ );
@@ -78,17 +97,28 @@
registerVariable( this->batID_[1], VariableDirection::ToClient, new NetworkCallback<PongBall>( this, &PongBall::applyBats) );
}
+ /**
+ @brief
+ Is called every tick.
+ Handles the movement of the ball and its interaction with the boundaries and bats.
+ @param dt
+ The time since the last tick.
+ */
void PongBall::tick(float dt)
{
SUPER(PongBall, tick, dt);
+ // Get the current position, velocity and acceleration of the ball.
Vector3 position = this->getPosition();
Vector3 velocity = this->getVelocity();
Vector3 acceleration = this->getAcceleration();
+ // If the ball has gone over the top or bottom boundary of the playing field (i.e. the ball has hit the top or bottom delimiters).
if (position.z > this->fieldHeight_ / 2 || position.z < -this->fieldHeight_ / 2)
{
+ // Its velocity in z-direction is inverted (i.e. it bounces off).
velocity.z = -velocity.z;
+ // And its position is set as to not overstep the boundary it has just crossed.
if (position.z > this->fieldHeight_ / 2)
position.z = this->fieldHeight_ / 2;
if (position.z < -this->fieldHeight_ / 2)
@@ -97,24 +127,31 @@
this->fireEvent();
}
+ // If the ball has crossed the left or right boundary of the playing field (i.e. a player has just scored, if the bat isn't there to parry).
if (position.x > this->fieldWidth_ / 2 || position.x < -this->fieldWidth_ / 2)
{
float distance = 0;
- if (this->bat_)
+ if (this->bat_ != NULL) // If there are bats.
{
- if (position.x > this->fieldWidth_ / 2 && this->bat_[1])
+ // If the right boundary has been crossed.
+ if (position.x > this->fieldWidth_ / 2 && this->bat_[1] != NULL)
{
+ // Calculate the distance (in z-direction) between the ball and the center of the bat, weighted by half of the effective length of the bat (with additional 10%)
distance = (position.z - this->bat_[1]->getPosition().z) / (this->fieldHeight_ * (this->batlength_ * 1.10f) / 2);
- if (fabs(distance) <= 1)
+ if (fabs(distance) <= 1) // If the bat is there to parry.
{
+ // Set the ball to be exactly at the boundary.
position.x = this->fieldWidth_ / 2;
+ // Invert its velocity in x-direction (i.e. it bounces off).
velocity.x = -velocity.x;
+ // Adjust the velocity in the z-direction, depending on where the ball hit the bat.
velocity.z = distance * distance * sgn(distance) * PongBall::MAX_REL_Z_VELOCITY * this->speed_;
acceleration = this->bat_[1]->getVelocity() * this->accelerationFactor_ * -1;
this->fireEvent();
}
+ // If the left player scores.
else if (GameMode::isMaster() && position.x > this->fieldWidth_ / 2 * (1 + this->relMercyOffset_))
{
if (this->getGametype() && this->bat_[0])
@@ -124,18 +161,24 @@
}
}
}
- if (position.x < -this->fieldWidth_ / 2 && this->bat_[0])
+ // If the left boundary has been crossed.
+ else if (position.x < -this->fieldWidth_ / 2 && this->bat_[0] != NULL)
{
+ // Calculate the distance (in z-direction) between the ball and the center of the bat, weighted by half of the effective length of the bat (with additional 10%)
distance = (position.z - this->bat_[0]->getPosition().z) / (this->fieldHeight_ * (this->batlength_ * 1.10f) / 2);
- if (fabs(distance) <= 1)
+ if (fabs(distance) <= 1) // If the bat is there to parry.
{
+ // Set the ball to be exactly at the boundary.
position.x = -this->fieldWidth_ / 2;
+ // Invert its velocity in x-direction (i.e. it bounces off).
velocity.x = -velocity.x;
+ // Adjust the velocity in the z-direction, depending on where the ball hit the bat.
velocity.z = distance * distance * sgn(distance) * PongBall::MAX_REL_Z_VELOCITY * this->speed_;
acceleration = this->bat_[0]->getVelocity() * this->accelerationFactor_ * -1;
this->fireEvent();
}
+ // If the right player scores.
else if (GameMode::isMaster() && position.x < -this->fieldWidth_ / 2 * (1 + this->relMercyOffset_))
{
if (this->getGametype() && this->bat_[1])
@@ -148,6 +191,7 @@
}
}
+ // Set the position, velocity and acceleration of the ball, if they have changed.
if (acceleration != this->getAcceleration())
this->setAcceleration(acceleration);
if (velocity != this->getVelocity())
@@ -156,38 +200,57 @@
this->setPosition(position);
}
+ /**
+ @brief
+ Set the speed of the ball (in x-direction).
+ @param speed
+ The speed to be set.
+ */
void PongBall::setSpeed(float speed)
{
- if (speed != this->speed_)
+ if (speed != this->speed_) // If the speed changes
{
this->speed_ = speed;
+ // Set the speed in the direction of the balls current velocity.
Vector3 velocity = this->getVelocity();
if (velocity.x != 0)
velocity.x = sgn(velocity.x) * this->speed_;
- else
+ else // If the balls current velocity is zero, the speed is set in a random direction.
velocity.x = this->speed_ * sgn(rnd(-1,1));
this->setVelocity(velocity);
}
}
+ /**
+ @brief
+ Set the bats for the ball.
+ @param bats
+ An array (of size 2) of weak pointers, to be set as the new bats.
+ */
void PongBall::setBats(WeakPtr<PongBat>* bats)
{
- if (this->bDeleteBats_)
+ if (this->bDeleteBats_) // If there are already some bats, delete them.
{
delete[] this->bat_;
this->bDeleteBats_ = false;
}
this->bat_ = bats;
+ // Also store their object IDs, for synchronization.
this->batID_[0] = this->bat_[0]->getObjectID();
this->batID_[1] = this->bat_[1]->getObjectID();
}
+ /**
+ @brief
+ Get the bats over the network.
+ */
void PongBall::applyBats()
{
- if (!this->bat_)
+ // Make space for the bats, if they don't exist, yet.
+ if (this->bat_ == NULL)
{
this->bat_ = new WeakPtr<PongBat>[2];
this->bDeleteBats_ = true;
Modified: code/branches/dockingsystem/src/modules/pong/PongBall.h
===================================================================
--- code/branches/dockingsystem/src/modules/pong/PongBall.h 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/pong/PongBall.h 2011-04-06 10:07:29 UTC (rev 8194)
@@ -26,16 +26,35 @@
*
*/
+/**
+ @file PongBall.h
+ @brief Declaration of the PongBall class.
+ @ingroup Pong
+*/
+
#ifndef _PongBall_H__
#define _PongBall_H__
#include "pong/PongPrereqs.h"
#include "util/Math.h"
+
#include "worldentities/MovableEntity.h"
namespace orxonox
{
+
+ /**
+ @brief
+ This class manages the ball for @ref orxonox::Pong "Pong".
+
+ It is responsible for both the movement of the ball in the x,z-plane as well as its interaction with the boundaries of the playing field (defined by the @ref orxonox::PongCenterpoint "PongCenterpoint") and the @ref orxonox::PongBat "PongBats". Or more precisely, it makes the ball bounce off then upper and lower delimiters of the playing field, it makes the ball bounce off the bats and also detects when a player scores and takes appropriate measures.
+
+ @author
+ Fabian 'x3n' Landau
+
+ @ingroup Pong
+ */
class _PongExport PongBall : public MovableEntity
{
public:
@@ -44,44 +63,77 @@
virtual void tick(float dt);
+ /**
+ @brief Set the dimensions of the playing field.
+ @param width The width of the playing field.
+ @param height The height of the playing field.
+ */
void setFieldDimension(float width, float height)
{ this->fieldWidth_ = width; this->fieldHeight_ = height; }
+ /**
+ @brief Get the dimensions of the playing field.
+ @param dimension A vector with the width as the first and height as the second component.
+ */
void setFieldDimension(const Vector2& dimension)
{ this->setFieldDimension(dimension.x, dimension.y); }
+ /**
+ @brief Get the dimensions of the playing field.
+ @return Returns a vector with the width as the first and height as the second component.
+ */
Vector2 getFieldDimension() const
{ return Vector2(this->fieldWidth_, this->fieldHeight_); }
- void setSpeed(float speed);
+ void setSpeed(float speed); //!< Set the speed of the ball (in x-direction).
+ /**
+ @brief Get the speed of the ball (in x-direction).
+ @return Returns the speed of the ball (in x-direction).
+ */
float getSpeed() const
{ return this->speed_; }
+ /**
+ @brief Set the acceleration factor of the ball.
+ @param factor The factor the acceleration of the ball is set to.
+ */
void setAccelerationFactor(float factor)
{ this->accelerationFactor_ = factor; }
+ /**
+ @brief Get the acceleration factor of the ball.
+ @return Returns the acceleration factor of the ball.
+ */
float getAccelerationFactor() const
{ return this->accelerationFactor_; }
+ /**
+ @brief Set the length of the bats.
+ @param batlength The length of the bats (in z-direction) as percentage of the height of the playing field.
+ */
void setBatLength(float batlength)
{ this->batlength_ = batlength; }
+ /**
+ @brief Get the length of the bats.
+ @return Returns the length of the bats (in z-direction) as percentage of the height of the playing field.
+ */
float getBatLength() const
{ return this->batlength_; }
- void setBats(WeakPtr<PongBat>* bats);
- void applyBats();
+ void setBats(WeakPtr<PongBat>* bats); //!< Set the bats for the ball.
+ void applyBats(); //!< Get the bats over the network.
static const float MAX_REL_Z_VELOCITY;
private:
void registerVariables();
- float fieldWidth_;
- float fieldHeight_;
- float speed_;
- float accelerationFactor_;
- float batlength_;
- WeakPtr<PongBat>* bat_;
- bool bDeleteBats_;
- unsigned int* batID_;
- float relMercyOffset_;
+ float fieldWidth_; //!< The width of the playing field.
+ float fieldHeight_; //!< The height of the playing field.
+ float speed_; //!< The speed (in x-direction) of the ball.
+ float accelerationFactor_; //!< The acceleration factor of the ball.
+ float batlength_; //!< The length of the bats (in z-direction) as percentage of the height of the playing field.
+ WeakPtr<PongBat>* bat_; //!< An array with the two bats.
+ bool bDeleteBats_; //!< Bool, to keep track, of whether this->bat_ exists or not.
+ unsigned int* batID_; //!< The object IDs of the bats, to be able to synchronize them over the network.
+ float relMercyOffset_; //!< Offset, that makes the player not loose, when, in all fairness, he would have.
};
}
Modified: code/branches/dockingsystem/src/modules/pong/PongBat.cc
===================================================================
--- code/branches/dockingsystem/src/modules/pong/PongBat.cc 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/pong/PongBat.cc 2011-04-06 10:07:29 UTC (rev 8194)
@@ -26,6 +26,11 @@
*
*/
+/**
+ @file PongBat.cc
+ @brief Implementation of the PongBat class.
+*/
+
#include "PongBat.h"
#include "core/CoreIncludes.h"
@@ -35,6 +40,10 @@
{
CreateFactory(PongBat);
+ /**
+ @brief
+ Constructor. Registers and initializes the object.
+ */
PongBat::PongBat(BaseObject* creator) : ControllableEntity(creator)
{
RegisterObject(PongBat);
@@ -49,6 +58,10 @@
this->registerVariables();
}
+ /**
+ @brief
+ Registers variables to be synchronized over the network.
+ */
void PongBat::registerVariables()
{
registerVariable(this->speed_);
@@ -56,14 +69,24 @@
registerVariable(this->length_);
}
+ /**
+ @brief
+ Is called each tick.
+ Moves the bat.
+ @param dt
+ The time since last tick.
+ */
void PongBat::tick(float dt)
{
+ // If the bat is controlled (but not over the network).
if (this->hasLocalController())
{
if (this->movement_ != 0)
{
+ // The absolute value of the movement is restricted to be lesser or equal than the speed of the bat.
this->movement_ = clamp(this->movement_, -1.0f, 1.0f) * this->speed_;
+ // If moveRightLeft() is used the movement is dependento on wehther it is the right or the left bat, so, it is i.e. dependent on the orientation of the bat.
if (this->bMoveLocal_)
this->setVelocity(this->getOrientation() * Vector3(this->movement_, 0, 0));
else
@@ -72,6 +95,7 @@
this->movement_ = 0;
this->bSteadiedPosition_ = false;
}
+ // If there is no movement but the position has not been steadied, the velocity is set to zero and the position is reaffirmed.
else if (!this->bSteadiedPosition_)
{
// To ensure network synchronicity
@@ -83,6 +107,7 @@
SUPER(PongBat, tick, dt);
+ // Restrict the position of the bats, for them to always be between the upper and lower delimiters. i.e. the bats stall if they reach the upper or lower boundary.
Vector3 position = this->getPosition();
if (position.z > this->fieldHeight_ / 2 - this->fieldHeight_ * this->length_ / 2)
position.z = this->fieldHeight_ / 2 - this->fieldHeight_ * this->length_ / 2;
@@ -95,18 +120,34 @@
}
}
+ /**
+ @brief
+ Overloaded the function to steer the bat up and down.
+ @param value
+ A vector whose first component is the inverse direction in which we want to steer the bat.
+ */
void PongBat::moveFrontBack(const Vector2& value)
{
this->bMoveLocal_ = false;
this->movement_ = -value.x;
}
+ /**
+ @brief
+ Overloaded the function to steer the bat up and down.
+ @param value
+ A vector whose first component is the direction in which we wnat to steer the bat.
+ */
void PongBat::moveRightLeft(const Vector2& value)
{
this->bMoveLocal_ = true;
this->movement_ = value.x;
}
+ /**
+ @brief
+ Is called when the player changed.
+ */
void PongBat::changedPlayer()
{
this->setVelocity(0, 0, 0);
Modified: code/branches/dockingsystem/src/modules/pong/PongBat.h
===================================================================
--- code/branches/dockingsystem/src/modules/pong/PongBat.h 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/pong/PongBat.h 2011-04-06 10:07:29 UTC (rev 8194)
@@ -26,51 +26,94 @@
*
*/
+/**
+ @file PongBat.h
+ @brief Declaration of the PongBat class.
+ @ingroup Pong
+*/
+
#ifndef _PongBat_H__
#define _PongBat_H__
#include "pong/PongPrereqs.h"
+
#include "worldentities/ControllableEntity.h"
namespace orxonox
{
+
+ /**
+ @brief
+ The PongBat class manages the bats for @ref orxonox::Pong "Pong", which are the elements controlled by the players.
+
+ It is responsible for the movement (controlled by the players) of the bat.
+
+ @author
+ Fabian 'x3n' Landau
+
+ @ingroup Pong
+ */
class _PongExport PongBat : public ControllableEntity
{
public:
- PongBat(BaseObject* creator);
+ PongBat(BaseObject* creator); //!< Constructor. Registers and initializes the object.
virtual ~PongBat() {}
virtual void tick(float dt);
- virtual void moveFrontBack(const Vector2& value);
- virtual void moveRightLeft(const Vector2& value);
+ virtual void moveFrontBack(const Vector2& value); //!< Overloaded the function to steer the bat up and down.
+ virtual void moveRightLeft(const Vector2& value); //!< Overloaded the function to steer the bat up and down.
- virtual void changedPlayer();
+ virtual void changedPlayer(); //!< Is called when the player changed.
+ /**
+ @brief Set the speed of the bat.
+ @param speed The speed to be set.
+ */
void setSpeed(float speed)
{ this->speed_ = speed; }
+ /**
+ @brief Get the speed of the bat.
+ @return Returns the speed of the bat.
+ */
float getSpeed() const
{ return this->speed_; }
+ /**
+ @brief Set the height of the playing field.
+ @param height The height of the playing field.
+ */
void setFieldHeight(float height)
{ this->fieldHeight_ = height; }
+ /**
+ @brief Get the height of the playing field.
+ @return Returns the height of the playing field.
+ */
float getFieldHeight() const
{ return this->fieldHeight_; }
+ /**
+ @brief Set the length of the bat.
+ @param length The length of the bat (in z-direction) as percentage of the height of the playing field.
+ */
void setLength(float length)
{ this->length_ = length; }
+ /**
+ @brief get the length of the bat.
+ @return Returns the length of the bat (in z-direction) as percentage of the height of the playing field.
+ */
float getLength() const
{ return this->length_; }
private:
- void registerVariables();
+ void registerVariables(); //!< Registers variables to be synchronized over the network.
- float movement_;
- bool bMoveLocal_;
- float speed_;
- float length_;
- float fieldHeight_;
- bool bSteadiedPosition_;
+ float movement_; //!< The amount (and direction), in z-direction, of movement of the bat.
+ bool bMoveLocal_; //!< Helper to know whether the movement is caused by moveFrontBack() or moveRightLeft().
+ float speed_; //!< The movement speed of the bat.
+ float length_; //!< The length of the bat (in z-direction) as percentage of the height of the playing field.
+ float fieldHeight_; //!< The height of the playing field.
+ bool bSteadiedPosition_; //!< Helper boolean, to keep track of when to steady the position, to ensure network synchronicity.
};
}
Modified: code/branches/dockingsystem/src/modules/pong/PongBot.cc
===================================================================
--- code/branches/dockingsystem/src/modules/pong/PongBot.cc 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/pong/PongBot.cc 2011-04-06 10:07:29 UTC (rev 8194)
@@ -26,6 +26,11 @@
*
*/
+/**
+ @file PongBot.cc
+ @brief Implementation of the PongBot class.
+*/
+
#include "PongBot.h"
#include "core/CoreIncludes.h"
@@ -35,6 +40,10 @@
{
CreateFactory(PongBot);
+ /**
+ @brief
+ Constructor. Registers the object and creates a PongAI controller.
+ */
PongBot::PongBot(BaseObject* creator) : Bot(creator)
{
RegisterObject(PongBot);
Modified: code/branches/dockingsystem/src/modules/pong/PongBot.h
===================================================================
--- code/branches/dockingsystem/src/modules/pong/PongBot.h 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/pong/PongBot.h 2011-04-06 10:07:29 UTC (rev 8194)
@@ -26,6 +26,12 @@
*
*/
+/**
+ @file PongBot.h
+ @brief Declaration of the PongBot class.
+ @ingroup Pong
+*/
+
#ifndef _PongBot_H__
#define _PongBot_H__
@@ -34,6 +40,18 @@
namespace orxonox
{
+
+ /**
+ @brief
+ A bot especially for @ref orxonox::Pong "Pong".
+
+ Uses the @ref orxonox::PongAI "PongAI".
+
+ @author
+ Fabian 'x3n' Landau
+
+ @ingroup Pong
+ */
class _PongExport PongBot : public Bot
{
public:
Modified: code/branches/dockingsystem/src/modules/pong/PongCenterpoint.cc
===================================================================
--- code/branches/dockingsystem/src/modules/pong/PongCenterpoint.cc 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/pong/PongCenterpoint.cc 2011-04-06 10:07:29 UTC (rev 8194)
@@ -26,16 +26,26 @@
*
*/
+/**
+ @file PongCenterpoint.cc
+ @brief Implementation of the PongCenterpoint class.
+*/
+
#include "PongCenterpoint.h"
#include "core/CoreIncludes.h"
#include "core/XMLPort.h"
+
#include "Pong.h"
namespace orxonox
{
CreateFactory(PongCenterpoint);
+ /**
+ @brief
+ Constructor. Registers and initializes the object and checks whether the gametype is actually Pong.
+ */
PongCenterpoint::PongCenterpoint(BaseObject* creator) : StaticEntity(creator)
{
RegisterObject(PongCenterpoint);
@@ -50,6 +60,10 @@
this->checkGametype();
}
+ /**
+ @brief
+ Method to create a PongCenterpoint through XML.
+ */
void PongCenterpoint::XMLPort(Element& xmlelement, XMLPort::Mode mode)
{
SUPER(PongCenterpoint, XMLPort, xmlelement, mode);
@@ -63,19 +77,28 @@
XMLPortParam(PongCenterpoint, "batlength", setBatLength, getBatLength, xmlelement, mode);
}
+ /**
+ @brief
+ Is called when the gametype has changed.
+ */
void PongCenterpoint::changedGametype()
{
SUPER(PongCenterpoint, changedGametype);
+ // Check, whether it's still Pong.
this->checkGametype();
}
+ /**
+ @brief
+ Checks whether the gametype is Pong and if it is, sets its centerpoint.
+ */
void PongCenterpoint::checkGametype()
{
- if (this->getGametype() && this->getGametype()->isA(Class(Pong)))
+ if (this->getGametype() != NULL && this->getGametype()->isA(Class(Pong)))
{
- Pong* pong_gametype = orxonox_cast<Pong*>(this->getGametype().get());
- pong_gametype->setCenterpoint(this);
+ Pong* pongGametype = orxonox_cast<Pong*>(this->getGametype().get());
+ pongGametype->setCenterpoint(this);
}
}
}
Modified: code/branches/dockingsystem/src/modules/pong/PongCenterpoint.h
===================================================================
--- code/branches/dockingsystem/src/modules/pong/PongCenterpoint.h 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/pong/PongCenterpoint.h 2011-04-06 10:07:29 UTC (rev 8194)
@@ -26,75 +26,211 @@
*
*/
+/**
+ @file PongCenterpoint.h
+ @brief Declaration of the PongCenterpoint class.
+ @ingroup Pong
+*/
+
#ifndef _PongCenterpoint_H__
#define _PongCenterpoint_H__
#include "pong/PongPrereqs.h"
#include <string>
+
#include <util/Math.h>
+
#include "worldentities/StaticEntity.h"
namespace orxonox
{
+
+ /**
+ @brief
+ The PongCenterpoint implements the playing field @ref orxonox::Pong "Pong" takes place in and allows for many parameters of the minigame to be set.
+ The playing field resides in the x,z-plane, with the x-axis being the horizontal axis and the z-axis being the vertical axis.
+
+ Various parameters can be set:
+ - The <b>dimension</b> is a vector, that defines the width and height of the playing field. The default is <em>(200, 120)</em>.
+ - The <b>balltemplate</b> is a template that is applied to the @ref orxonox::PongBall "PongBall", it can be used to attach different things to it, e.g. its @ref orxonox::Model "Model". See below for a usage example.
+ - The <b>battemplate</b> is a template that is applied to the @ref orxonox::PongBall "PongBat", it can be used to attach different things to it, e.g. its @ref orxonox::Model "Model". See below for a usage example.
+ - The <b>ballspeed</b> is the speed with which the @ref orxonox::PongBall "PongBall" moves. The default is <em>100</em>.
+ - The <b>ballaccfactor</b> is the acceleration factor for the @ref orxonox::PongBall "PongBall". The default is <em>1.0</em>.
+ - The <b>batspeed</b> is the speed with which the @ref orxonox::PongBat "PongBats" move. The default is <em>60</em>.
+ - The <b>batlength</b> is the length of the @ref orxonox::PongBat "PongBats" as the percentage of the height of the playing field. The default is <em>0.25</em>.
+
+ An example in XML of the PongCenterpoint would be:
+
+ First the needed templates:
+ The template for the @ref orxonox::PongBall "PongBall".
+ @code
+ <Template name="pongball">
+ <PongBall>
+ <attached>
+ <Model mesh="sphere.mesh" scale="2" />
+ <ParticleSpawner name="hiteffect" position="0,0,0" source="Orxonox/sparks2" lifetime="0.01" autostart="0" mainstate="spawn" />
+ </attached>
+ <eventlisteners>
+ <EventTarget target="hiteffect" />
+ </eventlisteners>
+ </PongBall>
+ </Template>
+ @endcode
+ As can be seen, a sphere is attached as the @ref orxonox::Model "Model" for the @ref orxonox::PongBall "PongBall", and also an @ref orxonox::EventListener "EventListener" that triggers a @ref orxonox::ParticleSpawner "ParticleSpawner", whenever the ball hits the boundaries is attached.
+
+ Additionally the template for the @ref orxonox::PongBat "PongBat".
+ @code
+ <Template name="pongbatcameras" defaults="0">
+ <PongBat>
+ <camerapositions>
+ <CameraPosition position="0,200,0" pitch="-90" absolute="true" />
+ </camerapositions>
+ </PongBat>
+ </Template>
+
+ <Template name="pongbat">
+ <PongBat camerapositiontemplate=pongbatcameras>
+ <attached>
+ <Model position="0,0,3" mesh="cube.mesh" scale3D="14,2,2" />
+ </attached>
+ </PongBat>
+ </Template>
+ @endcode
+ As can be seen, there are actually two templates. The first template is needed to set the camera for the @ref orxonox::PongBat "PongBat". The second template ist the actual template for the @ref orxonox::PongBat "PongBat", the template for the camera position is added and a @ref orxonox::Model "Model" for the @ref orxonox::PongBat "PongBat" is attached.
+
+ Finally the PongCenterpoint is created.
+ @code
+ <PongCenterpoint name="pongcenter" dimension="200,120" balltemplate="pongball" battemplate="pongbat" ballspeed="200" ballaccfactor="1.0" batspeed="130" batlength="0.25">
+ <attached>
+ <Model position="0,0,60" mesh="cube.mesh" scale3D="105,1,1" />
+ <Model position="0,0,-60" mesh="cube.mesh" scale3D="105,1,1" />
+ </attached>
+ </PongCenterpoint>
+ @endcode
+ All parameters are specified. And also two @ref orxonox::Model "Models" (for the upper and lower boundary) are attached.
+
+ For a more elaborate example, have a look at the <code>pong.oxw</code> level file.
+
+ @author
+ Fabian 'x3n' Landau
+
+ @ingroup Pong
+ */
class _PongExport PongCenterpoint : public StaticEntity
{
public:
- PongCenterpoint(BaseObject* creator);
+ PongCenterpoint(BaseObject* creator); //!< Constructor. Registers and initializes the object and checks whether the gametype is actually Pong.
virtual ~PongCenterpoint() {}
- virtual void XMLPort(Element& xmlelement, XMLPort::Mode mode);
+ virtual void XMLPort(Element& xmlelement, XMLPort::Mode mode); //!< Method to create a PongCenterpoint through XML.
- virtual void changedGametype();
+ virtual void changedGametype(); //!< Is called when the gametype has changed.
+ /**
+ @brief Set the template for the ball. (e.g. to attach the model of the ball, but also to attach an EventListener to it to detect, when it hits the boundaries, and e.g. display some ParticleEffets, when it does.)
+ @param balltemplate The name of the template to be set.
+ */
void setBalltemplate(const std::string& balltemplate)
{ this->balltemplate_ = balltemplate; }
+ /**
+ @brief Get the template of the ball.
+ @return Returns the name of the template of the ball.
+ */
const std::string& getBalltemplate() const
{ return this->balltemplate_; }
+ /**
+ @brief Set the template for the bats. (e.g. to attach the model of the bat, but also to attach CameraPositions to it, to be able to view the game from the bats perspective)
+ @param battemplate The name of the template to be set.
+ */
void setBattemplate(const std::string& battemplate)
{ this->battemplate_ = battemplate; }
+ /**
+ @brief Get the template of the bats.
+ @return Returns the name of the template of the bats.
+ */
const std::string& getBattemplate() const
{ return this->battemplate_; }
+ /**
+ @brief Set the dimensions of the playing field.
+ @param dimension A vector with the width of the playing field as first component and the height as second.
+ */
void setFieldDimension(const Vector2& dimension)
{ this->width_ = dimension.x; this->height_ = dimension.y; }
+ /**
+ @brief Get the dimensions of the playing field.
+ @return Returns a vector with the width of the playing field as first component and the height as second.
+ */
Vector2 getFieldDimension() const
{ return Vector2(this->width_, this->height_); }
+ /**
+ @brief Set the speed of the ball.
+ @param ballspeed The speed of the ball.
+ */
void setBallSpeed(float ballspeed)
{ this->ballspeed_ = ballspeed; }
+ /**
+ @brief Get the speed of the ball.
+ @return Returns the speed of the ball.
+ */
float getBallSpeed() const
{ return this->ballspeed_; }
+ /**
+ @brief Set the ball's acceleration factor.
+ @param ballaccfactor The ball's acceleration factor.
+ */
void setBallAccelerationFactor(float ballaccfactor)
{ this->ballaccfactor_ = ballaccfactor; }
+ /**
+ @brief Get the ball's acceleration factor
+ @return Returns the ball's acceleration factor.
+ */
float getBallAccelerationFactor() const
{ return this->ballaccfactor_; }
+ /**
+ @brief Set the speed of the bats.
+ @param batspeed The speed of the bats.
+ */
void setBatSpeed(float batspeed)
{ this->batspeed_ = batspeed; }
+ /**
+ @brief Get the speed of the bats.
+ @return Returns the speed of the bats.
+ */
float getBatSpeed() const
{ return this->batspeed_; }
+ /**
+ @brief Set the length of the bats.
+ @param batlength The length of the bats (in z-direction) as a percentage of the height of the playing field.
+ */
void setBatLength(float batlength)
{ this->batlength_ = batlength; }
+ /**
+ @brief Get the length of the bats.
+ @return Returns the length of the bats (in z-direction) as a percentage of the height of the playing field.
+ */
float getBatLength() const
{ return this->batlength_; }
private:
- void checkGametype();
+ void checkGametype(); //!< Checks whether the gametype is Pong and if it is, sets its centerpoint.
- std::string balltemplate_;
- std::string battemplate_;
+ std::string balltemplate_; //!< The template for the ball.
+ std::string battemplate_; //!< The template for the bats.
- float ballspeed_;
- float ballaccfactor_;
- float batspeed_;
- float batlength_;
+ float ballspeed_; //!< The speed of then ball.
+ float ballaccfactor_; //!< The acceleration factor of the ball.
+ float batspeed_; //!< The speed of the bat.
+ float batlength_; //!< The length of the bat (in z-direction) as a percentage of the height of the playing field.
- float width_;
- float height_;
+ float width_; //!< The height of the playing field.
+ float height_; //!< The width of the playing field.
};
}
Modified: code/branches/dockingsystem/src/modules/pong/PongScore.cc
===================================================================
--- code/branches/dockingsystem/src/modules/pong/PongScore.cc 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/pong/PongScore.cc 2011-04-06 10:07:29 UTC (rev 8194)
@@ -26,18 +26,29 @@
*
*/
+/**
+ @file PongScore.cc
+ @brief Implementation of the PongScore class.
+*/
+
#include "PongScore.h"
-#include "util/Convert.h"
#include "core/CoreIncludes.h"
#include "core/XMLPort.h"
-#include "Pong.h"
+#include "util/Convert.h"
+
#include "infos/PlayerInfo.h"
+#include "Pong.h"
+
namespace orxonox
{
CreateFactory(PongScore);
+ /**
+ @brief
+ Constructor. Registers and initializes the object.
+ */
PongScore::PongScore(BaseObject* creator) : OverlayText(creator)
{
RegisterObject(PongScore);
@@ -50,10 +61,18 @@
this->bShowRightPlayer_ = false;
}
+ /**
+ @brief
+ Destructor.
+ */
PongScore::~PongScore()
{
}
+ /**
+ @brief
+ Method to create a PongScore through XML.
+ */
void PongScore::XMLPort(Element& xmlelement, XMLPort::Mode mode)
{
SUPER(PongScore, XMLPort, xmlelement, mode);
@@ -64,12 +83,21 @@
XMLPortParam(PongScore, "showrightplayer", setShowRightPlayer, getShowRightPlayer, xmlelement, mode).defaultValues(false);
}
+ /**
+ @brief
+ Is called each tick.
+ Creates and sets the caption to be displayed by the PongScore.
+ @param dt
+ The time that has elapsed since the last tick.
+ */
void PongScore::tick(float dt)
{
SUPER(PongScore, tick, dt);
- if (this->owner_)
+ // If the owner is set. The owner being a Pong game.
+ if (this->owner_ != NULL)
{
+ // Get the two players.
PlayerInfo* player1 = this->owner_->getLeftPlayer();
PlayerInfo* player2 = this->owner_->getRightPlayer();
@@ -79,22 +107,23 @@
std::string score1("0");
std::string score2("0");
- if (player1)
+ // Save the name and score of each player as a string.
+ if (player1 != NULL)
{
name1 = player1->getName();
score1 = multi_cast<std::string>(this->owner_->getScore(player1));
}
-
- if (player2)
+ if (player2 != NULL)
{
name2 = player2->getName();
score2 = multi_cast<std::string>(this->owner_->getScore(player2));
}
+ // Assemble the strings, depending on what should all be displayed.
std::string output1;
if (this->bShowLeftPlayer_)
{
- if (this->bShowName_ && this->bShowScore_ && player1)
+ if (this->bShowName_ && this->bShowScore_ && player1 != NULL)
output1 = name1 + " - " + score1;
else if (this->bShowScore_)
output1 = score1;
@@ -105,7 +134,7 @@
std::string output2;
if (this->bShowRightPlayer_)
{
- if (this->bShowName_ && this->bShowScore_ && player2)
+ if (this->bShowName_ && this->bShowScore_ && player2 != NULL)
output2 = score2 + " - " + name2;
else if (this->bShowScore_)
output2 = score2;
@@ -126,12 +155,16 @@
}
}
-
+ /**
+ @brief
+ Is called when the owner changes.
+ Sets the owner to NULL, if it is not a pointer to a Pong game.
+ */
void PongScore::changedOwner()
{
SUPER(PongScore, changedOwner);
- if (this->getOwner() && this->getOwner()->getGametype())
+ if (this->getOwner() != NULL && this->getOwner()->getGametype())
this->owner_ = orxonox_cast<Pong*>(this->getOwner()->getGametype().get());
else
this->owner_ = 0;
Modified: code/branches/dockingsystem/src/modules/pong/PongScore.h
===================================================================
--- code/branches/dockingsystem/src/modules/pong/PongScore.h 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/modules/pong/PongScore.h 2011-04-06 10:07:29 UTC (rev 8194)
@@ -26,52 +26,101 @@
*
*/
+/**
+ @file PongScore.h
+ @brief Declaration of the PongScore class.
+ @ingroup Pong
+*/
+
#ifndef _PongScore_H__
#define _PongScore_H__
#include "pong/PongPrereqs.h"
#include "tools/interfaces/Tickable.h"
+
#include "overlays/OverlayText.h"
namespace orxonox
{
+
+ /**
+ @brief
+ The PongScore class displays the score for a game of @ref orxonox::Pong "Pong".
+
+ @author
+ Fabian 'x3n' Landau
+
+ @ingroup Pong
+ */
class _PongExport PongScore : public OverlayText, public Tickable
{
public:
PongScore(BaseObject* creator);
virtual ~PongScore();
- virtual void tick(float dt);
+ virtual void tick(float dt); //!< Creates and sets the caption to be displayed by the PongScore.
virtual void XMLPort(Element& xmlelement, XMLPort::Mode mode);
- virtual void changedOwner();
+ virtual void changedOwner(); //!< Is called when the owner changes.
+ /**
+ @brief Set whether the PongScore displays the players' names.
+ @param value If true the players' names are displayed.
+ */
inline void setShowName(bool value)
{ this->bShowName_ = value; }
+ /**
+ @brief Get whether the PongScore displays the players' names.
+ @return Returns true if the players' names are displayed, false otherwise.
+ */
inline bool getShowName() const
{ return this->bShowName_; }
+ /**
+ @brief Set whether the PongScore displays the players' scores.
+ @param value If true the players' scores are displayed.
+ */
inline void setShowScore(bool value)
{ this->bShowScore_ = value; }
+ /**
+ @brief Get whether the PongScore displays the players' scores.
+ @return Returns true if the players' scores are displayed, false otherwise.
+ */
inline bool getShowScore() const
{ return this->bShowScore_; }
+ /**
+ @brief Set whether the PongScore displays the left player.
+ @param value If true the left player is displayed.
+ */
inline void setShowLeftPlayer(bool value)
{ this->bShowLeftPlayer_ = value; }
+ /**
+ @brief Get whether the PongScore displays the left player.
+ @return Returns true if the left player is displayed, false otherwise.
+ */
inline bool getShowLeftPlayer() const
{ return this->bShowLeftPlayer_; }
+ /**
+ @brief Set whether the PongScore displays the right player.
+ @param value If true the right player is displayed.
+ */
inline void setShowRightPlayer(bool value)
{ this->bShowRightPlayer_ = value; }
+ /**
+ @brief Get whether the PongScore displays the right player.
+ @return Returns true if the right player is displayed, false otherwise.
+ */
inline bool getShowRightPlayer() const
{ return this->bShowRightPlayer_; }
private:
- Pong* owner_;
- bool bShowName_;
- bool bShowScore_;
- bool bShowLeftPlayer_;
- bool bShowRightPlayer_;
+ Pong* owner_; //!< The Pong game that owns this PongScore.
+ bool bShowName_; //!< Whether the names of the players are shown.
+ bool bShowScore_; //!< Whether the score of the players is shown.
+ bool bShowLeftPlayer_; //!< Whether the left player is shown.
+ bool bShowRightPlayer_; //!< Whether the right player is shown.
};
}
#endif /* _PongScore_H__ */
Modified: code/branches/dockingsystem/src/orxonox/OrxonoxPrereqs.h
===================================================================
--- code/branches/dockingsystem/src/orxonox/OrxonoxPrereqs.h 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/orxonox/OrxonoxPrereqs.h 2011-04-06 10:07:29 UTC (rev 8194)
@@ -95,6 +95,7 @@
class Dynamicmatch;
class Gametype;
class LastManStanding;
+ class LastTeamStanding;
class TeamBaseMatch;
class TeamDeathmatch;
class UnderAttack;
Modified: code/branches/dockingsystem/src/orxonox/gametypes/CMakeLists.txt
===================================================================
--- code/branches/dockingsystem/src/orxonox/gametypes/CMakeLists.txt 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/orxonox/gametypes/CMakeLists.txt 2011-04-06 10:07:29 UTC (rev 8194)
@@ -7,4 +7,5 @@
Asteroids.cc
Dynamicmatch.cc
LastManStanding.cc
+ LastTeamStanding.cc
)
Modified: code/branches/dockingsystem/src/orxonox/gametypes/Gametype.h
===================================================================
--- code/branches/dockingsystem/src/orxonox/gametypes/Gametype.h 2011-04-06 09:12:38 UTC (rev 8193)
+++ code/branches/dockingsystem/src/orxonox/gametypes/Gametype.h 2011-04-06 10:07:29 UTC (rev 8194)
@@ -149,6 +149,9 @@
inline void setTimeLimit(float t)
{ this->timeLimit_ = t; }
+ //inline bool getForceSpawn()
+ // { return this->bForceSpawn_; }
+
virtual void resetTimer();
virtual void resetTimer(float t);
Copied: code/branches/dockingsystem/src/orxonox/gametypes/LastTeamStanding.cc (from rev 8193, code/trunk/src/orxonox/gametypes/LastTeamStanding.cc)
===================================================================
--- code/branches/dockingsystem/src/orxonox/gametypes/LastTeamStanding.cc (rev 0)
+++ code/branches/dockingsystem/src/orxonox/gametypes/LastTeamStanding.cc 2011-04-06 10:07:29 UTC (rev 8194)
@@ -0,0 +1,324 @@
+/*
+ * ORXONOX - the hottest 3D action shooter ever to exist
+ * > www.orxonox.net <
+ *
+ *
+ * License notice:
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Author:
+ * Johannes Ritz
+ * Co-authors:
+ * ...
+ *
+ */
+
+#include "LastTeamStanding.h"
+
+#include "core/CoreIncludes.h"
+#include "network/Host.h"
+#include "infos/PlayerInfo.h"
+#include "worldentities/pawns/Pawn.h"
+#include "core/ConfigValueIncludes.h"
+#include "util/Convert.h"
+
+namespace orxonox
+{
+ CreateUnloadableFactory(LastTeamStanding);
+
+ LastTeamStanding::LastTeamStanding(BaseObject* creator) : TeamDeathmatch(creator)
+ {
+ RegisterObject(LastTeamStanding);
+ this->bForceSpawn_ = true;
+ this->lives = 1;//4
+ this->eachTeamsPlayers.resize(teams_,0);
+ this->teamsAlive = 0;
+ this->bNoPunishment = false;
+ this->bHardPunishment = false;
+ this->punishDamageRate = 0.4f;
+ this->timeRemaining = 15.0f;
+ this->respawnDelay = 4.0f;
+ this->setHUDTemplate("lastTeamStandingHUD");
+ }
+
+ LastTeamStanding::~LastTeamStanding()
+ {
+ //this->playerLives_.clear();
+ //this->eachTeamsPlayers.clear();
+ //this->timeToAct_.clear();
+ //this->inGame_.clear();
+ //this->playerDelayTime_.clear();
+ }
+
+ void LastTeamStanding::playerEntered(PlayerInfo* player)
+ {
+ if (!player)// only for safety
+ return;
+ TeamDeathmatch::playerEntered(player);
+ if (teamsAlive<=1)
+ playerLives_[player]=lives;
+ else
+ playerLives_[player]=getMinLives();//new players only get minimum of lives */
+
+ this->timeToAct_[player] = timeRemaining;
+ this->playerDelayTime_[player] = respawnDelay;
+ this->inGame_[player] = true;
+ unsigned int team = getTeam(player);
+ if( team < 0|| team > teams_) // make sure getTeam returns a regular value
+ return;
+ if(this->eachTeamsPlayers[team]==0) //if a player is the first in his group, a new team is alive
+ this->teamsAlive++;
+ this->eachTeamsPlayers[team]++; //the number of player in this team is increased
+ }
+
+ bool LastTeamStanding::playerLeft(PlayerInfo* player)
+ {
+ bool valid_player = TeamDeathmatch::playerLeft(player);
+ if (valid_player)
+ {
+ this->playerLives_.erase(player);
+ this->timeToAct_.erase(player);
+ this->playerDelayTime_.erase(player);
+ this->inGame_.erase(player);
+ unsigned int team = getTeam(player);
+ if( team < 0|| team > teams_) // make sure getTeam returns a regular value
+ return valid_player;
+ this->eachTeamsPlayers[team]--; // a player left the team
+ if(this->eachTeamsPlayers[team] == 0) // if it was the last player a team died
+ this->teamsAlive--;
+ }
+
+ return valid_player;
+ }
+
+ bool LastTeamStanding::allowPawnDeath(Pawn* victim, Pawn* originator)
+ {
+ if (!victim||!victim->getPlayer())// only for safety
+ return true;
+ bool allow = TeamDeathmatch::allowPawnDeath(victim, originator);
+ if(!allow) {return allow;}
+
+ playerLives_[victim->getPlayer()] = playerLives_[victim->getPlayer()] - 1; //player lost a live
+ this->inGame_[victim->getPlayer()] = false; //if player dies, he isn't allowed to respawn immediately
+ if (playerLives_[victim->getPlayer()]<=0) //if player lost all lives
+ {
+ unsigned int team = getTeam(victim->getPlayer());
+ if(team < 0|| team > teams_) // make sure getTeam returns a regular value
+ return allow;
+ this->eachTeamsPlayers[team]--;
+ if(eachTeamsPlayers[team] == 0) //last team member died
+ this->teamsAlive--;
+ const std::string& message = victim->getPlayer()->getName() + " has lost all lives";
+ COUT(0) << message << std::endl;
+ Host::Broadcast(message);
+ }
+ return allow;
+ }
+
+ bool LastTeamStanding::allowPawnDamage(Pawn* victim, Pawn* originator)
+ {
+ bool allow = TeamDeathmatch::allowPawnDamage(victim, originator);
+ if(!allow) {return allow;}
+ if (originator && originator->getPlayer())// only for safety
+ {
+ this->timeToAct_[originator->getPlayer()] = timeRemaining;
+
+ std::map<PlayerInfo*, Player>::iterator it = this->players_.find(originator->getPlayer());
+ if (it != this->players_.end())
+ {
+ if (it->first->getClientID()== CLIENTID_UNKNOWN)
+ return true;
+ const std::string& message = ""; // resets Camper-Warning-message
+ this->gtinfo_->sendFadingMessage(message,it->first->getClientID());
+ }
+ }
+ return allow;
+ }
+
+ void LastTeamStanding::spawnDeadPlayersIfRequested()
+ {
+ for (std::map<PlayerInfo*, Player>::iterator it = this->players_.begin(); it != this->players_.end(); ++it)
+ if (it->second.state_ == PlayerState::Dead)
+ {
+ bool alive = (0 < playerLives_[it->first]&&(inGame_[it->first]));
+ if (alive&&(it->first->isReadyToSpawn() || this->bForceSpawn_))
+ {
+ this->spawnPlayer(it->first);
+ }
+ }
+ }
+
+ void LastTeamStanding::playerStartsControllingPawn(PlayerInfo* player, Pawn* pawn)
+ {
+ if (!player)
+ return;
+ TeamDeathmatch::playerStartsControllingPawn(player,pawn);
+
+ this->timeToAct_[player] = timeRemaining + 3.0f + respawnDelay;//reset timer
+ this->playerDelayTime_[player] = respawnDelay;
+
+ std::map<PlayerInfo*, Player>::iterator it = this->players_.find(player);
+ if (it != this->players_.end())
+ {
+ if (it->first->getClientID()== CLIENTID_UNKNOWN)
+ return;
+ const std::string& message = ""; // resets Camper-Warning-message
+ this->gtinfo_->sendFadingMessage(message,it->first->getClientID());
+ }
+ }
+
+ void LastTeamStanding::tick(float dt)
+ {
+ SUPER(LastTeamStanding, tick, dt);
+ if(this->hasStarted()&&(!this->hasEnded()))
+ {
+ if ( this->hasStarted()&&(teamsAlive<=1) )//last team remaining -> game will end
+ {
+ this->end();
+ }
+ for (std::map<PlayerInfo*, float>::iterator it = this->timeToAct_.begin(); it != this->timeToAct_.end(); ++it)
+ {
+ if (playerGetLives(it->first) <= 0)//Players without lives shouldn't be affected by time.
+ continue;
+ it->second -= dt;//Decreases punishment time.
+ if (!inGame_[it->first])//Manages respawn delay - player is forced to respawn after the delaytime is used up.
+ {
+ playerDelayTime_[it->first] -= dt;
+ if (playerDelayTime_[it->first] <= 0)
+ this->inGame_[it->first] = true;
+
+ if (it->first->getClientID()== CLIENTID_UNKNOWN)
+ continue;
+ int output = 1 + playerDelayTime_[it->first];
+ const std::string& message = "Respawn in " +multi_cast<std::string>(output)+ " seconds." ;//Countdown
+ this->gtinfo_->sendFadingMessage(message,it->first->getClientID());
+ }
+ else if (it->second < 0.0f)
+ {
+ it->second = timeRemaining + 3.0f;//reset punishment-timer
+ if (playerGetLives(it->first) > 0)
+ {
+ this->punishPlayer(it->first);
+ if (it->first->getClientID() == CLIENTID_UNKNOWN)
+ return;
+ const std::string& message = ""; // resets Camper-Warning-message
+ this->gtinfo_->sendFadingMessage(message, it->first->getClientID());
+ }
+ }
+ else if (it->second < timeRemaining/5)//Warning message
+ {
+ if (it->first->getClientID()== CLIENTID_UNKNOWN)
+ continue;
+ const std::string& message = "Camper Warning! Don't forget to shoot.";
+ this->gtinfo_->sendFadingMessage(message, it->first->getClientID());
+ }
+ }
+ }
+ }
+
+ void LastTeamStanding::end()//TODO: Send the message to the whole team
+ {
+ Gametype::end();
+ int party = -1;
+ //find a player who survived
+ for (std::map<PlayerInfo*, int>::iterator it = this->playerLives_.begin(); it != this->playerLives_.end(); ++it)
+ {
+ if (it->first->getClientID() == CLIENTID_UNKNOWN)
+ continue;
+
+ if (it->second > 0)//a player that is alive
+ {
+ //which party has survived?
+ std::map<PlayerInfo*, int>::iterator it2 = this->teamnumbers_.find(it->first);
+ if (it2 != this->teamnumbers_.end())
+ {
+ party = it2->second;
+ }
+ //if (party < 0) return; //if search failed
+ //victory message to all team members, loose message to everyone else
+ for (std::map<PlayerInfo*, int>::iterator it3 = this->teamnumbers_.begin(); it3 != this->teamnumbers_.end(); ++it3)
+ {
+ if (it3->first->getClientID() == CLIENTID_UNKNOWN)
+ continue;
+ if (it3->second == party)
+ {this->gtinfo_->sendAnnounceMessage("You have won the match!", it3->first->getClientID());}
+ else
+ {this->gtinfo_->sendAnnounceMessage("You have lost the match!", it3->first->getClientID());}
+ }
+ return;
+ }
+ }
+ }
+
+
+ int LastTeamStanding::getMinLives()
+ {
+ int min = lives;
+ for (std::map<PlayerInfo*, int>::iterator it = this->playerLives_.begin(); it != this->playerLives_.end(); ++it)
+ {
+ if (it->second <= 0)
+ continue;
+ if (it->second < lives)
+ min = it->second;
+ }
+ return min;
+ }
+
+ void LastTeamStanding::punishPlayer(PlayerInfo* player)
+ {
+ if(!player)
+ return;
+ if(bNoPunishment)
+ return;
+ std::map<PlayerInfo*, Player>::iterator it = this->players_.find(player);
+ if (it != this->players_.end())
+ {
+ if(!player->getControllableEntity())
+ return;
+ Pawn* pawn = dynamic_cast<Pawn*>(player->getControllableEntity());
+ if(!pawn)
+ return;
+ if(bHardPunishment)
+ {
+ pawn->kill();
+ this->timeToAct_[player] = timeRemaining + 3.0f + respawnDelay;//reset timer
+ }
+ else
+ {
+ float damage = pawn->getMaxHealth()*punishDamageRate*0.5;//TODO: Factor 0.5 is hard coded. Where is the ratio between MaxHealth actually defined?
+ pawn->removeHealth(damage);
+ this->timeToAct_[player] = timeRemaining;//reset timer
+ }
+ }
+ }
+
+ int LastTeamStanding::playerGetLives(PlayerInfo* player)
+ {
+ if (player)
+ return playerLives_[player];
+ else
+ return 0;
+ }
+
+ void LastTeamStanding::setConfigValues()
+ {
+ SetConfigValue(lives, 4);
+ SetConfigValue(timeRemaining, 15.0f);
+ SetConfigValue(respawnDelay, 4.0f);
+ SetConfigValue(bNoPunishment, false);
+ SetConfigValue(bHardPunishment, false);
+ }
+}
Copied: code/branches/dockingsystem/src/orxonox/gametypes/LastTeamStanding.h (from rev 8193, code/trunk/src/orxonox/gametypes/LastTeamStanding.h)
===================================================================
--- code/branches/dockingsystem/src/orxonox/gametypes/LastTeamStanding.h (rev 0)
+++ code/branches/dockingsystem/src/orxonox/gametypes/LastTeamStanding.h 2011-04-06 10:07:29 UTC (rev 8194)
@@ -0,0 +1,93 @@
+/*
+ * ORXONOX - the hottest 3D action shooter ever to exist
+ * > www.orxonox.net <
+ *
+ *
+ * License notice:
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Author:
+ * Johannes Ritz
+ * Co-authors:
+ * ...
+ *
+ */
+/**
+ @file LastTeamStanding.h
+ @brief Declaration of the Gametype "Last Team Standing".
+*/
+
+#ifndef _LastTeamStanding_H__
+#define _LastTeamStanding_H__
+
+#include "OrxonoxPrereqs.h"
+#include "TeamDeathmatch.h"
+#include <map>
+#include <vector>
+
+//TODO: Hud doesn load; problem with destructor; teams are not assigned properly;
+
+namespace orxonox
+{
+ class _OrxonoxExport LastTeamStanding : public TeamDeathmatch
+ {
+ /**
+ @brief
+ Last Team Standing is a gametype where each team fights against each other, until one team remains.
+ @author
+ Johannes Ritz
+ */
+ protected:
+ int lives; //!< Standard amount of lives. Each player starts a game with so many lives.
+ std::map< PlayerInfo*, int > playerLives_; //!< Each player's lives are stored here.
+ std::vector<int> eachTeamsPlayers; //!<Number of players in each team.
+ int teamsAlive; //!< Counter counting teams with more than one player remaining.
+//Data for CamperPunishment
+ float timeRemaining; //!< Each player has a certain time where he or she has to hit an opponent or will be punished.
+ std::map<PlayerInfo*, float> timeToAct_; //!< Each player's time till she/he will be punished is stored here.
+ bool bNoPunishment; //!< Config value to switch off Punishment function if it is set to true.
+ bool bHardPunishment; //!< Switches between damage and death as punishment.
+ float punishDamageRate; //!< Makes Damage adjustable.
+//Data for RespawnDelay
+ float respawnDelay; //!<Time in seconds when a player will respawn after death.
+ std::map<PlayerInfo*, float> playerDelayTime_; //!< Stores each Player's delay time.
+ std::map<PlayerInfo*, bool> inGame_; //!< Indicates each Player's state.
+
+ virtual void spawnDeadPlayersIfRequested(); //!< Prevents dead players to respawn.
+ virtual int getMinLives(); //!< Returns minimum of each player's lives; players with 0 lives are skipped;
+
+ public:
+ LastTeamStanding(BaseObject* creator); //!< Default Constructor.
+ virtual ~LastTeamStanding(); //!< Default Destructor.
+
+ virtual void playerEntered(PlayerInfo* player); //!< Initializes values.
+ virtual bool playerLeft(PlayerInfo* player); //!< Manages all local variables.
+
+ virtual bool allowPawnDeath(Pawn* victim, Pawn* originator = 0); //!< Manages each player's lost lives.
+ virtual bool allowPawnDamage(Pawn* victim, Pawn* originator = 0); //!< If a player shoot's an opponent, his punishment countdown will be resetted.
+ virtual void playerStartsControllingPawn(PlayerInfo* player, Pawn* pawn); //!< Resets punishment time and respawn delay.
+ void tick (float dt); //!< used to end the game
+ virtual void end(); //!< Sends an end message.
+ void punishPlayer(PlayerInfo* player); //!< Function in order to kill a player. Punishment for hiding longer than "timeRemaining".
+ int playerGetLives(PlayerInfo* player); //!< getFunction for the map "playerLives_".
+ inline int getNumTeamsAlive() const//!< Returns the number of players that are still alive.
+ {return this->teamsAlive;}
+ void setConfigValues(); //!< Makes values configurable.
+
+ };
+}
+
+#endif /* _LastTeamStanding_H__ */
More information about the Orxonox-commit
mailing list