 |
The code for setting up lightgem is in function R_Lightgem_Render. I believe right now it always uses eye position as lightgem location. There is some logic to put to put location 30% between normal origin and leaned position, to adjust for crouching, etc. But right now it is not used. I guess all of it was broken during changing how lightgem works in terms of rendering (maybe 2.05?) So I would say that: 1) Use the LGPos as origin for lightgem subview rendering (lightgemRv.viewOrg). Check that lightgem works properly and nothing is broken =) 2) Make sure peeking does not modify lightgem position. I think as soon as p.1 is fixed, lightgem will behave properly while peeking. 3) Preferably move the whole stuff about lightgem position calculation into a method of idPlayer class. It is strange that frontend code contains this obviously gameplay logic. |
|
|
Here is restoring back LGPos. However, there are many more problems: 1) Moving mouse in peeked view is inverted horizontally from one side of the door. 2) It is weird that moving mouse around causes camera to slide along the door plane. At the same time, view direction is not orthogonal to this plane. The math and controls for peeking view need some love, that's for sure =) 3) I still get dark lightgem when peeking into a door from bright side. Moreover, I get dark lightgem when peeking even if there is strong light on both sides of the door. tr_subview.cpp.patch (508 bytes) |
 |
Hm, that is strange you are seeing a dark lightgem when looking into a lit room. Admittedly, I haven't really looked at this since I first reported this for Seeking Lady Leicester, but I'll do some testing later. Maybe something has changed? |
|
|
So I tested using func_peek in the 2.12 release build, and I am still getting this lightgem glitch. It's puzzling why you aren't able to replicate this. For me, the light gem changes slightly. Try this door in SLL: seekinglady (2024-03-16 12-26-08) (2580 642 41).jpg (140,796 bytes) |
 |
Lightgem while leaning was fixed recently. Can you still reproduce in the latest 2.13 Dev build? |
|
|
So I just tested this in SLL and A Good Neighbor on the latest dev build, and I'm still getting the same results; The lightgem still reflects the brightness of the room the player is peering into, not the room they are actually in |
 |
For context: I'm the guy that fixed the lightgem leaning inconsistency issue mentioned by nbohr1more. I've done testing on this func_peek problem on a custom built map to find more details. This bug will never occur if there are no areaportals involved. I've tried: - Loose func_peek entity attached to nothing - Func_peek attached to a wall with one side being dark and the other being light - Func_peek attached to a loose door (not placed in a doorway/wall) with different light levels - Func_peek attached to a proper door (inside a doorway) with different light levels NOT using areaportals All of the above cases work as expected. As soon as I put an areaportal in the doorway, the issue starts happening. I'm assuming this is somehow tied to the PVS system and its optimizations. Camera/eye position being moved behind the door into the other room, marking the "body position room" as not being in PVS anymore, therefore not rendering the light that's shining on the player's body and in turn, making the lightgem dark - from my experience it always turns pitch black, that part is consistent and actually has nothing to do with the light in the other room. As of yet, I don't have any concrete or potential solutions/suggestions because the PVS system is a bit "above my pay grade", but I'll keep looking into it when I get time. Edit: Regarding the issues with peeking mentioned by stgatilov (inverted mouse, movement on incorrect plane), I can confirm that those also exist. These seem to be problems with 3D math that are mostly isolated in the tdm_peek.script file. I'll see what I can do with those, since they're in my wheelhouse. |
- Anonymous
