No extensions and still pure Quake at the moment.

At a future unknown time, I anticipate making another run at acquiring more Spiked Quakespasm's features. 

also, STAT_ACTIVEWEAPON is sent as a byte in vanilla quake, and is thus normally limited to 9 different values, only 8 of which might be present in vanilla.
but that doesn't mean that they might be set on the server anyway, or that you'll never have more than one bit set.
hacking it to support more weapons is one of the first things that many mods need to achieve. you're better off using STAT_WEAPON.
unless you're making a new addition for ezquake anyway. other engines should avoid those hacks like the plague, but its too late for poor ezquake. 

2nd reason I implemented the per weapon crosshair system instead.

I very well know some people will end up making per model crosshairs for certain mods because now it requires zero QuakeC support.

You could just make a crosshair for the Drake crossbow in Something Wicked and name it appropriately and do it in 30 seconds or so. 

STAT_WEAPON

Hmmm ... looked. I can't do that.

It's a model index. cl.model_precache[cl.stats[STAT_WEAPON]]

A gun model index might be 23 or 47 depending on the precache order, as I understand it. I mean "player.mdl" and "eyes.mdl" --- if I recall are guaranteed to be the first 2 precaches (if I recall correctly, which is no sure thing).

So 1 and 2 sure can't be weapons, if I am correct above. 

(Haha ... I wish I could unpost that after re-reading ... sigh) 

(Now I wish I could unpost my wish to unpost, because I think I'm correct on 2nd re-read). 

Enough that I can do mirrors (stencil plus depth splitting trick - split range into 0 to 0.5, 0.5 to 1) ..

Stencil is done.

I suspect that depth-splitting problems are due to differences in how GL and D3D handle the depth range state. In D3D depth range and the viewport are part of the same state. In GL they're separate states. The current wrapper code just assumes a depth range of 0 to 1 when setting the viewport, so therefore viewport will overwrite depth range.

Fixing that needs some rearchitecting of the wrapper, which I intend doing anyway, so this is just an advance heads-up. 

Stencil is done.

Very nice!

Fifth: Mark V already split screen

@mh ... fifth is in, in fact, correct ... haha.

video

I literally only need multiple controller support. I'm just pointing that out for clarity. Not trying to get you to change your mind or anything. Just wrapping up unfinished loose end from yesterday. 

Fixing that needs some rearchitecting of the wrapper, which I intend doing anyway, so this is just an advance heads-up.

Ah ... I see. No wonder I couldn't get it to work. 

Had controller support recently added, I'm wondering if it can be adapted into this? 

http://quakeone.com/markv/older/1016_mark_v_temp_build.zip

Pulsar ....

1) Can you download this build ...

2) Alter your map in the following manner
a) func_illusionary with 6 mirror sides must go. Make 1 sided.

Here is why

It looks like all 3 of your mirrors are on the same plane. Which is fine.

But the 6-sided mirror is messing things up.

By definition, an func_illusionary doesn't block visibility. That means the six-sider is interfering with itself.

Truth be told, your map the mirrors can see each other because vis is not actually blocking them from seeing each other, but because they appear to be on the same plane that would be fine.

Mark V has r_lockpvs which if you stand somewhere and type r_lockpvs (invented by MH) you can walk around and see what walls are visibile.

Anyway, give it a try. Let me know if it works with build 1016.

/And if you could, after making those changes could you re-upload the map so I can test some more. Your test map was very useful to me including for some hidden reasons.

Extra note: really in order to run a map with multiple mirrors, a map must be vised. Yours was. And they were all on the same plane so it actually wouldn't matter. But a vised map can have mirrors not on the same plane provided they cannot see each other. 

a) func_illusionary with 6 mirror sides must go. Make 1 sided.
That's absolulely fine, the mirror in the actual map is 1 sided. 6 mirror sides were for test map only.

Let me know if I get you right: I need to correct the test map so that each mirror is visblocked from another one. Do I need to move mirror so that they are not on the same plane?

I'll download this build and make another version of the test map when I get home (in about 3 hours). 

Looks like the splash to explosion thing is MOSTLY fixed -- it still occurs at one point in splash.dem (2:44). And the blue splashes still seem to die almost instantly instead of moving outward.

I'm not using TE_GUNSHOT, just a straight drawing of several blue particles like:

particle(origin, direction, 32, intensity);

32 is the color (light blue), and I do this several times simultaneously to send particles out in different directions.



Giving each weapon number a different crosshair doesn't sound good to me. Of course, in FvF there are different classes, so each class would need a different crosshair, not each weapon -- a cyborg gun #5 is completely different than a mage gun #5. If I were assigning different crosshairs for each class and potentially for different guns within each class, I would need the stuffcmd method for precise control of what crosshair gets used.

