It is also a "feature" by ATI drivers. 

Are there any other libraries needed to build Fitz? (all I have is VC++ Standard) And...
Do you know if the Vertex Lighting tut @ quakesrc.org is compatible with your source since you've already made changes to how models are lit? 

First, check out this thread about building fitzquake; it should address most of the problems you are having or will have building it:

http://www.celephais.net/board/view_thread.php?id=60023

Second, i don't know which tutorial you're talking about... got a URL? 

http://www.quakesrc.org/tutorials/old/102 

Thanks for the link, I'll check it out... And here's the tut http://www.quakesrc.org/tutorials/old/102
Tremor is the only Q1 engine that uses it as far as I know of. It's subtle but a nice effect without going per-pixel. I'm just not sure if your overbright code would interfere. 

I think this would work, but you might have to do a little bit of reading and adapting rather than just pasting code in. I have color lighting instead of greyscale, so that's one difference. Overbright shouldn't pose a problem. 

I don't really have interesting to say, but FitzQuake has been one of the engines that I most study for understanding how different changes are implemented and just wanted to say thanks for all the work you put into it.

I've been comparing the incremental changes between the various versions a lot lately, in particular the texture manager which I very much like. 

thanks :)

how's your engine thing going? 

Very well. Someday in the distant future, I'll have something interesting to release. ;) 

This isnt only directed at you, but I'd imagine anyone out there who programs Quake engines - fog isnt supported in demo playback!

Well, I'd imagine it maybe is if the "fog" key is in the worldspawn (?) - but In my new level there are some trigger_multiples which target two info_commands (quoth entity), each:
"classname" "info_command"
"message" "fog # # # #"
One turns fog on, the other turns it off.
I think this effect is great, but it only works in-game and not in demo playback...

(not a niggle, just a 'discovery' :-) 

