Another of Chillo's models, the Shalrath, gives an error message when trying to load the model:

"Skin taller than 480"

Package with model (shalrath.mdl):
http://www.quaketastic.com/files/models/chillo.zip 

Ignore my last report. Just took a look at the Shalrath skin file, it's obviously a placeholder. It's just still about that ogre model, then. 

E4M6 crashes with the Authentic model improvements pack. This used to work with previous (OpenGL) builds of Mark V.

Download model pack:
http://www.quaketastic.com/files/models/auth_mdl163.zip

I could not identify which of the models is causing the problem. 

There are more maps that crash. I checked all maps of the original campaign and the model improvement pack does not work in these levels:

E1M5
E4M3
E4M4
E4M6 (as reported above) 

These maps likewise work fine in my original codebase.

It's obviously a model that's common to them all overflowing an internal buffer that's differently-sized in MarkV. 

I found the model that causes the problem. If you remove the Fiend model from the improvement pack (demon.mdl), the maps stop crashing.

This leaves two models to be investigated, demon.mdl from the existing improvement pack and ogre.mdl from Chillo's release. 

The only thing I can find as a possibility is mipmap generation for non-power-of-two textures.

In my original code I let D3D take over mipmap generation, whereas MarkV retains it's own mipmap generation.

These models have unusual texture sizes: odd numbers, not multiples of 4, etc. So when you go down a miplevel you need to be aware of whether you are going down exactly to half size, or if rounding down is involved, and depending on how the engine handles memory allocations for this, it may trigger a crash. 

Well, curiously the models won't work with Mark V 1.36, either. I just tried. However, they should since I remember playing through the entire game at least with the demon model since it is already in the improvements pack. 

I just tested various DX9 builds from previous Mark V releases. The last one that works with BOTH models without crashing is 1.27 rev. B:

http://quakeone.com/markv/builds/1027_mark_v_dx9_revision_b.zip

Starting at 1.28, the crashes start:

http://quakeone.com/markv/builds/1028_mark_v_beta_dx9_opengl_dx8.zip

Hopefully that narrows it down for Baker to find what's causing this. 

 

That is a high quality investigation, thanks for the detail that should make tracking this down easier.

I guess I'll do an OpenGL in the next one *only* for the purpose of trying to nail down what is going on with this.

I *do* want to know what the differences are and unwind this small mystery, but also I want to get some more new stuff out. I want to get new concepts off my hard drive and into reality.

Speaking of which. I expect a new version with something quite new in 24 hours. Maybe 36 to 48 hours because I had to kind of fork the codebase and need to "unfork" it to get the source code tidy.

This isn't the "big one". The "big one" is still a few days out. 

I thought you used your Surface Pro all the time. 

I am testing maps for dm4 Jam on Mark V 1.81 One of the maps uses a trigger_once to trigger a map hack using an info_null using W_FireLightning

The engine freezes and I have to Ctrl+Alt+Del to kill it. Here's the map and source. It's the large trigger once immediately after the info player start.

Map plays on most recent versions of DarkPlaces, FTE and Quakespasm 

These crashes with high-poly models occur in both DX and OpenGL builds starting at 1.28, doesn't matter which one you use.

This also explains why I remember the new Fiend model working - last time I launched Mark V was well before summer 2017. 

I rarely use it tbh, I may use it more since I get extra long lunches now and could map in them.
It has some issues with keeping charge and the keyboard isn’t great so this is why, plus I have a decent PC anyway 

I remember finding out that the skin loading code for either SPR sprites or MDL models in vanilla WinQuake has a bad pointer arithmetic. I really don't remember exactly where it is though, but its badly offset by a very small value, something like 4 bytes. I remember being surprised that it didn't cause any crashes. 

Dear Spike, gamers, programmers and Quake fans. Could any of you lend any knowledge about multiplayer capabilities for FitzQuake Mark V? Does one need to setup static ip, forward ports and establish DMZ for good old coop with a friend over the internet (local server)?
I found Mark V enging is very good and i love it. But Quake without coop is not complete. 

As far as I know you simply have one player start the game as a host and the other type in the IP address of the host in the join menu, same as usual. 192.168.whatever.whatever.

