 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
I'm sure Seven could do something about that.
*thinks about Seven's forthcoming SMC v5.53* Hmmm... Seveeeeen? The QC example in weather.cfg has spelling mistakes
Line 4 - particleeffectnum("weather.te_rain") In order to check for rain / snow functionality the engine should respond to the following extension checks, I am getting false from these. checkextension("DP_TE_PARTICLERAIN"); checkextension("DP_TE_PARTICLESNOW"); @Bloughsburgh not using QS-spiked will not have the rain or sound effects correct? I plan to only implement this for QS-Spike and DP clients Why not asking ericw to merge Spike�s code into QS for a new release?
I suspect it will be eventually. It isn't a set of changes that drastically changes the game. I don't even thing fog was a "vanilla" glquake feature and that was added.
The guys are probably just keeping it separate for quarantine while the bugs are sorted out and to see how it is used / abused. Get the following console messages
findfile: can't find particles/effectinfo.cfg findfile: can't find effectinfo.cfg This is after doing the file registering thing in world.qc. particleeffectnum("effectinfo.txt"); Any reason the engine is still trying to find a config file? You did say in the documentation the engine will not look for particles files by default. (line 73 in qs-spike.txt "no effects will be loaded by default" Any chance you can move the "Particle effect token stainblah blah" to developer 2? The engine is not going to support stain stuff so why spam the console about it? When I register my own weather.cfg file I keep getting "fte_weather.te_snow: is not a recognised particle type" There is no type specified in the effect, its default. Why do I get this error? @Icaro Why not asking ericw to merge Spike�s code This is nothing to do with me, totally up to the QS team. I plan to support QS,QS-S and DP egines for AD. Some features are not just present, this is something for the engine coders to add/sort/fix. It isn't a set of changes that drastically changes the game. I don't even thing fog was a "vanilla" glquake feature and that was added.
Your enthusiasm keeps baffling me, because I vaguely remember you giving me a speech about the need to avoid unnecessary feature creep. Maybe it was someone else? Too many shamblers on this map. a speech about the need to avoid unnecessary feature creep does sound more like Shambler than Shamblernaut.
@khreathor What are PBR and GI? It was less a "speech" and more an observation of how the QS contributors seem to operate.
For what it is worth I think there is a need to balance useful "good" changes vs chaff. It is the same reason why my IRC mod will never make it to the main fork. It's bloaty and nichey... And probably buggy as all hell. The Spiked modifications (I think) fit in well with the general "feel" of QS. The effects aren't "high-definition", so they don't feel out of place in quake. @sock
punchangles are indeed broken, thanks for reminding me to look in to those. 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. 'no effects will be loaded by default' means that r_particledesc defaults to empty (or classic, to use the classic particle system - note that relative to FTE, QSS always assumes that classic is specified even when its not, which avoids the need to rewrite the existing particle system, as such make sure classic is still listed in default.cfg or you'll probably mess up FTE a little). so if you're usingp articleeffectnum and using giving it a namespace, it'll now know to try loading effects from said namespace (effectinfo or effectinfo_* being special that automatically triggers importing from dp effect definitions from the relevant file name, if there's no fte effect available). re stains, stainmaps kinda suck. especially if you want your effects to work properly with q3bsp too, or rtlights. As such I can't really recommend using them anyway thanks to those inconsistencies. 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, but then that's my personal probably-biased opinion. @Mugwump, I don't think seven has any interest in any engine other than DP. there are a couple of qc fixes needed (namely: fixing up monster spawning so that it doesn't nudge monsters into the ground). I'd like to think that Seven would accept patches to fix that, so long as it doesn't break DP. it'd also need repackaging as quakespasm doesn't support pk3s, md3s, stereo sounds, and has lower mdl limits. thanks to the way smc works, much of that could be 'fixed' with some specific cvar settings. I would apprechiate it if someone were to go through smc's features looking for qss engine bugs, but whether its a qss bug or a quake-vs-dp difference, or just a qss content limitation is likely a bit more awkward to figure out. either way, if anyone were to do something significant, it does kinda need some cooperation from Seven, preferably in advance. @Shamblernaut, those particle effects are as high-def as they're made to be. if you want high-def, try the particles from AfterQuake or SMC. Sock's use of them is at least aesthetically consistent. http://triptohell.info/moodles/junk/quakespasm-spike-r5.zip
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) A quick test
1) Grab an item emitting effects (nail gun), the item remains visible. 2) Appears to run particles/map_e1m1.cfg to get per model effects, once level is changed the effects from the previous level persist. The ability to misc_model without progs support and the ability to do effects without a model are invaluable. So is honoring the angle of an entity for effect emission. I would say there are too many mugbumps on this board nowadays
i miss Kinn 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.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |