Project::OSiRiON

If you box-select a number of entities, and you want to move them, you have to drag the active selected entity.
CLicking any other selected (highlighted) entity will deselect the other members in the selection.

Dragging any member of the selection should work.

The camera handling is rather confusing. It would be best to retire the third-person "Turret" view and have a cockpit view and an external, third-person view.

Freelook should still work on both modes, but the camera angle should not be reset when leaving freelook.

TODO

• remove Turret view
• use shift+mousewheel to zoom in/out
• remember freelook angle
• remove 360-degree rotation limitation
• remove control lock (spacebar)
• do not pass ship control events when in a menu

Weapons, shields, armour...

TODO

- Shields & armor
- Mining equipment ?
- Misc equipment

DONE

- Weapons

Master server and multiplayer server list.

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

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.

Support for computer-controlled allies and opponents.

- Better AI control
- Dynamic patrols

Support for factions and player reputation.

Reputation influences prices, docking rights and NPC hostility.

TODO
- trade reputation
- player faction membership

DONE
- factions.ini
- faction colors
- faction reputation
- player reputation
- entity faction
- game:: player reputation savegame
- client:: reputation window window: stats refresh + reputation bars
- player reputation network transfer
- entity faction network transfer
- 'give reputation' function
- game:: deny dock on hostile stations
- game:: change reputation if player kills an NPC
- refresh reputation window if player reputation changes

To ease the transition to a multitexturing rendering environment, I propose that we fully adopt Quake 3 shader scripting. Currently, we support a simpler version with a single texture stage in mind.

DONE

- Support for material with multiple layers

TODO

- OpenGL multitexture support
- Improve syntax

Exmaple of current implementation:

shader/path/name
{
qer_editorimage path/to/texture
{
map path/to/texture
entity
}
{
map path/to/glow_texture
fullbright
blendfunc blend
}
}

---------------------------------
Quake 3:

shader/path/name
{
qer_editorimage path/to/texture
other_keywords
{
map path/to/texture
}
{
map path/to/texture2
blendfunc ...
}

The current inventory menu is too confusing.

TODO
- tabs for cargo/weapon/equipment
- show weapon slots
- show mounted weapons inside their slots,
mounting/unmounting a weapon moves it back and forth
between slot and inventory

Pirate base models, to serve as NPC headquarters.
Several generic models are required.

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

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.

The purchase and selling of ship equipment such as weapons.

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

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

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

TODO

- implement all starsystems on the starsystem roadmap

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.

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.

Use: The unfinished jumpgates between Finnmark and Kronenbaden.

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.

Clean up and homogenize material, light, flare, engine and particle color types and flags.

Those fx can be triggered by engine states (trigger_impulse, trigger_engine, trigger_destroyed, ..)
The color can be set as color_entity, color_entity_second, color_entity_third, color_engine, ...

TODO
- review/refactor: lights, flares, materials, and particles should have the some options for
triggers and colortypes.
The parameter names in .map file classes and .material files should be the same

The following issues appear if you're docked at another player's ship

TODO

- If the host docks a planet or a large base and you launch, you'll spawn inside the planet.
- Space dust isn't rendered if the host moves
- Correct undefinied behaviour if the host gets destroyed, docks should be destroyed as well

- Note: In theory, recursivedocking should work (player A docked at B docked at C),
issues should be resolved accordingly

If multiple patch mesh points are in the same place(like on many windows), certain polygons are lit incorrectly on Intel hardware.

Shot taken from netbook with Intel 945G chipset.

If a real-time shadowing method is to be used, sharp stencil shadows would be more in-line with the game's visual style. It apparently can be done with very little code.

At random, if you use 'give ship' while your ship is moving, you can be trapped in a state where you cannot turn or move in any direction. You are still given the new ship, however, and if you use 'give ship' a few more times, you can recover from the problem.

Leaving this as low-priority since 'give ship' is technically a cheat. Setting this as category 'src' because the cause is unknown.