duzenko

Ideally volumetric projected lights could have separate shadow implementation (just one projection instead of 6) and its shadow map would be used even when 'normal' lights are on stencil @stgatilovCan you tell me what the problem with lightgem seems to be? I think we should just skip volumetric during the lightgem pass

I'm very excited to see the first actual subtitles being added

r_showsmp prints something when set to 1 Anyway, does the parallel job cvar help with fps and GPU load any? And what is your fps?

getviewpos? r_showsmp? GPU load as reported by Afterburner/task manager?

What is your problem exactly?

Right

r_useparalleljob... something

For now I think mapper has to manually adjust the light so that it does not intersect any walls, etc

No one has complained because no existing mission features it yet OTOH a cvar is better than nothing and we can return to this later I still like LOD better for this

You realize that the mission creators don't target your PC specs? Why do you insist on having it with all bells and whistles at 60 fps? Feel free to contribute a source code patch that would achieve that, it would be very much welcome, but understand that the next mission that comes out after that will push the graphics details even further and you will have to start from scratch again Did you try the parallel jobs cvar like I advised above?

Originally I tied it to Level of details, but @stgatilov moved it to a new cvar, making it IMHO harder for 'normal' users to configure

Try it with parallel jobs on

Can we have some walkthrough spoilers in the first post, like where to get lock codes, etc.

How does it end? Did he get reunited with the family objective complete?

Do we support the old backend in 2.10? Seems to have no frob highlight?

Those are for custom GUI's in new missions

What about lightgem? I remember that being major drama trigger. It breaks missions!11

Should work in the next beta In this version I think you can uncomment the materials in tdm_camera.mtr and that should do it

We could argue that players seeing the light with their own eyes would assume they will have to stay out of it. I'd say it might be rather frustrating UX to never know if a light is going to tag you or not. I mean, it's the ultimate goal here - to let player through but the player themselves has no way to know if the light in front of them is decorative or not.

The logic behind this thing is confusing me How come visible lights aren't supposed to be affecting LG and AI? Quite counter-intuitive to players as well

In alternative reality I can parse pdb's and get all type info from there

I have no idea!11 I can see that text save code calls class methods to get members, could it be it? No idea how it works with sizeof/offsetof though, maybe those are immune to access modifiers?

Sorry, reverted that

glTexStorage2D/glCopyTexImage2D conflict

What is more important, how to prevent the uninitialized spam in the console for regular - no type info - builds?