I frequently receive feature requests for DirectQ, so in this post I'm going to list some of these, as well as some comments I have on them. I'm going to add a new "Sticky Posts" category on the right-hand side and include this post, and anything else that I want to have more easily accessible, to it.
Improvements to the Name Maker
I'm open to requests for this. What I currently have is very much a "first attempt" which was also broken for a good chunk of time, so fixing it was more important than adding extra functionality.
Bestweapon Support
I am of the opinion that this belongs in QC, although I might hack it into the engine at some point in time. I am however incredibly wary of crossing engine/QC boundaries, as I've learned in the past that it's one quick and certain way to break mod compatibility.
Scoreboard Ping
Doing this right requires a protocol change, e.g. an svc_pingtime message followed by a byte for playernum and (possibly) a short for ping time. In standard protocol 15 Quake only the server is aware of ping times, the client just does not know them. I am aware that other engines do it, and I have looked at their code, but I find the implementation to be quite hacky. If I decide to do it, I might at the very least copy something from ProQuake or QRack, but it would be nicer if everyone could just agree on standardising the protocol change instead. It's another boundary to cross, this time the client/server boundary, and once again there is a risk of breaking standard functionality in order to add a feature that may be desirable but is not utterly essential.
CSQC Support
I have looked at the CSQC sample implementation, and porting it to DirectQ is a non-trivial job. Doing so would mean putting all other engine work on hold for a substanatial period of time. Owing to the scarcity of actual real-world usages of CSQC (outside of the theoretical or tech demo arena), the return on investment would be quite low. If a major new mod was released that utterly required CSQC, and that everyone was using, then it might become worthwhile.
Linux or Mac OS Support
No can do owing to the use of Direct3D for the renderer. Run it under WINE instead. I would love to build a Linux box so that I could at least test performance and functionality under WINE, but I don't have the time or resources to invest in it (and the quality of documentation and real-world practical examples usable by someone who has zero Linux exposure is something I find to be quite pathetic). Best case scenario is that someone else volunteers to do this job and notifies me of what code changes may be required.
Enhanced Particle System
This is something that I play with every major release, and I'll probably do so again for the next one. I have yet to find a satisfactory solution for certain effects, and I am aware of a number of edge cases where an enhanced particle system would break down. To my mind, a robust and consistent look and feel is more important. The DirectQ particle system in it's current state (as of 1.7.3) is very easily extensible to an enhanced system - it's just a matter of changing a few params for each particle type - so engine hackers can build their own from it if they wish.
Bringing back HLSL
I won't do this, sorry. The only reason I added HLSL to earlier versions was to do better waterwarps, but that created a situation where at least one person was unable to run the engine, and where it didn't play nice under WINE. The whole bumpy/shiny/specular/reflective thing can look nice, and is a viable approach for other engines, but it's just not something that's in my own personal objectives.
Removing (or making optional) Fullbrights and/or Overbrights
I won't do this either, so sorry again. Fullbrights and Overbrights are an essential feature of software Quake and are explicitly and deliberately set (and not optional) in software Quake's colormap. If your map or textures look bad in DirectQ they will also look bad in software Quake, and I'm not going to let you abdicate responsibility for doing things right, or offload that responsibility to the engine.
Any other features
I'm always open to reasonable requests, so long as there is understanding that I can't promise to implement everything, that I do have certain design goals (which I must summarise in a single post sometime) which some feature requests may not be compatible with, and that other priorities may arise that may push new features to the back of the queue. I do however evaluate everything on it's own merits, and I also do try to think carefully about implications and edge cases before deciding to implement or not implement something. I won't just say "no" for the sake of saying "no", but likewise I won't say "yes" to everything. Correct basic functionality is always more important than new features, and sometimes I might just forget something I had indicated I would do. Other times if a new feature interferes with basic functionality and if I can't reasonably fix it, I might remove it.
If you do submit a feature request I would like to see some indication that you have thought about it yourself first. It's not mandatory, but it is always nice to see.
Thursday, October 22, 2009
Comments on Some Feature Requests
Posted by
mhquake
at
12:50 PM
Subscribe to:
Post Comments (Atom)
10 comments:
"Bestweapon Support
I am of the opinion that this belongs in QC, although I might hack it into the engine at some point in time. I am however incredibly wary of crossing engine/QC boundaries, as I've learned in the past that it's one quick and certain way to break mod compatibility." -mhquake
Up front let me say this:
I am aware of your design goals, and in that context I completely respect your decisions, one way or the other!
However, to avoid confusion or miscommunication, let me clarify:
Whenever I refer to the "bestweapon" command, I mean proquakes/qracks implementation of it.
This is used as folows:
alias BW "bestweapon 8 5 3 4 2 1"
//selects LG or falls back to SNG
//then SSG then NG then SG then AXE
//(whatever is available)
alias +BW "BW;+attack"
alias -BW "-attack"
bind "somekey" "+BW"
//select the best available non-explosive
//weapon and fire it
//(all in the push of one button)
As I understand it (and please DO correct me if i'm wrong), the bestweapon command only sends the impulse of the best available weapon to the server.
"best available" meaning: the best weapon that the player acutally has (and has ammo for) as specified in the argument to the bestweapon command.
Now, since the bestweapon command only sends one impulse to the server, I really can't see how this could break any mod.
Having said that, there are a lot of mods that use the dreaded "double-selection-method" for selecting some alternative weapon-mode for the selected weapon, without revealing the underlying impulse for selecting that alternative weapon directly.. IMO that is just evil! Why?? Because it forces the player to use a very basic one-fire-button weapon-system and manually selecting the weapon of choice before switching weapons.. can you say NOOB anyone?? I mean, come on..
Anyways.. in these situations the bestweapon command would not work as expected, but that is not the engines fault.. it is the mods fault (or the players fault for using the bestweapon command in a situation where it does not work as intended).
In any case this is easily "fixed" by just not using the bestweapon command..
I guess my point is: relying on whatever the server (mod) thinks is the best available weapon, usually sucks. And working around it with some fancy aliases (without having the bestweapon commmand available) usually does not work very well either..
I'm just hoping to change your mind on the matter, since I am not much of a singple-player-quake-player and without the availability of a bestweapon command, any client is pretty much useless to me..
But maybe i got it all backwards and you can change MY mind on the matter! :D
k.r. =peg=
It's just been added. ;)
allow me to say.. WOOT!! :DDDD
With Bestweapon support in,
Might we have Lastweapon support?
I dont think there are many people
clamoring for it, but I would appreciate it.
(Lastweapon is when you switch a weapon, then impulse to another one, you can have an impulse set to the weapon you switched FROM..makes for some nice aliasing tricks)
As I've explained here this can be done in any client with a bit of fancy scripting, but I'm all for a lastweapon command if that makes this easier ;)
And while I'm at it, I'd like to suggest a "inc" command (ala Fitzquake) to increase or decrease the value of an arbitrary cvar, like so:
bind MWHEELUP "inc fov -10"
bind MWHEELDOWN "inc fov 10"
Easy zoom functionality :D
Using a bit of fancy scripting this could make for a complete on-the-fly menu to be used with mousewheel, changing all kinds of cvars while playing.
(think sensitivity, volume, fog, skybox etc. etc.)
Yeah I already made a lastweap in QuakeC with a bit of help.
I'm just saying it would be nicer as a builtin.
The only way to properly switch weapons is by an impulse. Now, the engine isn't aware of impulses aside from the number, and what effect they have is entirely dependent on QC. Impulses are used for things other than weapons, and even next and previous weapons are controlled via impulses (which are 10 and 12 in ID1, but there's nothing to enforce this for mods). I gave in on bestweapon, but this is something that definitely does belong in QC. Oh, it could be done by checking impulse numbers and the value of the activeweapon stat, and learning which impulse is for which weapon, but that's the beginning of a very slippery slope.
I like the idea of the "inc" command, that's being added to the list.
"inc" is added.
I'm a big softie so I added lastweapon too. NO MORE!
sweet! :D
And there was MUCH REJOICING!
Thanks MH! WOOOO!
Post a Comment