Didn't you say there were already mods that do this via stuffcmd? Are there any mods that do it the way you are proposing? 

Pulsar, just make the middle mirror -- the one with 6 sides --- into a 1-sided mirror. Only that.

That should be all that is required. 

I've just found that can get home late today, so I can't say when it will be. But definitely tonight. 

weapon crosshairs

Yeah, that feature is targeted towards mappers and players. Kind of misses your situation as a QuakeC mod creator/server operator, I know. In proper world, a QuakeC extension would be the right tool for your needs like what no doubt DarkPlaces and FTE can do via QuakeC extensions to control crosshair on client directly.

splash to explosion thing is mostly fixed

It'll have to do for a while. I said I was going to stick with JoeQuake behavior (even if undesirable), but ended up largely discarding that to make an effort to try to fix about every issue you documented. On the plus side, skipping trails should be history, maybe in all cases. And you do at least have the option of turning off the "QuakeC particles" replacement.

And you unearthed some great short-comings on the JoeQuake QMB implementation, and precious few remain.

I did some testing on fvf yesterday and foq was there. With the QMB lightning sparks, some of the game play was pretty unreal.

You argue hard, but you sure do bug test hard. ;-) 

Just make sure you upload the changed map regardless of result. ;-) 

Quakespasm: Had controller support recently added, I'm wondering if it can be adapted into this?

Mark V does everything natively on both Windows and the Mac. The kind of things you need system access to do.

SDL2 is a wrapper, its goal is not providing system access. So a number of the nice things Mark V can do, especially on Windows but some on the Mac too, it wouldn't be able to do.

Case in point, add -resizable to your command line and you can resize the Mark V window like any other Windows application. SDL2 would not like that. I could name several other examples, but they are all very boring.

Mark V needs low level access to many things.

SDL2 makes everything easy, but puts lots of limits in your face. I'm not really a "limits" kind of guy.

/I hope that explanation helps. 

r_lockpvs (invented by MH)

Invented by Quake 2 :) 

Download at usual location:

http://quakeone.com/markv

New ...

- Sparks? Lightning? QMB option greatly enhanced! Video
- Mac version improved, both Open GL | WinQuake (johhny law)
- Several QMB enhancements (gunter)
- Installer enhancements handles more packaging types (Pritchard)
- Per weapon external crosshair support (c0burn)
- Several improvements to DX8 version (gunter)
- Theoretical func_illusionary mirrors (pulsar)
- Mark V page links good codecs, not link to bloatware. (Bloughsburgh)

Improvements to Nehahra support and many other small polishing/ hardening modifications.

Possible final build for 2016. If no issues, this release is promoted to Mark V - Version 1.1 Final.

(*) Awaiting on pulsar's map testing results for mirrors.

MH is working on creating a heavily updated Direct X 9 version wrapper for the engine.

If you have ever seen MH's DirectQ engine -- 5,000 frames per second on 2012 era hardware -- and is still listed on Quaddicted as Spirit's recommended engine of choice for Windows ... 

Didn't forget about you --- I sort of underestimated difficulty of rolling up what I was hoping to do (didn't realize how much video code I would have to combine, hadn't looked at it lately). And also had more last minute issues to resolve than I anticipated. I'm very sorry, I was hoping for this version. 

Translucent windows don't work in Jump. Is this normal?

Also, I noticed that the Winquake version complains about gl_texturemode (it's in my autoexec) in the console. It ignores other GL-specific commands, even though it doesn't recognize them when they're being entered. 

Is that the alpha sorting issue NewHouse was talking about that affects Mark V and Quakespasm in general abuse?

It's like a 30 minute fix, but I decided to procrastinate -- because far too many things are a 30 minute fix and I've pretty burnt out and have been for a week or so.

Mark V WinQuake recognizes all the console variables that Mark V Open GL recognizes -- but in Mark V is gl_texturemode is a command just like FitzQuake 0.85, so that's why that message happens. I'll consider making that silent for the future. 

Is that the alpha sorting issue NewHouse was talking about that affects Mark V and Quakespasm in general abuse?

Not sure, can't find that discussion. The windows are translucent in QS, but they're opaque in Mark V. 

Are the windows tranlucent (partially transparent) or masked textures (totally see through)?

Mark V does not support masked textures on world model, if the 2nd case. It breaks vis and several other things including (sv_cullentities).

And if it is the 2nd thing, it won't get changed. Spike and other top-tier experts know why it is improper, and I'm ok with things that are broken by improper design not working right in this engine.

I'm don't do race to the bottom. I understand that some map authors target broken engines, I'm fine with those things being broken in Mark V.

There are 1500 single player releases.