 Mark V - Build 1007
#245 posted by Baker on 2016/11/26 05:20:21
Download at normal location:
http://quakeone.com/markv
2 bug-fixes related to QMB -- gib trails, colored explosions. (gunter)
#246 posted by Gunter on 2016/11/26 05:48:12
I could really use a setting to always draw the standard explosion sprite even if QMB explosions are enabled (several FvF weapons make use of the sprite)....
Heck, I might even like having both the normal explosion particles and the QMB explosion effect both enabled at the same time. That would make the explosions look intense!
qmb_explosions 2 ?
#247 posted by Baker on 2016/11/26 05:54:55
qmb_explosiontype 1 ... keeps the sprite.
 Rocket Light Color / Explosion Light Color
#248 posted by Baker on 2016/11/26 06:07:40
I noticed when adding in QMB, setting qmb_rocketlightcolor ... 0 = normal, 1 = red, 2 = blue, 3 = red + blue
qmb_explosionlightcolor works possibly identically.
#249 posted by Gunter on 2016/11/26 06:11:44
Hm, qmb_explosiontype 1 keeps the sprite, but gets rid of all particles in the explosion (no QMB particles, and no regular particles either).
And standard QMB_bubbles are invisible when I play online, but they are visible when I am playing my own local multiplayer game.
But, qmb_trail_spike produces the underwater bubble trail both online and not.
 @nightfright, Dwere ... Keyboard
#250 posted by Baker on 2016/11/26 06:14:35
@nightfright, dwere ... (or others)
re: keyboard
Do I need to do anything with in_keymap 0, or is in_keymap 1 fine for both of you?
Need input on this issue, since I am USA keyboard user and not super-familar with keymapping likes/dislikes/etc, other than listening to conversations in the past when I implemented a somewhat similar solution in a different engine.
#251 posted by Gunter on 2016/11/26 06:16:55
Oh, qmb_explosiontype 0 makes both the sprite and the QMB explosion particles. A setting of 4 does likewise.... Maybe 4 is not valid, and it's just going back to the "0" setting. But 5 hides the sprite again, hmm.
I'll keep testing and see if I can tell a difference in other settings.....
But 0 is just what I needed.
#252 posted by Baker on 2016/11/26 06:24:25
bubbles: invisible online, visible offline
Are maps vised? This is all client side. If your server isn't sending the sprites to you because the maps aren't water vised, you don't receive them.
By definition, since QMB is client-side .. there can be no behavioral difference, so it has to be what the server is sending you.
Bubbles are sprites, not particles ... subject to same "can you see them test" on server as a weapon, player, healthbox.
qmb_trail_spike produces the underwater bubble trail both online and not
The spike bubbles are a client-side manipulation where they are emitted as particles, but no real sprite ever existed.
However, subject to the same conditions as first case.
If the server doesn't send you the nail spike, no trail would be emitted.
It probably just seems different because you were underwater at the time?
#253 posted by Baker on 2016/11/26 06:30:42
re: Explosions ... Just remember, for the purposes of this version if it behaves exactly like JoeQuake is implemented correctly.
(Doesn't mean I won't consider it for a future version 2 --- I agree with what you say about the weirdness of sprite + QMB explosion sprite but no particles --- but testing JoeQuake it works that way too ... seems unusual, but by that metric, it is implemented correctly.)
#254 posted by Gunter on 2016/11/26 07:27:30
I don't know why, but it's definitely not showing the QMB bubbles when I'm connected to the FvF server -- the ninja actually throws out a row of bubble sprite bombs, so I can do this even out of the water. They are visible when locally running my own game, but invisible when connected to the FvF server. qmb_bubbles 0 makes them come back as the usual sprites (HQ replacements, actually).
Hm, there's something odd happening. I ran my own dedicated proquake server and connected to it with Mark V, and the QMB bubbles show up, but they move very choppily... like, uh, non-interpolated motion or something.
Ok, I reset the level on the FvF server and now the QMB bubbles show, but again, very choppy movement. The regular bubbles move smoothly....
Connected to a different (non-fvf) server and got same result.
Well, more testing will have to wait till tomorrow. If you wanna compare, connect fvf.servequake.com
I left it on e4m3 where there is a nailgun right in the start room. Just select ninja class and use that gun to throw out a row of bubble bombs, and see how different it is with qmb_bubbles on or off.
Or go jump in a water pool....
The nail trail bubbles move smoothly.
#255 posted by Baker on 2016/11/26 08:41:28
Record a demo of it (tell me the clock time I should look at). I'll play it back. I can't debug connected to a server, I stop execution to examine, I'd lose connection.
I have a working theory that goes like this: there may be something in the renderer that isn't being reset to base state.
Would seem to be a fit for what you describe, but isn't necessarily the case.
But if it is a renderer state issue, I may not be able to replicate it easily because it depends on a very large number of factors.
With a demo of where you say you have the issue, my first goal would be replication (which could be the hard part! Could depend on your settings, like even things like overbright or gl_fullbrights or what things you have turned on or off or what external textures, if any are loaded and what entities are on the screen).
/Whenever I end up doing a future incremental upgrade (like a 1.1 or what not), I would likely implement a state manager and this could never happen. I already have a different engine with a state manager (Engine X, which is a few years ago) and it unearths lots of scenarios where the states are not reset.
 In_keymap
