@Sikk I'm starting to formulate a bunch of things I'd like to see added which need SDK work.
I've still been thinking which way to go after your last PM.
I don't exactly understand what you mean, do you mean add a fade out distance for the ssao or for the fog itself?
The bunch of stuff I'd like to see added can be split in visual stuff and gameplay stuff.
In terms of gameplay I need:
- Access to the player health in scripts ($player1.getHealth() always returns 0, not implemented in SP). This for a bunch of different reasons. I'd like to have GUI stuff going on, I'd like to remove the health meter totally and adjust the players moveability depending on their health (but not to a point where it becomes annoying). I'd like to have other subtle indicators that can feed the player information about their health. e.g. the weapons tend to hang lower if they are weaker, their attack is lower etc..etc.. I'm trying to make it so that all these signs together give players enough information to not even need the health meter.
- Making buttons shootable, my buttons are actually just doors which function the exact same way as a button would. In the func_mover() base code there is a line that applies damage, to the object. Around that line there's an (if MultiPlayer) statement. Which means doors and movers don't take damage in SP. I'd like that line commented so it works in SP. My workaround would be a func_damageable but that's less desirable, seeing how it's an easy fix.
- A way to dynamically adjust animations or
the animation speed. I have faster and slower walking/crouching anims for monsters and I'd like them to be much faster in harder difficulty modes.
- I need persistent game variable for upgrading weapon power. Right now I'm thinking of simply using CVars but internal counters would be much better.
- My traps are now basically trigger_hurts which have a model set, I can't get them solid. I could make them into movers but then they don't always hurt the player. So I need to be able to make trigger_hurts solid, or make func_movers also act like a trigger_hurt. Whichever is easier.
In terms of visuals:
- I have great difficulty with alpha planes and SSAO. Alpha sprites just stand out sorely, even though I intended to use them a lot. In combination with parallax mapping you can create a weapon that seemingly has tens of thousands of polies, even though it actually only has 16. The sprite and the added depth from parallax mapping does that job nicely. But the part where the sprite is transparent can show up really bright (it blocks the SSAO on objects behind it). My workaround is to simply add some vertices and model the sprite closely around actual image content. But that's not always possible. What I'd really like is to trick the renderer into actually treating alpha transparency as nodraw. Or in other words; handle alpha transparency correctly.
I was theorising about my 'own' implementation of transparency by doing the following:
- Create a camera from the sprite facing the back of it.
- Take it's image and project it onto the front of the sprite, but apply any image data that's not transparent as a mask to the camera view.
It would be dirty and cheap and whorish but maybe...
- I'd like an added bloom effect, implemented exactly like in pray. This bloom effect only occurs on materials that have the added 'bloom' keyword.
- I'd like an added screen effect when the scythe's power reaches maximum. I'd like to apply the equivalent of a hue/saturation filter (basically colorgrading) and have that fade in stronger, as the Scythe's power builds up. It should be a warm amber effect, comparable to old pictures. Next to that the player sees light reddish shadows/glows around AI entities to emphasise their mortality (e.g. visual cue for the player).