#276 posted by Baker on 2016/11/27 00:18:21
@gunter --- when you were doing the auto-connect test earlier were you using port 26000? Doesn't change that the Spiked Quakespasm networking code prefers Windows Vista and later operating system for best results and certain enhanced features, but server auto-detect requires server using port 26000.
#277 posted by dwere on 2016/11/27 00:30:37
Is it monster_banshee?
Yes, it's one of them. The other one is called "Takahiro Rider" (don't know the internal name).
Off the top of my head, a banshee can be found on d8.bsp. Cheat yourself keys to speed things up, go to the yellow lift. You'll end up in a big square room. The banshee mech is gonna be revealed when the middle section opens.
Sorry, should've told that earlier.
#278 posted by dwere on 2016/11/27 00:33:04
The ones in d12 work for me, but on d8 it appears without head most of the time.
@dwere
#279 posted by Baker on 2016/11/27 00:35:59
Haha ... yeah that doesn't look right. The top isn't there.
#280 posted by Gunter on 2016/11/27 00:45:03
Yep, default port 26000
I don't suppose these monsters you are looking at have skins with alpha transparency? That caused my replacement bubble sprite to be invisible....
@dwere - Malice Multipart Monster
#281 posted by Baker on 2016/11/27 01:00:28
You can type sv_novis 1 for that map to make even the top part of the monster visible in that room.
The upper model (banbody.mdl) is highly unusual as it is highly above the model centerpointer ("the origin" in QuakeC).
On the server side, I think it thinks that part of model is in the ceiling.
A can't change how server side visibility works, it would potentially bust modern compatibility with modern map releases.
Mark V WinQuake tries to handle it like the GLQuake engines for consistency.
/At some point, I might do some more thinking since technically "WinQuake is, by, definition actual Quake" -- but in practice, the GLQuake engines have been the dominant ones for 15 years -- which is why I made Mark V WinQuake handle things like a GLQuake engine. It isn't immediately clear if there is any change that could resolve this without breaking something else as a side-effect, but many times after thinking about things for a few days I might get an idea.
I was hoping using NightFright's Malice .vis files might fix, but it didn't.
I See
#282 posted by dwere on 2016/11/27 01:08:08
Well, thanks for looking into it anyway.
Malice
#283 posted by NightFright on 2016/11/27 02:32:34
I also experienced this back then when I was testing Malice by myself. However, I was focussing on the showstopper bugs that had still exited back then.
In case you don't find a way to solve this, it's not the end of the world imho since the addon itself remains quite playable. Which is quite something.
#284 posted by Baker on 2016/11/27 03:20:19
I've already outlined possible solutions.
I do not like incompatibility.
I want the engine to be able to play everything the way it is meant and the way it worked with original Quake.
I'm hardcore about that.
#285 posted by Gunter on 2016/11/27 05:51:48
The qmb lighting bolt has transparency problems with vid_hardwaregamma 0
The lower your txgamma setting, the more noticeable it gets. Or maybe just modifying the setting makes it stick out more....
Just shoot some lightning and do a freezeall and you'll see what I mean.
Actually, now that I'm looking for it I can see it faintly when using hardware gamma too -- it's just more noticeable using txgamma.
But the view blends... the view blends look PERFECT when using txgamma.... Not too dark, not too light. I guess gamma adjustments really mess with those.
#286 posted by Gunter on 2016/11/27 06:15:37
... and I'm REALLY picky about my view blends.... But these look JUST RIGHT.
#287 posted by metlslime on 2016/11/27 08:24:32
The axe is alwys transparent. But no other gun.
Axe is the one gun without fullbright pixels, so probably follows a different codepath that doesn't use the fullbright mask.
#288 posted by Baker on 2016/11/27 08:43:50
What metlslime said.
@gunter ... since you can find moving sprites (I honestly don't know of any moving sprites in any mod except yours, makes lerping of sprites real hard to test), the QMB bubble's lerping in next build will be test candidate.
If you say it works, fine -- I'll apply lerping to all sprites.
#289 posted by ericw on 2016/11/27 09:22:03
I honestly don't know of any moving sprites in any mod except yours, makes lerping of sprites real hard to test
Go into the water in e1m4, the air bubbles coming from the doorway on the right side are moving spirtes, I think? The player makes them when choking, too.
#290 posted by metlslime on 2016/11/27 10:06:51
steam & flame in rubicon 2 are sprites.
@dwere - Malice Multipart Model Solved.
#291 posted by Baker on 2016/11/27 10:19:10
@ericw -- e1m4 .. keep forgetting about those bubbles.
@dwere - sv_setmodelrealbox 0 -- before map load gets the job done.
Is no doubt an ok setting for playing the entire Malice mod. Like "game malice; sv_gameplayfix_setmodelrealbox 0" in console which reverts to ancient style WinQuake culling boxes.
sv_gameplayfix_setmodelrealbox defaults to 1 (1 = FitzQuake culling/physics box, 0 = WinQuake culling/physics box).
That banbody.mdl model is pretty awkward, I don't if it thinks it is in several visibility leafs or just all the ones it thinks it is in are wrong or what.
Mark V - Build 1008
#292 posted by Baker on 2016/11/27 12:26:59
Download at normal location:
http://quakeone.com/markv
Changes
1) Removed all the internal testing commands except "dir" (c0burn).
2) DX8 build: equivalent .alpha appearance for .mdl (gunter)
3) sv_gameplayfix_setmodelrealbox 0 improved for Malice (dwere)
4) Sprites like E1M4 bubbles are now lerped (gunter).
5) QMB bubbles should behave like normal bubbles. (gunter).
6) Autosaves are named auto_save_0.sav to 2
7) GL/DX8 version can do -dedicated again ok.
/Typing "version" in the console will show as build 1008.
@metlslime - the more sprite examples the better. ;-)
@gunter - Pay close attention to sprites and if you could, could you give the WinQuake build a look too. I don't expect problems, but without a lot of live testing, I'm always suspicious of any change.
@dwere - This Malice multi-part model on d8 map is a great compatibility test case. First example I know of where FitzQuake bounding boxes cause unwanted culling. It is extremely rare and due to that, hard to find any examples at all. Conversely, Mark V WinQuake adopted FitzQuake bounding boxes as part of first version because it solved a glitch in the X-Men mod where items disappeared if you stood in the right place.
sv_gameplayfix_setmodelrealbox ...
0 - WinQuake (-16 xyz to 16 xyz)
1 - FitzQuake (measure model, default)
For Malice, set sv_gameplayfix_setmodelrealbox 0 before loading a map or save game and everything should be great with any multipart models.
Next update will contain:
1) Alpha channel support for 2D replacement textures, current support is alpha mask only (yes/no).
2) Rewire QMB to be more consistent with particles and be able to turn precise particle behaviors off. (+ alpha channel issue with txgamma)
#293 posted by Gunter on 2016/11/27 17:19:27
4) Sprites like E1M4 bubbles are now lerped (gunter).
5) QMB bubbles should behave like normal bubbles. (gunter).
Uhhh, the first thing was never a problem. It was ONLY the qmb bubbles that were being weird. All other sprites were always fine and smooth-moving. So I don't know what you fixed, but you might wanna un-fix it to be safe, heh.
The second things is definitely improved. The qmb bubbles now move smoothly, BUT the "sometimes invisible" issue still remains. I tested on the actual server and in the previously-recorded demos I made. So, if you watch bubble3.dem now with qmb bubbles, they will move smoothly. But with bubble1.dem you will see no bubbles at all....
This is a tricky one. All I know for sure is that if the level has been running for a while, the qmb bubbles are no longer being drawn. Resetting the level brings them back.... I'm going to try this locally by leaving Quake running for a while to see if it is just an issue when connected to a server.
Hm, things now render transparently no matter what the gl_overbright_models setting is, BUT now gl_fullbrights affects them the same way:
gl_fullbright 1 = most weapons opaque (not axe) unless using custom textures (must be as metlslime said, and the custom textures don't contain fullbright pixels). Illusionary ent guy is also opaque.
gl_fullbrighs 0 = everything transparent, including illusionary guy.
Also, toggling external_textures does not affect sprites (like the bubble and light ball sprites in id1\progs\) until level change.
#294 posted by Gunter on 2016/11/27 19:04:19
Mmmkay, verified: after running a map for 35-40 minutes, qmb bubbles become invisible.
Tested on e1m1 and reproduced. Go stand by the mega health and jump in the water and drown a little bit. Watch your QMB bubbles pop out and float above you.
Now sit there and idle for 40 minutes... You don't need to do anything else in Quake. Now jump in the water and drown a little more, and you won't see any bubbles unless you disable the qmb effects.
Oh, you don't wanna sit there for 40 minutes to test this? No problem! Just set host_timescale 100 or 1000 and run the clock up to around 40:00 and you get the same result!
Isn't that weird?
Ah, it's easier to test by going to e1m4 in single player, noclip, notarget and go stare at the bubbles underwater. Mess with your timescale.... I have found that the qmb bubbles go away like clockwork at: 34:08
QMB Bubbles: "This level is taking too long! I'm outta here!"
#295 posted by Mugwump on 2016/11/27 19:27:15
34'08" = 2048 seconds, or 8*256. Sounds like a pretty significant number to me. Does it give you guys a clue?
#296 posted by Gunter on 2016/11/27 20:00:40
Ooo, good catch. I never would have considered that.
Hmm, I have no idea what the engine code looks like, but just making a complete guess, perhaps if there is some property of the qmb bubbles being set by:
time / 8
then once time gets to 2048 or higher, that calculation produces a number of 256 or greater, and that might be "our of range" for some Quake calculations....
Like particle color generally ranges from 0-256, but it wraps around so that 256 is treated as 0, 257 as 1, etc.
Build 1009
#297 posted by Baker on 2016/11/27 20:21:33
Temp Build before I continue trying to clear queue ...
http://quakeone.com/markv/mark_v_1009.zip
- DX8 .alpha fully addressed now?
- Removed sprite lerping, since it produced no rendering difference.
/Temporary middle point before build 1100
#298 posted by Baker on 2016/11/27 20:33:40
@gunter - Live toggle of sprite textures --- would be too time consuming (15 hours), mostly because I never thought of sprites when writing the live external textures toggle. Maybe someday.
I'll see what is going on with 34:08 too, while I'm getting QMB pacified.
#299 posted by Gunter on 2016/11/27 20:58:10
The scr_showpos 1 crash on startup has returned....
Hm, I have to set either gl_overbright_models 1 OR gl_fullbrights 0 to get transparency.
And the transparency looks very different depending on which one I set. With gl_overbright_models 1, no matter the fullbright setting, things look much less transparent.
Hm, yeah, it's like the gl_overbright_models 1 effects is being drawn on top of the gl_fullbright 0 effect.
On the positive side, I like having all the exes in only one zip file to download, instead of separating them like on the Mark V web page ;)
#300 posted by Baker on 2016/11/27 21:13:27
scr_showpos 1 crash on startup has returned
Are you sure? Can't reproduce. Does "version" say build 1009?
If you are getting it, what method are you using to set it? Did you add to command line or autoexec or config.cfg?
|