Search in commentsSearch detailsSearch for all wordsTasks I watchTasks not blocking other tasksTasks blocking other tasksBlocker or nonblocker, selecting both filter options doesn't make sense.Has attachmentHide SubTasks

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.

* 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

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.

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 usedto send trade and docking requests, and to replace the silly 'hail' commandwith a 'request for private chat'.

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

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

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 witha particle system (like projectiles) representing the 'beam-in'effect (think star trek transporters).

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

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.

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

- 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

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.

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.

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).