Project::OSiRiON

For finer control of the ship, thrust points should be defined. Instead of the ship being pushed from its origin point, thrust entities would define where the force against the ship is coming from. This would allow for more realistic control.

If more than one entity is used, the thrust power is split between them, or defined by percentage specifically with entity keys.

Improved map menu, implement a 'galactic overview'. Provide galactic coordinates for each zone.
DONE
- add Info record type for zone info
- add Zone location
- add galactic overview to map
- add Zone::info() to network message
- add Zone::flags()
- add Zone::flags() to network message
- add Zone::location() to network message
- add Zone::color() and use it on the galactic map
- add Zone::color() to network message

TODO
- mechanism to request zone map content in multiplayer games
- do not delete client-side ShowOnMap entities in multiplayer games
- show jumpgate links on the galactic map (this requires engine infrastructure)
- mechanism to show only visited places
- map zoom

Windows is extremely slow to load compared to other platforms.

$time ./src/osirion +connect +quit

Linux: 3.3 seconds
Windows: 23.7 seconds

This may be related to the binaries being produced via mingw:

http://osdir.com/ml/gnu.mingw.msys/2006-03/msg00024.html

The best solution is to probably use a Visual C++ toolchain for windows binaries.

Iron commodity model.

Gate Parts commodity model.

http://thoronir.net/osirion/flac_patch.patch

Adds flac support to osirion.

Use: The unfinished jumpgates between Finnmark and Kronenbaden.

The engine needs a way to be able to use a LOD system for performance reasons. I propose a method for this: all brush entities(except worldspawn and misc_model) will have a 'lod' key. The existence of this key in the entity(as in, if it's actually set) tells the engine to enable LOD on the entity. The value for the LOD key would be an integer of 0 through 3. A value of 3 tells the engine to only render the brushes at 75% and above of the detail LOD distance. A value of 2 renders at 50-75%. A value of 1 renders at 25-50%. 0 renders at 0-25% distance. If the key is not set, the brushes will render at all distances(unless set to detail).

This allows two things: Patch meshes get LOD, and LOD gradually degrades with distance.

An alternative would be in patch loading. At model load, bake 4 levels of LOD for the patch meshes into the model, and apply the same rules as above. This may not be desirable because some patch meshes may be required to stay at full LOD for specific reasons.

The only downside to this is that it requires more memory to store the LOD models, but it would cut down on polygon count at render time significantly.

Implement a system where players can send arbitrary signals to each other
(arbitrary, from the point of view of the network protocol). This would be used
to send trade and docking requests, and to replace the silly 'hail' command
with a 'request for private chat'.

In the future this could also be used for other signals, like players declaring
their hostile intent.

It might also be possible to use the signals mechanism
to exchange targetting info.

Extend the current Material system to support GLSL shader programs. Normal map, specular map and glow map support.

Add an improved options menu with video, audio, controls and game settings.

TODO
- video settings
- menu to configure game settings
- merge settings menus into a single, tabbed window

DONE
- menu to configure controls
- menu to configure player settings (name, colors, ..)
- menu to configure graphics settings
- menu to configure audio settings

Add client support for playing background music.It should be possible to define a number of audio tracks per zone,
for the intro, and make provisions for 'battle music'. Investigate support for FLAC, OGG and MP3 audio formats.

Master server and multiplayer server list.

Requires elaborate trade routes, balanced ships and ship hardware, adequate difficulty curve

TODO

- implement all starsystems on the starsystem roadmap

Improved particle systems: weapon effects, engine effects, explosions, smoke...

An improved framework for particle systems unifying all of the above.

DONE
- Particle system code needs to support multiple ejectors per system,
at the moment a particle system is created for each ejector
- Add fine-grained control parameters (alpha start mid end) (radius start mid end) ..
See tremulous particles
- Streak style particles (aka 'trail sprites')
- replace [ejector] with [sprites] [flares] [trail] etc
- ejector thrust trigger
- ejector impulse trigger
- ejector explosion trigger

TODO
- Flame style particles -> needs thinking, how to do it exactly

Weapons, shields, armour...

TODO

- Shields & armor
- Mining equipment ?
- Misc equipment

DONE

- Weapons

Attaching the model/weapon to its associated 'slot' on the ship, and handling the position of said slot.

Models for cannons and turrets to be used in the trade menu.
The colors used on the model should reflect the projectile color.

Laser: red (civilian)
Blaster: yellow (military)
Ion: light blue (lindblade)
Neutron: green
Metrion: pink

TODO
- Proximity mine
- Smart mine

- Laser turret
- Improved laser turret

- Blaster cannon
- Improved blaster cannon
- Blaster turret

- Ion cannon
- Ion turret

- Neutron cannon
- Improved neutron cannon
- Neutron turret
- Improved neutron turret

- Metrion accelerator

- Singularity projector (fires missiles)

DONE
- Dumb mine
- Laser cannon
- Improved laser cannon
- Advanced laser cannon

Pseudo-dynamic economy support.

Ideas:
- Stations and planets are supplied by NPC convoys
- Prices fluctuate according to availability

Fuel System.

The purchase and selling of ship equipment such as weapons.

Implement beam particles for tractoring cargo.

The tracktor beam is currently completely server-side,
this will require additional engine infrastructure or a hack.

Instead of 'beams' a general 'effect' could be created.
It is possible to create an entity holding a model with
a particle system (like projectiles) representing the 'beam-in'
effect (think star trek transporters).

On the other hand, implementing beam style would open the door
for beam weapons.

Since the 'say' chat command is now used to chat in the current zone,
it become useless on dedicated servers because the console does
not have a current system.

There are several ways to solve this:
- Have say behave like shout
- Add an extra parameter to say to indicate the zone to chat in
- Provide a way for the console to set the current zone

Add player-to-player trading.
Implementation:

* Docking player ships should require owner permission
* Player shops
* Player must be able to decide what items to sell, at what prices.
*'tradeable' flag
*shop allows multiple buyers, player-to-player only one.
*Player factory ships, base factories, per-item adjustable conversion rate and ratio.
e.g. 2 units of niobum to 1 superconductor per 30 seconds

Right now the client keyboard input code is hardwired
to a US-QWERTY layout. It should use the native keyboard
layout of the user.

At the same time, the code should be tested for UTF8.