Difference between revisions of "Source Feature Requests"
(split up article)
m (moved Source Feature Requests and Bug Reports to Source Feature Requests: split up feature request and bugs)
Revision as of 13:11, 23 September 2009
This page is about things happening in-game.
For bugs (only) concerning things occurring while using the SDK, see Source SDK Bugs.
If you think something is not intended to function like it does, post it in the Source Bug Reports page.
If you think something is intended to function like it does, but you are still not satisfied with it, post it in the Feature Requests section.
- 1 Feature Requests
- 1.1 Animation/Physics
- 1.2 General
- 1.3 Graphics
- 1.4 Hammer
- 1.5 Audio
- 1.6 Code/Scripting
- 1.7 Entity and brush behavior
- 1.8 Mapping
NPCs should be able to be hit by an object and that object will move the ragdoll, but the NPC will react and reposition itself.
For example, if you were to throw an object at an NPC's head, currently the object just bounces off and the NPC doesn't react. What should happen is that the NPC's head moves and the NPC reacts to return their head to its original or ideal position.
This would also help add realism to combat. For example, if you were to shoot a combine soldier in the knee, it should make the knee move, maybe even knocking the soldier over. The solder will try to get back up, and if it succeeds, it should be limping if the knee is damaged enough.
Valve is planning to add more physics-based animation to their engine, and this would be an excellent addition.
In this the player entity would be more interactive with it's environment. Example: When an explosion in near the player the player is ragdolled(somewhat) and pushed away.This including first-person views.
sv_autosave should disable map-specific autosaves too.
Better progress bar for bzip2ed fast map downloads.
Addition Add a percentage complete display? Also do not make the progress bar wrap many times (make 100% the end).
If you've gotten Source to work on the PS3, there's really no reason you can't have the full engine (client included) run on Linux. If you haven't made an OpenGL renderer yet, I believe winelib supports DirectX.
Seeing the current decline on Windows, especially with the backwards-incompatibilities of Vista, it would probably be a good time to hedge bets.
Dynamic shadows handling
Better handling of dynamic shadows to prevent shadows in indoor spaces being cast in inappropriate directions for lighting conditions. Either enable dynamic shadows to be cast by light sources other than light_environment, or institute 'fallback' diffuse shadow directly under object if not directly lit from sky light. This would require a trace along the vector of the light_environment angle to see if it hits a skybox texture, but would at least prevent the situations we get where indoor shadows are falling in completely the wrong direction.
Other possible 'cheap' solution would be to enable multiple shadow_control entities in a map, one per area separated by area portals. In this way, a map with strong directional daylight in outdoor areas could use straight down shadow controllers in indoor areas to reduce the jarring appearance of indoor shadows.
- Ah finally thats gonna add a little amount though to the overall performance.--Gear 04:57, 31 Oct 2006 (PST)
Addition Allow your own player shadow to be visible to you. At the moment you cannot see where the shadow is cast, however your enemy can in multiplayer games- big advantage in some cases.
The ability to make materials that reflect the world, instead of using cubemap reflection. Exactly like water.
- It's been added to Source 2007 Engine. Check glass/ folder in Source Shared 2007. --JakeB 15:30, 18 Jun 2008 (PDT)
More Skybox control
The ability to change the settings of a 3D Skybox (namely its texture) would be beneficial. I'm unsure of the best way to achieve this. Changing the sv_skyname in the console does not actually change the sky texture even after trying mat_reloadtextures or mat_reloadmaterial. It does however change the sky texture after reconnecting, if you are playing on an online server.
An alternative to changing the sv_skyname would be to edit the skyname keyvalue of the worldspawn entity.
Adding an OpenGL renderer would be a good idea, like Half-Life had.
Addition: As a comment to both this and the Linux porting suggestion, adding OpenGL support would greatly benefit Linux WINE users even if there is not official port of Source for Linux. OpenGL translates far easier then DirectX under WINE and would likely allow games to run much better.
- A possible newer camera view to show how far a light entity will cast it's light as well as the shadows it will create. Also the camera view can be special, it can be toggled like others and even show other events within the map and maybe incorrectly placed entities and possible errors.
- A built in cinematic editor that allows for users to build a scene in Hammer and preview the animation in real-time.
- An in-editor material editor complete with texture importing and material customization tools.
Real-Time Editing Solutions
- The ability to edit game environments in real time through Hammer is one so chooses.
- Tools to create add-ons from with in hammer.(e.g. An add-on for randomly distributing trees to large environments)
Better music support
Better support for music, including:
- Ability to mark a sound as music regardless of the format.
OnFinishedPlayingoutput to cleanly loop a sound.
- Fade in and fade out effects (in a map entity).
- Music not to suddenly cut out between maps
Soundscape creation tool
Soundscape creation tool with real-time preview.
Sound sample previews
First of all, it would be good if you could preview button sounds instead of choosing them from a list and testing them each in-game.
Second of all, I'd like to be able to play looping sounds using the loop, so that I know which ones are looped and which are not, and how they sound looped. You could add a Stop button to prevent a loop going on forever.
More sound formats, particularly Ogg Vorbis (not difficult to implement) or FLAC.
Improved chapter system
Improved chapter system, ideally with only one file (plus any images) to worry about!
GCF priority for HL2:SP
I'd like to have custom content have priority over the Half-Life 2 GCF files. For example I'd like to be able to add custom sentences to a custom hl2/scripts/sentences.txt file without having to create my own mod for that. The GCF overriding custom material is apparently unique to HL2:SP. Even Lost Coast lets custom content have priority over the GCF. --Andreasen 05:40, 3 Apr 2006 (PDT)
- Annoying as that is, it's pretty easy to create your own mod for HL2:SP - have a look at MINERVA as an example, and feel more than welcome to rip it apart and convert into something new with a search-and-replace on the word 'MINERVA'. It makes the final mod much easier to distribute, install and remove as well, as it's a single folder in SourceMods rather than many files scattered through HL2's directories... —Cargo Cult (info, talk) 07:14, 3 Apr 2006 (PDT)
I would really love to have a complete source engine documentation designed for mod developers, because right now I have to spend hours of code reading to find out how to do a minor change.--Psycommando 20:12, 14 Jan 2009 (PST)
Entity and brush behavior
An Entity/Command for reading variables
We have a method of modifying server variables (incrementVar), but no way of reading back what we set. Can we have either a client/server command for reading variables, or an entity that can do it?
The super gravity gun
I don't know what exactly is causing this, but while working on the npc_citizen_fleeing prefab, I noticed that shooting/punting/pulling the citizen with the Super gravity gun won't kill him, but just rip away ragdoll duplicates from his body. He won't die. I'm posting this under feature requests because I'm thinking that the scripting isn't written for citizens (or perhaps other NPCs too) interacting with the super gravity gun.
Also, if the super gravity gun global state is turned on, the bodies of zombies killed with another weapon simply vanishes, instead of turning into ragdolls. (The headcrab can detach as a ragdoll if the zombie is blown up though.)
The current trigger_teleport isn't teleporting thrown grenades or weapons, it is even (to my understanding) impossible to set a filter to allow hegrenade_projectile, weapon_hegrenade, or weapon_glock entities, The filter or trigger_teleport ignores these entities.
Multiple Fog Controllers
It would be helpful to have more than one env_fog_controller allowed in a map. The current work around is the use of triggers in conjunction with a point_clientcommand that changes the values of many settings; fog_color, fog_colorskybox, fog_enableskybox, fog_end, fog_endskybox, fog_override, fog_start, fog_startskybox. I propose an enable/disable function (plus 'start disabled' flag) added to env_fog_controller to allow triggering between each.
There does not seem to be a simple way to adjust internal unit scale and physics in the source code in a similar way to HL1 (hull.txt). Changing the values in vphysics_interface.h do not seem to have a visible effect in game. Without this models adjusted for 0.16 scale will not have accurate physics.
Getting bitten by a black headcrab isn't dangerous even if you're not wearing a HEV suit. The damage is mysteriously healed anyway. I would like it if poison damage is only healed/non-lethal if the player is wearing a HEV suit.
Improved chapter unlock entity
Entity to trigger chapter unlock without re-locking later ones.
- This can be done using the
incrementvarcommand, as demonstrated here.- RodeoClown 05:01, 26 Apr 2006 (PDT)
Every entity should have an OnSpawn output
We could do away with many logic_auto's if all other objects had OnSpawn outputs. We could also remove Names from many objects because they could call functions on !self without having to refer to a name.
See Hammer Feature Requests for tool enhancements.
Give us Steam VGUI
It'd be a great advancement in modding if the Steam vgui2 interface was made public as well as overriding the vgui2 dll.
Add the ability to use displacements on triangular faces.