Spring - User contributions [en]

GSoC New rendering system

2010-03-11T23:03:46Z

Imbaczek: /* Difficulty */

= GSoC idea: New Rendering System =

== Why ==
Rendering would be faster and more extensible, making it easier to bring in new features and players. It should help prevent Spring's visuals become 'dated' compared to commercial games running DX11 or OpenGL 3.1. It may eliminate some long-standing rendering bugs.

== Background ==
The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower than shader usage and less flexible.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either through direct loading or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

OpenGL ES 2.0 compatibility should be aimed at where possible.

== Required skills ==
* Knowledge of C++
* Knowledge of OpenGL 2.0 API and GLSL
* Understanding Spring's sync system

== Difficulty ==
Estimated: medium

* Refactor C++ code and classes
* Create new GLSL shaders and integrate some from Lua scripts
* Add threading to renderer
* Remove all direct OpenGL calls from synced (sim) code.
* Push more work onto GPU and use DMA transfers (VBOs) while retaining OpenGL 1.4 code path for intel chipsets
* Reduce/refactor the amount of code paths used for rendering different world objects and model types.
* Use more class overriding for new rendering code (instead of branching)

== Possible Mentor(s) ==

[http://www.example.com FORUMLINK]

[[Google_Summer_of_Code_2010]]

Google Summer of Code 2010

2010-03-11T23:03:34Z

Imbaczek: /* New Rendering System */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== An IDE for Spring game developing ==

Estimated difficulty: medium

At the moment Spring as a game engine project has no dedicated IDE for developing Spring games which would allow easier developing of Spring games.
A new IDE or plugins/addins for an existing IDE like Eclipse would lower the barrier for new developers. Speeding up the developing process and managing the huge amount of files which come with most games would allow developers to focus more on the content than on organization.

The IDE should handle most of the typical Spring files like Lua files, textures and models. A few templates for project startups and Spring file types should be created.
Syntax highlighting, auto-completion (including Spring functions) and text snippets for Lua should be included in the IDE. A texture and model editor which can export/import and modify simple options would be nice, too.

[[GSoC_Spring_IDE]]

== Limited play area ==

Estimated difficulty: medium

Current spring map formats have an harcoded rectangle geometry, also they provide very limited support for defining aestetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game trough the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, Seismic. Some can be jammed, some can not. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features wich would be then available for all types.

Preferably this all should also be faster than the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium to hard

The Spring engine has it's roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be enough flexible to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in the mind, possibly integrated with spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: hard

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones. (for pathfinder-aware tunnels/teleporting/etc.)

Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: medium

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: medium

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower than shader usage and less flexible.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either trough direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

OpenGL ES 2.0 compatibility should be aimed at where possible.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: medium to hard

Spring's network model implies the existance of a server to host a battle. For various reasons the network link between host and clients can die, so a system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

== New map format ==

Estimated difficulty: hard

Spring at the moment has two map formats - SM2 which is the most used, but old, rather inflexible and requires a lot of storage. SM3 is newer but incomplete.

The goal of this proposal would be a map format that doesn't consist of a giant texture layered on top of a basic height mesh, but something smarter that also supports correct texturing on vertical slopes (ie. no streching.) Look at e.g. DOW2 for inspiration. Not supporting heightmap deformation is acceptable, provided the pros outweigh the cons.

[[GSoC_New_map_format]]

GSoC:student application

2010-03-11T23:03:13Z

Imbaczek: /* Google Summer of Code student application */

= Google Summer of Code student application =

# Basics
## Write a small introduction to yourself.
## State your preferred email address.
## If you have chosen a nick for IRC, the Spring forums and the Spring game lobby, what is it?
## Why do you want to participate in summer of code?
## What are you studying, subject, level and school?
## What country are you from, at what time are you most likely to be able to join IRC?
## Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.
# Experience
## What programs/software have you worked on before?
## Have you developed software in a team environment before? (As opposed to hacking on something on your own)
## Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?
## Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.
## Gaming experience - Are you a gamer?
## If you have contributed any patches to Spring, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC.
# Communication skills
## Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.
## What spoken languages are you fluent in?
## Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.
## Do you give constructive advice?
## Do you receive advice well?
## Are you good at sorting useful criticisms from useless ones?
## How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want
# Project
## Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?
## If you have invented your own project, please describe the project and the scope.
## Why did you choose this project?
## Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".
## Include as much technical detail about your implementation as you can
## What do you expect to gain from this project?
## What would make you stay in the Spring community after the conclusion of SOC?
# Practical considerations
## Are you familiar with any of the following tools or languages?
##* Git (used for all commits)
##* C++ (language used for all the normal source code)
##* STL, Boost, Sdl, Lua (C/C++ libraries used by Spring)
##* build environments (eg. cmake, scons)
## Which tools do you normally use for development? Why do you use them?
## What programming languages are you fluent in?
## Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

[[Google_Summer_of_Code_2010]]

Google Summer of Code 2010

2010-03-11T22:58:29Z

Imbaczek: /* Project proposals */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== An IDE for Spring game developing ==

Estimated difficulty: medium

At the moment Spring as a game engine project has no dedicated IDE for developing Spring games which would allow easier developing of Spring games.
A new IDE or plugins/addins for an existing IDE like Eclipse would lower the barrier for new developers. Speeding up the developing process and managing the huge amount of files which come with most games would allow developers to focus more on the content than on organization.

The IDE should handle most of the typical Spring files like Lua files, textures and models. A few templates for project startups and Spring file types should be created.
Syntax highlighting, auto-completion (including Spring functions) and text snippets for Lua should be included in the IDE. A texture and model editor which can export/import and modify simple options would be nice, too.

[[GSoC_Spring_IDE]]

== Limited play area ==

Estimated difficulty: medium

Current spring map formats have an harcoded rectangle geometry, also they provide very limited support for defining aestetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game trough the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, Seismic. Some can be jammed, some can not. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features wich would be then available for all types.

Preferably this all should also be faster than the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium to hard

The Spring engine has it's roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be enough flexible to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in the mind, possibly integrated with spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: hard

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones. (for pathfinder-aware tunnels/teleporting/etc.)

Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: medium

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: below medium

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower than shader usage and less flexible.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either trough direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

OpenGL ES 2.0 compatibility should be aimed at where possible.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: medium to hard

Spring's network model implies the existance of a server to host a battle. For various reasons the network link between host and clients can die, so a system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

== New map format ==

Estimated difficulty: hard

Spring at the moment has two map formats - SM2m which is the most used, but old, rather inflexible and requires a lot of storage. SM3 is newer but incomplete.

The goal of this proposal would be a map format that doesn't consist of a giant texture layered on top of a basic height mesh, but something smarter that also supports correct texturing on vertical slopes (ie. no streching.) Look at e.g. DOW2 for inspiration. Not supporting heightmap deformation is acceptable, provided the pros outweigh the cons.

[[GSoC_New_map_format]]

GSoC:student application

2010-03-11T22:52:45Z

Imbaczek: New page: = Google Summer of Code student application = # Basics ## Write a small introduction to yourself. ## State your preferred email address. ## If you have chosen a nick for IRC, the Spring f...

GSoC New rendering system

2010-03-11T21:54:24Z

Imbaczek: /* Difficulty */

= GSoC idea: New Rendering System =

== Why ==
Rendering will be faster and more extensible, making it easier to bring in new features and players. It should help prevent Spring's visuals become 'dated' compared to commercial games running DX11 or OpenGL 3.1. It may eliminate some long-standing rendering bugs.

== Background ==
The Spring rendering engine uses a lot FFP (fixed function pipeline) OpenGL functions, this model is becoming deprecated, it is generally slower than shader usage and less flexible.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either trough direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

OpenGL ES 2.0 compatibility should be aimed at where possible.

== Required skills ==
* Knowledge of C++
* Knowledge of OpenGL 2.0 API and GLSL
* Understanding Spring's sync system

== Difficulty ==
Estimated: below medium

* Refactor C++ code and classes
* Create new GLSL shaders and integrate some from Lua scripts
* Add threading to renderer
* Remove all direct OpenGL calls from synced (sim) code.
* Push more work onto GPU and use DMA transfers (VBOs) while retaining OpenGL 1.4 code path for intel chipsets
* Reduce/refactor the amount of code paths used for rendering different world objects and model types.
* Use more class overriding for new rendering code (instead of branching)

== Possible Mentor(s) ==

[http://www.example.com FORUMLINK]

[[Google_Summer_of_Code_2010]]

GSoC Smarter pathfinder

2010-03-11T21:49:16Z

Imbaczek:

= GSoC idea: Smarter pathfinder =

== Why ==
Current pathfinder is rather inflexible and inefficient.

== Background ==
Spring's pathfinder uses a 2d grid and is somewhat limited in functionality. A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones. (for pathfinder-aware tunnels/teleporting/etc.)

Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

== Required skills ==
* knowledge of graphs and pathfinding (particularly navigation graphs)
* C++ and Lua/C api

== Difficulty ==
Estimated: hard

The pathfinder is one of the better encapsulated subsystems in spring; generally, there will only be minor changes required in the rest of the engine, if any. There's a lot of algorithmic work to do under the hood, though:
* Cooperative pathfinding exists in a very scant form and could be greatly improved
* Navigation mesh could be introduced for better paths and faster searches - at the cost of generating the mesh and updating it online due to terrain modification

== Possible Mentor(s) ==

[http://www.example.com FORUMLINK]

[[Google_Summer_of_Code_2010]]

GSoC Engine resource abstraction

2010-03-11T21:14:03Z

Imbaczek: /* Difficulty */

= GSoC idea: Engine level abstraction of resources =

== Why ==
So game designers can reuse engine resource system and avoid all weird behaviours caused by the hardcoded assumptions all over the place.

== Background ==
The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be enough flexible to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to modify it's state.

== Required skills ==
* C++
* Lua
* OpenGL skills to adapt the engine gui (optional)

== Difficulty ==
Estimated: medium to hard

* The new system should completely supersede the current
* Sync check should be adapted to hash the new resource system
* Hardcoded assumptions such as cost-based targeting should be removed completely

== Possible Mentor(s) ==

[http://www.example.com FORUMLINK]

[[Google_Summer_of_Code_2010]]

Google Summer of Code 2010

2010-03-11T21:13:50Z

Imbaczek: /* Engine level abstraction of resources */

[[Image:GSOC.png]]

= Google Summer of Code 2010 project proposals =

This is a list of projects suggested to students willing to work on the Spring engine during the summer of 2010.

== Limited play area ==

Estimated difficulty: medium

Current spring map formats have an harcoded rectangle geometry, also they provide very limited support for defining aestetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game trough the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, Seismic. Some can be jammed, some can not. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features wich would be then available for all types.

Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium to hard

The Spring engine has it's roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be enough flexible to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in the mind, possibly integrated with spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: hard

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones. (for pathfinder-aware tunnels/teleporting/etc.)

Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: medium

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: below medium

The Spring rendering engine uses a lot FFP (fixed function pipeline) OpenGL functions, this model is becoming deprecated, it is generally slower than shader usage and less flexible.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either trough direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

OpenGL ES 2.0 compatibility should be aimed at where possible.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: medium to hard

Spring's network model implies the existance of a server to host a battle, because of various reasons, the network link between host and clients can die, a system should be designed to allow manual and/or automatic switch game host (possibly using an existing player after testing load handling capabilities), and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

GSoC Engine resource abstraction

2010-03-11T21:13:03Z

Imbaczek: /* Difficulty */

= GSoC idea: Engine level abstraction of resources =

== Why ==
So game designers can reuse engine resource system and avoid all weird behaviours caused by the hardcoded assumptions all over the place.

== Background ==
The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be enough flexible to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to modify it's state.

== Required skills ==
* C++
* Lua
* OpenGL skills to adapt the engine gui (optional)

== Difficulty ==
Estimated: medium

* The new system should completely supersede the current
* Sync check should be adapted to hash the new resource system
* Hardcoded assumptions such as cost-based targeting should be removed completely

== Possible Mentor(s) ==

[http://www.example.com FORUMLINK]

[[Google_Summer_of_Code_2010]]

GSoC Engine resource abstraction

2010-03-11T21:12:34Z

Imbaczek: /* Required skills */

= GSoC idea: Engine level abstraction of resources =

== Why ==
So game designers can reuse engine resource system and avoid all weird behaviours caused by the hardcoded assumptions all over the place.

== Background ==
The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be enough flexible to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to modify it's state.

== Required skills ==
* C++
* Lua
* OpenGL skills to adapt the engine gui (optional)

== Difficulty ==
Estimated: medium

* The new system should completely superseed current
* sync check should be adapted to hash the new resource system
* hardcoded assumptions such as cost-based targeting should be removed completely

== Possible Mentor(s) ==

[http://www.example.com FORUMLINK]

[[Google_Summer_of_Code_2010]]

GSoC Engine resource abstraction

2010-03-11T21:12:14Z

Imbaczek: /* Background */

= GSoC idea: Engine level abstraction of resources =

== Why ==
So game designers can reuse engine resource system and avoid all weird behaviours caused by the hardcoded assumptions all over the place.

== Background ==
The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be enough flexible to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to modify it's state.

== Required skills ==
* C++
* Lua
* OpenGL skills to adapt the engine gui ( optional )

== Difficulty ==
Estimated: medium

* The new system should completely superseed current
* sync check should be adapted to hash the new resource system
* hardcoded assumptions such as cost-based targeting should be removed completely

== Possible Mentor(s) ==

[http://www.example.com FORUMLINK]

[[Google_Summer_of_Code_2010]]

GSoC Engine resource abstraction

2010-03-11T21:10:51Z

Imbaczek: /* Background */

= GSoC idea: Engine level abstraction of resources =

== Why ==
So game designers can reuse engine resource system and avoid all weird behaviours caused by the hardcoded assumptions all over the place.

== Background ==
The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be enough flexible to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

== Required skills ==
* C++
* Lua
* OpenGL skills to adapt the engine gui ( optional )

== Difficulty ==
Estimated: medium

* The new system should completely superseed current
* sync check should be adapted to hash the new resource system
* hardcoded assumptions such as cost-based targeting should be removed completely

== Possible Mentor(s) ==

[http://www.example.com FORUMLINK]

[[Google_Summer_of_Code_2010]]

GSoC Sensor handling redesign

2010-03-11T21:10:03Z

Imbaczek: /* Difficulty */

= GSoC idea: Sensor handling redesign / simplification =

== Why ==
Game designers have indicated a more generic sensor system would be desired, and a number of desired features have, over time, been mentioned.

== Background ==
Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, Seismic. Some can be jammed, some can not. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features wich would be then available for all types.

Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

== Required skills ==
* Being able to program in C++
* Bachelor level algorithmics knowledge
* Bachelor level software engineering knowledge

== Difficulty ==
Estimated: hard

* A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems to reduce amount of code per functionality.
* It should be possible to specify different behaviours for sensors of either type: is it based on e.g. simple 2d or 3d distance check or terrain raycast (i.e. LOS).
* It should be possible to use multiple different types of radar in one game (possibly current seismic sensors system could be a type of radar too, internally).
* It should be possible to use "reversed LOS" for the sensor (instead of sight distance, detection distance is used - like cloak now).
* There should be a generic mechanism for jamming (removing coverage of an area) and stealth (only this unit is not detectable using this sensor) for each type of sensor.
* There should be support for Lua defined areas that block sensors operating in that area, hide units in that area for certain sensors, or block the rays of terrain-raycasting sensors.
* There should be support for creating false positives and false negatives using Lua.

== Possible Mentor(s) ==

[http://www.example.com FORUMLINK]

[[Google_Summer_of_Code_2010]]

GSoC Sensor handling redesign

2010-03-11T21:09:23Z

Imbaczek: /* Difficulty */

= GSoC idea: Sensor handling redesign / simplification =

== Why ==
Game designers have indicated a more generic sensor system would be desired, and a number of desired features have, over time, been mentioned.

== Background ==
Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, Seismic. Some can be jammed, some can not. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features wich would be then available for all types.

Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

== Required skills ==
* Being able to program in C++
* Bachelor level algorithmics knowledge
* Bachelor level software engineering knowledge

== Difficulty ==
Estimated: hard

* A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems to reduce amount of code per functionality.
* It should be possible to specify different behaviours for sensors of either type: is it based on e.g. simple 2d or 3d distance check or terrain raycast (i.e. LOS).
* It should be possible to use multiple different types of radar in one game (possibly current seismic sensors system could be a type of radar too, internally).
* It should be possible to use "reversed LOS" for the sensor (instead of sight distance, detection distance is used (like cloak now)).
* There should be a generic mechanism for jamming (removing coverage of an area) and stealth (only this unit is not detectable using this sensor) for each type of sensor.
* There should be support for Lua defined areas that block sensors operating in that area, hide units in that area for certain sensors, or block the rays of terrain-raycasting sensors.
* There should be support for creating false positives and false negatives using Lua.

== Possible Mentor(s) ==

[http://www.example.com FORUMLINK]

[[Google_Summer_of_Code_2010]]

Google Summer of Code 2010

2010-03-11T20:46:13Z

Imbaczek: /* Reconnect / Host change during a match */

[[Image:GSOC.png]]

= Google Summer of Code 2010 project proposals =

This is a list of projects suggested to students willing to work on the Spring engine during the summer of 2010.

== Limited play area ==

Estimated difficulty: medium

Current spring map formats have an harcoded rectangle geometry, also they provide very limited support for defining aestetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game trough the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, Seismic. Some can be jammed, some can not. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features wich would be then available for all types.

Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium

The Spring engine has it's roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be enough flexible to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in the mind, possibly integrated with spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: hard

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones. (for pathfinder-aware tunnels/teleporting/etc.)

Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: medium

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: below medium

The Spring rendering engine uses a lot FFP (fixed function pipeline) OpenGL functions, this model is becoming deprecated, it is generally slower than shader usage and less flexible.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either trough direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

OpenGL ES 2.0 compatibility should be aimed at where possible.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: medium to hard

Spring's network model implies the existance of a server to host a battle, because of various reasons, the network link between host and clients can die, a system should be designed to allow manual and/or automatic switch game host (possibly using an existing player after testing load handling capabilities), and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-11T20:45:46Z

Imbaczek: /* New Rendering System */

[[Image:GSOC.png]]

= Google Summer of Code 2010 project proposals =

This is a list of projects suggested to students willing to work on the Spring engine during the summer of 2010.

== Limited play area ==

Estimated difficulty: medium

Current spring map formats have an harcoded rectangle geometry, also they provide very limited support for defining aestetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game trough the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, Seismic. Some can be jammed, some can not. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features wich would be then available for all types.

Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium

The Spring engine has it's roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be enough flexible to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in the mind, possibly integrated with spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: hard

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones. (for pathfinder-aware tunnels/teleporting/etc.)

Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: medium

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: below medium

The Spring rendering engine uses a lot FFP (fixed function pipeline) OpenGL functions, this model is becoming deprecated, it is generally slower than shader usage and less flexible.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either trough direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

OpenGL ES 2.0 compatibility should be aimed at where possible.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: medium to hard

Spring's network model implies the existance of a server to host a battle, because of various reasons, the network link between host and clients can die, a system should be designed to allow manual and/or automatic switch game host ( possibly using an existing player after testing load handling capabilities ), and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-11T20:44:17Z

Imbaczek: /* More AI interfaces */

[[Image:GSOC.png]]

= Google Summer of Code 2010 project proposals =

This is a list of projects suggested to students willing to work on the Spring engine during the summer of 2010.

== Limited play area ==

Estimated difficulty: medium

Current spring map formats have an harcoded rectangle geometry, also they provide very limited support for defining aestetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game trough the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, Seismic. Some can be jammed, some can not. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features wich would be then available for all types.

Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium

The Spring engine has it's roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be enough flexible to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in the mind, possibly integrated with spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: hard

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones. (for pathfinder-aware tunnels/teleporting/etc.)

Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: medium

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: below medium

The Spring rendering engine uses a lot FFP (fixed function pipeline) OpenGL functions, this model is becoming deprecated, it is generally slower than shader usage and less flexible.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either trough direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: medium to hard

Spring's network model implies the existance of a server to host a battle, because of various reasons, the network link between host and clients can die, a system should be designed to allow manual and/or automatic switch game host ( possibly using an existing player after testing load handling capabilities ), and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

GSoC Limited play area

2010-03-11T20:43:02Z

Imbaczek: /* Difficulty */

= GSoC idea: Limited play area =

== Why ==
So the mappers can define which part of the map is designed for gameplay and which for the looks.

== Background ==
Current spring map formats have a harcoded rectangle geometry. They also provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game trough the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

== Required skills ==
* grep
* C++ and Lua/C api

== Difficulty ==
Estimated: medium

The code pretty much everywhere assumes that the map top left is always at (0, 0) and bottom right at (width, height). The most difficult part is identifying all places that check for point-in-map condition and determining whether they should be converted to the new limited map area or left as-is (e.g. for drawing.)

== Possible Mentor(s) ==

[http://www.example.com FORUMLINK]

[[Google_Summer_of_Code_2010]]

GSoC Limited play area

2010-03-11T20:30:26Z

Imbaczek: /* Why */

= GSoC idea: Limited play area =

== Why ==
So the mappers can define which part of the map is designed for gameplay and which for the looks.

== Background ==
Current spring map formats have a harcoded rectangle geometry. They also provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game trough the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

== Required skills ==
* grep
* C++ and Lua/C api

== Difficulty ==
some blabla

== Possible Mentor(s) ==

[http://www.example.com FORUMLINK]

[[Google_Summer_of_Code_2010]]

GSoC Limited play area

2010-03-11T20:29:59Z

Imbaczek: /* Background */

= GSoC idea: Limited play area =

== Why ==
so the mappers can define which part of the map is designed for gameplay and which for the looks

== Background ==
Current spring map formats have a harcoded rectangle geometry. They also provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game trough the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

== Required skills ==
* grep
* C++ and Lua/C api

== Difficulty ==
some blabla

== Possible Mentor(s) ==

[http://www.example.com FORUMLINK]

[[Google_Summer_of_Code_2010]]

GSoC Limited play area

2010-03-11T20:27:59Z

Imbaczek:

= GSoC idea: Limited play area =

== Why ==
so the mappers can define which part of the map is designed for gameplay and which for the looks

== Background ==
Current spring map formats have a harcoded rectangle geometry. They also provide very limited support for defining aesthetics of the surrounding environment outside the play area. 
The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions. 
The restriction shapes should be readable and changeable mid-game trough the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented. 

== Required skills ==
* grep
* C++ and Lua/C api

== Difficulty ==
some blabla

== Possible Mentor(s) ==

[http://www.example.com FORUMLINK]

[[Google_Summer_of_Code_2010]]

Google Summer of Code 2010

2010-03-11T20:17:49Z

Imbaczek:

= Google Summer of Code 2010 project proposals =

This is a list of projects suggested to students willing to work on the Spring engine during the summer of 2010.

== Limited play area ==

Estimated difficulty: medium

Current spring map formats have an harcoded rectangle geometry, also they provide very limited support for defining aestetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game trough the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, Seismic. Some can be jammed, some can not. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features wich would be then available for all types.

Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium

The Spring engine has it's roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be enough flexible to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in the mind, possibly integrated with spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: hard

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones. (for pathfinder-aware tunnels/teleporting/etc.)

Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: medium

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience ( for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot ).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: below medium

The Spring rendering engine uses a lot FFP (fixed function pipeline) OpenGL functions, this model is becoming deprecated, it is generally slower than shader usage and less flexible.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either trough direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: medium to hard

Spring's network model implies the existance of a server to host a battle, because of various reasons, the network link between host and clients can die, a system should be designed to allow manual and/or automatic switch game host ( possibly using an existing player after testing load handling capabilities ), and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-11T20:15:26Z

Imbaczek:

== Limited play area ==

Estimated difficulty: medium

Current spring map formats have an harcoded rectangle geometry, also they provide very limited support for defining aestetics of the surrounding environment outside the play area.

The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.

The restriction shapes should be readable and changeable mid-game trough the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, Seismic. Some can be jammed, some can not. Some respect terrain, and some are always circular.

A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features wich would be then available for all types.

Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium

The Spring engine has it's roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be enough flexible to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in the mind, possibly integrated with spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: hard

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones. (for pathfinder-aware tunnels/teleporting/etc.)

Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: medium

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience ( for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot ).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: below medium

The Spring rendering engine uses a lot FFP (fixed function pipeline) OpenGL functions, this model is becoming deprecated, it is generally slower than shader usage and less flexible.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either trough direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: medium to hard

Spring's network model implies the existance of a server to host a battle, because of various reasons, the network link between host and clients can die, a system should be designed to allow manual and/or automatic switch game host ( possibly using an existing player after testing load handling capabilities ), and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-11T20:12:16Z

Imbaczek: added estimated difficulties

== Limited play area ==

Estimated difficulty: medium

Current spring map formats have an harcoded rectangle geometry, also they provide very limited support for defining aestetics of the surrounding environment outside the play area. 
The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions. 
The restriction shapes should be readable and changeable mid-game trough the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented. 

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, Seismic. Some can be jammed, some can not. Some respect terrain, and some are always circular. 
A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code per functionality, and eventually add additional features wich would be then available for all types. 
Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features. 

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium

The Spring engine has it's roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places. 
The old system needs to be replaced, the new one should be enough flexible to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles. 
The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it. 

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces ( lobbies ) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate. 
A new, Lua scriptable lobby should be implemented with customization and control in the mind, possibly integrated with spring codebase and/or running as a separate process overlaying to the game's UI. 
Optionally, the engine's start screen should be replaced and integrated with it. 

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: hard

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons. 
Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones. (for pathfinder-aware tunnels/teleporting/etc.) 
Preferably this all should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features. 

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: medium

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported. 
Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience ( for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot ). 

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: below medium

The Spring rendering engine uses a lot FFP (fixed function pipeline) OpenGL functions, this model is becoming deprecated, it is generally slower than shader usage and less flexible.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats ( backwards compatibility with current available formats is mandatory either trough direct load or automatic conversion to the new types ) and eventually introduce some graphic enhancing features ( bump mapping, normal mapping, multitexturing, etc.)

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Spring's network model implies the existance of a server to host a battle, because of various reasons, the network link between host and clients can die, a system should be designed to allow manual and/or automatic switch game host ( possibly using an existing player after testing load handling capabilities ), and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Lua MoveCtrl

2009-12-26T23:10:15Z

Imbaczek: /* MoveType-specific */

[[Engine_Development|Development]] < [[Lua_Scripting|Lua Scripting]] < {{FULLPAGENAME}}

== Enable/Disable ==
'''Spring.MoveCtrl.Enable'''
( number unitID ) -> nil

'''Spring.MoveCtrl.Disable'''
( number unitID ) -> nil

== Tags ==
'''Spring.MoveCtrl.SetTag'''
( number unitID, number tag ) -> nil

'''Spring.MoveCtrl.GetTag'''
( number unitID ) -> nil

'''Spring.MoveCtrl.SetProgressState'''
( number unitID, number state | "done" | "active" | "failed" ) -> nil

== Physics ==
'''Spring.MoveCtrl.SetGravity'''
( number unitID, number gravity ) -> nil

'''Spring.MoveCtrl.SetDrag'''
( number unitID, number gravity ) -> nil

'''Spring.MoveCtrl.SetGroundOffset'''
( number unitID, number offset ) -> nil

'''Spring.MoveCtrl.SetWindFactor'''
( number unitID, number windFactor ) -> nil

'''Spring.MoveCtrl.SetPhysics'''
( number unitID,
number posX, number posY, number posZ,
number velX, number velY, number velZ,
number rotX, number rotY, number rotZ ) -> nil

'''Spring.MoveCtrl.SetPosition'''
( number unitID,
number posX, number posY, number posZ ) -> nil

'''Spring.MoveCtrl.SetVelocity'''
( number unitID,
number velX, number velY, number velZ ) -> nil

'''Spring.MoveCtrl.SetRelativeVelocity'''
( number unitID,
number relvelX, number relvelY, number relvelZ ) -> nil

'''Spring.MoveCtrl.SetRotation'''
( number unitID,
number rotX, number rotY, number rotZ ) -> nil

'''Spring.MoveCtrl.SetRotationVelocity'''
( number unitID,
number rotVelX, number rotVelY, number rotVelZ ) -> nil

'''Spring.MoveCtrl.SetRotationOffset'''
( number unitID,
number rotOffX, number rotOffY, number rotOffZ ) -> nil

'''Spring.MoveCtrl.SetHeading'''
( number unitID, number heading ) -> nil

== Options ==
'''Spring.MoveCtrl.SetNoBlocking'''
( number unitID, boolean noblock ) -> nil

'''Spring.MoveCtrl.SetLimits'''
( number unitID,
number minX, number minY, number minZ,
number maxX, number maxY, number maxZ ) -> nil

'''Spring.MoveCtrl.SetTrackSlope'''
( number unitID, boolean trackslope ) -> nil

'''Spring.MoveCtrl.SetTrackGround'''
( number unitID, boolean noblock ) -> nil

'''Spring.MoveCtrl.SetLeaveTracks'''
( number unitID, boolean leavetracks ) -> nil

'''Spring.MoveCtrl.SetExtrapolate'''
( number unitID, boolean on ) -> nil

'''Spring.MoveCtrl.SetShotStop'''
( number unitID, boolean shotstop ) -> nil

'''Spring.MoveCtrl.SetSlopeStop'''
( number unitID, boolean slopestop ) -> nil

'''Spring.MoveCtrl.SetCollideStop'''
( number unitID, boolean collidestop ) -> nil

== MoveType-specific ==
NOTE: all Set*MoveTypeData functions support the following number keys:

maxSpeed
maxWantedSpeed
repairBelowHealth

'''Spring.MoveCtrl.SetAirMoveTypeData''' - new in version 0.81
( number unitID, string key, value ) -> nil
( number unitID, table values ) -> nil
supported keys:
numbers:
wantedHeight
myGravity
maxBank
maxPitch
turnRadius
maxAcc
maxAileron
maxElevator
maxRudder
booleans:
collide
useSmoothMesh
NOTE: not all keys and not all values may work correctly.
[[SetMoveTypeDataExample|Example usage]]

'''Spring.MoveCtrl.SetGroundMoveTypeData''' - new in version 0.81
( number unitID, string key, value ) -> nil
( number unitID, table values ) -> nil
supported keys:
numbers:
baseTurnRate
turnRate
accRate
decRate
maxReverseSpeed
wantedSpeed
requestedSpeed
requestedTurnRate
booleans:
floatOnWater
NOTE: not all keys and not all values may work correctly.
[[SetMoveTypeDataExample|Example usage]]

'''Spring.MoveCtrl.SetGunshipMoveTypeData''' - new in version 0.81
( number unitID, string key, value ) -> nil
( number unitID, table values ) -> nil
supported keys:
numbers:
wantedHeight
turnRate
accRate
decRate
altitudeRate
currentBank
currentPitch
breakDistance
booleans:
collide
useSmoothMesh
bankingAllowed
dontLand
NOTE: not all keys and not all values may work correctly.
[[SetMoveTypeDataExample|Example usage]]

SetMoveTypeDataExample Example usage

2009-12-26T19:15:35Z

Imbaczek: SetMoveTypeDataExample Example usage moved to SetMoveTypeDataExample: brainfart

#REDIRECT [[SetMoveTypeDataExample]]

SetMoveTypeDataExample

2009-12-26T19:15:35Z

Imbaczek: SetMoveTypeDataExample Example usage moved to SetMoveTypeDataExample: brainfart

<pre>

function gadget:GetInfo()
return {
name = "FlashTurnRate",
desc = "Adds an option for flashes and friends to turn faster but go slower",
author = "Baczek",
date = "26 Dec 2009",
license = "GNU GPL, v2 or later",
layer = 0,
enabled = true -- loaded by default?
}
end

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------

if (not gadgetHandler:IsSyncedCode()) then
return
end

local EditUnitCmdDesc = Spring.EditUnitCmdDesc
local FindUnitCmdDesc = Spring.FindUnitCmdDesc
local InsertUnitCmdDesc = Spring.InsertUnitCmdDesc
local GiveOrderToUnit = Spring.GiveOrderToUnit
local SetUnitNeutral = Spring.SetUnitNeutral
local GetUnitMoveTypeData = Spring.GetUnitMoveTypeData
local SetGroundMoveTypeData = Spring.MoveCtrl.SetGroundMoveTypeData
local SetGunshipMoveTypeData = Spring.MoveCtrl.SetGunshipMoveTypeData

local FLASH = {
[UnitDefNames["armflash"].id] = true,
[UnitDefNames["corgator"].id] = true,
[UnitDefNames["armatlas"].id] = true,
}

local flashList = {}

local CMD_SET_TR = 34581

local turnCmd = {
id = CMD_SET_TR,
name = "flashTurnRate",
action = "flashTurnRate",
type = CMDTYPE.ICON_MODE,
tooltip = "Changes the turn rate of the Flash",
params = { '0', ' Lo ', ' Hi '}
}

function gadget:UnitCreated(unitID, unitDefID, unitTeam, builderID)
if FLASH[unitDefID] then
InsertUnitCmdDesc(unitID, 500, turnCmd)
local tr = UnitDefs[unitDefID].turnRate
local ms = UnitDefs[unitDefID].speed
flashList[unitID] = {orgturnrate=tr, orgspeed=ms}
end
end

function gadget:UnitDestroyed(unitID, unitDefID, unitTeam)
flashList[unitID] = nil
end

function gadget:AllowCommand(unitID, unitDefID, teamID, cmdID, cmdParams, cmdOptions)
if FLASH[unitDefID] then
if (cmdID == CMD_SET_TR) then
local mt = GetUnitMoveTypeData(unitID)
Spring.Echo("turnRate="..tostring(mt.turnRate))
if mt.name ~= "ground" and mt.name ~= "gunship" then return false end
local cmdDescID = FindUnitCmdDesc(unitID, CMD_SET_TR)
Spring.Echo("cmdparams[1]=" .. tostring(cmdParams[1]))
if mt.name == "ground" then
SetGroundMoveTypeData(unitID, {
turnRate=(1+cmdParams[1]) * flashList[unitID].orgturnrate,
maxSpeed=flashList[unitID].orgspeed / (1+cmdParams[1])
})
elseif mt.name == "gunship" then
-- setting maxSpeed on gunships should automatically adjust
-- brakeDistance
SetGunshipMoveTypeData(unitID, {
turnRate=(1+cmdParams[1]) * flashList[unitID].orgturnrate,
maxSpeed=flashList[unitID].orgspeed / (1+cmdParams[1])
})
end
turnCmd.params[1] = cmdParams[1]
EditUnitCmdDesc(unitID, cmdDescID, turnCmd)
turnCmd.params[1] = 1
return false
end
end
return true
end

</pre>

Lua MoveCtrl

2009-12-26T19:15:18Z

Imbaczek: /* MoveType-specific */ oops

[[Engine_Development|Development]] < [[Lua_Scripting|Lua Scripting]] < {{FULLPAGENAME}}

== Enable/Disable ==
'''Spring.MoveCtrl.Enable'''
( number unitID ) -> nil

'''Spring.MoveCtrl.Disable'''
( number unitID ) -> nil

== Tags ==
'''Spring.MoveCtrl.SetTag'''
( number unitID, number tag ) -> nil

'''Spring.MoveCtrl.GetTag'''
( number unitID ) -> nil

'''Spring.MoveCtrl.SetProgressState'''
( number unitID, number state | "done" | "active" | "failed" ) -> nil

== Physics ==
'''Spring.MoveCtrl.SetGravity'''
( number unitID, number gravity ) -> nil

'''Spring.MoveCtrl.SetDrag'''
( number unitID, number gravity ) -> nil

'''Spring.MoveCtrl.SetGroundOffset'''
( number unitID, number offset ) -> nil

'''Spring.MoveCtrl.SetWindFactor'''
( number unitID, number windFactor ) -> nil

'''Spring.MoveCtrl.SetPhysics'''
( number unitID,
number posX, number posY, number posZ,
number velX, number velY, number velZ,
number rotX, number rotY, number rotZ ) -> nil

'''Spring.MoveCtrl.SetPosition'''
( number unitID,
number posX, number posY, number posZ ) -> nil

'''Spring.MoveCtrl.SetVelocity'''
( number unitID,
number velX, number velY, number velZ ) -> nil

'''Spring.MoveCtrl.SetRelativeVelocity'''
( number unitID,
number relvelX, number relvelY, number relvelZ ) -> nil

'''Spring.MoveCtrl.SetRotation'''
( number unitID,
number rotX, number rotY, number rotZ ) -> nil

'''Spring.MoveCtrl.SetRotationVelocity'''
( number unitID,
number rotVelX, number rotVelY, number rotVelZ ) -> nil

'''Spring.MoveCtrl.SetRotationOffset'''
( number unitID,
number rotOffX, number rotOffY, number rotOffZ ) -> nil

'''Spring.MoveCtrl.SetHeading'''
( number unitID, number heading ) -> nil

== Options ==
'''Spring.MoveCtrl.SetNoBlocking'''
( number unitID, boolean noblock ) -> nil

'''Spring.MoveCtrl.SetLimits'''
( number unitID,
number minX, number minY, number minZ,
number maxX, number maxY, number maxZ ) -> nil

'''Spring.MoveCtrl.SetTrackSlope'''
( number unitID, boolean trackslope ) -> nil

'''Spring.MoveCtrl.SetTrackGround'''
( number unitID, boolean noblock ) -> nil

'''Spring.MoveCtrl.SetLeaveTracks'''
( number unitID, boolean leavetracks ) -> nil

'''Spring.MoveCtrl.SetExtrapolate'''
( number unitID, boolean on ) -> nil

'''Spring.MoveCtrl.SetShotStop'''
( number unitID, boolean shotstop ) -> nil

'''Spring.MoveCtrl.SetSlopeStop'''
( number unitID, boolean slopestop ) -> nil

'''Spring.MoveCtrl.SetCollideStop'''
( number unitID, boolean collidestop ) -> nil

== MoveType-specific ==

'''Spring.MoveCtrl.SetAirMoveTypeData''' - new in version 0.81
( number unitID, string key, value ) -> nil
( number unitID, table values ) -> nil
supported keys:
numbers:
wantedHeight
myGravity
maxBank
maxPitch
turnRadius
maxAcc
maxAileron
maxElevator
maxRudder
booleans:
collide
useSmoothMesh
NOTE: not all keys and not all values may work correctly.
[[SetMoveTypeDataExample|Example usage]]

'''Spring.MoveCtrl.SetGroundMoveTypeData''' - new in version 0.81
( number unitID, string key, value ) -> nil
( number unitID, table values ) -> nil
supported keys:
numbers:
baseTurnRate
turnRate
accRate
decRate
maxReverseSpeed
wantedSpeed
requestedSpeed
requestedTurnRate
booleans:
floatOnWater
NOTE: not all keys and not all values may work correctly.
[[SetMoveTypeDataExample|Example usage]]

'''Spring.MoveCtrl.SetGunshipMoveTypeData''' - new in version 0.81
( number unitID, string key, value ) -> nil
( number unitID, table values ) -> nil
supported keys:
numbers:
wantedHeight
turnRate
accRate
decRate
altitudeRate
currentBank
currentPitch
breakDistance
booleans:
collide
useSmoothMesh
bankingAllowed
dontLand
NOTE: not all keys and not all values may work correctly.
[[SetMoveTypeDataExample|Example usage]]

Lua MoveCtrl

2009-12-26T19:14:45Z

Imbaczek: /* MoveType-specific */ added link to example usage

[[Engine_Development|Development]] < [[Lua_Scripting|Lua Scripting]] < {{FULLPAGENAME}}

== Enable/Disable ==
'''Spring.MoveCtrl.Enable'''
( number unitID ) -> nil

'''Spring.MoveCtrl.Disable'''
( number unitID ) -> nil

== Tags ==
'''Spring.MoveCtrl.SetTag'''
( number unitID, number tag ) -> nil

'''Spring.MoveCtrl.GetTag'''
( number unitID ) -> nil

'''Spring.MoveCtrl.SetProgressState'''
( number unitID, number state | "done" | "active" | "failed" ) -> nil

== Physics ==
'''Spring.MoveCtrl.SetGravity'''
( number unitID, number gravity ) -> nil

'''Spring.MoveCtrl.SetDrag'''
( number unitID, number gravity ) -> nil

'''Spring.MoveCtrl.SetGroundOffset'''
( number unitID, number offset ) -> nil

'''Spring.MoveCtrl.SetWindFactor'''
( number unitID, number windFactor ) -> nil

'''Spring.MoveCtrl.SetPhysics'''
( number unitID,
number posX, number posY, number posZ,
number velX, number velY, number velZ,
number rotX, number rotY, number rotZ ) -> nil

'''Spring.MoveCtrl.SetPosition'''
( number unitID,
number posX, number posY, number posZ ) -> nil

'''Spring.MoveCtrl.SetVelocity'''
( number unitID,
number velX, number velY, number velZ ) -> nil

'''Spring.MoveCtrl.SetRelativeVelocity'''
( number unitID,
number relvelX, number relvelY, number relvelZ ) -> nil

'''Spring.MoveCtrl.SetRotation'''
( number unitID,
number rotX, number rotY, number rotZ ) -> nil

'''Spring.MoveCtrl.SetRotationVelocity'''
( number unitID,
number rotVelX, number rotVelY, number rotVelZ ) -> nil

'''Spring.MoveCtrl.SetRotationOffset'''
( number unitID,
number rotOffX, number rotOffY, number rotOffZ ) -> nil

'''Spring.MoveCtrl.SetHeading'''
( number unitID, number heading ) -> nil

== Options ==
'''Spring.MoveCtrl.SetNoBlocking'''
( number unitID, boolean noblock ) -> nil

'''Spring.MoveCtrl.SetLimits'''
( number unitID,
number minX, number minY, number minZ,
number maxX, number maxY, number maxZ ) -> nil

'''Spring.MoveCtrl.SetTrackSlope'''
( number unitID, boolean trackslope ) -> nil

'''Spring.MoveCtrl.SetTrackGround'''
( number unitID, boolean noblock ) -> nil

'''Spring.MoveCtrl.SetLeaveTracks'''
( number unitID, boolean leavetracks ) -> nil

'''Spring.MoveCtrl.SetExtrapolate'''
( number unitID, boolean on ) -> nil

'''Spring.MoveCtrl.SetShotStop'''
( number unitID, boolean shotstop ) -> nil

'''Spring.MoveCtrl.SetSlopeStop'''
( number unitID, boolean slopestop ) -> nil

'''Spring.MoveCtrl.SetCollideStop'''
( number unitID, boolean collidestop ) -> nil

== MoveType-specific ==

'''Spring.MoveCtrl.SetAirMoveTypeData''' - new in version 0.81
( number unitID, string key, value ) -> nil
( number unitID, table values ) -> nil
supported keys:
numbers:
wantedHeight
myGravity
maxBank
maxPitch
turnRadius
maxAcc
maxAileron
maxElevator
maxRudder
booleans:
collide
useSmoothMesh
NOTE: not all keys and not all values may work correctly.
[[SetMoveTypeDataExample Example usage]]

'''Spring.MoveCtrl.SetGroundMoveTypeData''' - new in version 0.81
( number unitID, string key, value ) -> nil
( number unitID, table values ) -> nil
supported keys:
numbers:
baseTurnRate
turnRate
accRate
decRate
maxReverseSpeed
wantedSpeed
requestedSpeed
requestedTurnRate
booleans:
floatOnWater
NOTE: not all keys and not all values may work correctly.
[[SetMoveTypeDataExample Example usage]]

'''Spring.MoveCtrl.SetGunshipMoveTypeData''' - new in version 0.81
( number unitID, string key, value ) -> nil
( number unitID, table values ) -> nil
supported keys:
numbers:
wantedHeight
turnRate
accRate
decRate
altitudeRate
currentBank
currentPitch
breakDistance
booleans:
collide
useSmoothMesh
bankingAllowed
dontLand
NOTE: not all keys and not all values may work correctly.
[[SetMoveTypeDataExample Example usage]]

2008-10-11T15:03:07Z

Imbaczek: add link to debugging sync errors