|
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. |
|
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
|
|
37 | render | Bug Report | High | Colors are randomly broken on open-source 'radeon' and ... | Closed | |
Task Description
Using an ATI Radeon HD 5770. Mesa 7.10. The colors for all environment-mapped surfaces(which means nearly all model surfaces) are randomly chosen when the renderer begins. The colors that are used are out of all the colors used by the models, rather than some random color. Also, it appears to be only entire materials that are switching to the wrong color, rather than per-surface. How to reproduce: Open up colors.shader, and comment(//) the 'environment' part of grey25, and run the game. You will see grey25 as the color it's supposed to be, only with its envmap fixed. My thoughts: It's either a bug in the driver or some logic error in the fragment drawing code that's only manifesting on the radeon driver. This may also affect other drivers that use Mesa, but as yet radeon is the only one that I have seen that has this issue. EDIT: This bug also occurs on the nouveau driver for nvidia. Perhaps Gallium3D is at fault? |
|
80 | client | Bug Report | High | Slider loses focus while the mouse button is pressed | Closed | |
Task Description
If you change the value of a slider by moving the indicater with the mouse, it loses focus if the mouse cursor leaves the widget. As long as the mouse button is pressed down, focus should stick to the widget that had focus when the mouse button was first pressed. This is not a problem within the ui::Slider class. This is an issue that needs to be resolved in the input handling core. |
|
2 | client | Bug Report | Medium | Skyboxes rendering junk on random sides on Intel | Closed | |
Task Description
For some reason, a random side(or two) of the skybox renders complete nonsense. This only seems to happen on Intel cards. I have attached a shot taken from my netbook which has an Intel 945G chipset. |
|
7 | src | Bug Report | Medium | Rotated misc_models render in wrong positions. | Closed | |
Task Description
A misc_model that has been rotated in certain ways does not render correctly in-game(at least when it uses a .map as the model). The expected behavior should be how it appears in Radiant. In my testing: A simple Z-axis rotate renders fine. Any other complex rotations, like Y-axis rotations cause it to rotate(as expected), but the origin is in the wrong place. So, theoretically, any rotation that does not move the misc_model's referenced model's origin should work fine. Any other will break. The latest committed version of the pirate juggernaut has misc_models with this problem, so that can be used as a test case. |
|
10 | core | Bug Report | Medium | Sub-model clip brushes are not inherited by parent mode ... | Closed | |
Task Description
If you use a collision model on a sub-model(called with misc_model or some other way), it does not include the clip brushes used in the sub-model if collision models are activated in ships.ini(or equivalent). |
|
14 | game | Bug Report | Medium | Preserving thruster setting | Closed | |
Task Description
If a ship drops out of impulse, the previous thruster setting should be restored instead of beeing set to 0. This depends on the game not using entity_thrust when entity_state != Entity::Normal. Changes to this variable are send back to the client and override any previous thruster setting. |
|
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. |
|
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. |
|
73 | src | Bug Report | Medium | testmodel primary/secondary colors set incorrectly | Closed | |
Task Description
When using testmodel, the secondary color seems to be copied from the primary color rather than cl_colorSecond. |
|
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 |
|
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. |
|
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. |
|
8 | client | Bug Report | Low | Alt-Enter fails to drop key modifier | Closed | |
Task Description
Using Alt-Enter to change from windowed mode to fullscreen, fails to drop the 'Alt' key modifier, meaning no other input will be accepted until this key is pressed again. |
|
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. |
|
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 |
|
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. |
|
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. |
|
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. |
|
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. |
|
1 | src | Bug Report | Very Low | Sample Task | Closed | |
Task Description
This isn't a real task. You should close it and start opening some real tasks. |
|
102 | src | Bug Report | Very Low | Variable-length arrays preventing compilation with Clan ... | Closed | |
Task Description
When compiling with clang, it will run until stopping with an error on mapfile.cc: In file included from mapfile.cc:1: mapfile.cc:293:36: error: variable length array of non-POD element type 'math::Vector3f' math::Vector3f patchvertices[rows][columns]; ^ mapfile.cc:294:37: error: variable length array of non-POD element type 'math::Vector2f' math::Vector2f patchtexcoords[rows][columns]; ^ 2 errors generated. make[3]: *** [mapfile.lo] Error 1 make[3]: *** Waiting for unfinished jobs.... Clang isn't super-important, so I'm marking this as very low severity. In the future, someone might want to compile Osirion for FreeBSD, or another OS that uses Clang as the default compiler, so it might help to fix this problem. |
|
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. |
|
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. |
|
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 |
|
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. |
|
11 | core | Feature Request | Low | OBJ support | Closed | |
Task Description
OBJ support would be great for sub-models. Radiant's brushexport2 can export brushes into this format, in addition to natively supporting it in the editor itself. Wavefront .obj file Wikipedia article: https://secure.wikimedia.org/wikipedia/en/wiki/Wavefront_.obj_file Info page including a long list of sample obj files: http://people.sc.fsu.edu/~jburkardt/data/obj/obj.html |
|
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. |
|
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. |
|
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 |
|
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. |
|
40 | client | Feature Request | Low | Ogg Vorbis support | Closed | |
Task Description
I've written a patch that handles the xiph ogg vorbis format. http://thoronir.net/osirion/vorbis_audio.patch Note that this will only read the first logical bitstream in the container (you should not require more than one for sound effects). You will need to link against vorbisfile. |
|
46 | client | Feature Request | Low | Flac Support | New | |
Task Description
http://thoronir.net/osirion/flac_patch.patch Adds flac support to osirion. |
|
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 |
|
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). |
|
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. |
|
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. |
|
79 | client | Planned Feature | Critical | Add listview scrollbars | Closed | |
Task Description
The listview doesn't show a scrollbar if there are more items in it than can be displayed. |
|
23 | src | Planned Feature | High | Weapons | Closed | |
Task Description
The basic ability for players to shoot each other. |
|
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. |
|
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 |
|
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. |
|
67 | game | Planned Feature | High | NPC support | In progress | |
Task Description
Support for computer-controlled allies and opponents. - Better AI control - Dynamic patrols |
|
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 ... } |