On Windows you can do Winkey, type run, hit enter, type ipconfig, hit enter then look for ipv4 address. 

You're assuming a LAN game tho. Cadaver747 sounds like probably he's talking about co-oping over the internet?

Baker would of course be the best guy to ask about Mark V's port usage. I'm pretty sure I recall that he's included some of the fixes done in a few modern NetQuake engines so that it only requires its single listen port (26000?) to be forwarded. 

for engines using a single server port, just reconfigure your router to forward that sepecific port (26000 for nq servers, 27500 for qw servers) to your machine, then eg google for 'ip' and give that to your friend to connect to (don't depend upon windows - it'll show you addresses that are only valid on your lan, which is not what you want).

for other engines, you'll need to set up dmz stuff crippling your router's nat+firewall stuff, as get your friend to do the same.

all quakeworld servers+fte+dp+qss+markv use a single port for connections. the rest all suck big hairy donkey balls (including quakespasm) at least for internet coop.
this is not the only reason that most people favour quakeworld for online play, prediction is another significant factor...

sidenote: with the exception of non-fte quakeworld, the above engines all also support ipv6. assuming your isp isn't dragging their heals and generally being lame then ipv6 makes things cleaner by removing the need for NATs. You'll still be firewalled by any good router though.

lazy people: if your router follows certain ICE-friendly rules (eg most home routers but few business ones), you may find that just setting sv_public 1 on your server is enough (the heartbeats should automatically open your firewall/nat).
the other person can then use their client's menus to find your server according to its hostname cvar - if they can spot it. This should be true of FTE+DP+QSS, but I don't think markv supports any real master server protocol so good luck with that.
probably the server listed by the master will appear to use a different ip+port, that's just the nature of NATs, but means they can't use a direct connect command.
But again, this depends on the server's router, so it might not work. Setting up explicit port forwarding on your router should fix it for any other routers.

do not use 192.168.x.x over the internet. it will not work. 169.254.x.x won't leave your lan. 10.x.x.x is another unroutable one, 127.x.x.x is also not going to work, 172.16.x.x/12 isn't going to go far either , and 100.64.x.x/10 means you're fucked and need to get a new ISP (carrier-grade NAT - this would only be between you and your isp, so you're likely to be screwed without otherwise noticing it) - ipv6 is your only real choice when it comes to CGNAT, or just get the other person to host. 

Thank you Spike! I tested Mark V 1.36 and 1.60 (beta) for coop with my friend over the internet today. It works like a charm, just a simple port forwarding from my external ip 77.50.xx.xxx to internal 192.168.x.xxx (for port 26000) and that's it!
You wouldn't believe what i tried to do to play Quakespasm online. Mark V rules!

Too bad not all maps from Arcane Dimensions currently supported by it. But i'm sure that'll be fixed in time. 

Cadaver747, you and your friend could also try connecting to FvF, which is almost always in co-op mode. Then you don't have to mess with running your own server (though it sounds like Mark V made that easy for you anyway). Other people might connect to FvF and join you as well. It's... different than standard Quake, with lots of cool options and enhancements.

connect fvf.servequake.com

www.fvfonline.com 

Correction, only 1 map doesn't work, it's ad_sepulcher (The Forgotten Sepulcher).
Host_Error: ModLoadLeafs: 74168 leafs exceeds limit of 65535 

Thank you Gunter, but unfortunately your server is not meant to connect from my country (Russia), ping is almost 150. The idea of implementing RPG elements in Quake is quite interesting though. 

ad_sepulcher needs a bit more than just the standard "big map" support.

It's also the case that there are a handful of big static arrays scattered about the engine for which, by the time you move to supporting ad_sepulcher sized maps, you really need to move to dynamic allocation.

Finally, ad_sepulcher is going to run like shit in the GL version of MarkV because it still uses glBegin/glEnd code. It will run fine, but still far more poorly than it should, in the D3D9 version because it's transferring a lot of vertexes that don't even change to the GPU each frame. The particle system may however kill it with draw call counts; IIRC there's some very sub-optimal state change stuff hanging over from the original GLQuake still in the sprite code, and that's going to prevent the D3D wrapper from being able to batch things up.