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. 

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. 

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 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. 

More testing will have to wait till tomorrow. 

Connect lan will find other Mark V or Quakespasm Spiked servers. If I recall correctly, original Quake's TCP/IP broadcasting was broke -- only IPX -- and old networking protocol from the 1980s -- worked.

Spike fixed this in Quakespasm Spiked so that servers do broadcast correctly. 

When entering the level stats screen, Mark V displays the "Current Music Track" message on top of the screen. This should be hidden (like when entering a new level). 

Version updated: http://quakeone.com/markv

@nightfright ... updated Mark V to only print those if developer 1. Same with external .vis files, missing impulse 12 message and lack of fish fix message.
----------

@gunter - Here's a challenge for you.

Test your problem in these 2 engines, be sure to test it exactly the same ...

Quakespasm Spiked R4 -- http://triptohell.info/moodles/junk/quakespasm-spike-r4.zip (do +sv_protocol 666- +map [map you test on] )
Quakespasm Regular -- (you already got this)

If your problem only appears in Quakespasm Spiked R4, Mark V and not Regular Quakespasm it will tell me that Spike's ever so slight change to the network message read only is involved in your problem.

Mark V acquired this from Quakespasm Spiked R4, but I can't see it making a difference really but maybe in highly specialized cases in can. 

Useful stuff:

External .vis files for id1 maps, makes maps have transparent water data without vispatching:

http://quakeone.com/markv/visfiles_go_in_folder_quake_id1_maps.zip

Correct fmod.dll for Nehahra:

http://quakeone.com/markv/nehahra_fmod_go_in_folder_quake_nehahra.zip

To run Nehahra it is game nehahra -nehahra 

The problem does not occur in Quakespasm or Quakespasm Spiked.

Tested several times in each engine -- I just load the Start map and take the e1m1 exit (but it affects any exit).

It happens consistently in the recent Mark V.

I'm gonna go do some code testing and see if I can narrow it down to the specific code that's causing the issue.... 

Music message fix for level stats screen confirmed.

I am already using pak files with .vis/.lit files for Quake and all mission packs for a while. If any of you want to use them, here they are:

VIS/LIT files for ID1/Hipnotic/Rogue (.zip, 22.2 MB)

Basically just unzip this into your Quake installation dir. Make sure you don't have other custom pak files there which may get overwritten (ID1: pak2.pak, HIPNOTIC/ROGUE: pak1.pak). 

frogbot mod, im trying to change the map, i'm typing map dm4, the game just says something like this "unknown command" "1" unknown command "8"

and i have to type admin 1 0 , all over again, to play the bots, NQ bots,(your version, modified by you and then modified by me) 

@nightfright ... awesome! .. mirrored as ...

http://quakeone.com/markv/vis_lits_id1_hipnotic_rogue_pak_files.zip

@spy -- Hmmm. What's up with that? Investigating ... 

For the moment, use "changelevel dm3" instead of "map dm3"

And you shouldn't encounter issues.

Frogbots is clever and deals from both sides of the deck to save information even beyond "disconnect".

Mark V will flush away server aliases on disconnect, but frogbots went to a lot of trouble to store info across disconnect and then restore it for the player's convenience.

I'm planning a way to address this. 

Update http://quakeone.com/markv

1) frogbots issue resolved (spy)

(Type: "find frogbot" if you actually care about the setting that controls that. Me neither ..)

2) gunter e1m2 "toggle external_textures" issue resolved. That map has a missing texture, it was causing a problem.

3) hdfolder now only prints a folder not found if the user is actively setting it. By design a missing folder is allowed, it is just ignored .. made it do a better job of ignoring it.

4) Made a couple more things into develop prints because the user doesn't really need bothered with them.

Should be the end of the queue. Except if the FVF mod problem Gunter is having turns up something. 

question about the hdfolder ... where does it fit in the priority order for loading content? 

Great question. It's simple, but effective.

We read from it (first), but we never write to it, nor does it ever become gamedir.

Example: hdfolder "hdmymodels,hdtexture_set2"

1) READ (.pak files ignored in hdfolder)

The path will be:
hd\\mymodels (first priority)
hd\\texture_set2
id1\\pak1.pak
id1\\pak0.pak
id1

2) WRITE - hdfolder does not become com_gamedir

- Has no impact on saves, demos, screenshots or server operations.

com_gamedir stays id1, travail, warpspawm -quoth. hdfolder has no effect on that.