I tried to compile this with CodeBlocks, but im getting TONS of error messages.. Is it possible to release a non broken source?? :/ 

I use Visual Studio on Windows. XCode on the Mac. Every once in a blue moon, I may check to see if the CodeBlocks compile works, but it is rarely up-to-date.

Linux isn't supported at this, if that is what you are trying to do. 

The WinQuake Debug, GL Debug, GL Release all compile fine with CodeBlocks 13.12 Full Install on Windows from freshly downloaded source.

Although I use Visual Studio and rarely update the CodeBlocks project, it isn't often that I make changes that would cause the CodeBlocks project file to break very much.

But the CodeBlocks project has unsupported builds in it too, like the Linux build. 

I fixed it myself, it was indeed caused by an older version of CodeBlocks... However, for some reason i cant assign my mousebuttons to a key..
Is it possible to add a simple MD3 loader?
I want to use a FitzQuake engine for my game (atm im using an older Mark5 version), but i dont want to use mdl. 

I tried to play warpb_sw4848 demo from quaketastic.com/?dir=files/demos (protocol 10002). It ends around 2 min 40 sec in with the message:

Host_Error: CL_ParseServerMessage: Illegible server message, previous was svc_clientdata

Not sure if it's a bug or expected behavior. 

I had issues with demos too, if you delete the demos (and keep the lines in the quake.rc) the engine hangs up.. Very unstable... 

I only added protocol 10002 to support the Warpspasm demos that come with the game and play when you start it.

But thanks for letting me know it doesn't work with user made demos, because I didn't know. 

@steve - It's unlikely that I would add md3, Mark V follows "the path of one". One format, one name, one place for all formats and types of files. md3 has no place that in that scheme, would be a 2nd model format.

Mark V also has a software renderer that can do almost everything the GL version, but it sure can't do md3. md3 isn't a Quake 1 format, but I can understand why you would want it from a make a game perspective.

You might try to convert the MD3 to mdl with the best and most awesome tool ever created .... http://richwhitehouse.com/index.php?content=inc_projects.php#prjmp91

Ultimately, Mark V is not made for total conversion purposes. But I do wish you luck with your project.

I'm glad you enjoy the engine.

/At the same time, please understand I am not an engine coding help forum. What you may not know is that I have had in the past literally dozens of people attempt to make me their personal coding help guy. I'm pretty good at saying no. ;-) 

That's what I suspected.
Ironically, the Warpspasm startup demos get overridden by the latest Quoth's startup demos anyway :D 

the Warpspasm startup demos get overridden by the latest Quoth's startup demos anyway

I know Preach didn't do that on purpose, but that's highly undesirable. I never did any testing with Quoth 2.2 back in 2014 when I added support for the Warpspasm start demos.

I like Warpspasm enough that I may cause it to load in original form so the start demos play. 

Thx for the reply, but i think i can add MD3 myself to the old base engine i use (its an older Mark5), i mostly want it for viewmodels only because i need the "details" active on it (iron sights etc..)...

I already managed to add a working sound dsp system (based on crowbars psp engine), which is awesome btw. 

https://youtu.be/UD7xKlV2yJY 

Wow, I'm not easily impressed but that is awesome. Do you have a link to the source for any engine with that modification?

Engoo has sound modifications, and I can't recall the name of the "open source Half-Life engine", but I'm sure it has sound modifications.

I think it would be awesome to somehow expose parts of a map, sound modifications. Quake .bsp doesn't support that. And at the moment, I can't recall exactly how Half-Life marked those areas ... probably a trigger.

I have not thought about sound for a while, but obviously since Mark V can do Half-Life .bsp (provided the textures are compiled into the .bsp) ... and .alpha entities and masked textures .. that I think of a more complete engine, although in the context mostly of what someone would do in a Quake map.

I think of mirrors, security camera, portals and such because they could add more complex and richer environments to, for instance, a base map.

Plus I have largely completed intermap travel-system which requires no QuakeC support (but offers QuakeC the opportunity to intervene).

/I couldn't say exactly when any of the above would happen because there are always so many items on a to-do list. One of the main challenges of moving an engine forward is that there are always choices and with limited time some things have trouble finding their way to the front of a queue. Case in point, splitscreen and Linux build may consume much time in future and integration of possible DirectX 9 version by MH or acquired Spike's optimized network compression. It's always of a sea of choices :( 

I can give you the sources if you want ;)
I plan to control the DSP with simple triggers and stuffcmd, it adds so much to the levels ;) 

Maybe there could be something like loc files for environmental sound effect locations. 

8x multitexture (which was easy, even for me)

I'm going to offer 4.

Here's the reason why: http://www.nvidia.com/object/General_FAQ.html#t6

Summary, for anyone who didn't follow the link, is that with fixed-pipeline OpenGL NVIDIA only offer 4 texture units. 

Yeah, I'd like to take a look at that source code. 

I can't think of a Quake scenario where anything more than 4 texture units would be necessary. I think even 3 may be enough to eliminate to the overbright pass as a separate pass in FitzQuake. 

is awesome... no idea how that could be implemented in quake maps... trigger volumes?

Unreal Engine used to allow "zones" to be created by sealing off entire rooms and areas, that was a good technique. 

If I were to add a modification to that certain areas of a map had special zone modifications zones like Half-Life (echo areas) I would probably be inclined to implement it in the following manner:

- A brush similar to func_illusionary indicates the sound region. Static entities are available to the client. A field of the entity indicates the sound modification.

- Although someone like Spike may correctly point that this to some degree does not follow the client/server model ... every modern engine already breaks the client/server model by indicating skybox and fog (and now several other keys like wateralpha and friends) in the worldspawn, which is client-side. The server has no opportunity to legitimately set those global values, and maybe for the best because those would have a delay of a split second.

I would mostly need to examine a way to make it backwards compatible to non-supporting engines.

This would also allow easy editing via external .ent files. And to possibly allow someone so inclined to take an existing map and add sound zones.

Also makes it so no complex new way of communicating sound zones to a client need be added to an engine and would be compatible with save games and everything else. 

The Engoo engine has some of sound modification capability. It's one of the software renderer engines like qbism super 8.

But yeah ... I'll do some thinking and figure out some way to support such a thing --- and in a way that is very friendly to mappers and easy.

/Isn't a soon thing but more likely a vague "probably some time in 2017" thing -- like security cameras security cameras concept video. So many items in the queue + limited time ... 

I can see 5 being used for diffuse+lightmap+fullbright+caustics+detailmaps maybe.
Or add 3 more if you split the lightmaps into their own textures.
Then add two extras if you want light directions and deluxemaps for bumpmapping.
And add 4 more if you want to ramp up specular to a decent exponent...

Although its kinda pointless to worry about it if the engine needs to retain a 4-tmu pathway anyway... or two... or one...
But yeah, more than 4 and you really should be using glsl/hlsl, trying to do everything with only an alpha channel for temp data is just unworkable. 

Yeah, eventually I do have something like a "surface effect texture" planned in my head for possible surface effects.

Might as well ask your thoughts on this question to you ...

Although not soon, I would like to use probably 4-8 QME 3.1 bit flag slots but and would like to avoid any possible with what FTE uses.

One example might be to indicate additive blending.

/I have not put much thought into this lately, but while discussion about future mapping enhancements ensues ... is fairly good time to bring up those thoughts. 

hexen2 defines modelflags up to and including 23.
1<<24 is the first undefined one as far as fte is concerned.
Not that fte implements all of the hexen2 ones, or that I'm even aware of any models that use them... but hey.

that said, for additive, you're probably better off sticking with EF_ADDITIVE=(1<<5). Yes, this can be used by mappers, and does not necessitate any wire change (read: protocol uses a previously-unused bit which permits backwards-compatibility on the assumption that old implementations can safely it).
maybe some of the other bits you're thinking of are similarly already implemented in another engine. 

if (!strcmp(gl_vendor, "Intel"))

I see that Mark V has inherited this from the original code too.

The D3D equivalent (which is read from the driver so I don'thave control over it) is actually "Intel(R) HD Graphics" so this test will incorrectly not identify it.

Strictly speaking this is also a bug in the GL case because Intel may change their vendor string.

Change it to:

if (strstr(gl_vendor, "Intel"))