Paril
commented
2 years ago Degenerate windings are triangles that are super thin that they get collapsed into an invalid triangle (one that has two identical points), so the entire face is just removed. It shouldn't be a problem in most cases, but there are known cases where this results in a missing triangle (edge outside has a couple). The second warning is because portals are generated from brush sides, but because of floating point inaccuracies it's possible for a portal winding to end up not being able to find the brush side it came from. It's not fatal but does indicate something that we should look into.
cg_add_entity_shadows 2 and 3 were experimental to try to make them look nicer on angles & allow shadows to be dropped down edges (for instance you'd see an overhang of a shadow if somebody was standing above you over a lip), but it's too buggy and I'll probably just remove it. It'd be better for us to spend our time later on doing proper shadow mapping.
We have a doppler effect applied to the listener, so when you move around sounds you'll hear the pitch shift. It might be a tad too strong. You can adjust the intensity with s_doppler (the default is 1.0 but it can be any value). It's a global listener effect so it can't be disabled per sound. It's possible our doppler is just too strong, but keep in mind you move pretty fast in the game so maybe it's just working as intended.. we can increase the speed of sound if need be.
This image here is puff_cloud on impact: seems fine to me, are you referring to a different effect? No, this image probably doesn't need to be 512x512 given the in-game sprite size.
Panjoo
jdolan
I will report here the issues that I come across while finalizing the DM maps. The more I actively work in the mapeditor again and test all kinds of things ingame, the more little bugs I find. (If I encounter more things I'll add to it here.)
Buglist:
~~Shadows start to flicker on medium and high setting. See videoclip. https://user-images.githubusercontent.com/10857572/149621498-8a7d45ba-abe5-4a95-b4bf-c32890f8991b.mp4~~
~~Footsteps sounds "are not valid". I was trying to set some footstep sounds for metal surfaces but no matter what I try it only takes 'metal' as valid sound. Even though for instance 'metal2' is in the players/common dir, it will say: "... not valid". Tried with and without the qutotes.~~
I'm not sure but I think there's a problem with themisc_soundattenuation. I want this sound to be very subtle and local so I've set it to atten 3 (cubic). Now if I move around the location of the misc_sound in spectator-mode, the pitch of the .wav seems to change up and down, depending on the distance. Because this .wav has a constant background tone it's very noticable. Here is a test boxmap with a looping .wav file. (It's all in the zipped pk3, type 'map soundtest') > soundtest.zipAlso, if you set the sound key to a wav that doesnt exist, eg. 'world/silentdummy' - the game crashes (see pic). A warning msg when it;s trying to play the missing sound would be nicer. Or perhaps include a silent.wav for when you dont want a sound? play.sample null.jpgSomething looks wrong with the _puffcloud fx. Ingame it looks tiny, almost not visible and too coloured. (Also is a 512x512 image necessary for this?)If you've set angles on a mapobject (eg. a plant model) and then later touch the mapobject to move it to another spot, the angles get deleted... (Might be Netradiant related though).
It's not possible to aim a rocket down into the lift shaft without hitting the floor. I don't know how it works but I think the origin of where the projectile shoots from needs to be made somewhat higher. cantaimdown.jpg@jdolan > a reminder to change the defaultr_alpha_test_thresholdfrom 0.8 to 0.5 like we discussed. I've made a new fern.obj plantmodel (mapobject) which needs a lower default valueJust checked https://ci.appveyor.com/project/Paril/quetoo and downloaded the latest develop snapshot from @Paril. But there seems to be a problem. Quetoo crashes after a few seconds and just look at the textures in this screenshot of a fastcompile (no light) of Edge: ohcrap~~r_caustics suggestion On most liquids the caustics look alright, really like the way it shows up above water, but on maps that have open and clear water areas like Tokays and Pits, the default caustics look too present, almost like a leopard skin. Especially against darker textures. I typed r_caustics 0.5 and to my surprise that worked and it looked better on the maps that I mentioned. But on other maps it looks better with the default 1.0 - depending on the brightness of the background textures. @jdolan You mentioned that you are baking "proximity to translucent liquid" into the lightmap and lightgrid data. Now it got me thinking, can this perhaps also be made into a
worldspawn keyjust like any other key that has to do with lighting, so that the mapper can setcausticsto override the default value of 1 for that particular map?~~~~Surface light Found these problems earlier on but I was hoping that it was something in the map, like a wrong surface flag or a misplaced light or whatever. Turns out they are real bugs that I can't fix in the map editor. In fragpipe I can't seem to get a uniform lava lighting going. Some walls get lit by a reddish glow (as expected), while others just seem unaffected by the lava surface light. Tried everything; removed fog, manually set a different light value than what is used in the material, etc. One moment they are lit correctly, then other times they aren't) lavalight1, lavalight2, lavalight3 -Also, there seems to be some light leakage going on. In the 2nd screenshot the lava from the left area was protruding under the floorbrush of the shard hallway, once I pushed the lavabrush back the reddish hue was gone.~~
~~Emitting surface light on bmodels is acting wacky This one is very strange. I couldn't understand where the strong orange lightglow was coming from in the middle atrium as seen here. At first I thought it had to be coming from the lava itself, but then it should never reach the floor of the quad room. The only light source close by was the little yellow lamp texture, on that moving platform. That surface light is only set to 100 in my material so that couldn't be the cause for all that light, but as it turned out, it was. Once I changed that lamp texture for something else, all the extra light was gone.~~
~~misc_model _alphatest no longer works on misc_models -> (miscmodel.pk3 testmap) misc_model-alpha~~
~~Clip holes & compiler warnings There seems to be something going on with content_clip brushes. Look at these images, it's from that little rock in the outside area in Edge but it was also happening with the terrain near the tunnel exit where I had added clipbrushes. (Although it may not be visible in the current Git version of Edge).
With the warnings still there, I've already gotten rid of the holes in the rocks and terrain by adjusting the clips so that they don't intersect with the other solid brushes so much.Admitted, it's pretty intricate brushwork there, but either way I don't think clipbrushes should create visible holes or even split brushfaces. (Not sure about the latter though). ... clip-editor clip-wireframe-overlay clip-removed~~~~Flares draw order This isn't a new bug but in some maps it's become a problem since it's clearly a visibility bug. - In the map Pits I want the water opaque again, just like the original map, but as you can see here the flares are visible from under the water and also shine through entity models. flares-prob~~
~~Armor respawns In Quetoo armor respawns currently after 40 seconds. In Q3 it respawns after 25 seconds and in Q2 after 20 seconds, which to me always felt a bit too fast. So 25-30 seconds would probably suit best. I don't know if anyone would mind to change this back, but game elements like this should probably be kept more or less the same as other Quakes.~~
~~Rocketjump height With the current rocketjump velocity it's too easy to overshoot your target spots. I can't reach heights over 384 units but anything around 256 is way too easy to each. Perhaps a middle ground like 288-320 units would be better and less noobish?~~
~~Crushers _funcplat: these will now crush you to death if you get stuck under them and there's no key that I can set to stop them from doing it. _functrain: if you get crushed by the two moving pilar-platforms in Fragpipe's slimepit, you'll see nice fireworks.~~
Slime dmg is still not set to damage per second so it kills the player way too fast. The mapper should have the option to set this.~~Player’s boundingbox should be able to fit in 64 unit height spaces or at least 68 units, without having to duck. As of now he doesn’t even fit in 68 units. (In cg_third_person you can see the playermodel will easily fit when standing upright). Examples: Fragpipe - the area with the Megahealth. I’ve already raised the ceiling as much as possible but this guy still has to duck here to get under: tootalldude Pits - the staircase with jacket armor underneath has a opening of 68 units high but you have to duck to get under. Hallways - the cornerstairs that has the combat armor underneath. Lavatomb - the two secret doors (64 units) next to the sinking pillars. From the outside you can walk right in without having to duck, but from the inside you have to duck first.~~
fps ? The game runs okay on my 12 yr old pc (that I mainly use for editing), but there's something that I noticed while checking the fps. I've set vertical sync off and the framelimiter to 250 since I usually don't get much more than that, and on average in most maps it's around 115-190 (with just me walking around). Setting the framelimiter to 0 seems to lock it @ 59 fps, which is not what I expected, I expected it to allow the fps to reach its true max. On the smallest test maps the fps is not even breaking 200, and I'm talking about a "map" that consists of 10 brushes and 3 simple alpha_test plants. That doesn't seem right. ... As you can see here, if I'm in spec mode and fly outside the map the fps is at its max, but I've never seen it go over 250, regardless of fps settings. As soon as I fly inside the playable map area the fps drops to 168. I would have thought that this game would easily run a box map at a much higher fps, even on this pc. I wonder what is going on here, why would running a box map give me almost the same fps as running a real map that has 1800 brushes and dozens of entity models?
...
See screenshots below. When I'm tuning specific areas I usually like to just block out the rest of a map to speed up the compile. So this is only a small portion of the map dm4-hallways. In spectator mode, the soon as fly inside the map you can see the fps drop, from 250 to 110. But as it's not even a quarter of dm4 (~500 brushes) I expected better results.
...
Outside the map: ~250fps / Inside the map: ~110-140
dm4portion1 / dm4inside
Water fx = fps killer In tokays if I'm looking up from under the water I lose like 50 frames per second. Especially transparent water + the splash sprites is a real fps killer. And it almost looks like a bright white nuclear dot anyways, you can't even see all the actual splash textures. (water-fx-fpskiller) this is from the same location as shown above. The fps goes from low (110) to lower (43) when I shoot the LG in the water. And this is not even the entire map but only a small portion of it, 3/4 is blocked out. The water splash still uses waaaay too many animations and it steals too much framerate.
[new]
Swimming [ bug returned] .1. When you're in the water and you touch the bottom, it won't let you swim upwards at all unless you press the
+move_upkey.-Lightmap unwanted lines Sometimes lightmaps get cut off and it produces an abrupt break in the lighting of the texture, for instance see these pics:
If the light emitting surface (the slime) has a light.radius of < 70 it produces a break in the lightmap here. But if I increase the light.radius to 80, the lightmap doesn't break and fades out with a smooth transition. It almost seems as if there is some sort of threshold.
..
Also, I sometimes like to set a different light value on liquid brushes if needed with the Surfaceflag-editor, without changing the overall value in the material. This has always worked but if I do this now, the surface won't emit light (while Light flag is checked) and the texture shows as fully opaque.
Direct patch light on liquids oddity I was testing different light values on liquid slimebrushes and noticed that the base texture now has these weird glowing lines. Here's a screenshot of just the base textures without the scrolling stage layers. Looks like you're using some sort of tile texture as patch lightmap?
..
Anyway I was trying to mask these obvious lines by setting the base slime tex as liquid (warp) but it doesn't seem to do anything. Tried both with the surfaceflag in the Editor and in the materials. In fact, more Surface flags in the Editor no longer seem to function properly. ...
Slope bouncing While doing some work on Slimyplace I noticed that the player almost gets catapulted when running and jumping up steep slopes, like the ones shown in this pic :