#256 posted by NightFright on 2016/11/26 09:12:18
I haven't tested 1006 or 1007 yet, but in general, the only thing I noticed was the tilde key. I am playing Quake mostly with numpad keys (the block on the right keyboard side) which isn't affected by these changes.
Will try with the newer builds soon, but basically, the default behavior should always be the tilde key for console.
#257 posted by Gunter on 2016/11/26 16:31:45
Bubble demos:
http://fvfonline.com/bubbles.zip
The bubbles are weird.
I get the same result in JoeQuake.
They work fine and smooth locally, but when connected to a server (even a server running on the same computer), they are very choppy, or if the level has been running a long time, the bubbles just don't show up at all.
The effect is seen in the demos based on the settings you make while watching it.
 Bug
#258 posted by c0burn on 2016/11/26 17:19:38
Typing "pak help" in the console crashes the winquake engine for me.
#259 posted by Gunter on 2016/11/26 17:20:13
I thought maybe the difference might be that a proquake server would be protocol 15 and a local multiplayer game would be 666... But nope, that doesn't seem to make a difference.
Also, I tried running a dedicated Mark V server. DX or GL versions seem to start up and do stuff, but then the window instantly closes....
So I ran Mark_V_Winquake -dedicated, and the server window ran fine.
But then doing "connect local" or slist or find local multiplayer game in the menu does not work in my Mark V client.
connect [local ip address] works fine.
 @coburn, @gunter
#260 posted by Baker on 2016/11/26 19:38:39
@coburn -- there are a few interfaces for internal things that aren't meant for users (just for me for testing) that I need to make unavailable. You found one of them.
Mark V has the ability to read, write, edit pak files for future hub system for single player that want fully re-entrant maps (that requires no special QuakeC support!) -- so it needs to save the state of several maps.
Not meant to be available to the user.
@Gunter: connect local doesn't work
It's "connect lan" ;-)
#261 posted by Gunter on 2016/11/26 19:42:09
gl_overbright_models 0 makes my gun opaque instead of transparent when using r_viewmodel_ring 1
#262 posted by Gunter on 2016/11/26 19:45:40
"connect lan" doesn't work either.... "no lan quake servers found"
Connect 192.168.254.15 [lan ip on same computer] does work.
 @gunter - Part 2
#263 posted by Baker on 2016/11/26 19:47:02
Let me know if "connect lan works" on Windows XP. Mark V acquired Spiked Quakespasm's rewritten networking -- it uses some Windows networking capabilities that weren't available until Windows Vista, and uses a fallback on Windows XP.
If don't know if you are using Windows XP SP1 or Windows XP SP2 (or whether it SP2 makes a difference in this case).
 @gunter - Dx8 No Overbrights = No .alpha Support
#264 posted by Baker on 2016/11/26 19:52:51
@gunter - gl_overbright_models 0 + no alpha transparency ... yeah, in DX8 version there is no GL combine capability. Needs to have overbrights enabled for the transparency to work when no combine extension available.
The rendering code is a complex twisty path.
#265 posted by Baker on 2016/11/26 20:10:43
@gunter --- -dedicated issue with GL fixed.
Bubbles -- hmmmm ... interesting. Those are in fact bubbles1.dem --- are those bubble sprites for 100% sure? I'm digging into this, but s_bubble.spr is blue, right?
 @gunter - Re:gray Particles With QMB On ...
#266 posted by Baker on 2016/11/26 20:26:26
I know what is going on with the gray particles not appearing. Need to decide best way to address or maybe even make an extra qmb_ option to control behavior.
One way or another, later today you'll have those gray particles back.
#267 posted by Gunter on 2016/11/26 21:21:23
Windows XP Service Pack 3
Uh... what grey particles? Oh, was that about the chaingun weapons? It would be nice if they made sparks like when a nail hits the wall.
My ninja bubbles are definitely sprites (I did the standard water drowning bubbles in the demos too). I usually use a replacement sprite texture though. Actually, I mentioned in the past, the replacement sprite texture that is included in the Quake Retexturing Project comes out as invisible in Mark V DX, so I had to alter its opacity. In any case, I've tested this new bug just using the standard bubble sprite too, so it's not the previous issue (qmb_bubbles replace the sprites anyway). Yeah, s_bubble.spr is pale blue, usually. When I watch bubbles1.dem I can toggle qmb_active 1 and the bubbles instantly go invisible, but they re-appear as soon as I set it back to qmb_active 0.... In both DX and GL versions. Were the qmb_bubbles invisible for you in the bubbles1.dem? And did they appear to move really choppily in bubbles3.dem?
Oh my... yes, I can imagine the twisty mess of code that's doing transparency in DX, because I'm getting strange results. But transparency DOES work even with gl_overbright_models 0 ... depending on... circumstances.
For example:
r_viewmodel_ring 1
external_textures 0
gl_fullbright_models 0
grab a ring (e4m6 has one at the start) and your gun will be opaque... But not the axe. The axe is alwys transparent. But no other gun.
Unless you activate external_textures 1 (and you actually have replacement textures). Then all your guns are transparent....
Setting gl_overbright_models 1 also makes everything correctly transparent....
 Re: Bubbles/QMB
#268 posted by Baker on 2016/11/26 21:33:39
Maybe there are a few separate particle scenarios. I'll check each one out.
 @gunter
#269 posted by Baker on 2016/11/26 21:35:54
For clarity, can I get demo name + time into the demo for each separate issue so I don't miss one.
Like bubbles1.dem @ 18:45, etc.
|