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. 

I wanted to say it's the former, but now that I looked more closely - it's more complex than that. Though I'm not sure if it changes anything.

A window is made of 2 layers:

1. A translucent texture without any "holes" in it. This is glass. There's some space behind it.

2. An additional masked texture in front of it - to make the frame look solid, apparently. It's also translucent for some reason, though it's not very noticeable.

http://i.imgur.com/zcSFt8A.png

Masked texture is see-through in Mark V, but both textures are opaque.

http://i.imgur.com/qTMSaG9.png 

It's all good! Don't overwork yourself on my account, I'm simply a beneficiary of your time and skill. In the meantime, I'm collecting various maps/episodes to replay when the new wquake drops... it just doesn't feel right playing in anything else :P 

Ok, I've been thinking about custom crosshair possibilities.

Having a different crosshair for each gun? Boring, inside-the-box thinking.

What would I do if you gave me the ability to use 24 custom crosshair images? I'd make an interactive crosshair that would act like radar and point in the direction of the nearest enemy. 24 images would be perfect for that: 8 directions x 3 height levels (low, medium, and high) to show you the direction and relative height of the enemy.

Yes, this would require the use of stuffcmds. There is nothing wrong with stuffcmds. Sure, they can be misused (but so can anything else in a mod). But in this case, it would be a fine way for the server to send information to the client to update their crosshair image to show the direction of the nearest enemy.

However, to maintain compatibility and not mess with people's crosshairs who aren't using Mark V, perhaps the custom crosshair stuff should be moved to a new console variable, like newcrosshair.

So you could actually have both the old crosshair AND a new crosshair image active at the same time. And I could be sending stuffcmd only for newcrosshair so that it wouldn't touch their standard crosshair value, if they didn't have my custom crosshair images.

To be extra sure about compatibility for other mods that might use stuffcmd to change custom crosshairs with the standard crosshair command, then "newcrosshair -1" would make newcrosshair use whatever setting is in crosshair.


So I guess whatever you're doing with crosshair could exist alongside what I want to do with crosshair.....

Though I'm not sure how many people will actually make use of the thing you're doing (different crosshair for each gun). But I'm completely certain I would do the thing I am thinking about, if you gave me the ability to select specific crosshair images by use of stuffcmd :D