Could you add the teamplay scores to the scoreboard sheet
there is an ancient engine by tonic(?)glsq.exe
that actually does this thing(very handy when playing vs frogbots)

at this moment that engine refuse to run on my current rig , so there's no example screenies 

I think I like the con_verbose 1 (information is good), but I would really suggest reversing the order of what is printed; when someone types just a cvar in the console, they are wanting to get its current value of the cvar. So the current value should be the last thing printed, because your eye automatically goes to the last thing printed in the console when you are looking for the output of your request.


I do not like cl_truelighting. In fact, I think I GREATLY dislike it, heh. The lighting gun does not fire in a constant stream like a water hose; it fires in rapid pulses, like a lot of separate lighting strikes. This effect makes your visual indicator inaccurate and misleading. This may make a bigger difference online, but test it for yourself in single player by setting your host_timescale 0.1
You can now clearly see that your lighting bolt fires in pulses; the sound effect is now spaced out so you can clearly recognize this -- the stain maps on the wall also will demonstrate clearly where you are actually hitting. The sounds and stains will line up exactly with where you see the bolt strike if you have cl_truelighting 0. this is the correct effect -- the lighting gun fires in rapid pulses. But if you have cl_trulighting 1, you only see a "laser beam" effect of where your gun is pointing rather than the actual beam that is hitting the wall, when and where it is actually striking. So... "true lightning" is actually "false lighting."

I have no use for this deceptive effect. Throw it away, or disable it by default! heh

Disable it by default, and if someone tries to enable it, print a warning, "Are you SURE you want to enable this awful, deceptive effect??"

;) 

Hey killpixel, have you tried the GL or DX versions to see if you get the lag spikes in those versions?

You can change settings in them to make them look all pixely too, like:

gl_texturemode gl_nearest

and other stuff....



Uhhh, Baker, I know you're messing with particles... it seems the Grenade and Rocket Launcher have lost their particle explosions.


And my Fvf chat bind is no longer working for the ` key when I bring down the console.

I use:

bind ` "impulse 39;toggleconsole"

bindlist shows it is still set, but it doesn't seem to trigger the impulse. If I bind another key to that, like "w" then it works as usual. 

in the quakeworld community, truelightning is otherwise known as fakeshaft.
and it breaks mods, so should normally be disabled by default if you care about maps+mods rather than trying to be a replacement proquake.
assuming baker implemented this too, try a fractional value. that should smooth it a bit while retaining a bit of its snappyness so you can still sync it up. 

cl_truelightning was written by Joszef, the author of JoeQuake -- the engine used by speed runners.

It just uses the player origin as the starting point.

It sure as hell doesn't break mods, doesn't support fractional values, isn't server side.
And it existed long before anyone in QW ever made such a thing. 

I can't add teamplay scores to the frogbots scoreboard in the engine because it requires QuakeC support. However, since you've modified the frogbots source yourself, you may be able to implement this in the mod by examining the only open source mod that I know of that leverages the feature source code.

/Contrary to impression some people get, my QuakeC skills are about cut-and-paste newbie level except I can see function operations from the engine side and I mentally have a catalog of modifications and what releases do what.

@gunter - kp wants the real deal, he likes the software Quake look. He knows about GLQuake texture filtering command.

@Spike - p.s.: guess which engine does not have such a feature -- it's modern ProQuake. I was a beta tester for JoeQuake, I sure knew about the feature. I've always considered truelightning a single player visual enhancement.

Hence, gunter who plays co-op online is the only person who will complain about truelightning, that's the only time you wouldn't want the effect.

It's like animation smoothing for the lightning gun. 

it's just depends of the color of given team,

the red team gives its own score points and so on

not related to fb(qc whatever) at all 

re: RL Particles -- I'm on it. I was going to try to get a 2nd update in about an hour after that one. Thanks for heads up.

re: toggleconsole ... With international keyboard support, binding to the USA tilde key has no effect.

It is now key placement specific behavior hard-wired in the engine to support that the key below ESC activates the console no matter if the keyboard is German, French or Brazilian. 

You should have eaten the beetle. Good source of nutrients!

