 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
It would be so sweet to have DP's features implemented to QS-Spiked since it's way too unoptimized for me even with RT World off and the interface stretches badly with widescreen for some reason.
How would those decals work? I feel like they would affect map aesthetics if there are too many around. Great work so far. PD: Any idea if these effects will have a performance hit? I am guessing it's minimal... The bonus is that these particles should also result in smaller demo sizes
regarding DP_TE_PARTICLERAIN+SNOW, I'm not entirely sure that its correct to advertise those when the engine gives no guarentees that there's a particle configs loaded that it can actually use for those effects.
I once asked LordHavoc for a way to query the DP engine so that I could customize a MOD I was building. He told me there was no way of doing it. When I asked him why, he said, I want MODs to query features not engine types. So that is why "pr_checkextension" exists. MODs are suppose to query the Quake client for features; Particles, fog, surface inspections, rain and snow volume effects. This is the standard that Quake engines *should* follow. If QS-Spike refuses to tell what features it has then its just going to be a clusterfuck of guessing, spamming the console and wasting people's time. Either way, they're DPrints, so end-users won't see them, unless they actually want that info. Considering that quakespasm traditionally spams all sorts of 'WARNING:' messages for simple things like using a couple too many entities, I don't feel that its entirely out of place I agree QS use to be really bad for console spam, but over the past year I have worked with Eric to move all the console spam to Dev 2. As a mapper I rely on Dev 1 all the time, I need to know what errors are happening with a map. Having to wade through pointless spam messages every time I load a map is just a waste of time. I highly recommend the stain messages be dev 2 because you are reporting a feature that does not exist. So I am not sure how this is useful to know every time a map is loaded. includes a variation of baker's 'e1m1_effects' thing with some hacks gone (some of which required engine tweaks to resolve). Otherwise just a bugfix release. the zip is bigger because it includes both win32 and win64 engines (still no dlls) I have asked all members of the AD team to download this zip and try to install the engine. Every person has said the same thing, How do I install this engine? The Zip file is just seems to be a clutter of stuff. There is no readme file, a ton of config files and no clues what to do. I know you expect everyone to just work it out for themselves, but the organization of the zip file could be a better layout. @Baker, WTF, why are you arguing for abandoning a current standard for querying clients for features? Anyone who mixes Quake clients is always going to have problems, so using that as a justification for not applying a current standard is totally wrong. The extension system was designed so that MODs don't have to guess what features are active and spam console with endless commands hoping they will work. Lets all move in the same direction for once! WARNING : MOD USES BUILTIN #xxx - blahblah I am not sure why this is a warning on the console? Its not a problem, how is it a warning? a warning against what? Anyone who reads this will wonder if something is broken. This is a good candidate for Dev 2 spam because mappers/modders know they are using particle query commands already. This is just confusing and misleading atm. On a final positive note, I really love this version of QuakeSpasm. The particles are amazing, finally I can play quake with good movement code and have clouds of smoke swirl around me as I fire rockets! I highly recommend anyone from the QS team to consider merging this stuff into the main branch. It really brings maps to life with extra ambience and does not go full on crazy with eye candy. Also on a side note, the rain/snow effects in this engine are so much better than DP!?! No more hardcoding effects, can finally customize the weather candy with unique effects! :D Its such a shame the FTE/Spike particle system did not become the standard, because its got some really lovely features missing from DP. Its like the classic 90's battle of VHS vs Betamax and we all know how that turned out based on popularity! @Baker, why are you arguing for abandoning a current standard for querying clients for features?Spike explained to me why it is non-issue because of how he designed Quakespasm Spiked.
So ignore my old thoughts on that, Spike obsoleted them ;-) checkextension</>
it depends how you define 'checkextension'. Remember that there is absolutely no standard way to query the client's extensions on the server, you can only check the server's. Which generally means that the server should only advertise what it's client component also supports. If you want to define checkextension as purely serverside, or with potential client support then yes, particlerain+snow should be advertised. On the other hand, if it should only be things that are going to work out of the box then it shouldn't be listed. Hurrah for things being more complicated than they should be!.. This wouldn't be an issue if QSS had a built-in fallback for rain/snow particles, but unfortunately the only built-in is the original/classic particles. engine types vs engine features it depends how far down the rabbit hole you are. Once you're using 20 different extensions for a range of different things, its very unlikely that the mod will still be checking those extensions properly. Its also unlikely that the modder will be aware that half those features they're using are actually later extensions built upon a previous extension - like checking for pointparticles and assuming that means that 'effectinfo.txt' is also supported and parsed. Plus many mods are too lazy to even bother to even check for extensions... As a result, checking for QSS/QS/DP vs QS/markv/vanilla/others, makes a lot of sense (those with string support and those without). Then use individual extensions for more minor optional features, like rain volumes. The trick is in figuring out which set of extensions ensure that its safe to put it in that first group... Either way, there does kinda need to be a way to check the engine's name and version even if its just to blacklist things - there'll always be implementation differences and bugs. builtin warnings its along the same lines as eg the '%i nodes exceeds standard limit of 32767.' warning. I went for consistency rather than practicality. :) if you cleared pr_checkextension so that mods shouldn't be able to detect any extensions, then any builtins that are used despite the apparent unavailability of any extensions are going to be an issue for compatibility reasons. Any other builtins that are being warned about are warned because the qss implementation is a stub and doesn't necessarily even do anything (its probably better than crashing on those mods that fail to check extensions properly). Otherwise users without developer set will see none of those warnings. Tbh, I was kinda leaving half the developer warnings for someone else to tame. :) the zip yeah, its not organised that well. end-users just need the exe so it doesn't really need that much. The readme file isn't really aimed at end-users either, because frankly my changes arn't really aimed at them either. I could make a clone of vanilla quakespasm's installer and by doing so obsolete it entirely, but frankly that's rude and not really what I intend to achieve with QSS, if only because I don't want to have to keep merging quakespasm's changes over to qss. Really, the biggest issue is that it lacks all of the required dlls... So yeah, its kinda intentionally bad. :s Its such a shame the FTE/Spike particle system did not become the standard While mods like yours only provide DP efffects, not much is going to change that. :P In the meantime, nothing is stoppng you from making an effect for FTE+QSS, and a fallback one for DP. You don't even need to change any QC. Hurrah for being able to plug a tape/mod into either type of player/engine. :) ... waffle waffle waffle
OMG spike, that is like 2 pages of not agreeing to anything! Are you going to support check extension for rain and snow or not? Tbh, I was kinda leaving half the developer warnings for someone else to tame. :) Are you giving up on this engine already? In the meantime, nothing is stoppng you from making an effect for FTE+QSS, and a fallback one for DP You are missing the irony of my analogy, its too late! The DP particle language is standard and there is no going back in time. I am certainly not going to maintain QS particle, DP particle and FTE particle files!?! Sorry man, that moment is long gone! The rain and flames with smoke effects appear to be so great, it NEEDS to be implemented into the standard QS !
Now I'm just wondering about their implementation for old maps : will the flame effect be automatic, or be turned on in recent maps, only if they ask for it ? It should be automatic, IMO. About the rain (and possibly snow or other effects), could it be turned on by the user, even on old maps to add more atmosphere ? I guess not, but I would like to have a confirmation. if I do an r6, yeah. its not like mods can do very good fallbacks anyway, so a false positive that's invisible won't do any serious harm.
regarding an r6, I'm kinda hesitant. I don't want to have to maintain a fork long term. I've achieved the major things that I personally wanted, csqc being the only real thing that I didn't try tackling but at least that one has good reason. There are a couple of omissions like some minor builtins that I doubt anyone will use, but meh. Regarding someone else taming the warnings, QuakeSpasm, even QSS, is not the engine that I personally favour. The final polish needs to come from someone who actually cares about the whole package, and that person isn't me. By 'QS particles' I assume you mean sprite ones? Yeah, I can understand not wanting to support those... :P I can disable the effectinfo support if that'll make the idea more palettable (which would be more correct with regard to your analogy)... Really the only way to get away from DP's particles is to fork DP and port over the particle system (and fix its stupidities too, hmm)... It would be so sweet to have DP's features implemented to QS-Spiked
If you want a quake engine with more DP features but which isn't DP, then try FTE some time. QSS is meant to retain the QS aesthetics, but without ignoring modders/multiplayer. Bling is kinda irrelevant when other engines can already do that much better. regarding an r6, I'm kinda hesitant. I don't want to have to maintain a fork long term. I've achieved the major things that I personally wanted
Well that is a shame, I only plan to support weather in AD if the checkextension is active. Good luck with your next project then and exit stage left from me. well, there's a few things that would be worthy for an r6, but I need to talk to ericw I guess about logistics or something.
What else did I miss? What bugs are there? What is there that I should actually care about? What is there that would make an r6 actually worthwhile?.. that doesn't also invole rewriting half of quakespasm... :) So if a mod wants to use more weapon slots, the engine adds them. Or pergaps even better, gfx.wad texture replacement support based on an integer so mods could have custom weapon, ammo, face, hud images. Or maybe not.
Here's a bug report from mfx:
- extract https://www.quaddicted.com/filebase/ad_v1_42final.zip - launch qss-r5 with "-game ad_v1_42final" - type "map ad_crucial" - press F6, then F9 to quickload - "QUAKE ERROR: Loadgame buffer overflow" if you want more (hud) weapons or different huds, then the only way I'd consider doing that is with csqc. Anything else would be a hackfest.
One alternative would be a q2-like hud string that says what images to put where, and which conditions for them to be enabled. Using the same formatting as Q2 is probably not practical due to q2's configstrings, and they should probably be defined via configs or something, and I've no idea how to control which ones are used. Maybe just lots of conditional cvar expansion. Lots of aliases or something that get re-evaluated every now and then, I dunno. Maybe I'm just overcomplicating things again. Side note: At what point does it stop being quakespasm and become just a crippled version of FTE? :s What else did I miss?
I haven't had a chance to check any of this stuff out for a while, because reasons, but is crunchy lego pixel mode working on particles yet? What is there that I should not actually care about?
* I get constant crashes with save games or demo files. Maybe this is a new DarkSouls feature of the engine, one life no saves! :P * Volume weather (te_particlerain / te_particlesnow) goes through solid brushwork. It now rains indoors, DP is good with the same setup :) DP volume particles
* checkextension te_particlerain / te_particlesnow * console vars cl_particles_rain / cl_particles_snow * hardcoded volume particle effects QS-S volume particles * no checkextension * console var r_part_rain only * flexible volume particle effects I looked at SMC and its checking the CL_ console variable to enable / disable the QC functions for volume effects. DP also switches off the volume effects if the console vars are set. QS-S is really aimed at surface weather effects. The different console variable only work with the surface option and ignores the volume version. Why the brand new standard for console variables? How can the mod know if the effects exist or not? How to detect the state of the particle weather if the console vars don't work with both systems? I am beginning to think this is some cruel joke by Spike. Maybe I should of saw the signs when the download link points to a junk folder. Man, I am so disappointed with this situation. :( Spike's engine code gift can't be a cruel joke.
I know because the next version of Mark V has devoured 1/3 of the engine enhancements that most interested me from the co-operative play perspective. Spike saved me a ton of time in just the 1/3 acquisition, the fact he implemented these in a familiar codebase like Quakespasm is incredible. I did what I could to try to make a working demonstration of the client-side particle system (where client-side = what does not require QuakeC). Why the brand new standard for console variables?
most cvars are not part of ANY standard. This results in random crappy inconsistent names. The only winning solution is to boycott all cvar hacks. They're user settings, and NOT how you modify the behaviour of builtins. r_part_rain 0 blocks support for surface-emittance and technically isn't about just rain. Yeah, its a crappy name that dates back to the primary feature. You can use to to prevent your snow stuff working too. Either way, that's the user's choice, if they want to block it then they can, but they won't end up with what the mod really intended. Its the same with DP's cl_particles_rain / cl_particles_snow except that they break te_particlerain/snow rather than surface-emittance. Default 1, users can reconfigure them to 0 to break the mod. SMC checking for them as well makes the engine support for that cvar redundant. You can add the same check in AD if you want, go ahead, it'll block the effect just the same in each of DP+FTE+QSS, just be sure to create an autocvar with default value enabled, or something. Obviously, it goes without saying that using a cl_* named cvar in ssqc is a bit stupid, but there you have it. There are very very few standards when it comes to cvars. FTE's console scripting allows for all sorts of if-statements and other logic to control which particles get defined, unfortunately QSS doesn't use the console to parse particlesets, and lacks that cool logic stuff, so yes the result is a little more limited. You can still use r_particledesc to control which sets should be loaded. How can the mod know if the effects exist or not? Reliably? It can't. Not even in DP. Sure, it might exist on the server, but maybe the server was reconfigured to use protocol 15 (so that other clients can actually connect or whatever), in which case the server will still report that it exists, and yet noone will ever see it. False positive? False negative? Either way its flawed. If you want to ensure that FTE+QSS will load a particle config containing suitable effects for te_particlerain then you can just use particleeffectnum on the effect name to ensure that its containing config is parsed, at which point you'll start to question what the actual name is for the exact arguments you passed to the builtin, as opposed to the default name that gets used if the full name wasn't defined, and why you couldn't just pass a friggin effect number for it instead... But, well, DP. I am beginning to think this is some cruel joke by Spike http://triptohell.info/moodles/this_is_not_a_cruel_joke/honest/quakespasm-spike-r6.zip New update, just for you sock. :) either irony or just a barefaced lie, depending on whether you think I was being witty or just a dick.
I do have some tweaks towards an r6, including pk3 support, but I'm too lazy to bother making sure everything else still works, and I still need to do something about that demo issue that sock reported (to fix, I need to rewrite some crappy code that someone else ported over from proquake, and as I said, I'm lazy). so yeah, there will be an actual qss-r6 eventually, and not just for sock/AD (ooo, a proper readme! okay fine, enough hype...).
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |