 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
... 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...). http://triptohell.info/moodles/junk/quakespasm-spike-r6.zip
adds pk3 support, a few bugfixes (saved games+demos), and a couple of minor things that smc uses. the zip is also slightly more end-user friendly, imho, your milage may vary. its almost certain that I missed something though. I love the effect, I wish it would be come standardized.
https://www.youtube.com/watch?v=aHCocIjeWuw&feature=youtu.be Its great to have particles and weather in AD without the DP slowness. My r9 290 would go down to 2 fps in some of those levels.
It's performance is better even than MarkV at my laptop which was from 2013 with an i3 CPU and integrated graphics core. The frame rate is definitely higher than in MarkV when I am playing AD_TFUMA.
Now if this supports multiple gamedir and using path as game dir (as in "-game Summary:
bigger maps, downloads, voip, more networking choices. Changelog: http://triptohell.info/moodles/qss/qss-changelog.txt Download: http://triptohell.info/moodles/qss/quakespasm-spike-r7.zip Some light testing
It connects to DarkPlaces using DPP7 and appears to work just fine in a vanilla situation. /Very incredible work in R7, Spike! I will no doubt be making acquisitions some time this year. entering "r_wateralpha 0.5" at the console with no map loaded crashes.
This bit in R_SetWateralpha_f seems to need an additional check for cl.worldmodel != NULL: if (cls.state && !(cl.worldmodel->contentstransparent&SURF_DRAWWATER) (same for tele/slime/lava)
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2025 John Fitzgibbons. All posts are copyright their respective authors. |