|
Posted by Baker on 2016/11/19 04:53:11 |
http://quakeone.com/markv/
* Nehahra support -- better and deeper link
* Mirror support, "mirror_" textures. video
* Quaddicted install via console (i.e. "install travail")
* Full external texture support DP naming convention
* Enhanced dev tools texturepointer video inspector video
* IPv6 support, enhanced server capabilities
* Enhance co-operative play (excels at this!)
* Software renderer version (WinQuake)
* "Find" information command (ex. type "find sky")
Thanks to the beta testers! NightFright, fifth, spy, gunter, pulsar, johnny law, dwere, qmaster, mfx, icaro, kinn, adib, onetruepurple, railmccoy
And thanks to the other developers who actively provided advice or assistance: Spike (!), mh, ericw, metlslime and the sw guys: mankrip and qbism.
/Mac version is not current yet ...; Linux will happen sometime in 2017 |
|
|
#1412 posted by mh on 2017/02/20 00:13:00
I think it's safe enough to say that nobody else has even seen that bug.
You might give a little more info. Map? Custom progs? Etc?
#1413 posted by PRITCHARD on 2017/02/20 01:15:24
I first mentioned this happening in post #1182, here's the link I posted back then: https://streamable.com/4an03
That's a RJ6 map, and I'm pretty sure that pack used original id1? Anyway, what happens is that if I die and click lmb to restart the map, I start the map "dead" like in the video. Except I can swing my invisible axe and make particles, also shown in the video. I'll see if I can make it happen again soon and try collecting more evidence.
@pritchard
#1414 posted by Baker on 2017/02/20 02:38:43
Here is me playing that map ...
http://youtu.be/JjmY5L5kROY
Kinn was playing that map in WinQuake and he didn't say he had a problem with dying and spawning wrong.
There are tons of QuakeC bugs (i.e. the progs.dat).
A demo and a savegame would be something to go ;-)
#1415 posted by PRITCHARD on 2017/02/20 02:41:47
Yeah, I'll try playing some id1 maps tonight and see if I can get it to happen. I've had it happen both in that map and one other which I forget the name of. The other one was a mod though so it's not as useful.
#1414
#1416 posted by killpixel on 2017/02/20 04:57:32
I've experienced this numerous times (can't confirm the axe thing, never tried) with vanilla quake. I was unsure if the behavior was intentional and too busy to check.
#1417 posted by Gunter on 2017/02/20 05:27:07
The two new Mark V users played again tonight, and both experienced the disconnecting issue when loading a new level. One of them had fiddled with his firewall and thought he'd maybe fixed it, but nope. It only happened to them one time each. It's odd that both of them are having the issue, since they have different setups.
One is from Texas, one is from Canada. One is Win7, the other Win10.
The error they said they got was "level load failed"
One said he usually spams the console with "ping" to sometimes get back in... but I guess it didn't work this time.
I told them to try and come here and post any more details if they could figure out anything else.
Other than that, they really like Mark V, heh.
#1418 posted by Baker on 2017/02/20 06:49:45
You might need to adjust your server's connection timeout, and to be honest as a non-server operator I'm not 100% on how that's done.
Are they using external textures or lots of external fluff? (If they using the really high res versions of an external texture pack, the impact is going to be multiplied.)
During reconnect, if someone is using a lot external textures it increases the load time and can increase it beyond the connect timeout.
I've played a number of multiplayer games on your server. Never had any level change problems ever.
But I don't use external textures except if I am doing testing that needs it.
#1419 posted by PRITCHARD on 2017/02/20 07:55:34
I think I found out how to repeat the bug: it happens when you die after reloading a save. Or at least a quicksave, I haven't tested with regular saves but I'd assume it's the same. Can anyone else make this happen, or just me?
https://www.youtube.com/watch?v=RO3WH0RL1kI&feature=youtu.be
#1420 posted by Baker on 2017/02/20 16:18:02
I'm able to reproduce this problem. I'll see what's up when I have time.
#1421 posted by mankrip on 2017/02/20 17:11:19
#1385
The "semi-official" 32-player deathmatch map death32c, still available on ID's FTP server (ftp://ftp.idsoftware.com/idstuff/quakeworld/maps/) has lightmapped water.
And the lightmaps are messed-up
[...]
other maps with messed-up lightmaps on water surfaces may very well be out there in the wild, but in the absence of engine support for lightmapped water nobody was ever aware of them.
[...]
Since lightmapped water is a new feature I suggest a worldspawn key indicating it's presence. That way engines that don't support it can ignore it. Engines that do support it can pick it up. Maps like death32c aren't subject to false positives.
#1389
DarkPlaces shows the same problem on death32c
Just because mh, lordhavoc and others don't know how to reliably detect lit water, it doesn't mean it's impossible. Retroquad never accepts false positives.
Cluttering the tools and engine code with a worldspawn key for this is pointless, and only serves to hide the fact that the engine's support for lit water is done poorly.
Also, let me rectify Baker's false statement @ #1285:
Mankrip said maps like e1m4 don't compile with lit water.
This is false. What I said is that a few ID1 GPL maps such as e1m4 has countless leaks. This means that their VIS data can't be compiled, which has nothing to do with the lighting. I've already compiled it with lit water and no VIS ages ago, but I wanted to be able to get the VIS data compiled too.
Until someone steps forward proving any of this stuff works and is polished ... I'm not sold.
The solution in Retroquad works flawlessly, is robust, clean and polished. But I try not to care about proving stuff for others. Nobody ever asked me about it, it would just make me seem bitter, and I'm sure I've already mentioned ages ago that the Retroquad implementation of lit water was finally perfect.
Also, <a href="https://twitter.com/mankrip/status/774418444523606016">by the end of last September, EricW's implementation in the light tool was already perfect too. I've done extensive testing for him and showed it when the final problems got fixed.
</a> Fail
#1422 posted by mankrip on 2017/02/20 17:15:07
#1423 posted by Gunter on 2017/02/20 17:45:52
I always have net_connecttimeout set to 45 seconds, and I know the players with the connection trouble aren't using any external textures (I keep telling them they should try the external textures, heh).
It could very well be some issue with the server. It's just odd how it only affects certain players, and it affects them repeatedly, but nobody else. Extra odd how it affects BOTH these two new players....
Though the fact that it's known that typing "ping" in the console can sometimes get around it, would indicate that it's been a Quake issue for a long time....
I can't really provide enough information about it to really troubleshoot :/
@mankrip
#1424 posted by Baker on 2017/02/20 18:22:08
I didn't know the GPL map sources for e1m4 had leaks. I thought when you mentioned the problem that it was a tool issue when using lit water.
Anyway, the conversation evolved a lot since then and yeah ... I'm sold now.
But my non-belief was largely due to the apparent non-existence of any known test maps.
When avirox, myself and gb were working on true rotation, we made a number of test maps with QuakeC sources, engine sources, .map files and map compile instructions.
@gunter
#1425 posted by Baker on 2017/02/20 18:47:52
I guess if one of them could play using "developer 1" and also record a demo, then the next time they get the problem zip up the demo + qconsole.log, there would be some information to go on.
From your description about how typing "ping" helps, it sounds like a message got blocked by a firewall in a non-NAT fixed client.
If I had a qconsole.log where developer 1 was enabled where one of these players had the problem, I might be able to learn more.
I just now connected to your server, I don't experience this problem. And apparently you don't.
At the moment, there really isn't enough information to speculate.
Mankrip
#1426 posted by ericw on 2017/02/20 19:45:01
So how do you detect that those water faces weren't compiled with lit water?
#1427 posted by mh on 2017/02/20 20:50:34
I obviously can't speak for Mankrip, but I adopted Spike's suggestion of checking the styles too, and confirmed that they were all 0. Lightdata offset for these surfaces was also 0, so whichever light tool was used clearly left the surface uninitialized rather than explicitly setting offset to -1.
My current tests looks like this:
1) Initialize loadmodel->litwater to false at the start of Mod_LoadFaces.
2) Check lightdata offset as standard; if it's -1 there's no lightmap so none of the rest applies.
3) As an additional check test all styles for 0 and lightdata offset for also 0; if this check passes then we have an uninitialized surface so also no lightmap.
4) Otherwise there is a lightmap; at this stage check if the surface has a water texture and if so loadmodel->litwater goes to true.
5) Finally when building the surface polys and lightmaps, I set surf->litwater to the value of m->litwater.
It's clear what happened here; the code that correctly initializes the face for no light ( https://github.com/id-Software/Quake-Tools/blob/master/qutils/LIGHT/LTFACE.C#L489) must have been removed from whicever tool was used for lighting this map.
#1428 posted by mankrip on 2017/02/20 22:17:14
ericw: Detecting maps compiled with lit liquids.
mh: whichever light tool was used clearly left the surface uninitialized rather than explicitly setting offset to -1
That's not a problem, because there's no need to initialize the surface cache parameters since they should be ignored on non-lit surfaces. See my code on the link above.
My current tests looks like this:
1) Initialize loadmodel->litwater to false at the start of Mod_LoadFaces.
That is bad. Non-lit surfaces are defined on a per-texture basis, and it's perfectly possible for a map to be compiled with both unlit slime and lit water, for example. The engine should not use a global setting for this.
4) Otherwise there is a lightmap; at this stage check if the surface has a water texture and if so loadmodel->litwater goes to true.
There's no need to tie the engine's lightmap usage to texture naming conventions.
One of the potential ideas I have is to implement support for non-subdivided unlit surfaces with regular textures: for example, surfaces using fully black textures (or textures with fullbright texels only) could be rendered much faster this way.
the code that correctly initializes the face for no light (...) must have been removed from whicever tool was used for lighting this map.
It was not removed, because what truly defines the lack of lighting on specific surfaces is not the face data. The map was correctly set to use no lighting.
#1429 posted by mh on 2017/02/20 22:46:37
TEX_SPECIAL works cleanly. I guess the fact that it's unused in the engine made it easy to miss.
That's not a problem, because there's no need to initialize the surface cache parameters since they should be ignored on non-lit surfaces. See my code on the link above.
I'm actually talking about the face having been left unitialized by the light tool, not by the engine.
If you check the link I posted to LightFace ( https://github.com/id-Software/Quake-Tools/blob/master/qutils/LIGHT/LTFACE.C#L489) you'll see that what it does is first set offset to -1 and all styles to 255, then does the TEX_SPECIAL check.
A face with TEX_SPECIAL should also have offset -1 and styles 255. death32c has faces with TEX_SPECIAL and offset 0, styles 0.
The only concern I have about using TEX_SPECIAL is that it's set by the bsp tool, not the lighting tool. This may be purely theoretical: are there any bsp tools that don't set TEX_SPECIAL?
Ohh
#1430 posted by ericw on 2017/02/20 23:15:23
nice catch, those water faces in death32c have the TEX_SPECIAL flag set on their texinfo. So I agree there should be no need to have special handling for styles = (0 0 0 0) and lightofs = 0; seeing TEX_SPECIAL is enough to indicate that they are meant to be rendered fullbright.
#1431 posted by mh on 2017/02/20 23:24:28
Lest my questioning be thought of as criticism, I'm actually really happy with the outcome of this. I was able to simplify a bunch of horrible code and the case where one liquid type is lit but another unlit just falls out naturally from it.
It's rare in Quake that the right solution turns out to be so simple, but this is one of those moments.
@pritchard (@mh @mankrip @ericw)
#1432 posted by Baker on 2017/02/20 23:36:03
Pritchard, awesome beta testing work you did in identifying the situation causing the problem.
I've identified and solved the issue.
@mh @mankrip @ericw - pretty cool discussion sorting out the inner mysteries of lit water. It's nice to see lit water look like it getting closer to go "prime time" from the bsp editor to the compiler tools to the engine.
#1433 posted by mh on 2017/02/21 00:30:20
I guess the only real outstanding questions I have are (firstly) relating to dynamic lights.
Specifically: should unlit water surfaces receive dynamic lights?
Now, I would LOVE to put dynamic lighting on all water surfaces, lit or not. But it's admittedly easy for me because I've decoupled dynamic lights from lightmaps - it's just commenting out one line of code. (This also made it easy for me to add dynamic lights to BSP brush models.)
The other one is interaction of lightmaps and translucent water.
I've pretty much decided that translucent objects of all kinds (water, glass, etc) don't get lit - they're translucent so light goes through them rather than reflects off them. So instead they're drawn fullbright but with translucency.
#1434 posted by PRITCHARD on 2017/02/21 00:50:31
I think this has been brought up before, and I stand by what I said back then. Lighting translucent surfaces is the way to go. I think it would look more accurate, considering that surfaces which are semi-opaque (i.e. 99% of water/brush alpha uses) will still catch/reflect some light in real life.
Also, having to choose between lit water and transparent water would suck.
#1435 posted by ericw on 2017/02/21 00:56:57
This may be purely theoretical: are there any bsp tools that don't set TEX_SPECIAL?
The only one I know of is the -splitspecial flag from TreeQBSP (which is in tyrutils, as well as Bengt's TreeQBSP). TxQBSP (as well as id qbsp) always set TEX_SPECIAL for texture names starting with * or sky in map.c:FindTexinfo.
I guess if someone happened to compile a map with TreeQBSP/tyrutils and used "-splitspecial", and then used whatever light tool was used for death32c.bsp, we could have false positives again, but it seems pretty unlikely.
#1436 posted by TERMiNAL on 2017/02/21 01:48:25
The SQLauncher is AWESOME.
I've been renaming all my map titles in the Quake folder to the actual name of the maps, and I can just use SQLauncher to play them. It takes a bit more time renaming everything, but it's much neater. And you will actually the map title.
Quake Injector is a bit buggy, I just prefer to download maps from Quaddicted one at a time so I know what I'm getting.
|
|
You must be logged in to post in this thread.
|
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.
|
|