haze.cfg --- assigned the te_quad_sparkfan effect to progs/quaddama.mdl

Loaded dm3

When I pull up the console. The effect spams continually. Obvious the "die" time cannot happen when the console is up. But new particles shouldn't spawn.

Oddly this does not seem to happen with rain/snow. So far only te_quad_sparkfan seems to have this problem. 

Baker, protocol 15 might be the only commonality between all engines, but if you ignore vanilla, all the other engines have boosted what their engines are willing to receive to at least ethernet's limits.
requiring everyone to upgrade basically includes to every single notable engine with the exceptions of vanilla and proquake. One of which you(baker) can fix with a new revision.
The alternative is to cripple dp,qrack,fitzquake,markv,etc clients that give no way to identify what they support.
These clients would also need to be limited to 600 entities too, etc.
Its not that its a big change, its more that its really limiting. 

I think what've you done here is incredible as is.

Spike: you(baker) can fix with a new revision.

Heheheheh. Should the day ever come when I have time, hehe ;) Probably won't be within the next 12 months.

No one expected to get particles because you seemed down on it. The stuff on top of the particles was unexpected and a bonus.

The particle stuff by itself is quite the enhancement and I hope it gets put to good use by Sock and possibly others. 

if I'm not critical of something, I can't easily spot the flaws in it.
At the end of the day, if someone does something stupid with the particle system then that's their own damn fault, and not something that should hold back eg Sock.

Regarding protocol 15, if clients can tell the server that its not crippleware, then its only the crippleware engines that will suffer from being crippleware.
I made some tweaks, and r4 will (bug-willing) do protocol 15 properly. I even made it reduce the number of usable sounds/models if the serverinfo packet is too big, which seemed to get AD going with a proquake client, although it did feel a little empty with half the entities missing (like I said, limiting)...
I guess I also ought to do something about makestatic too now though. Stupid cans of worms... :(
Also got the server part of proquake-compatible-rcon working, although I wouldn't personally recommend using it because the password is still sent as plain text, which sucks.
Also found a nice reliable way to crash proquake servers. Hurrah.

yay polish?.. 

Question:

I don't understand your objection to the FitzQuake "game travail" or "game warp -quoth"

Is it because it doesn't use gamedir like Quakeworld and DarkPlaces and JoeQuake? I used to dislike the slightly different naming, but I've gone from disliking it to prefering it because I type it in the console a lot for single player.

Is your dislike just because the name? Or is there something else I'm not seeing?

/Slightly surprised you decided to do the protocol 15 thing, I did look through all the mega-tons of changes you did and I can see your POV. rcon on the other hand is barely a cut and paste, relatively speaking ... even easy stuff is slight PITA. 

until some rcon command crashes the server and fails to even tell the (rcon) user what happened. Blind copy+paste is never a good idea.
no feedback on errors = bad
plain text passwords = bad
client only supporting one rcon command at a time even when its just a single packet = bad
modifying the system-specific code for something common to all = bad
willingness to exceed proquake's own mtu resulting in 'bad read' errors instead of results = bad
not giving any feedback at all when the server is a listen server = bad
copy+paste = bad. :)


I dislike 'game' because it differs from the command name that id themselves used with quakeworld. that said, quake2 used 'game' so I can't really justify that much further (although q2 used a cvar, which has its own set of issues, which an engine that also supports q2 needs to be able to deal with).
What I really *really* hate about it is the '-quoth' part, which limits it to only a few base-mods that are hardcoded into the engine. This also affects the choice of hud, and even the network protocol. Each of those 3 things are unacceptable to me.
So yeah, I feel justified in disliking it, even if I ignore that qw+fte even existed.
The deltas stuff deals with the protocol change. The hud lumps can be auto-detected. The hardcoded list of 'permitted' mission-packs is just plain stupid. Oh, and quakespasm doesn't support more than those 2(+id1) either.
But yes, I should do something about the server announcing the correct gamedir to use, but probably I'll just leave that until someone else wants to actually fix up the 'game' mess and add auto-downloads and deal with the versioning fallout resulting from that. 

