 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
See post 1014 that I accidentally posted in the Arcane Dimensions thread instead of this one
I guess I'll just repost it ----------------- A thought for Sock: The QuakeC extensions check is only for what language extensions a server has. That's why they are QuakeC extensions. In single player, that's the same thing as the server. But it sounds like you are doing coop too. Remember, a regular Quakespasm client and a DarkPlaces client could be connect to a Quakespasm Spiked server. Doing checkextension("DP_TE_PARTICLERAIN") tells doesn't tell you anything about a client. Send some WriteByte wizardry to regular Quakespasm client and it'll crash out? Quakespasm Spiked R25 have new extension that uses WriteByte (that DarkPlaces doesn't have and R24 doesn't have) and DarkPlaces or Quake Spiked R24 as client to R25 server gets unexpected message and crashes out after 5 minutes because explosion effect sends unexpected bytes? /Please let me be wrong and that I haven't found the achilles heal of the QuakeC extension system where even a server never knows what clients will work --- it just needs to run the progs and maybe the client crashes out eventually or maybe it doesn't. Hope to hear "Baker is completely wrong because baker, use the te_particlerain builtin, and hope the server isn't stupid and knows how to filter. writebytes are evil.
where there's an actual builtin to do the exact same thing, just use that. seriously, writebytes are evil! alternatively you can just order everyone to use the exact same engine+revision and then you don't even need to bother checking for extensions! yay for lock-in! How would a client know what version is needed for a given server, though?
/I'm just thinking things ahead to try to avoid a tower of Babel situation. You'll hate this, but as you've noticed a ProQuake server sends a byte indicating the server version.
Just trying to avoid a situation where clients have no frogging idea whether or not they could play on a server or not and the server has no clue either. /Yeah, WriteBytes are evil. Do any the QSS extensions require WriteBytes? If not, I'll feel a ton better. And btw Spike, don't take these questions wrong.
I know you know your stuff and think about these things, you can do multiprotocol stuff on your FTE servers and have done it for years. The opposite of this is an engine that can't play Zerstorerer or the Mission Packs without a patch and used to have keys falling out of standard Quake maps. I know you aren't like that and do a ton of thinking about compatibility. So don't take any of this wrong -- all the looking at QSS for R4, it all seemed impressively super-compatible. I think the solution to this is simple. Protocol 66600 (protocol is 32 bit when sent to client)
66600 = FTE666 + no extensions are used. 66605 = FTE666 + all Quakespasm Spiked R5 extensions. 66606 = FTE666 + theoretical Quakespasm Spiked R6 extensions. etc. Server knows if mod wants to use extensions. If the mod doesn't ask for extensions, have it report the protocol as simply 66600 (00 means no extensions required). Server reports to client the protocol in the form of printf("666%d", QUAKESPASM_SPIKED_LEVEL) so to speak. Quakespasm Spike R5 sees server running Quakespasm Spike R9 feature set, says "Server requires R9 extensions level. Update engine.". FitzQuake 0.85 tries to play a 66605 demo, "Can't play demo, protocol is not 15 or 666." Duplicate process for 999. Everybody win/no hassles! No incompatibility! test2 say sv_protocol 66605 AddressSanatizer on macOS reported this bug: the memcpy at net_udp.c:443 is reading past the end of myAddrv6.
sizeof(struct sockaddr_in6) == 28 bytes, and the myAddrv6 is only 16 bytes. Also I mirrored r5 as a branch on my github mirror of QS: https://github.com/ericwa/Quakespasm/tree/spiked It builds and runs fine on macOS 10.12, btw, once I added the new @baker
the server already tells the client what the protocol is. go read how the pext stuff is communicated to the client, and possibly how the server queries what the client supports too. for server browsers, if it really matters then just use different master servers (or a different protocol name for dpmaster). otherwise just listing servers that might not work helps encourage people to update! an old client is an unhappy client... @ericw the memcpy size is wrong, sorry. memcpy(&((struct sockaddr_in6 *)addr)->sin6_addr, &myAddrv6, sizeof(((struct sockaddr_in6 *)addr)->sin6_addr)); should be more correct. 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.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |