 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
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 ]hdfolder 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 ]condump Scancode: 0 ascii 0 Current download: http://quakeone.com/markv
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! 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. 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: http://quakeone.com/markv 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. Be sure to try this screenshot:
type: install http://quake-1.com/files/maps/undergate.zip 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:
http://forums.insideqc.com/viewtopic.php?f=3&t=5492 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. ]install http://quake-1.com/files/maps/undergate.zip
Download complete Couldn't open zip C:\Documents and Settings\Aaron\My Documents\Games\Quake/id1/_library/undergate.zip 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\undergate.zip 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. +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. 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. Write something like this:
oldxyz = xyz (your calculation) if (newvalue.x == 0 && newvalue.y == 0 && newvalue.z == 0) 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 mark_v_20160915_windows.zip 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.
|
|
| This thread has been closed by a moderator. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |