Yeah, it's a great misfortune that you don't and probably never will have time to put a little more polish on this... :/

Maybe some other engine coder will decide to pick it up. I'm tempted to take up engine coding myself to see if I could fix some of these things, but I doubt I'd have the time for that either.

I tried Quakespasm but I just don't like it. It's just not right, somehow. Perhaps if they imported some of the Fitz V features, like the ability to disable custom textures. Additionally, I find the Quakespasm website to be nothing but annoying. Yeah, great, they chose to have an "artistic" presentation with vague, arcane-sounding words and messages, but that's just stupid and irritating when I'm trying to find solid information about the thing. It's even difficult to find any real documentation of the features (as far as like console variables, etc.) in the included readme files... and I don't feel motivated to bother with the effort of digging through all the changelogs in the file to try and figure it out.

Digressing a bit, I remember giving feedback and reports for modern proquake, but the farther that project went along, the farther and farther it got away from standard Quake in feel and function, and it was a major hassle to track down all the console variables I needed to reset back to the defaults in order to get the right Quake feel back, so I gave up on that and just stuck with Proquake 3.5 (the last version by the original author). Modern Proquake was just no longer the same game. Apparently that's what hard-core runequake players wanted (to disable all special effects and change the defaults in order to get any and every advantage in deathmatch)... however, I feel that was against the spirit of the original Proquake to fix things without making too many changes to the presentation. Also, after "string safety" stuff was added in to Proquake 3.39+, it broke the FvF vote menu.... So yeah, I just can't use modern Proquake. It made too many changes.


I always liked Fitzquake, but it was just lacking some features to push it to the top of the pile. With the great additional features added by Baker (NAT fix possibly being the biggest factor for online play), I just can't prefer anything else over Fitzquake Mark V.

Going "back to basics" with usability improvements and bug fixes (and optional graphics enhancements that can be toggled off easily), instead of just cramming in everything everyone wants (I cringe a little when people start asking for Darkplaces stuff to be added in to this) is why this little engine has received so much attention. It's refreshing to go back to how Quake was meant to feel, instead of getting a bloated engine full of too much eyecandy, changed defaults, and hyperactive tweaker features.

I've found ways to work around most of the bugs (hah, I hard-coded some Fitz-specific workarounds into the FvF mod!), and I even put up a Fitzquake configuration page on the FvF website to help people get it setup, heh.... So yeah, I'm goiing to stick with Fitz V and I'll keep recommending it to people who play FvF. It just looks and feels "right" and has all the right enhancements in the right places (well, almost -- it would benefit greatly from a few specific proquake features).


Anyway, you have my admiration, Baker, for taking this little engine which had so much unrealized potential, and unlocking some of that potential. Even if seeing some of the potential unlocked just leaves us wanting to see MORE of it unlocked, heh.



The rest of you, come play FvF using Fitzquake Mark V :P

www.fvfonline.com
fvf.servequake.com:26008 

is there a port for Macs? 

Mark V release 14. All reported bugs fixed (*) and thank you for the bug reports!

1) BSP2 support via Spike
2) MP3 playing on top of each other = fixed
3) White HUD bug for some video cards = fixed
4) jdhack/Requiem "automatic impulse 12" for non-supporting progs
5) jdhack/Requiem "automatic fish fix" (jdhack is brilliant!!)

6) scr_crosshairscale 0 draws a dot

There are about 20 other improvements, the details are in the readme.

Download:

http://quake-1.com/docs/utils/fitzquake_mark_v.zip

Read Me

(*) Except Gunter's bug reports relating to mods missing skins and skin with toggling external textures.

If you notice any bugs, please let me know ASAP!

This should be a very polished release because I had no time pressures! 

Nice update! 

yay, that's a nice surprise! the release notes look really delicious! bugfixes, bsp2 and even requiem features implemented, just wow.

looks like warpspasm works fine now, the skies/liquids and polyblend effects were messed up for me in previous release.

old version http://imgur.com/jvqZZAY
new version http://imgur.com/xLNOiT0

