|
Posted by Baker on 2016/11/19 04:53:11 |
http://quakeone.com/markv/
* Nehahra support -- better and deeper link
* Mirror support, "mirror_" textures. video
* Quaddicted install via console (i.e. "install travail")
* Full external texture support DP naming convention
* Enhanced dev tools texturepointer video inspector video
* IPv6 support, enhanced server capabilities
* Enhance co-operative play (excels at this!)
* Software renderer version (WinQuake)
* "Find" information command (ex. type "find sky")
Thanks to the beta testers! NightFright, fifth, spy, gunter, pulsar, johnny law, dwere, qmaster, mfx, icaro, kinn, adib, onetruepurple, railmccoy
And thanks to the other developers who actively provided advice or assistance: Spike (!), mh, ericw, metlslime and the sw guys: mankrip and qbism.
/Mac version is not current yet ...; Linux will happen sometime in 2017 |
|
|
#1667 posted by Joel B on 2017/08/23 15:47:23
What command line are you using to launch it?
#1668 posted by Baker on 2017/08/25 09:28:29
Using -hipnotic the command line? Yes/No?
Probably your problem. Let me know.
@gunter - ok, r_shadows 3 option. Maybe a week later after his post I realized that was likely the issue he was experiencing.
#1669 posted by Baker on 2017/08/25 09:29:30
I meant -rogue, not -hipnotic.
:(
No More Vsync In Mark V WinQuake?
#1670 posted by jayoo on 2017/08/26 16:26:14
WinQuake runs with constant stutter but I couldn't find any way to turn on vsync. Can anyone help?
#1671 posted by Baker on 2017/08/26 21:15:52
I don't know of any WinQuake that ever vsync since that is a Open GL feature.
That being said, if you really want a WinQuake with vsync ... here is a slightly older beta with vid_vsync 0|1 capability:
http://quakeone.com/markv/builds/1025_mark_v_beta.zip
It is the WinQuake-GL.exe in that .zip that has vid_vsync because it renders the buffer to an texture and then draws it on the screen through Open GL.
#1672 posted by jayoo on 2017/08/27 09:53:05
Thanks Baker, I found that build last night and it's fantastic for playing Quake as authentically as possible.
Is there a reason why this .exe is no longer included or being worked on? It's really the best of both the GL and software modes, since it has no graphic glitches and z-fighting like the GL version, while retaining it's best features such as UI scaling and vsync.
It just makes no sense to me at all.
#1673 posted by Baker on 2017/08/27 10:32:16
The regular WinQuake can hit higher frames per second, doesn't matter much for small resolutions but if someone decides to max out in a very large resolution there is a gap.
It is actually maintained because the Linux and Mac versions of Mark V WinQuake are WinQuake-GL builds, I just don't put a Windows one in the Windows .zip because it would confuse most people.
#1674 posted by jayoo on 2017/08/27 13:42:07
Are you planning to put WinQuake_GL.exe's in future builds?
#1675 posted by Baker on 2017/08/27 14:03:58
I could make it available somewhere on the page in the future when new releases happen.
#1676 posted by jayoo on 2017/08/27 14:48:16
Also, there have been two longstanding bugs to do with monster spawns that have been around since the original WinQuake - one in e3m3 where the fiend spawns midway in the air in the circular lava room when the final bridge activates and another in e4m7 where the zombies spawn after killing all the underwater zombies in the first circular room. In both cases the monsters are stuck in the air after spawning when they should fall to the ground/water and start attacking. Could you look into fixing these issues?
@jayoo
#1677 posted by mh on 2017/08/27 18:35:51
Are you sure that these are engine and not QC bugs? My recollection is that they happen in all engines, not just WinQuake. If QC bugs it would be inappropriate to modify this behaviour in the engine.
#1678 posted by jayoo on 2017/08/27 18:57:09
There's definitely source ports out there that fix these issues, but I admit that most I've seen don't.
Why would it be inappropriate to modify this behaviour in the engine? They are gameplay bugs after all so shouldn't they be fixed?
Compaibility
#1679 posted by Preach on 2017/08/27 21:38:52
If the bug is due to bad QC code or mapping errors, then changing the behaviour of the engine to work around the bug does carry a risk: some mods may be using this behaviour of the engine intentionally to create a desirable effect. The fix for the bug in vanilla will break those mods in your engine. Which isn't to say that it's never the right choice to make those kinds of change, but you have to be thinking about the potential cost as well.
@jayoo
#1680 posted by Baker on 2017/08/27 22:03:50
QuakeC is game logic in a progs.dat, found in Quake pak0.pak. It exists outside the engine and is the game logic program. It can be compiled with a QuakeC compiler like fteqcc.
Some people (like preach) are really into QuakeC, he is the main author of Quoth and was involved in Arcane Dimensions.
Concise version: QuakeC behavior isn't related to the engine.
#1676
#1681 posted by mankrip on 2017/08/27 23:18:22
Quake Info Pool - Currently not researched Quake bugs
"Right in the beginning on E4M7 some Zombies start spawning after you kill the ones in the water. If you stay under water as you kill them, the new ones will spawn above you, and fall down into the water. However, if you kill the ones already there under water, and get back up on the ground level, the Zombies will spawn in the ceiling, and just hang there."
Reported by Alexander "Prodigy" Møller
Demo is available for download (e4m7zombie.zip)
QIP lives!
#1682 posted by mankrip on 2017/08/27 23:20:59
I bet it's a bug in the map itself. Some trigger misfiring or something.
@mankrip
#1683 posted by Baker on 2017/08/28 00:15:23
#1684 posted by Gunter on 2017/08/29 01:41:25
The zombies' teleport entry points in e4m7 are just too close to the ceiling.
But if you have an online server with a sys_ticrate of 0.1 then they fall just fine, because the server doesn't check their position fast enough to know they are stuck before they fall far enough to not be stuck. sys_ticrate .05 or faster and they get hung up.
It can be fixed directly in the map or with QuakeC by altering the locations of the teleport points.
#1685 posted by Baker on 2017/08/29 04:05:29
Sounds like a mapper or advanced user could make an external .ent file if that is what is going on.
#1686 posted by Gunter on 2017/08/29 06:42:38
Hey, *I* am an advanced user!!
Uh, is tool_inspector broken? it seems broken (in both GL and DX 8, 9). I had to go back to version 1.27 to make it work again. It did not work for me in 1.28
Ok, here is what the zombie problem is, I believe:
In triggers.qc, info_teleport_destination function raises ALL teleport destinations by 27 units upward. I think this is to get them off the ground a bit, to make sure monsters don't get stuck in the floor, hah. Well, the problem is that it causes the zombie teleport destinations in e4m7 to move too close to the ceiling. Though oddly, it's not completely consistent that the zombies get stuck. Sometimes they seem to fall just fine in single player, other times they may get stuck.... Maybe it has something to do with whether they are moving or seeking a target or something when they teleport in. Or it could even have to do with the FPS you are getting in Quake....
Yeah, that might make sense -- if you are getting really high FPS, then Quake checks sooner to see where the zombies are, and determines they are partially in the ceiling. If you are getting a lower FPS, then the physics check doesn't happen quite as fast, so the zombies fall down a bit and free themselves. That may explain why the original Quake people didn't catch the problem; they weren't getting a really high FPS back in the 90s!
But that's just a guess on my part, knowing that Quake physics are dependent on your frame rate.
In any case, lowering the teleport destinations should fix the problem.
So load e4m7, then type in console: copy ents
Go paste those ents into a text file: \id1\maps\e4m7.ent
Go to line 883, 889, 895 and change the "origin" Z values from 136 to 100, just to be safe. Save the file. Problem solved.
...
The problem is solved!
We solved the problem...
So ev'rything is awesome!
Problem solved!
#1687 posted by Baker on 2017/08/29 06:57:02
Yes, you are certainly an advanced user, haha.
You might consider uploading that file to somewhere for jayoo.
If you do, I'll mirror a permanent copy of the file.
ericw may interested in it as well.
/Yeah, Pritchard pointed out I messed up the inspector.
#1688 posted by mh on 2017/08/29 12:08:38
As a quick double-check, playing it with a sufficiently low host_maxfps should be enough to confirm the theory
#1689 posted by jayoo on 2017/08/29 14:02:45
That sounds like a very plausible cause Gunter (though I am far from an advanced user!).
I'd really appreciate it if you could run me through the steps to fix this and the other instance of the bug I mentioned.
Thanks for looking into this everyone!
#1690 posted by Mugwump on 2017/08/29 14:14:39
I'd really appreciate it if you could run me through the steps to fix this
He did just that in post #1686...
Jayoo
#1691 posted by Baker on 2017/08/29 19:35:06
I'll give you some pointers since you are passionate about this stuff.
That being said, after this initial information I'll leave it to others to give you tips or answer any follow up questions you have --- mostly because I'm largely "engine-only" and this is more QuakeC (gunter/preach) and mapping territory.
In that Mark V 1.25 or up to 1.27 in the Open GL version ONLY, there is tool inspector.
Activate it by typing tool_inspector 1. Type "impulse 9" and switching weapons with change information. https://www.youtube.com/watch?v=_QplswG5umo
For the map you want to fix, like Gunter said, load the map and type "copy ents" in the console. Open a decent text editor like TextPad or NotePad++ and paste that text into the editor. Then save the file as c:\quake\id1\maps\e4m7.ent.
From the information for tool inspector (you may need to type like "edict 3" (where 3 is an entity edict number) in the console, you can find out enough information to locate the mapping entity information in the .ent file.
Doing anything with this information, it is very helpful if you are a mapper (what this site is all about) or QuakeC master (gunter is).
But what Gunter did was edit some spawn point coordinates.
A .ent file is an external entity file recognized by all modern engines (DarkPlaces, FTE, Quakespasm, Mark V, others), it overrides the maps information.
You might struggle with this at first if you aren't a mapper.
Happy hunting!
|
|
You must be logged in to post in this thread.
|
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.
|
|