... how the hell did I not see the source link the first time I looked at that page... 

just looking at host_cmd.c

maybe use an external file for the bad words array rather than a hardcoded one, that way it can be user updated 

Probably at some point I'll do that.

Thinking about host_cmd.c ... I don't think I documented anywhere ...

give command extra options

give silverkey
give goldkey
give rune1 // rune1 to rune4

If you already have the gold key and wish to remove it, typing "give goldkey" will remove it if you already have it.

Typing "give" in the console will display a list of item names. 

Note: Did end up getting Requiem sorted out. 

QMB effects: lava balls or knight spikes do not leave trails when traveling very fast (velocity 2000) when the server is at .1 ticrate (FvF default due to many monsters and projectiles constantly flying all over the maps).

The QMB trails work fine at .05 ticrate even with the very fast projectiles (Mage's RL = Instant Fireball attack).

Non-QMB particle trails do work under these conditions, but they tend to "skip" a bit. 

Most engines assume a distance traveled per update frame of 200 units or more is a teleportation.

That's my guess without looking at the code because 2000/10 (ticrate .1) = 200

An entity that is assumed to have teleported won't be treated with any kind of continuous movement treatment. 

I saw on Quakeone, Dutch mentioned Mark V has "a difficult time playing external MP3" on his WinXP computer.

That's not very specific, but I wonder if he's seeing the same issue I reported, where there is a pretty significant delay loading the MP3s, during which time the game is completely frozen up.


We tried LOTS of troubleshooting steps in the old thread, but nothing helped for me on my netbook (though the problem didn't exist on my older WinXP laptop). The only thing that made a difference in the end was me re-encoding the MP3s with certain settings that decreased the loading delay (from 17 seconds to 4.5 seconds!). 

I've noticed that with the latest Mark V, it doesn't carry over my video settings (from id1 config) when playing a mod.

Also some occasional flickering/corruption when using GL. I know it's not helpful just to say that so I'm experimenting a bit more to see if has anything to do with my latest NVidia driver update and/or if it happens in other engines. If there's anything you'd want me to do or try that would be helpful in debugging that, let me know. FWIW, latest qconsole.log is at https://dl.dropboxusercontent.com/u/11690738/temp/qconsole.log 

Hm. Upon startup, my autoexec.cfg sets up some aliases (or runs other cfg files that set up aliases).

But then if I am sitting on the server and I reconnect to the same server (by "connect fvf.servequake.com" -- I was toggling external lit files), many of my aliases are forgotten.

But not all of them....

For example:

alias zoom_out "chase_active 1;chase_mode 1"

Is always forgotten upon reconnecting, but:

alias start "changelevel start"

is never forgotten.


This is pretty inconvenient. It means I have to re-run my cfg files when I want to reconnect or connect to a different server without completely restarting Mark V.




QMB effect difference: Particles in Quake are "fullbright" but the QMB blood effect is not fullbright.... So, in Quake you can always tell when you are hitting a monster in a dark area, but with the (more realistic) QMB blood, you can't tell.... Perhaps in this case it would be good to throw in a few standard red particles (even QMB particles are fullbright) in addition to the blood sprites (they are kind of sprites, aren't they?).

But this will fall under QMB fine-tuning.... 

alias zoom_out "chase_active 1;chase_mode 1"

Cannot reproduce.

I bound the above exact alias. Connected to a random server. Disconnected. The alias was there. Reconnected. Disconnected. The alias was there. Even connected to your server, disconnected, reconnected, changed the map, disconnect, reconnect, disconnect.

The alias was still there.

red fullbright blood - monsters in the dark

Interesting difference. Although I haven't looked into it, I suspect QMB blood is already fullbright, it just isn't very bright. Something to think about. 

QMB blood types 1 and 2 have a blend mode of GL_ZERO, GL_ONE_MINUS_SRC_COLOR, so they're not lit, they're just blended with the background geometry. 

Probably should change then. At least for the ones that aren't intended as true "ambience" and few of them are. 

Ok... There's some weird interaction of FvF + my tricky aliases + Mark V

So in FvF, when a player connects, or when a map first loads, I do:

stuffcmd(self, "re-exec\n");

Then I can set up stuff like this, in autoexec.cfg for example:

---------------

alias fogon "fog 0.05; bind f8 fogoff; alias fogset fogon; echo Fog On"

alias fogoff "fog 0; bind f8 fogon; alias fogset fogoff; echo Fog Off"

alias re-exec "fogset"

alias blah1 "echo blah1 is set"

fogon

alias blah2 "echo blah2 is set"

------------------

Yeah, I don't know how "correct" that is, but it works. It lets me toggle fog on and off with F8, and at each level change the automatic "re-exec" alias will run the "fogset" alias which will be assigned to either the "fogon" or "fogoff" alias, depending on which I last toggled with the F8 key....

But I think the problem is arising where I am assigning one alias to another alias like that ("alias fogset fogon" within the fogon alias...).


So, as I said, usually all this works fine. Every level change the fog setting will be re-applied after the level starts, or upon first connecting to FvF.

But if I am sitting on the server and I re-connect to the server, things go wrong, and ANY alias that was assigned AFTER the "fogon" command in the cfg above will be forgotten (so blah1 above will remain, but blah2 will be forgotten, as will any alias you have manually entered into the console).


OHHH, I think I may get it... or part of it....

It seems to happen upon DISCONNECTING from the server.

So this may be happening:

- All aliases are set up before connecting.
- Upon connecting, the server has you run "re-exec" by stuffcmd, which runs "fogset" which runs "fogon" which includes "alias fogset fogon" so now Mark V thinks it's a SERVER stuffed alias, so it discards it when you disconnect from the server....? Maybe?

That still doesn't explain why ANY alias set after that point (either in your cfg file or manually by console) is also forgotten....


Let me see if I can trim this example down a bit more.... The above fog setting code is actually useful (to me anyway -- I don't just do this crazy stuff for no reason!), but here's just a proof of concept to show the issue I'm having:

-----------

alias setblah "alias blah say blah"

alias re-exec "setblah"

alias blah1 "echo blah1 is set"

setblah

alias blah2 "echo blah2 is set"


--------------


The odd thing is if you remove the manually running of "setblah" from the autoexec,cfg file above, then everything seems to work, and only the "blah" alias will be forgotten upon disconnecting. Blah2 will remain. Ah, but any alias you set AFTER connecting to the server will be discarded.

But if that line is there, then every alias after that point will be forgotten upon disconnecting from the FvF server.... blah2 will be gone, as will any alias you set in the console after that point.

That's weird, right? 

QMB Effects: I think I know why my splash effects are being destroyed so quickly... and also why my chat smoke looks a bit odd.

It seems that most QMB particle effects are quickly removed if they are touching a player.

Try jumping up and shooting the floor below you with the shotguns. You will see that the particles vanish as soon as you come back down on them.

Perhaps this is an attempt to prevent obscuring the player's view with too many particles right on top of him? Though the explosion effects are what's really bad at doing that, and this doesn't work for them!

But yeah, that's messing with my splash effects, which are created at the player's location. 

QMB particle effects are quickly removed if they are touching a player

They are. In single player fire a rocket an even angle. Type "freezeall".

Now with everything frozen except you ...

Walk through the smoke, any smoke you walk through goes away. 

I've noticed that with the latest Mark V, it doesn't carry over my video settings (from id1 config) when playing a mod.

I used to have Mark V read those settings only from id1. Then someone said, I when "I play a mod, it ignores my settings I changed when I play it next". So I had to iterate through the proper Quake way.

Which might describe what is happening in the above.

To get it to be ideal (both!) would be bit involved, but I do have a plan for that in version 1.3, it's elegant and simple. It also involves some slight evil, but it's awesome kind people like and some other engine coder will say "Ah, that's ingenious."

Story for another time ;-)

my latest NVidia driver update

Let me know. Is it new for the driver or new for the version of Mark V?

They say NVidia's latest driver does flicker, but I'm not going to assume that it also couldn't be the engine's fault somehow in some rendering circumstances.

None of the FitzQuake derived engines have a state manager. Which means there can easily be an errant situation where something crazy like a glBegin without a glEnd or two of them or such other possibilities exist.

1) If the problem persists or exists without the current driver ...
2) Or if a previous version of Mark V doesn't have issue ...
3) Or if a certain map ...
4) Or certain combination of options ...

Short version is that at some point Mark V will have state manager, which would reduce the chances of the engine being at fault greatly (but a few other situations would still be possible).

Let me know if it persists and if it happens with a certain map or a certain setting on. 

It happens to me too. It has started once I switched to geforce 1060 videocard. It happens in both old and new versions of mark v on any map. I hope it helps.

And there's one minor issue about mirrors. I want to make a small map about mirrors. I placed two mirrors on the opposite sides of the room (I know it's not the way it should be intended, but it looks soo cool), you can't see them both at a time, they reflect well, but one of them turns off once I stand close the other mirror (touching it with player's back). I supposed that the second mirror somehow got in the view (but it didn't) so I placed a clip brush in front of it, so I can't get close to it. But it happens the same way once I touch that clip brush. And it always happens with only one of two mirrors (the rooms are completely symmerical), while the first one works as it should when I touch it with player's back. I tried it in two different rooms and the problem always occurs with the south mirror. The problems disappears once I get 1 unit away from the wall. 

It seems that the flame cut-off system for the QMB particles doesn't work on replacement models. I'm using this pack and the flame polygons stay:

http://www.quaketastic.com/files/models/auth_mdl163.zip

Another minor nitpick is that only the main Enter/Return key works in the menus, the numeric pad Enter doesn't. 

backbuffer.clear(depthandcolour);
for (i = 0; i < nummirrors; i++)
{
scene.addclipplane(mirror[i].surfaces.backplane); //ensures the mirror can only draw what is actually reflected, and not things that cross the mirror's plane.
//fixme: set scissor region
mirror[i].draw_reflectionof(scene);
scene.killlastclipplane();
mirror[i].draw_diffusetransparent();
backbuffer.clear(depthonly); //anything in the real scene should not be obscured by the mirror
for (j = 0; j <= i; j++)
mirror[j].draw_onlydepth(); //mask the depth so nothing further within the real scene can overwrite.
}
//fixme: reset scissor
scene.draw();

assuming I typoed it wright and you already know which mirrors you want to draw, the above algorithm should allow you to have cubes with mirrors on each face or whatever.

if you can make the mirror-list calcs recursive like in FTE(r_portalrecursion > 1), then you can get mirrors reflecting other mirrors. Just beware that if one mirror can see two mirrors then any further recursion will likely be exponential (read: really slow). 

here's some obscure territory

Quake is originally designed for 320x200 resolution to be run on 4x3 displays (just like Doom). This means, that whole screen should be stretched vertically. The original game nicely adjusts viewport so that actual gameplay window is always at true aspect no matter what resolution is set - 320x200 will look exactly like 320x240. But the UI is not. It is designed to be stetched, so it only looks right on 320x200 and 640x400 resolutions and is "squished" on every other.

So what's the problem? Mark V removed id's aspect corrcection and treat every resolution identically. Setting up 640x400 and 320x200 result in stretched in height gameplay window.

The ideal solution would be to add an option to make correct UI scaling. Here's some example shots of original winquake and Mark V scaled to 4x3 and upscaled

http://i.imgur.com/ZnPksXb.jpg
http://i.imgur.com/mJLsJH5.jpg
http://i.imgur.com/dWRoC5M.jpg
http://i.imgur.com/fj0f4aI.jpg
http://i.imgur.com/n8lznjF.png
http://i.imgur.com/tmH5eHL.png

http://imgur.com/a/jAW3U 

Right now, I treat Open GL and WinQuake identically (it's biased towards Open GL treatment).

From your screenshots I do see what you are saying. Thanks for providing screenshots. 

At some point like what Spike hinted at, I would like to improve the mirrors.

There are certain 3D calculations, reworked drawing, even tool support (.vis) and possibly some recursion that could make mirrors better.

Blocking a mirror with a brush doesn't necessarily help because Quake map vis truly sucks and does a relatively poor job (play r_lockpvs 1 and walk around and be prepared for surprises).

I'd like to put mirrors on 2 sides of a room too.

Limits suck and you can hope for better in the future, but right now you can't have 2 mirrors that can see each other according to map vis.

And it is worse than that, because in the current implementation there should not be a location where 2 mirror planes can be seen from anywhere in the map.

That being said, it still gives plenty of freedom to do awesome stuff with mirrors --- even with current limitations. 

Yeah, I hear you.

Original QMB as witnessed in JoeQuake or similar engines, would actually override a custom flame.mdl with its own.

Allowing for no possibility of using a replacement model for flame.mdl at all.

One possibility among many is that I might at some point do the flame drawing more aggressively to not require my "sawed off flame.mdl" method --- the flame would acceptably draw over the part of the model that shouldn't be shown.

At the same time, one problem with the QMB flames method is it is tailored to pak0.pak flame.mdl. 

It is probably easy to resolve in the engine.

In a few weeks, I'll probably have my hands on a NVIDIA "gaming laptop" or 2. All my machines are AMD, including the Mac ones. :/ 

I had no idea how dirty you are ;)