|
26 | src | Planned Feature | Low | Mouse aiming | Closed | |
Task Description
Players should be able to aim their guns with the mouse. |
|
43 | data | Required Media | Medium | Model: Unfinished Jumpgate | New | |
Task Description
Use: The unfinished jumpgates between Finnmark and Kronenbaden. |
|
108 | data | Required Media | High | Model: pirate base | New | |
Task Description
Pirate base models, to serve as NPC headquarters. Several generic models are required. |
|
44 | data | Required Media | Medium | Model: Kerman station | Closed | |
Task Description
Use: Kerman station, Khorsand system. Info: Produces superconductors from niobium, should probably look like some form of factory. |
|
45 | data | Required Media | Medium | Model: Generic Colonial Outpost | Closed | |
Task Description
Use: The stations next to the unfinished jumpgates in finnmark and kronenbaden Other uses: Generic == profit |
|
47 | data | Required Media | Low | Model: Commodity: Water | Closed | |
Task Description
Water commodity model. Some kind of water tank. |
|
49 | data | Required Media | Low | Model: Commodity: Superconductors | Closed | |
Task Description
Superconductors commodity model. |
|
50 | data | Required Media | Low | Model: Commodity: Optronic Components | Closed | |
Task Description
Optronic Components commodity model. |
|
51 | data | Required Media | Low | Model: Commodity: Niobium | Closed | |
Task Description
Niobium commodity model. |
|
52 | data | Required Media | Low | Model: Commodity: Liquor | Closed | |
Task Description
Liquor commodity model. |
|
53 | data | Required Media | Low | Model: Commodity: Iron | New | |
Task Description
Iron commodity model. |
|
48 | data | Required Media | Low | Model: Commodity: Gate Parts | New | |
Task Description
Gate Parts commodity model. |
|
54 | data | Required Media | Low | Model: Commodity: Diamonds | Closed | |
Task Description
Diamonds commodity model. |
|
55 | data | Required Media | Low | Model: Commodity: Crystals | Closed | |
Task Description
Crystals commodity model. |
|
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. |
|
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. |
|
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 ... } |
|
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? |
|
32 | src | Planned Feature | High | Master Server | New | |
Task Description
Master server and multiplayer server list. |
|
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. |
|
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. |
|
61 | src | Required Media | Low | Jump exit gives mostly random thruster setting | Closed | |
Task Description
Upon exiting a jump(as in, appearing in the target system) using a jump gate or the jump command, the player starts with a thruster setting above 0. The value is mostly random. |
|
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 |
|
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 |
|
62 | src | Planned Feature | Medium | Improved main menu framework | Closed | |
Task Description
The main menu classes have to be move from ui/ to client/. Provide a client::MainMenu class for menu managment, provide support for save/load game menu where approriate. Remove ui::Menu and ui::Container classes and support methods in ui::Window. |
|
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 |
|
58 | data | Required Media | High | Icon: Eject Cargo | Closed | |
Task Description
An Eject Cargo icon A Trashcan or recycle bin, or ... in SVG. |
|
57 | data | Required Media | High | Icon: Close Window | Closed | |
Task Description
A close window icon. A cross or something approriate, in SVG. |
|
106 | client | Planned Feature | Low | HUD camera mode button | Closed | |
Task Description
The HUD lacks an iconbutton to change and indicate the current camera mode. TODO - Add an iconbutton to the hud, change the icon depending on the current camera mode - Add three camera icons to icons.svg: track (aka third person) cockpit (aka first person) free (aka turret view) |
|
95 | client | Planned Feature | Low | Health indicators | Closed | |
Task Description
Health indicators DONE - Show ship health in HUD - Show target health in HUD |
|
6 | render | Feature Request | Low | Hardware Workaround Scripts | Closed | |
Task Description
Despite the renderer being written very well and to the spec, certain hardware has trouble doing functions reported to be supported by the driver. I propose an ini file that the engine reads directly after loading all standard configuration files. This ini file instructs the engine to make specific checks and if they pass, execute a configuration file. The workaround handling being outside the engine allows future changes in the event that new hardware requires a workaround, without requiring recompiling the engine. Attached are proposed example files. |
|
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. |
|
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. |
|
19 | game | Feature Request | Low | Fuel System | New | |
Task Description
Fuel System. |
|
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. |
|
46 | client | Feature Request | Low | Flac Support | New | |
Task Description
http://thoronir.net/osirion/flac_patch.patch Adds flac support to osirion. |
|
39 | client | Bug Report | Low | Fails to read WAV files that contain header. | Closed | |
Task Description
Osirion will fail to read a WAV file that contains header information such as Artist, Album etc. Steps to reproduce: Create file in audacity export to wav and enter title/artist information attempt to load in osirion. |
|
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. |
|
71 | game | Required Media | High | Faction and Reputation support | In progress | |
Task Description
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 |
|
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. |
|
91 | render | Feature Request | Medium | Extend spawnflags for Lights/Flares/Particles to includ ... | Closed | |
Task Description
Lights, Flares, and Particle system entities are allowed to use entity color for coloring their graphics, but entitysecond and entitythird are not available. DONE - Particlesystems can be set to entity second from inside the script - entity_second spawnflag for lights - entity_second spawnflag for flares - entity_second spawnflag for particle systems - entity_third can be enabled by setting both entity and entity_second. |
|
42 | client | Bug Report | Medium | ESC key doesn't close buy and trade windows | Closed | |
Task Description
While docked, pressing ESC doesn't close the current window and doesn't open the main menu from the launch bay window. |
|
18 | game | Planned Feature | Medium | Equipment Trading | Assigned | |
Task Description
The purchase and selling of ship equipment such as weapons. |
|
28 | src | Planned Feature | High | Equipment | Assigned | |
Task Description
Weapons, shields, armour... TODO - Shields & armor - Mining equipment ? - Misc equipment DONE - Weapons |
|
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. |
|
78 | core | Bug Report | Low | Entire model fails to load when a submodel is invalid | Closed | |
Task Description
An easy way to test this is to erase the entire contents(as in, ascii text) of any submodel. The whole model will fail to load when this submodel is tried by the loader. |
|
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 |
|
38 | render | Feature Request | Low | Distance LOD for Patch Meshes | Closed | |
Task Description
Patch Meshes currently render at a fixed subdivisioning at all distances, making the extra polys sometimes useless when the player is far enough away. Distance LOD would drastically reduce the amount of polygons generated by patch meshes in the distance. This would probably result in some accuracy issues when two patch meshes are next to each other, but probably wouldn't be seen due to their distance. This is an acceptable tradeoff for increased performance(and it would have a configurable minimum subdivision level). As I understand it though, patch meshes are presubdivided as the model is loaded, which would make this difficult to implement. As with a few of my other feature requests, there is example code in ioquake3 that does this. |
|
101 | data | Required Media | Low | Dagon Texture Set | New | |
Task Description
House Dagon needs a set of textures. |