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. 

That's safe. The engine only intervenes if you increase the monster count both during and after spawns, and only intervenes incorrectly if you only do so once per fish but are inconsistent about when you do so. The spawnflag idea was the closest to a sensible reason I could invent why it might vary from fish. 

Non power of 2 is broken in quakespasm also.

Hammer of Thyrion for Hexen 2 has a cvar for this -

https://www.dropbox.com/s/9hwef9vd513qteq/npot0.jpg
(without NPOT)

https://www.dropbox.com/s/7iy61i3rlsynpc9/npot1.jpg
(with NPOT) 

thanks for this, only engine that Map Jam 1 doesnt lag for me. 

Looks like the quakespasm patch is supposed to fix the problem. But I can't find a download link for the .exe or a way to figure out how to patch the game. The CVAR is the same as the hammer of thyrion one though. 

Thanks for trying the engine! I'm glad it was of use to you. 

I'll throw that into Mark V and upload it in less than 2 hours.

Then you can look and see what you think. You seem to know what you are seeing as a problem. 

Demo playback improvements, documentation on how to turn AVI into demos via the command line, a couple of tool_texturepointer fixes.

A non-power of two patch snagged from Quakespasm's site to see if it addresses what FifthElephant points out about texture appearance.

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

README

The supports "no power of two" texture sizes can be disabled via the command line using -no_npot

(*) Not that there is any reason on Earth to even want to disable non-power of two, but fifthelephant needs to be able to do to see if the sizing issue he sees is resolved. 

that fixed it! 

Glad the NPOT patch was useful for MarkV, Baker.

Afaik There's no build available for QS with the NPOT fix yet. I want to set up a nightly build server for QS at some point so it's easier to get development builds. 

That was a timely patch, thanks! And now you know that it seems to work.

And now FifthElephant is happy. 

I'm a simple man with simple needs. 

allow ctrl+v of server/ip addresses into the menu for joining multiplayer games 

map sm169_ijed - sky and water textures won't load, although they work fine in quakespasm. that only affects the bsp2 version of the map, the regular bsp version (sm169_ijed2) performs fine in both mark v and quakespasm.

also, i hope the compatibility with ne_ruins and other potentially edict breaking maps (arwop with its icon of sin scenario?) will be improved...

great thanks to Baker for all the work however! 

"ctrl+v of server/ip addresses into the menu for joining multiplayer"

In console type "connect " and then paste IP address? 

Yay, nice work, Baker.

I don't have tons of time to really give this a proper workout, but I'm checking out some of the things I previously reported, and I found some issues are still there. Search the "quoted" phrases to find my previous (more-detailed) reports on this page.

"windowed resolutions" -- text chopped off at the top in certain resolutions, like windowed 800 x 600

"mp3 soundtrack" "delay" -- describes the problem of how if you don't have a CD drive (physical or virtual) the MP3 tracks will not play, but there is no way to stop them from trying to load, because with no CD drive, Quake won't respond to "cd" commands like "cd off"

"what am I chasing?" -- whatever it is, I'm still chasing it....

"there is no bolt1" -- unless this is something from another mod? So it's un-needed in the noshadow list. Though I still think k_spike and lavaball should be in the list, since they glow and shouldn't cast shadows (looks really weird to me to see lavaballs casting shadows, when they are casting light...).

"always run" -- Not exactly a fitzquakeV issue (except defaulting it ON), since it's a standard Quake "feature" (read upthread about why it's bad).

"gamma goes lower than 0.5" and "gl_overbright_models" -- blindingly bright blends and models when at the lower gamma settings.

"cshift" -- well, the water color in Fitz is changed from the default.... Not sure, but Ring/Pent/Quad blends might also be changed from the defaults.

Of course, fog and skybox settings don't save across levels, but hey, skyalpha does save across levels, and it works right too!


And then just the "not bugs but pleeeeeease?" enhancements:


Proquake positioning for centerprints (higher on screen) so they don't block the view.

Proquake RCON protocol

And Gulliver really wants Proquake IP/Name logging thing. 

fog and skybox settings don't save across levels

oh god here we go 

on the coag3 pack. Check out ericw's map, for some reason I am getting a problem with the fact that the skybox of 16x16 is causing it. 

I'll see what's up with that. 

I'm wondering if this was an intentional change?

The relevant bit of the SCR_CalcRefdef source looks odd:

#define SCREEN_CORRECTION_ASPECT 1.33333f
// if (scr_fov_adapt.value)
// {
r_refdef.fov_y = CalcFovy (fov_base, r_refdef.vrect.height * SCREEN_CORRECTION_ASPECT, r_refdef.vrect.height);
r_refdef.fov_x = CalcFovy (r_refdef.fov_y, r_refdef.vrect.height, r_refdef.vrect.width);
// }
// else
// {
r_refdef.fov_x = scr_fov.value;
r_refdef.fov_y = CalcFovy (r_refdef.fov_x, r_refdef.vrect.width, r_refdef.vrect.height);
// }

With the current commenting, those last two lines will clobber the result of the previous two (which would account for the FOV no longer adapting to the aspect ratio). 

Revision 16 will be out soon and has wide-screen perfect and there won't be a need for a cvar.

The long version is technical, but I've always hated the widescreen correction. Short version: MH's version of widescreen correction if properly applied (really long conversation, involving status bars) --- is perfect.

But that conversation is so dreadfully boring ...

I would have release version 16 by now, except I've been combing over fine details and have a couple of more things to do ...