News | Forum | People | FAQ | Links | Search | Register | Log in
Fitzquake Mark V
I wasn't planning on doing this mini-project, it started as an effort to address some Fitzquake issues, fix them the right way up to Fitzquake standards (i.e. do it right, once and properly versus continual releases) and donate it back.

FitzQuake Mark V Download:

Short version: Eliminated most issues in FitzQuake thread, most issues I can even remember hearing of ever and marked every single one clearly with a very minimal implementation.

It may be the case that only metlslime and Quakespasm and engine coders may find this engine upgrade of interest.

Features: 5 button mouse support, single pass video mode, external mdl textures, alpha textures (like RMQ), record demo at any time, rotation support, video capture (bind "capturevideo toggle"), console to clipboard, screenshot to clipboard, entities to clipboard, tool_texturepointer, tool_inspector (change weapons to see different info), clock fix, contrast support, fov does not affect gun, gun displays onscreen, Quakespasm wrong content protection, external ent support, session-to-session history and .. (see readme).
First | Previous | Next | Last
Found a typo when HD folder is set. Message misses a "set" i think.

Could you explain this? 
Scancode: h 104 ascii 0

Scancode: 0 ascii h 104

Scancode: h 104 ascii 0

Scancode: d 100 ascii 0

Scancode: 0 ascii d 100

Scancode: d 100 ascii 0

Scancode: f 102 ascii 0

Scancode: 0 ascii f 102

Scancode: f 102 ascii 0

Scancode: 9 ascii 0

hdfolder (command)
Scancode: 0 ascii 0

Scancode: 9 ascii 0

Scancode: 13 ascii 0

Scancode: 0 ascii 0

Set high content resolution folder. Set to "" for none.
Current HD folder is to "hd".
Scancode: 13 ascii 0

Scancode: c 99 ascii 0

Scancode: 0 ascii c 99

Scancode: c 99 ascii 0

Scancode: o 111 ascii 0

Scancode: 0 ascii o 111

Scancode: o 111 ascii 0

Scancode: n 110 ascii 0

Scancode: 0 ascii n 110

Scancode: n 110 ascii 0

Scancode: d 100 ascii 0

Scancode: 0 ascii d 100

Scancode: d 100 ascii 0

Scancode: u 117 ascii 0

Scancode: 0 ascii u 117

Scancode: u 117 ascii 0

Scancode: m 109 ascii 0

Scancode: 0 ascii m 109

Scancode: m 109 ascii 0

Scancode: p 112 ascii 0

Scancode: 0 ascii p 112

Scancode: p 112 ascii 0

Scancode: 13 ascii 0

Scancode: 0 ascii 0 
Current HD folder is to "hd".

should read

Current HD folder is set to "hd". Or..? 
Looks like I need to remove that dprint I used for testing because it spams. 
Scancode spam annoys a lot 
New Version With Ericw's Deadkey Fix 
Current download:

Ericw's deadkey fix, seems to solve this issue!

The spams are gone and touched up the hdfolder print that mfx pointed out. 
It looks like this code is meant to be called after a WM_KEYDOWN?

Yeah, it should be safe to call it any time, but you probably want to call it after the WM_KEYDOWN that opens the console. In QS we call it when the console is opened / closed, or any time we enter or leave text input mode (for chat.)

The idea in QS is we are listening to WM_CHAR messages when the user is typing in the console / chat, so their keyboard layout is respected (QWERTZ, etc.), but in game we just use WM_KEYDOWN/WM_KEYUP. That WIN_ResetDeadKeys function prevents keys pressed in game mode that happen to be dead keys (e.g. the ^ key) from leaking over into the text input in the console.

MSDN link describing the messages that are sent when the user presses '^' then 'o' on a German keyboard.

It's all very confusing, hope this makes sense somewhat! 
Is Somebody Testing The Mac Version? 
On my machine it does not find the id1 directory and it can not load the gfx.wad, while the windows versions, installed in the same directory, are running perfectly. 
Baker, cool, sounds like the deadkey fix worked! I will give it a try later.

In my experience you need to enter "-basedir /full/path/to/quake" in the Mac version launcher.
Could be a problem that only affects newer macOS versions. 
Baker, ^ fixed. Thx! 
Ok, I implemented that for a change in the intended key input mode (scan code intent vs. character code intent -- console/menu/messagemode). Thanks for your explanation!

Updated again:

Perhaps now the international keyboard support is finally rock solid due to ericw.

@icaro -- the Mac version is about 3 revisions old. That being said, if the Quake folder on your Mac is say /Desktop/Quake and your pak0.pak lives at /Desktop/Quake/id1/pak0.pak then putting the Mac version in /Desktop/Quake should work. It is less polished than the Windows versions in some ways, but still isn't bad. Not sure when I will have the time to update the Mac version. But wanted to make the Mac version at least findable. 
@ericw ... Thanks, It Works 
Be sure to try this screenshot:

type: install
type: game undergate
menu Single Player->New Game 
Hm, Baker, you've changed something about exiting a map in the recent versions....

In FvF, upon exit, I draw a line out from the player and move the intermission point there, so it will point at the player while he dances.

But something weird is happening now and the camera is ending up on the '0 0 0' world spot....

Though if the player is moving, sometimes my safety code kicks for when he leaves the view of the first camera point, and it draws a new line and moves the camera there so that the player is in view. 
This might be a good read:

I don't know if it applies, but both ProQuake and FitzQuake 0.85 separately created the same intermission camera bug. Since JoeQuake uses ProQuake network code, that engine family line too (Qrack, etc.)

I fixed the bug via a solution from Enhanced GLQuake (Ben Jardrup's engine).

If this is the nature of the problem, a GLQuake or WinQuake would have the same issue because FitzQuake/QuakeSpasm/ProQuake/JoeQuake/Qrack all have the camera reversed. 
Download complete
Couldn't open zip C:\Documents and Settings\Aaron\My
Warning: Couldn't extract gfx/env/morose_bk.tga


It downloaded, but the install didn't work, and I can't locate the file anywhere on my hard drive. There is no _library folder.

Oh, I found the file. it's in c:\Documents and Settings\Aaron\Application Data\Mark V\caches\__tempfiles\

Wait, I'll make an id1\_library folder and try again....

Ok, that seems to have made it work. Now it installed and ran just fine after I manually created the _library folder and did the command again. 
I checked with the original Quake.exe -- my intermission code works fine in that. 
+1 on install bug.

Could you describe what the QuakeC does very specifically. Like step by step. Are you using "stuffcmd" during that?

It might be fighting against a Mark V defensive feature that prevents Nehahra or Zerstorer from wrecking your settings. 
Updated with "install" command fix. 
Uhhh... it's complicated.... Plus I wrote it years ago. And I hack code like a crazy mofo, heh.

But I'm pretty sure there's no stuffing at that point.

Um, let's see.... In execute_changelevel, it uses FindIntermission() to pick one of the intermission points (I guess that's standard behavior).

Then I search through the list of classname = "player" to find the person with the highest score, then I do a randomy traceline out from him and setorigin for the selected intermission point to that location, along with setting its model to the bubble sprite (I think I did that so I can give it a velocity sometimes).

Then I set its angles to point at the player, where "org" is the player's origin:

ang = vectoangles (org - cam.origin);
ang_x = 0 - ang_x;

cam.angles = ang;
cam.mangle = ang;

Hm, I'm pretty sure that code is not the problem, because I re-run it every couple seconds to make sure the cam stays pointed at the leader (often he will still have some momentum when the level ends), and then it also checks to be sure the leader is visible to the camera, and if not, it re-runs the positioning of the camera again.

It seems only the first run through of the code is getting the glitch and putting the camera on '0 0 0' with no angle pointing at the player (I think the angle is also '0 0 0'), but if the code runs a second time (due to the player getting out of view of the camera, which is harder to do when the camera is outside the map at '0 0 0' because it can see into the map almost everywhere) -- then it runs through the same function again, but works correctly....

Hm, interesting... when I check the entity information for the intermission camera, it says it's in the correct location, so maybe the issue is at the point when the player's view is set on the intermission camera.

Ok, here's a difference in what I do for each player

msg_entity = other;
WriteByte (MSG_ONE, 5);
WriteEntity (MSG_ONE, pos);

I believe that sets the player's view to that of my intermission camera since it can change angles and I want to keep them seeing through it's "eyes." I guess normally Quake doesn't do that because it has static intermission points with set angles, so it just sets each player to that spot and angle.

I'm guessing this is where the problem occurs... but wait... I never set that again, but as I said, if the code runs through a second time then it sets everything correctly.

So... it seems the player's view being TOLD to be set to the view of the camera, but on first pass, the player's view (and position?) is not correctly updated to reflect that. The cam itself seems to be in the correct position when I check its edict info... Perhaps at the time the player is trying to jump to the cam, the cam's fields are un-readable for some reason... but then... why does it only kick in when I re-position the camera, without any further setting of the player's view... hmm.

This would require some code alteration for me to really test this, but I can't get to that for a couple hours, because I have to watch Supernatural now, heh.

But maybe some of this rambling will help you zero in on the issue with whatever change has been made. 
In FvF, upon exit, I draw a line out from the player and move the intermission point there, so it will point at the player while he dances.

Need some clarity here. Precise clarity.

1) Is this on your ProQuake server with Mark V as a client?
2) This is on your computer. No ProQuake involved.

The difference is crucial.

If this is running on your ProQuake server, Mark V isn't involved with any QuakeC calculations.

B) Are stuffcmds involved at all where it changes a player's settings? 
The second one -- No Proquake involved. This is what happens when running FvF on Mark V on my own computer. Though previous versions of Mark V didn't do this.

There should be no stuffcmds happening at that point -- they only occur when a level first loads or a client first connects. 
What happens if ProQuake is the server and Mark V is the client running this code?

This will tell you whether or not it is a client or server issue. I'm assuming it is a server issue so a Mark V client connected to ProQuake will not experience the issue.

But there are several differences between a Mark V server and a ProQuake one.

1) Mark V does not support QCCX at all. May cause unpredictable results. If you can compile with fteqcc or frikqcc 2.7, you are fine.
2) Mark V's QuakeC interpreter is for all practical purposes using Quakespasm's QuakeC interpreter. It may generate NaN results (not a number) when GLQuake/WinQuake/ProQuake will not.

This is a highly technical issue that MH and Spike and the 2 original Quakespasm authors talked about --- I didn't fully grasp the conversation at the time. (But I knew far less back then).

Since you say you are getting 0,0,0 I wonder if you are dividing by zero or getting a NaN result.

Maybe write code to check if the result should be 0 and then try to trap an example.

If you have found a bug in the "Quakespasm Virtual Machine" can trap an example, I think all the engine guys would be grateful.

Because it probably means that bug will get fixed. Nehahra spits out "NaN developer errors" in Mark V with developer 1. 
Short Version: 
Write something like this:

oldxyz = xyz

(your calculation)

if (newvalue.x == 0 && newvalue.y == 0 && newvalue.z == 0)
... print all the factors of your calculation

Then post it here! 
Ok, ran proquake dedicated server on my computer, then ran Mark V on same computer to connect to it.

"connect lan" did not work; no servers found.
"connect 192.168.254.blah" did work.

Intermission camera functions as expected.

My compiler is frikqcc 2.6
I don't know what QCCX is, heh.

This issue doesn't occur in the previous version of Mark V which I was using from

The thing is, I'm not actually getting '0 0 0' when I check the edict info (everything looks correct there), but the view seems to be stuck at '0 0 0' in the world, like it was not correctly set. But then if the code runs to change the origin of the camera, then the view becomes correct with the camera without me issuing any additional command to set the player view to the camera. It seems like just changing the camera origin makes the view lock back on....

Hm, it seems that my special victory intermission cam that has a velocity also works -- the camera moving seems to cause the view to lock onto it. 
First | Previous | Next | Last
This thread has been closed by a moderator.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.