Planet
navi homePPSaboutscreenshotsdownloaddevelopmentforum

Custom Query (296 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (22 - 24 of 296)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Ticket Resolution Summary Owner Reporter
#249 invalid Document all code everybody bknecht
Description

Outline

Not everything is documented in Orxonox. This is bad, since we have a a lot of changes with the developers and undocumented code is shit to read. Just try it once and you will never want to do it to anybody.

Starting point

We have a nice [doxygen Doxygen-Plugin] in our Trac. There you can check out what is already documented and what needs to be better.

How to start

While working you should document your code and find parts of code which are poorly documented. While working with that other code, why not improve its documentation.

Goal

Have well documented code at the end of the semester.

#255 invalid Multiple player support nobody scheusso
Description

Task

Extend Orxonox to support multiple players and implement transmission of the input from clients to the server and synchronization between server and client.

Difficulties

The connection from network part and input system, hud, etc. has to be developed. At the moment we don't have a clean input system, so this will also depend on other tasks.

#291 invalid Extend GameStates nobody rgrieder
Description

The GameState implementation in Orxonox is currently not ready for practical use, especially with the GUI. Currently there are only an "enter" and a "leave" function plus a state transition algorithm. This concept has a serious issue: You cannot load a GameState without entering it. For instance it would be very useful to load GSGUI (GUI GameState) in advance so that entering it requires only very little time.
A suggestion to solve this problem would be to introduce a "load" and an "unload" function, also implemented by the GameState class. The idea is that we will be able to load and unload an arbitrary GameState (with all its parents) from anywhere in the GameState tree, maybe even with console commands. State transitions will stay the same as before.

As a direct consequence to this change we have to rethink the concept in the GUIManager because most of it's code can simply be put in the load/unload functions of GSGUI. There still has to be a mechanism to choose the right GUI sheet. That may require some more thinking…

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Note: See TracQuery for help on using queries.