hindsight is 20/20... next time

@gunter - yeah, I've tried the other versions, but only briefly. I will revisit that.

My quakespasm setup is as you suggest. However, Mark V has two key features: indexed colors and resolution scaling. That aesthetic is my jam! 

Ah, I see. At some point, I'll look at the frogbots mod and see if I can causes it emit teamscores to achieve what you want, but using what I consider the "correct design" way.

I like knowing the team score. Admittedly, when I am playing frogbots, I'm generally playing free-for-all style, so didn't think of your idea. 

i'm aware of thr team x leads by x frags 

i'm gonna resurrect my old rig to give you a clearly view of my desired wishes

thanks for your reply 

/Contrary to impression some people get, my QuakeC skills are about cut-and-paste newbie
level except I can see function operations from the engine side and I mentally have a catalog of modifications and what releases do what.


Mister B, you're underestimate yourselves and your skills 

"true"lighting -- actually, playing coop online won't be the only time I'd complain about it, heh -- it feels wrong in single player too. It is NOT the same as animation smoothing -- you are drawing the actual "projectile" that comes out of the lighting gun *in the wrong place*. I can tell this even in single player, and it feels wrong and fake, like I know that lighting bolt is a harmless illusion instead of an actual bolt that is striking where it appears to strike. The bolt just doesn't feel "real" anymore -- like real electricity is a series of rapid flashes, not a steady laser point beam.

though I do wonder how it could possibly "break mods..." unless slow motion was in play or something.



toggleconsole/international keyboard -- err... this breaks compatibility then. Can it be disabled?



New report -- during the "congratulations" screens, pressing TAB causes the text to disappear, but not the "congratulations" banner (this is in "DM mode" that FvF Quest runs in, when normally TAB should show the scoreboard). It doesn't actually show the scoreboard, it just makes the text vanish. Proquake didn't do this.

Also, I guess I'll note that centerprint text still appears behind the standard menus (this is altered behavior too).


And, should not "Weapon Draw" in the menu be defaulted to "Quake Default" rather than "Fitzquake?"

Heck, "crosshair" in the menu should probably default to "quake default" too, even though the actual Quake default was "no crosshair" ... but everyone uses crosshair. 

Download same place as usual

Changes
- Fixes rocket explosion a missing particle.

This is a correction of the 1002 build.

/Typing "version" in the console will show as build 1003. 

I will put in a an option to disable the hardwired tilde key behavior in one of the upcoming versions.

I'll have it so if in_keymap is 0 (turns off international keyboard support), tilde behaves in the old way. 

The lighting gun does not fire in a constant stream like a water hose...

I hate to get all "Quake Manual" again, but...

Thunderbolt: Try it. You'll like it. Use the same technique as watering your rosebush. 

Adding to what mh said:

QuakeC is trying to get the beam position to always be starting at player origin.

The problem is, it is only updating 10 times per second because QuakeC is 10 fps.

The implementation of rendering the lightning beam as if real-time (an illusion) on the client side is merely doing what QuakeC is trying to do, but can't.

/I mean jerky sky scroll is how original WinQuake works, but Mark V straightens that out too. Same can be said about FitzQuake 0.85 animation interpolation. I don't see Jerky Lightning Beam being something that was a design plan, but rather a side-effect of a technical limitation of the speed of a 1990s computer. 

I'd be inclined to go slightly further with this: Lightning angles are another of those framerate-dependent client-side behaviours, so they should be simulated at a fixed rate instead. 

NightFright went all out!

Take a look!

If you want transparent water without vispatching (.vis) and colored lights (.lit) for Add-On Mission Packs ... see this ...

https://quakewiki.org/wiki/External_Lit_And_Vis_Files

- Nehahra
- Beyond Belief
- Abyss of Pandemonium
- Several more ...

There is a link to that page on the Mark V site next to the Transparent Water/Color Lights (says "More ...")

/The .vis files work in DarkPlaces and FTE too, some others like Engoo. 

Could you explain that in a bit more detail ... 

I suspect I'll make it work like this:
0 = off
1 = single player only + if you are playing bots [sv.active in engine terms] (because in my view this is the only correct use of feature)
2 = always 

