Another fine catch.

When I rewrote QMB particles, I missed something. Should be able to make the behavior proper. 

If you are using using TE_GUNSHOT as a particle effect in splash1.dem, QMB modifies that into an effect. 

Should be the final temp build

Build 1014 - Windows Open GL | DX8 | WinQuake

Addressed some issues mostly reported by gunter and a few small things I noticed, like drawing external crosshairs slightly wrong.

func_illusionary mirrors is not in the above build.

func_illusionary mirrors will be in next build now that I finally have closed out all bugs reported. Needed to have a clean and stable base before putting in the complex changes for func_illusionary mirrors. 

AFR setups will generally require gl_clear 1 in order to activate properly, while other setups won't really care too much.

why numbers for crosshairs, and not filenames? 

why numbers for crosshairs, and not filenames

I'm guessing you mean model names? Like gfx/crosshairs/v_axe.tga or soemthing to that effect?

Here is just my thoughts ...

cl.stats[STAT_ACTIVEWEAPON] == (1 << i)

cl.stats[STAT_ACTIVEWEAPON] is a bit flag with 24 possibilities (but not 32? Because QuakeC is floating point, can't do unsigned?).

I used what sbar.c knows about the weapon, which is the weapon number.

Never thought of the idea of using the model name, that being said isn't it true that QuakeC could set anything it wanted as the view model weapon (including none!!)?

So QuakeC itself does not know the concept of a view weapon model, as far as I know. Someone could write some QuakeC where a fully charged weapon uses different model? 

I meant for the crosshair cvar. 

Which just reminded me. There are 25 possibilities, not 24. Because 0 is typically the axe (weapon 1). Makes Quoth Plasma gun weapon #25 (24th bit possibility) and Quoth sword weapon #13.

/Add to the model name thing ... hipnotic or rogue uses same model for a few weapons doesn't it? Like lava nails gun is same as nail gun, but different skin? Another possible example of how might be more confusing to use weapon model name -- if that is what you meant ... and might not have been. 

qc can't change the viewmodel's skin. so they're different models if they have different skins.

the exception being .viewmodelforclient, but your engine doesn't support that... yet? 

Ok, Mark V ...

crosshair 0 (none)
crosshair 1 (Quake +)
crosshair 2 (dot)

That's it. I was briefly going to change to implement to number system like DarkPlaces.

Then I thought it about some more, and decided to tie it to the weapon number instead. Beats passing around "stuffcmd crosshair 1" -- I hate stuffcmd.

Mark V crosshair remains simple system .. crosshair 0, crosshair 1 (+), crosshair 2 (dot) are only possibilities.

But if a mod contains any weapon crosshairs (scanned on gamedir initialize), it will display the weapon crosshair unless user sets scr_weapon_crosshair 0 to override. 

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. ;-)