Scenario:

Someone is using DarkPlaces as a listen server.
They decide to coop.
They use multi-game dir for replacement content.

Problems:
(1) So does the client need to download all of that person's replacement content when connecting?
(2) Make sure content are the right models with CRC check etc? How do you do that when the loaded model is a replacement model?
(3) Download doesn't download the replacement textures that the replacement content needs to look right.

Multiple gamedir support is mostly a mechanism for using replacement content.

Within that context --- the support for a small set of mods (rogue, hipnotic, quoth, possibly -ad in the future) is not much of a problem.

And is probably a major benefit. I don't know how many single player users require the Quake Injector to play a custom map, but its probably no small number.

When I first wanted to try custom single player, I was not used to the installation instructions or using -game in the command line. Figuring out where things go and the startup procedure is a big challenge to most people.

Shorter version: I think a finite list of double gamedir like "game -quoth" is fine, Preach knows what's he's doing, Sock knows what he's doing ... other than Preach and Sock and some of the power mappers that really know their stuff (czg, necros, tronyn, etc.) --- there aren't a lot of people that are going to be making an expansion pack level add-on for immersive content.

When DarkPlaces added double-gamedir support, the thought wasn't of "hey, make sure feature is properly architected and well designed" but rather for modder convenience. 

IIRC the only reason for -quoth is to allow it to support the Hipnotic HUD, together with Quoth content, together with an (optional) additional gamedir for a mod which requires Quoth.

-quoth is just a hack, in other words. But it's a hack that the community has come to accept and expect.

This is clearly a "survival of the unfittest" situation. A simple-to-implement, adequately robust, but not necessarily full featured solution will always win over an elegant, extensible, more correct solution but that is significantly more difficult to implement. 

EF_STARDUST in the DarkPlaces source looks nearly identical to EF_FLAME, except that it uses pt_static instead of pt_flame.

Is EF_STARDUST needed for a model to emit, say, sparks?

Is or EF_STARDUST redundant because the same effect can already be achieved through other means? Hence its non-inclusion in "Spikespasm".

/I'm looking at smc and thinking about extracting an effect or of it for a tutorial later in the week or on the weekend. 

its either '-quoth' in an engine that hardcoded a specific mod, or '-hipnotic -game quoth' for vanilla, but yeah iiuc its just for the hud.
DP didn't add 'double-gamedirs', it has multiple gamedirs, because limits suck. As does FTE. of course, when you have more than one, order matters. I handled 'game foo -quoth' by parsing the list twice and then re-ordering. And if you want to mess everything up for everyone, all you have to do is to put a space in the subdirectory name! yay!

EF_STARDUST is what exactly?.. Its a specific effect that you wouldn't have a clue what it really looks like until you've actually used it so that you can see. I don't see the point of it because its a specific effect. Its just not significant compared to the more generic stuff like r_effect or traileffectnum.
Iiuc, it predates custom effects and stuff, dating back to the time of hardcoded effects. Same with all the extra TE_ effects.
Yeah, it might be simple enough to rename it to 'ef_customeffect1' or something lame, but that's just lame.
So yeah, you might want it for compatibility, but moving beyond that its probably not very useful, so I didn't see the point of implementing it. 

If I remember correctly, it's an effect used on slipgates that displays star-like sparkles floating upwards. I don't think it would do for, say, electric sparks coming from a broken panel. 

That's what I thought! (It's obsolete, artifact from more primitive days). Thanks!

@mugwump - the particle system lets you set the origin and the velocity and other things. the originoffset could be instead of above it could be to the side and instead of sparkles, sparks. It's just an emitter. 

Simple effect videos

1) Sparkle: https://youtu.be/9TWUVe2_T3c
2) Smoke: https://youtu.be/K4iyK6yW8bw
3) Flame: https://youtu.be/ZH9zMBCyRFw
4) Myst: https://youtu.be/YXRx6sr-H4k
5) Rocket Trail: https://youtu.be/mOE71jc0RtI
6) Decal: https://youtu.be/3mRtTRSOKeE
7) Model Light: https://youtu.be/L8QX0TuTLTw

To be followed up maybe this weekend by tutorials. 

Hey there,
I recently dug around a bit trying to find out how to get some popular source ports including Quakespasm to look as close to the original DOS Quake as possible. Changing texturemode, particles, lerpmove, lerpmodels, etc. one can get Quakespasm to look nearly identical, but the weapon offset is still problematic, it's just too low. Using scr_ofsx gets you somewhat closer, but it's not ideal. I've seen that Tarvis/bangstk made some effort here earlier this year to change that with an unofficial fork, but I guess that wouldn't work for the most recent release. Or can that somehow still be included without official support?

Otherwise, is there any way to change the weapon offset to really get the original look, or isn't that possible right now? And if it isn't, can anybody give me some insight into why exactly that change is there in the first place?
Thanks :) 

There's a comment in the source explaining this removal:

//johnfitz -- removed all gun position fudging code (was used to keep gun from getting covered by sbar)

I believe that Baker's FitzQuake Mark V fork restores that code, but QuakeSpasm doesn't. 

Original gun is available as an option in mark v. Default is still the FitzQuake norm that Quakespasm uses but yeah you can go menu ... preferences ... set gun position to classic. 

I'd like a cvar for that.. we had a patch contributed that enables the classic gun position: https://github.com/bangstk/Quakespasm

It's on my todo list to review and compare to how MarkV implements it. 

You might as well take "fov doesn't affect gun" option too when the time comes. 

Ironically, if I recall, Mark V doesn't have gun fudging code. Original Quake did fudge the gun position. Classic weapon in Mark V calculates the right gun position for the gun to appear on top of the status bar based on FOV and HUD settings and screen aspect ratio. This calculation also has to take into consideration FOVy adjustments for screen aspect ratios.

When you think about the gun fudging code in original Quake, it sounds newbiesauce easy.

But just see what happens when you change the resolution to something with a weird aspect ratio or set an irregularly sized window resolution of 600 x 600 or 400 x 600.

The original weapon position fudging code breaks down terribly in situations deviating far from a 4 x 3 aspect ratio or with enlarging the HUD (hudscale).

(If I recall correctly, it's been a while since I worked on that.) 

Speaking about FOV, I think this option should have a threshold of sorts. Right now it always draws the gun the same, even with a very narrow FOV, which makes zooming very weird. Maybe it should take a value (in degrees) beyond which the gun stops changing. 

Hehe, I noticed that once but thought that I was only the person that actually created such a bind.

You could actually modify your zoom bind.
+zoom "fov 70; r_viewmodel_fov 70; wait; fov 50; r_viewmodel_fov 50"
-zoom "fov 50; r_viewmodel_fov 50; wait; fov_70; r_viewmodel_fov 70; wait; fov 90; r_viewmodel_fov 90" 

Good to know, thanks. 

will Spike's code be integrated into the next Quakespasm release or it is intended to be a stand-alone piece of software? 

Thanks for the explanation about the weapon offset. I hope the patch or another kind of fix finds its way into a release eventually :)

Regarding Mark V, I noticed that it's better there, although unfortunately the beta release of the mark_v.exe crashes on my computer, unlike the latest stable release. However, I've used the WinQuake port of Mark V for playing through Quake the first time only recently and it worked flawlessly :) Now onto Arcane Dimension with Quakespasm. For the time being I'll stick to scr_ofsx -2.8. 

Mousewheel weapon switching is broken on macOS 10.12 due to a SDL2 bug: https://bugzilla.libsdl.org/show_bug.cgi?id=3432

The SDL1.2 version seems to be unaffected.

Icaro: I'm not sure.. For the time being, it's a fork / branch.