it's always nice to have more engine choices just in case something goes wrong with certain hw setup or map release... dynamic light performance fix and various improvements make mark v a strong contender for the best performance/mod compatibility ratio out there imo. 

Can't check right now, but does this also address the issues with over-limit maps and/or demo playback in such maps that were first discovered in Backsteingotik as well as the Custom Gamer video thereof? 

Does it adress the non standard texture resize issue? 

@negke

I wasn't aware of that, but I will fix. Am I correct to assume if I check the Backensteinogtik thread I'll find the description of the bug?

@Fifth

Quakespasm did a power of two texture patch.

http://sourceforge.net/p/quakespasm/patches/25/

I have no eye for this sort of thing, does it look like their patch solved this issue to you? 

There's some mention of it in the release thread, something about monsters becoming invincible under certain circumstances. sock would know in more detail.

This is the video in question. MarkV was used to playback a video for capturing, not sure which engine the demo was recorded on. IIRC, what happens is that some models are rendered black/unlit. 

xoxoxoxoxoxoxoxoxoxoxooxoxoxoxoxox 

That bug in the Daz video was fixed in the October 2013 update. The some models rendered black/unlit thing wouldn't have been the October 2013 update either.

However, should anyone spot anything like that, please record a demo and save a savegame.

At the moment, I have time to fix bugs.

Next week I have new 2 new mapping features I want to introduce into Mark V, but unless every known bug is smashed I won't be happy. 

should i expect ne_ruins pack not working with this engine? looks like it was mentioned previously mark v was going to run out of edicts on this map, and i got a crash at a certain point playing it. 

jdhack/Requiem "automatic fish fix"

Curious about how exactly this works. 

Ran out of edicts in smqe08d_lun, which is id1. 

was it during gameplay or just at spawn? 

It was the teleporting monsters after the GL teleporter. 

Checking the monster count before and after swimmonster_go is run. 

I never heard of r_skyalpha before. I thought it might be great for taking "outside the map" screenshots, but no such luck. I did finally figure out what it was for though. 

Curious about how exactly this works.

The engine sets a flag if the total monsters increases when a monster_fish spawnfunction is run. It then watches think functions on the first two frames after spawns, watching for any entities of class monster_fish running swimmonster_start_go. If it finds one, and the flag is set, then the engine reverses a second increase of the monster totals (should one occur). 

Will it cause problems if that's fixed in my id1 progs.dat? 

Just looks to see if when a single fish spawns if the count goes up by more than +1.

Both that and the auto-impulse 12 modification were really well crafted by jdhack in the implementation in Spirit's Requiem engine.

They can be turned off, type sv_ in the console and press TAB and the names are obvious. 

Depending on how you fixed it either:

a) it won't set the flag when the entities are loaded because you deleted the line from swimmonster_start

or

b) there will be no changes during swimmonster_start_go for the engine to reverse, because you deleted the line from that function.

Either way you are safe. You'd need some very strange progs, one which had a legitimate reason to increase the monster count by 1 after some monster_fish spawns while still increasing the count in the spawn function as well. Well, actually here's a potential scenario...


Suppose that you add a spawnflag which allows monsters to teleport in when triggered. Also suppose that depending on the spawnflag the code in your swimmonster_spawn function branches:

* with the spawnflag you increase the monster count immediately but skip swimmonster_start_go (since the teleport code will handle that setup later)

* without the spawnflag you wait for swimmonster_start_go to set the monster count.

I believe that a map with some fish that do and others that don't teleport would then score a false positive under this scheme, and miss the non-teleport fish off the monster count erroneously. 

Looking forward to the release. 

Spirit's Requiem engine

jdhack's Requiem engine! I was just a beta tester who decided to release it after he vanished. All I do is trying to promote it and get people.interested in fixing outstanding bugs. 

Suppose that you add a spawnflag which allows monsters to teleport in when triggered.

yeahhh, that's why I asked. :)

So I take it if all my monstercount incrementing is done in monster_fish() I'm safe? I moved all the increments out of walk/swim/flymonster/go to facilitate monsters doubling as spawners.