If you look in CL_UpdateTents you'll see that lightning angles depend on a rand: ent->angles[2] = rand()%360;

So if you run at 20 fps this angle changes 20 times per second.

If you run at 72 fps it changes 72 times per second.

Etc.

So this angle is framerate-dependent.

A possible solution: create a lookup table of angles and index into it by some function of cl.time; probably also need to use the temp entity number so that not all bolts get the same angle.

Ent->angles[2] = angletable[(Cl.time * 72) + i]

Something like that. Forgive capitalization & typos, on a phone keypad. 

I actually remember that line from the manual about watering the flowers, heh. However, you could still water a rosebush with a sprayer that spurts water 10 times per second ;)


Ok, there is no limit in QuakeC about running things more than 10 times per second. You can easily make thing do stuff in much smaller increments. I actually have some test code I sometimes activate for fun that lets your weapons fire INSANELY fast. 10 nails per second is the standard rate of fire of the nail gun too, but I can modify it to fire a bazillion nails per second if I want.

Screenshot of me firing a bazillion nails per second:

http://imgur.com/a/m3ija

heh

The reason the guns don't fire any faster than that is not because of any QuakeC limitation -- it's because if it fires any faster, it would be too powerful in addition to burning through your ammo way too fast.

Of course, the standard .05 ticrate of Quake would tend to limit things from happening more than 20 times per second when playing online.... not to mention a bazillion nails onscreen would cause lag, heh, but it's not at all a QuakeC limit.

The lightning gun could easily have been made to fire/strike much faster than 10 times per second, but that would require it to do less damage per strike among other things.


Now, the firing origin of the lightning bolt, by default, DOES stick to the player. You can see this in chase mode (use host_timescale .1 or slower). The end point of the bolt, however, sticks to where it HITS. There is no QuakeC limitation causing this behavior -- this IS the intentional and correct behavior of a rapidly-pulsing lightning gun.

You're trying to fix a problem that does not exist.

If id wanted the end point of the bolt to stick to your crosshair position, they could have done that, just as the start point of the bolt sticks to your player position in chasecam.


Oh, and I found a mod that "breaks" because of "truelighting" ... My mod! FvF! heh... Ok, "breaks" is an overstatement, but the Mage class has his own, slower-firing, lighting attacks, and this makes them look very bad. Well, it's the same kind of "bad" as for the regular lightning gun, but it is just more noticeable because the Mage fires his bolts more slowly than 10 times per second....


Anyway, if you want an "eycandy" effect like this, fine, but default OFF please. And be very careful about adding stuff like this -- junk like this is the whole reason many people dislike the majority of other Quake engines -- it changes the gameplay feel or look too much.

A smoother-scrolling sky? Sure, that's just a visual thing that makes no difference in gameplay feel. Smoothed monsters look much better than jerky ones too (though some people prefer a "retro" feel). But the "jerkyness" of the lighting gun is not merely an animation issue -- it's actually showing you precisely where the bolt is striking as it pulses 10 times per second. 

Excuse the double post, but it's probably worth mentioning that in my own code I use 36, not 72, and talking a bit about why.

I take issue with the common statement that Quake is designed to run at 72 fps. If you look back at the time it was developed, while there certainly was hardware that could run it at 72, most hardware couldn't. Especially in the typical configuration, which was playing the DOS version on Windows 95.

Most people were playing Quake at 20 fps, 30 maximum, and while id do design for the future, they also design to get a good game on current hardware.

So I'm more inclined to say that Quake was actually designed to run at 20-30 fps and that 72 fps was nothing more than a framerate cap, "so packets don't flood out", according to the comment in host.c

The number 72 is significant: it would have been a typical refresh rate of a typical CRT monitor from the time.

Hence for certain framerate-dependent effects (rocket trails are another, rocket trails aren't actually a smooth trail at all but rather clumps of particles with each clump spaced out & intended to represent a puff of smoke) it makes more sense to run them at a slower rate. 36 is just a nice even reaction of 72 (24 would be another) but there's no actual technical or analytical basis for it.