I PMed LH about some suggestions I had for DP a few days ago. It turned out that a lot of what I suggested was already possible in DP, it just needed someone with some decent knowledge to explain it to me. He then recommended that I start a public topic about this to get your opinion on what you want to see in DP. So post you suggestions!
Here are a few of mine:
- .float getsound: similar to .vector getlight but returns sound level in specified location.
- .vector scale: Scale x, y and z of model individually.
- SOLID_BSP_LOW: Lower 'quality' SOLID_BSP for faster hitmodels. What I mean by lower quality is that it gets the average surfaces of the model instead of calculating the angle of every face on the model.
- .vector ears: Only use the x and y variables of this vector (left and right ear). The higher the vector, the less the player can hear sounds around him. Range between 0 and 1. Uses: Flashbangs!
- Echoing sounds and adjusting pitch and speed of sound playback. Also entities hear sounds differently depending on their current condition (ie those underwater won't hear sounds as clearly as those who are not underwater).
- Some sort of built-in AI navigation to reduce the use of waypoints and stuff (basically, an improved movetogoal and walkmove)
- Interpolating scale and alpha change
- .vector anglepunch: Instead of offsetting the view_ofs of entity, offset the viewangle of entity to make earthquakes possible.
I know a lot of these are hard to implement.
Suggestions for LordHavoc's Darkplaces
-
behind_you
- Posts: 237
- Joined: Sat Feb 05, 2011 6:57 am
- Location: Tripoli, Libya
Re: Suggestions for LordHavoc's Darkplaces
Makaqu has this, but it's named "scalev" instead, since the name "scale" already belongs to a .float .behind_you wrote:- .vector scale: Scale x, y and z of model individually.
Re: Suggestions for LordHavoc's Darkplaces
It's a nice enough concept, and would work best if it had channel masking (such that you could detect the sound level of CHAN_WEAPON in a given area for instance), this requires the server to keep track of recently started sounds and calculate attenuated volume and read the sound data to figure out how loud the sound is (or a cvar could make it all simulated, saving a lot of memory and CPU).behind_you wrote:- .float getsound: similar to .vector getlight but returns sound level in specified location.
But in practice you can generally do this a lot faster in qc by doing a findradius when a sound starts and wake up enemies that can hear it.
So this may or may not warrant an engine feature, in general you don't actually need to know the overall sound volume at a given location.
Needs a different name to avoid conflicting, as mankrip pointed out this could be called .vector scalev for makaqu compatibility.behind_you wrote:- .vector scale: Scale x, y and z of model individually.
Requires additional networking.
A separate .collisionmodelindex would be more useful, to store the modelindex of a model that is simplified, because the engine can not safely simplify a model while preserving the intent.behind_you wrote:- SOLID_BSP_LOW: Lower 'quality' SOLID_BSP for faster hitmodels. What I mean by lower quality is that it gets the average surfaces of the model instead of calculating the angle of every face on the model.
Temporary muting of sounds on each ear is probably best done by csqc, and could be implemented with two cvars.behind_you wrote:- .vector ears: Only use the x and y variables of this vector (left and right ear). The higher the vector, the less the player can hear sounds around him. Range between 0 and 1. Uses: Flashbangs!
However be aware that this may not be the best way to implement the effect - DarkPlaces has a surround sound mixer (up to 7.1) and the idea of stereo channel volumes is thus something it has to kind of guess about when adapting it to surround...
Well usually games use a reverb effect when underwater to simulate this.behind_you wrote:- Echoing sounds and adjusting pitch and speed of sound playback. Also entities hear sounds differently depending on their current condition (ie those underwater won't hear sounds as clearly as those who are not underwater).
Regarding pitch and speed of sound playback - you are describing the doppler effect, the DarkPlaces sound mixer still retains the Quake design and is incapable of playback speed changes, this requires significant internal changes to the mixer and sound loading.
Waypoints work fine, movetogoal does not have waypoints, they would be a significant improvement to it, I haven't given much thought to changes to it in the engine though, generally qc implements advanced navigation itself (there are many considerations in this, like hazards, obstacles, whether the enemy is able to jump, etc).behind_you wrote:- Some sort of built-in AI navigation to reduce the use of waypoints and stuff (basically, an improved movetogoal and walkmove)
Sure, sounds good, I don't have enough interest in implementing it right now though.behind_you wrote:- Interpolating scale and alpha change
You can do this in csqc.
This is what the .vector punchangle; in stock Quake does.behind_you wrote:- .vector anglepunch: Instead of offsetting the view_ofs of entity, offset the viewangle of entity to make earthquakes possible.
DarkPlaces added .vector punchvector to let you move the view around.
Some are difficult, some not.behind_you wrote:I know a lot of these are hard to implement.
But it all depends on how much time I have available.
Just like to add some thoughts on this.
Engine development is not a democratic process, and not all engine feature requests are born equal. If you're developing or maintaining an engine, it's inevitable that you're going to get feature requests, and everybody has their own set of favourites. It would be fair to guess that among any random selection of two people, their feature requests will have an average crossover of maybe 50%.
Even if time was an infinite resource (it isn't but let's pretend) there are other factors that influence whether or not an engine developer will implement a feature. For me, and in no particular order of priority.
Stability and compatibility with ID1
These two override everything else. Breaking the original game is not an option. And it not only must work, but it must work with the rest of your code (which may be radically different to the original code).
Compatibility with your vision of what your engine is
Every engine developer has a clear idea of what they want their engine to do or be. If a feature request goes outside of this vision the chances of it being taken up get reduced.
Doesn't fight against other features
If you have two new features and they conflict with each other then one of them will have to go. This means letting someone down, and that sucks, but it's also very real.
Reasonably popular/populist
If a given new feature is only ever going to be used by one person then it's of quite limited value. This is a bit of a grey area - the developer might think it's a cool idea despite that, or whatever.
Easy for others to implement
Every new feature has a chance of becoming a future standard. If it's not easy enough for other engines to also take up, that chance becomes lower.
Works the way mod authors/mappers/etc expect
If not, then it won't be used by the wider community. Take the interpolating alpha example - nice idea, but no engine supports interpolating alpha. If a mod author switches alpha from 1 to 0, the mod author therefore expects the change to happen immediately. Break that and you'll piss off the mod author.
Works the way players expect
Quake is a known factor, if you play it then you expect it to behave in a certain manner, and if a new feature causes it to not do so, then the feature becomes of dubious value.
Can't be reasonably implemented elsewhere
Some engine features are better off being done in QC (SS or CS), some are better off being part of model/map formats, and so on. Quake already has too much in the engine that really should be elsewhere, let's not add to it.
Not an exhaustive list, but comprehensive enough to think about when requesting new features. Let's get back to time. The last feature request I got that was claimed to be "so simple and will only take you 5 seconds" took two days. It was something I wanted to do, otherwise I would have junked it after half an hour, but it could so easily have been the other way around.
Enough. Derail over.
Engine development is not a democratic process, and not all engine feature requests are born equal. If you're developing or maintaining an engine, it's inevitable that you're going to get feature requests, and everybody has their own set of favourites. It would be fair to guess that among any random selection of two people, their feature requests will have an average crossover of maybe 50%.
Even if time was an infinite resource (it isn't but let's pretend) there are other factors that influence whether or not an engine developer will implement a feature. For me, and in no particular order of priority.
Stability and compatibility with ID1
These two override everything else. Breaking the original game is not an option. And it not only must work, but it must work with the rest of your code (which may be radically different to the original code).
Compatibility with your vision of what your engine is
Every engine developer has a clear idea of what they want their engine to do or be. If a feature request goes outside of this vision the chances of it being taken up get reduced.
Doesn't fight against other features
If you have two new features and they conflict with each other then one of them will have to go. This means letting someone down, and that sucks, but it's also very real.
Reasonably popular/populist
If a given new feature is only ever going to be used by one person then it's of quite limited value. This is a bit of a grey area - the developer might think it's a cool idea despite that, or whatever.
Easy for others to implement
Every new feature has a chance of becoming a future standard. If it's not easy enough for other engines to also take up, that chance becomes lower.
Works the way mod authors/mappers/etc expect
If not, then it won't be used by the wider community. Take the interpolating alpha example - nice idea, but no engine supports interpolating alpha. If a mod author switches alpha from 1 to 0, the mod author therefore expects the change to happen immediately. Break that and you'll piss off the mod author.
Works the way players expect
Quake is a known factor, if you play it then you expect it to behave in a certain manner, and if a new feature causes it to not do so, then the feature becomes of dubious value.
Can't be reasonably implemented elsewhere
Some engine features are better off being done in QC (SS or CS), some are better off being part of model/map formats, and so on. Quake already has too much in the engine that really should be elsewhere, let's not add to it.
Not an exhaustive list, but comprehensive enough to think about when requesting new features. Let's get back to time. The last feature request I got that was claimed to be "so simple and will only take you 5 seconds" took two days. It was something I wanted to do, otherwise I would have junked it after half an hour, but it could so easily have been the other way around.
Enough. Derail over.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Hello LordHavoc and MH,
I recently found the great possibilities of QC modding.
Before, I only worked on mods outside QC (effectinfo, shaders, textures, ...)
Working with QC the last couple of month very intense and using the functions in dpextensions.qc very much,
makes me very happy. The existing "special features" of dpextensions.qc are already really nice.
The recently implemented DP_ENT_TRAILEFFECTNUM is a very welcome feature (thank you again LH !).
Though I have one request, that has been mentioned by behind_you, too.
And not only from behind_you. Many other raising very talented modders (like Nahuel, ..) also have this wish:
We talked about it many times at quakeone.com and via chat:
Interpolation of scale.
DP_ENT_SCALE gives the possibility to scale every model you want. That is a superb feature.
Unfortunately, even when I shrink it in very small steps:
1 --> 0.9 --> 0.8 --> 0.7 --> ...
It is still very jerky. Far away from fluent.
Modders have such a great interest in DP_ENT_SCALE, because so many amazing things can be done with it.
Unfortunately I can only use it, giving it fixed values from beginning and dont change them.
So this feature has a limited usage.
I feel very sad, reading that you dont have much interest in implementing a improved DP_ENT_SCALE at the moment.
MH mentioned it: A new feature should not be implemented just because 1 person wants it. I totally agree with him !
But this is something, that I know many modders will love.
Please think about it again LordHavoc.
Maybe you can change your mind (of course depending on how difficult the implementation is) ?
Kind regards,
Seven
PS: The mentioned interpolation of DP_ENT_ALPHA is in my eyes already working quite good today.
I use this feature regularly in my mods (changing alpha in small or big steps). It is fluent enough for me.
I recently found the great possibilities of QC modding.
Before, I only worked on mods outside QC (effectinfo, shaders, textures, ...)
Working with QC the last couple of month very intense and using the functions in dpextensions.qc very much,
makes me very happy. The existing "special features" of dpextensions.qc are already really nice.
The recently implemented DP_ENT_TRAILEFFECTNUM is a very welcome feature (thank you again LH !).
Though I have one request, that has been mentioned by behind_you, too.
And not only from behind_you. Many other raising very talented modders (like Nahuel, ..) also have this wish:
We talked about it many times at quakeone.com and via chat:
Interpolation of scale.
DP_ENT_SCALE gives the possibility to scale every model you want. That is a superb feature.
Unfortunately, even when I shrink it in very small steps:
1 --> 0.9 --> 0.8 --> 0.7 --> ...
It is still very jerky. Far away from fluent.
Modders have such a great interest in DP_ENT_SCALE, because so many amazing things can be done with it.
Unfortunately I can only use it, giving it fixed values from beginning and dont change them.
So this feature has a limited usage.
I feel very sad, reading that you dont have much interest in implementing a improved DP_ENT_SCALE at the moment.
MH mentioned it: A new feature should not be implemented just because 1 person wants it. I totally agree with him !
But this is something, that I know many modders will love.
Please think about it again LordHavoc.
Maybe you can change your mind (of course depending on how difficult the implementation is) ?
Kind regards,
Seven
PS: The mentioned interpolation of DP_ENT_ALPHA is in my eyes already working quite good today.
I use this feature regularly in my mods (changing alpha in small or big steps). It is fluent enough for me.
-
frag.machine
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Silly question: have you tried to use a higher granularity to scale ? I mean, instead transitioning directly from 1.0 to 0.9, use 0.01 steps (or even less). If the transition gets too slow, then try to use smaller values for nextthink. Find a compromise between both values, I'm sure you'll achieve the smooth transition you want.Seven wrote:DP_ENT_SCALE gives the possibility to scale every model you want. That is a superb feature.
Unfortunately, even when I shrink it in very small steps:
1 --> 0.9 --> 0.8 --> 0.7 --> ...
It is still very jerky. Far away from fluent.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
(LordHavoc)-
behind_you
- Posts: 237
- Joined: Sat Feb 05, 2011 6:57 am
- Location: Tripoli, Libya
You could add a .float interpalpha or scale and set it to true when you want to interpolate it.mh wrote:Works the way mod authors/mappers/etc expect
If not, then it won't be used by the wider community. Take the interpolating alpha example - nice idea, but no engine supports interpolating alpha. If a mod author switches alpha from 1 to 0, the mod author therefore expects the change to happen immediately. Break that and you'll piss off the mod author.
As I stated already, I don't know anything about how easy or hard any of my suggestions are. I also do not know how long it would take for these to be implemented.mh wrote:Not an exhaustive list, but comprehensive enough to think about when requesting new features. Let's get back to time. The last feature request I got that was claimed to be "so simple and will only take you 5 seconds" took two days. It was something I wanted to do, otherwise I would have junked it after half an hour, but it could so easily have been the other way around.
I'm not demanding anything. I'm just starting a topic about stuff that I and maybe others want to see in DP. Notice how I used the words 'want to see' instead of 'demanding to see'. I know this isn't a democracy. Lordhavoc was in fact the one who wanted me to post this topic when I PMed him (You would've known if you weren't too lazy to read my first post). You would have a point if the topic was called "Demands for Lordhavoc's DP".mh wrote:Engine development is not a democratic process, and not all engine feature requests are born equal.
I understand the point you are making, but what I don't understand is why you have to be such a killjoy.mh wrote:Enough. Derail over.
Anywho...
Yeah, you can get a good effect if you did something like this:frag.machine wrote:Silly question: have you tried to use a higher granularity to scale ? I mean, instead transitioning directly from 1.0 to 0.9, use 0.01 steps (or even less). If the transition gets too slow, then try to use smaller values for nextthink. Find a compromise between both values, I'm sure you'll achieve the smooth transition you want.
Code: Select all
void() fadeout =
{
if (self.alpha <= 0.01)
return;
else
self.alpha = self.alpha - 0.01;
self.nextthink = time + 0.05;//Reduce for faster fade
}Hello frag.machine and behind_you,
yes sure.
If you use a very short time and a very small alpha/scale reduction, you can make everything fluent that you want.
But then we would not need interpaolation for anything, right ?
Your described procedure is a manual workaround, that I use in all my work.
Just because we dont have a interpolation for these things yet.
The manual workaround can be avoided when we have the interpolation. That was my idea (and I guess behind_you´s too).
Seven
yes sure.
If you use a very short time and a very small alpha/scale reduction, you can make everything fluent that you want.
But then we would not need interpaolation for anything, right ?
Your described procedure is a manual workaround, that I use in all my work.
Just because we dont have a interpolation for these things yet.
The manual workaround can be avoided when we have the interpolation. That was my idea (and I guess behind_you´s too).
Seven
-
behind_you
- Posts: 237
- Joined: Sat Feb 05, 2011 6:57 am
- Location: Tripoli, Libya
Yeah, I posted a QC alternative to interpolating scale and alpha. Works well, I guess.Seven wrote:Hello frag.machine and behind_you,
yes sure.
If you use a very short time and a very small alpha/scale reduction, you can make everything fluent that you want.
But then we would not need interpaolation for anything, right ?
Your described procedure is a manual workaround, that I use in all my work.
Just because we dont have a interpolation for these things yet.
The manual workaround can be avoided when we have the interpolation. That was my idea (and I guess behind_you´s too).
Ceriux mentioned a good idea. Also, I can't get .skin files to work with weaponmodels. The weaponmodel doesn't show up at all when I use .skins on it.
-
frag.machine
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Huh... No. You cannot fake alias interpolation with QuakeC, for example.Seven wrote:Hello frag.machine and behind_you,
yes sure.
If you use a very short time and a very small alpha/scale reduction, you can make everything fluent that you want.
But then we would not need interpaolation for anything, right ?
Solving a simple problem like this with QuakeC is a "manual workaround" ? :?Seven wrote:Your described procedure is a manual workaround, that I use in all my work.
Just because we dont have a interpolation for these things yet.
The manual workaround can be avoided when we have the interpolation. That was my idea (and I guess behind_you´s too).
IMHO people should resort to engine side coding only if a) it's impossible to implement the feature directly with QuakeC in a easy way, or b) there are performance/resource usage issues, which I believe is not the case. But hey, that's just my opinion.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
(LordHavoc)My only want is the full functionality of the Quake 3 shader functions. It would make for some amazing customizations - plus would greatly benefit projects like Quake Reforged - the Chthon skin for example. Takes like 30mb - whereas if we had full functionality it could drop to 4mb tops as there wouldn't be a need for so many textures to animate the effect - but 2-4 textures and have them fade in.
I'll probably embarrass myself asking for something that already exists (and you should probably be able to do it in csqc, although I think having it in the engine would make the qc a lot simpler)
I'd like to be able to offset where the crosshair and the prydoncursor get drawn. e.g. say I wanted to replace the prydoncursor icon with a crosshair graphic, and aim the crosshair anywhere on the screen using the mouse. The centre of whatever crosshair graphic I used wouldn't be where the cursor is actually pointing. The cursor would actually be pointing to the top left of the crosshair graphic.
A few years ago I fiddled with the source and had something basic working, e.g. changing this line in sbar.c
to:
In a similar way I think it'd be useful to be able to move where the normal crosshair gets drawn.
No idea if anybody would use it much, though. It's not like I'm pumping out the mods.
I'd like to be able to offset where the crosshair and the prydoncursor get drawn. e.g. say I wanted to replace the prydoncursor icon with a crosshair graphic, and aim the crosshair anywhere on the screen using the mouse. The centre of whatever crosshair graphic I used wouldn't be where the cursor is actually pointing. The cursor would actually be pointing to the top left of the crosshair graphic.
A few years ago I fiddled with the source and had something basic working, e.g. changing this line in sbar.c
Code: Select all
if (cl_prydoncursor.integer)
DrawQ_Pic((cl.cmd.cursor_screen[0] + 1) * 0.5 * vid_conwidth.integer, (cl.cmd.cursor_screen[1] + 1) * 0.5 * vid_conheight.integer, Draw_CachePic(va("gfx/prydoncursor%03i", cl_prydoncursor.integer), true), 0, 0, 1, 1, 1, 1, 0);Code: Select all
if (cl_prydoncursor.integer)
{
if (cl_prydconcursoroffset.integer)
{
pic = Draw_CachePic(va("gfx/prydoncursor%03i", cl_prydoncursor.integer), true); //no idea if this is stupid
DrawQ_Pic(((cl.cmd.cursor_screen[0] + 1) * 0.5 * vid_conwidth.integer) - (pic->width * 0.5), ((cl.cmd.cursor_screen[1] + 1) * 0.5 * vid_conheight.integer) - (pic->height * 0.5), Draw_CachePic(va("gfx/prydoncursor%03i", cl_prydoncursor.integer), true), 0, 0, 1, 1, 1, 1, 0);
}
else
DrawQ_Pic((cl.cmd.cursor_screen[0] + 1) * 0.5 * vid_conwidth.integer, (cl.cmd.cursor_screen[1] + 1) * 0.5 * vid_conheight.integer, Draw_CachePic(va("gfx/prydoncursor%03i", cl_prydoncursor.integer), true), 0, 0, 1, 1, 1, 1, 0);
}No idea if anybody would use it much, though. It's not like I'm pumping out the mods.
-
behind_you
- Posts: 237
- Joined: Sat Feb 05, 2011 6:57 am
- Location: Tripoli, Libya
A really good feature I was reminded of when playing half life today:
A func_conveyor. Basically, the brush would act like a conveyor belt with the text scrolling in whichever direction you want. .vector conveyor would use x and y to scroll in the wanted direction and the higher the value you give it, the faster it will scroll (negative values = scroll backwards). The texture scrolling is the only thing that requires engine code (I believe). The pushing of the conveyor can easily be done in qc.
A func_conveyor. Basically, the brush would act like a conveyor belt with the text scrolling in whichever direction you want. .vector conveyor would use x and y to scroll in the wanted direction and the higher the value you give it, the faster it will scroll (negative values = scroll backwards). The texture scrolling is the only thing that requires engine code (I believe). The pushing of the conveyor can easily be done in qc.
To quote a popular meme: You're doing it wrong.Seven wrote:Unfortunately, even when I shrink it in very small steps:
1 --> 0.9 --> 0.8 --> 0.7 --> ...
It is still very jerky. Far away from fluent.
Correct approach:
Code: Select all
void() ShrinkThink =
{
self.nextthink = time;
self.scale = self.scale + frametime * 4; // takes 0.25 seconds to reach 1.0
if (self.scale > 1)
{
self.scale = 0;
self.nextthink = 0;
self.think = SUB_Null;
}
};So this is smooth as long as the networking can keep up (in singleplayer it always does, in multiplayer it usually does).
When I heard of requests for scale interpolation I immediately thought of interpolation between server frames (which seems "reasonable" but not high priority to me at this time), I did not think of interpolating a clunky 0.1 at a time increase, and I am skeptical of such interpolation.
The only reason .frame, .origin and .angles are interpolated at an adaptive speed (as low as 10fps) is because the Quake monsters do such movement stepping, it is more dubious to encourage such behavior in new qc code for other parameters.
Please consider carefully the framerate of your qc code, it is often the culprit.