 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
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! 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. As a quick double-check, playing it with a sufficiently low host_maxfps should be enough to confirm the theory
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! I'd really appreciate it if you could run me through the steps to fix this
He did just that in post #1686... 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 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 You might struggle with this at first if you aren't a mapper. Happy hunting! Yep, setting host_maxfps 16 or slower does indeed make them fall down, even if they are currently stuck.
But even host_maxfps 20 is making them stick.... Ah... that's why they were falling last night on me -- I had tool_inspector enabled, and that was killing my FPS, haha. And as I have pointed out, sys_ticrate of But in the end, it's a bad interaction between QuakeC and the map itself. The instructions I gave should be pretty simple to follow to fix it with an Though it would probably be better if someone really wanted to test to see EXACTLY how far the zombies need to be moved down to still fall correctly. Don't look at me; I don't care that much. I run my server with Guhhh... who am I kidding? Now that I said it, I can't not do it... heh. Oh, well, it looks like they only need lowered by 3 units to work correctly (from 136 to 133). Do I really need to upload the I thought only the spiked version did. Thanks for the info, Baker.
I managed to fix the issues. Still need to trial and error the E3M3 fiend spawn position but the zombies in E4M7 were an easy fix. Thanks again!
OK, after much messing around with an
Maybe I'm missing something obvious so any help would be appreciated. Perhaps I should try reading instructions more carefully in future...
I used tool inspector to find the offending fiend's actual target_name and changed the teleport coordinates to fix the spawn. e3m3 Line 1244 "origin" "-832 416 140" heres the demo of two bots dueling each other on zed2 - the vondurs property
i'm using mark_v to record the demo, and my fov is something like 135/145 but when i try to replay the demo something's strange has happened to me, using mark_v 0/99 the latest ad_1/60 engine(quakespasm-admod) has been playing the demo ok Downloaded zed2.bsp map and played your fbots20.dem.
Changed fov several times ok, didn't experience any problems. I believe you, but I can't reproduce what you are experiencing but maybe something will come to mind eventually. take a look at these screenies
http://quaketastic.com/files/screen_shots/fov.rar yeah i can change the fov value, but the viewing perspective is a very weird in mark_v My initial guess works like this:
Mark V has angle smoothing, which is not obvious in single player. An online player can immediately tell. It looks like Frogbots use some sort of QuakeC evil to move the camera around (jerky style) that isn't compatible with camera smoothing. I didn't invent camera smoothing and in fact several engines have it, Quakespasm isn't one of the engines that have it. It is possible you found a special case no one noticed before. I get a consistent "Mark V has stopped working when trying to play a demo. Doesn't seem to matter what, but specifically now I am trying to play jam 9 demos.
Windows 10, 64-bit using latest MarkV release. Happens in any version (DX9, 8, markv.exe) Let me know what else I can provide! Ugh annoying when the solution comes to you moments after finally giving in to ask for assistance.
I attempted to switch to jam 9 using the game command in markv. But running a shortcut with the -quoth -jam9 is what worked. there's this Admer guy at QuakeOne having trouble running Mark V. I told him I'd drop you a line, so for troubleshooting purposes you might wanna check posts #55-58 here.
Also, a few posts above those, Dutch states that he's experiencing a notable performance drop with the latest DX9 exe. I look at issues posted in this thread by the individual having the issue. There is a link to this thread on the Mark V page.
Keeps everything organized. Dutch probably made some setting that harms his FPS. Like r_shadows 3
He should try a clean install. Same with the other guy who it won't run for -- completely new install in a new, clean Quake folder. Looks like an experimental map (an awesome looking one at that).
If that map gets released I'll see what is going on. It could be one of a million things (vis, a texture, a skybox, external textures, a lit file, entity error, parsing issue, a texture name, a setting in Mark V even.).
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |