|
56 | client | Bug Report | Medium | Extremely slow to load. | Assigned | |
Task Description
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. |
|
97 | client | Bug Report | Low | Move default fonts from ui::UI to ui::PAlette | Assigned | |
Task Description
The corrent ui code has default fonts and font size in ui::root(). They have to bo moved to the ui::Palette class and handled like colors and related settings. The initial default fonts should be set in the ui::Pallette class. It might be better to merge ui-style related settings into a single ui::Stylesheet class and read settings from a .css file. |
|
110 | client | Bug Report | Critical | Better camera handling and control | Assigned | |
Task Description
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
|
|
5 | core | Bug Report | Low | 'give ship x' while moving makes player unable to contr... | Assigned | |
Task Description
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. |
|
16 | core | Bug Report | Low | say doesn't work on dedicated servers. | New | |
Task Description
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 |
|
107 | editor | Bug Report | Critical | Moving selection fails unless active entity is clicked | Assigned | |
Task Description
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. |
|
3 | render | Bug Report | Low | Merged patch mesh points produce bad results on Intel | New | |
Task Description
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. |
|
9 | render | Bug Report | Low | Entity axis transformation is not applied to Cubemap te... | New | |
Task Description
Symptom: When rotating the ship, cubemap reflections are not rotated in effect, and stay in the default rotation axis. |
|
74 | render | Bug Report | Low | Scene drawing is not skipped when testmodel screen is o... | New | |
Task Description
If the testmodel window is opened, the current scene is still drawn. Fixing this would provide quite an optimization. |
|
76 | render | Bug Report | Low | Patch meshes with texcoords generated from Radiant's 'c... | New | |
Task Description
For an example of this, take a look at the Talon's main guns. |
|
96 | src | Bug Report | Medium | Problems while docked at another player's ship | New | |
Task Description
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 |
|
13 | client | Feature Request | Low | Support for non us-qwerty keyboard layouts. | New | |
Task Description
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. |
|
46 | client | Feature Request | Low | Flac Support | New | |
Task Description
http://thoronir.net/osirion/flac_patch.patch Adds flac support to osirion. |
|
72 | client | Feature Request | Low | Allow mouse to directly control steering like joystick. | New | |
Task Description
I propose a key bind(toggle) to allow the ship to be steered via the mouse in the same method as the joystick: directly steering based on relative mouse position(locking the cursor in the center of the screen). |
|
19 | game | Feature Request | Low | Fuel System | New | |
Task Description
Fuel System. |
|
20 | game | Feature Request | Low | Economy | New | |
Task Description
Pseudo-dynamic economy support. Ideas: - Stations and planets are supplied by NPC convoys - Prices fluctuate according to availability |
|
12 | render | Feature Request | Low | Light Flare Occlusion | New | |
Task Description
Having light flares occlude behind objects would allow more detailed flares to be used. The following is a screenshot from Mass Effect, and is the back of the Normandy: http://www.bioware.com/_commonext/images/me/screenshots/dlc/masseffect_01_1280x760.jpg If this were tried in Osirion with a regular light entity and a similar flare texture, it would be partially visible from behind surfaces, which is not the desired effect as the light shouldn't be making a flare if it's seen from behind a wall. This is also the reason why most of the flares in Osirion are circular, because a horizontal flare(also known as the 'film-style' flare) is too difficult to get right when it can move in all angles. In the end, this might actually lower performance a tiny bit because each flare has to be checked if it's behind a surface, but if a flare is completely blocked, it shouldn't render at all which would make up for the loss. Q3 has several methods of doing this, including a timed fade, real fade, and instant. Timed fade: when a flare becomes visible, begin rendering the quad and slowly increase its size and alpha from 0 until it reaches the size indicated by the entity. The rate of size increase is based on a simple timer. Real fade: like timed fade, begin rendering the quad once visible but instead of using a fixed timer, only increase the size and alpha depending on how much of the flare is in view. I believe this is done via the size indicated in the entity, and is based on how much of it at its full size is visible(I'm guessing an invisible quad at max size is used to test this). This method is best because it can be tweaked to allow the flare to overlap the surfaces in front of it by a small amount, making it look very realistic. Instant: the flare is instantly visible at max size and alpha as soon as the light entity's origin is visible by the camera. |
|
41 | render | Feature Request | Medium | LOD entity keys + Automatic patch LOD | New | |
Task Description
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. |
|
75 | render | Feature Request | Low | Fade for strobe lights. | New | |
Task Description
Fade-out of strobe lights should occur by default, with an optional float fade time and boolean fade spawnflag. |
|
93 | render | Feature Request | Low | Allow currently loaded skybox to be bound as a texture. | New | |
Task Description
We need this in order to clean up the material drawing(specifically the environment mapping section). This could also possibly enable us to use the skybox cubemap for nice reflection effects. |
|
60 | src | Feature Request | Low | Thrust Point Entities | New | |
Task Description
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. |
|
63 | src | Feature Request | Low | Port to Raspberry Pi | New | |
Task Description
port osi to raspberry pi |
|
92 | src | Feature Request | Medium | Clean up of material, light, flare and particle color ... | New | |
Task Description
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 |
|
103 | src | Feature Request | Low | Gunmen | Unconfirmed | |
Task Description
Allow a player to control (some) weapons on another player's ship, making him a gunman The details of this idea still need to be worked out. |
|
34 | client | Planned Feature | High | Improved options menu | Assigned | |
Task Description
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 |
|
59 | client | Planned Feature | Low | Improved map menu | In progress | |
Task Description
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 |
|
104 | client | Planned Feature | High | Improved inventory menu. | Assigned | |
Task Description
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 |
|
36 | core | Planned Feature | High | Player signals | New | |
Task Description
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. |
|
112 | core | Planned Feature | Low | Pause game | New | |
Task Description
Pause the game server module when opening the menu in single player.
Add an option for a server admin to pause the game in multi player. |
|
24 | data | Planned Feature | Medium | Weapon Models | New | |
Task Description
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 |
|
15 | game | Planned Feature | Medium | Player-to-player trading | Assigned | |
Task Description
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 |
|
18 | game | Planned Feature | Medium | Equipment Trading | Assigned | |
Task Description
The purchase and selling of ship equipment such as weapons. |
|
67 | game | Planned Feature | High | NPC support | In progress | |
Task Description
Support for computer-controlled allies and opponents. - Better AI control - Dynamic patrols |
|
94 | game | Planned Feature | Low | Space mine tracking capabilities | New | |
Task Description
Implement seeker mines and tracking mines. |
|
4 | render | Planned Feature | Low | Z-Fail Stencil Shadows | New | |
Task Description
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. |
|
30 | render | Planned Feature | Low | Improved particle systems | In progress | |
Task Description
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 |
|
35 | render | Planned Feature | Low | GLSL Shader program support | New | |
Task Description
Extend the current Material system to support GLSL shader programs. Normal map, specular map and glow map support. |
|
65 | render | Planned Feature | Low | Material blend modes. | In progress | |
Task Description
Shaders need a way to enable different OpenGL blending modes, like Quake 3's "blendFunc". This will allow special effects like light beams and 3d exhaust effects. DONE - blenfunc none - blendunc add - blendfunc blend TODO - blendfuncGL_SOMETHING GL_SOMETHING - blendfunc filter? |
|
98 | render | Planned Feature | High | Material texture stages | In progress | |
Task Description
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 ... } |
|
17 | src | Planned Feature | Medium | Tractor beam effect | New | |
Task Description
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. |
|
25 | src | Planned Feature | Medium | Model weapon slots and positioning. | New | |
Task Description
Attaching the model/weapon to its associated 'slot' on the ship, and handling the position of said slot. |
|
28 | src | Planned Feature | High | Equipment | Assigned | |
Task Description
Weapons, shields, armour... TODO - Shields & armor - Mining equipment ? - Misc equipment DONE - Weapons |
|
32 | src | Planned Feature | High | Master Server | New | |
Task Description
Master server and multiplayer server list. |
|
33 | src | Planned Feature | Medium | Soundtrack support | New | |
Task Description
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. |
|
66 | src | Planned Feature | Low | Nebula support | New | |
Task Description
Support for decent-looking nebulas. |
|
68 | src | Planned Feature | Low | Asteroid field support | New | |
Task Description
Support for asteroid fields. |
|
69 | src | Planned Feature | Low | Framework for player missions | New | |
Task Description
A generic engine framework to support player missions. core support, client menu support, network command support. |
|
105 | src | Planned Feature | Low | Admin commands | New | |
Task Description
Implement administrative commands. Players should be able to receive and 'admin level' enabling them to execute special administrative commands. Those commands should still be available to the console. The admin level is unrelated to the in-game player level. TODO - Implement a core::Player admin level property - Implement admin command functions (core::Func) - Implement admin.ini to define admin levels and the commands they have access to - Add admin commands to handle player admin levels - Turn existing core administrative commands (kick, mute, ...) into admin commands - Change existing cheats (give, goto, ..) into admin commands, have them take a player name as argument (e.g. give ingar credits 1000) - Combine the 'jump' and 'goto' cheats into a 'teleport' command, make it work while docked, support teleporting players accross zones - Add 'nudge' admin command. |
|
31 | data | Required Media | Medium | Playable, Consistent Universe | In progress | |
Task Description
Requires elaborate trade routes, balanced ships and ship hardware, adequate difficulty curve TODO - implement all starsystems on the starsystem roadmap |
|
43 | data | Required Media | Medium | Model: Unfinished Jumpgate | New | |
Task Description
Use: The unfinished jumpgates between Finnmark and Kronenbaden. |