the ideal way to do it is to have a SVC code for changing fog built into the network protocol, and have the quakec send that SVC message. And actually, fitzquake does, but i never documented it. (I was going to wait for "The Quake Standards Group" to get back to me with approval of the SVC numbers I wanted to use, but they never got back to me. That was like 4 years ago. So I guess there's not going to be any standard.)

But anyway, i'll look into info_command hacks and demo playback. But what's weird is the background flash when you pick up items works during demo playback, and I believe that's done the same way (quakec using the "stuffcmd" feature) 

Question: Did you record the demo before you added the trigger_command to the map? Demos load the entities they were recorded with, not the entities in the map. So if you hadn't added the fog trigger when recording it shouldn't come up in playback. 

I recorded demos since the triggers/info_commands were added!
Download the map and Mikko's demo and see! 

is because the Quoth commands are executed with localcmd instead of stuffcmd. The former only executes on thr server and is never sent to the client, which means that it's not recorded in the demo.

For a local area fog command (or wateralpha or similar), it'll produce strange effects since this should depend on a particular client's position and then is seems more appropriate to use stuffcmd.

Ammo pickups use stuffcmd, therefore they work properly in demos.

I don't know why Quoth uses localcmd for this really, maybe some other command requires that. 

That's been the behavior since hipnotic I think, although it's going to change in the next version of Quoth. Everyone seems to use commands that are intended for stuffcmd, so the info_command is going to be fixed to cycle through every client and use stuffcmd. This will also ensure that commands work in coop for any player other than the server. New entities like info_command_server and trigger_command have been introduced; the former to replicate the behaviour of the old entity with localcmd and the latter to create a trigger that only sends commands to the player that touches it. In single player you won't notice the difference between the old and new info_command.

You might jump in and say that's going to wreck Ricky's map in coop, but it's only highlighting the problem that's there. At the moment, every time somebody descends to the lower level, the player running a listen server will see fog, but nobody else will, and it'll turn off every time someone goes back up. This is why the new trigger_command is being added, to provide a correct way to make such things work in coop. 

with strange effects; you shouldn't send any fog commands to all clients (nor the server), only to the client that's actually in the fog area.

Maybe other commands would require different behaviour but not this. 

i misunderstood what localcmd did.

i used localcmd because i thought it would execute on the server so that all players connected would get the effect. thing is, i forgot cheats actually DO work in COOP, but the idea was that if you wanted to use godmode or sv_gravity xxx or something in your info_command. 

Yeah, something like sv_gravity would work correctly with the old info_command, because the physics is done on the server side(godmode wouldn't). It's also the only way that you could do such a command, a client executing sv_gravity does nothing if they're connected to a remote server. sv_gravity is the kind of thing the new info_command_server is for. For strict backwards compatibility the way to do it would be to leave info_command using localcmd, and create a new info_command_client that sends stuffcmd to every connected client. But it seemed to me that pretty much every existing map is using info_command to send client commands, so changing it that way round made less sense. It's not set in stone yet, if people feel strongly about it. 

First of, I am allergic to programming in any kind of C language, so I speak purely from a mapping POV:

If I made a map in the past that fog didnt work in then I'm not bothered if it still doesnt work. I'd rather have full functionallity of maps in their original state, but have new entities for new maps which allow better functionality.

On the other hand:

If old quoth maps will work under quoth2 progs (?) and you CAN re-program the info_command function to allow the fog to work then great!! But if the modification to the progs for the info_command entity fucks up other stuff in other old maps, then it would be better to leave it as it was, I would be atleast grateful for the new info_command_client option for future maps... 

in demo playback... 

Just to make clear - in single player mode all maps will behave exactly as before regardless of which way round the changes are made. This is because the client and the server are the same machine. The only time this will affect behaviour is for people playing in coop mode. Quoth2 has coop support as one of it's focuses, which is why these things are being considered.

Changing info_command and adding info_command_server

PROS: Will automatically fix existing maps where the effect should apply to all players - like say a global change in fog triggered by an event or a trigger forcing r_wateralpha at the start of a map(walking into an area with fog still won't be treated correctly because it'll change each time anyone hits the trigger - doing this correctly requires a whole new entity). Such commands will also show up in demos.

CONS: Will break an existing map that uses info_command to issue a true server side command, for example sv_gravity. I believe that there are no existing maps for quoth that do this. If somebody knows otherwise, tell me now and I'll rule this option out.


Leaving info_command alone and adding info_command_client

PROS: Existing maps will function as before in co-op - true backwards compatibility.

CONS: Client side commands in existing maps will still only be sent to the server, not any separate clients. This also affects demo recording.


My thinking is that the con of the first option doesn't apply to any maps so far, and new ones can use the entities correctly. But obviously if this change is gonna break someone's map I don't want to do it, which is why I'm asking this kind of development question in an open forum. In summary of the summary, quoth2 will fix all your ills! 

i agree :)

but if anyone can think of a map where you need to execute a server only command, you should post here!

server only: sv_ anything, impulse9 + 11 (heh, it'd be funny to make a map that would execute impulse 1 -> 8 and impulse 12 and stuff like that... really fuck with the player's head :P )

client: bf, v_cshift... 

actually, when i checked what thread this was... you should probably post somewhere else. ^_^; 

When I connect in any server I can't see other players skins. I can see the models, but there is only strange colors on them, lots of black/yellow/green covering in lines/blocks all the model. It looks like a Matrix character.

This problem only occurs in v0.80, when I'm connect to a server. If I'm the host or using v0.75, there is no problem. Standard GLQuake is OK too.

How can I fix this?

Thanks for this project, it solved a lighting bug in my old ATI Rage 128! 

Thanks for the report. I've seen some stuff like that, but I thought I had fixed it all. The player colormapping code has been revised a few times, and it looks like I need to go over it again to see if there are still bugs like that.

As for what you can do to fix it in the current version, i'm not sure exactly. If there is a cvar that disables colormapping, like cl_nocolors or nouploads or something, that would probably solve it... I'm at work now, so the source is not here in front of me.