 |
I don't think this will affect game balancing, as the player would never lean while having the lantern out, so this would only be an improvement for player comfort. Do you agree? Don't you? Please share your thoughts. |
 |
Changing the position of the lantern isn't a big deal in regards to implementation, and as you said I fairly doubt it will affect game balance. Players don't use their lantern when there are enemies around, I guess. Whether it will cause any other issues is something that needs testing, though, as well as the fact how it 'looks' like. |
|
|
I have had a quick look at how the player lantern is positioned. Since it is attached to the player hip, and none of the player joints reflect viewport animations (like leaning or mantling), a simple adjustment of some defs will not suffice to implement this feature. While I haven't found a final solution to this problem, I have two ideas I'd like to investigate closer: a) Add a dummy joint to the player for the lantern. The position of that joint would be adjusted whenever the viewport position is set. b) Instead of attaching the latern to some joint, calculate it's position each frame and set it directly on that entity. Currently, the game code doesn't actually know about the existence of the player lantern, so I'd prefer to stick with option a). I have found rudiments of a "camera" joint of the player model in the code, but couldn't find anything like that in our player. Maybe something like that could be reintroduced. I'll have a look at the original doom 3 files, to see if there was a "camera" joint on the player model. |
|
|
I don't see how adding a joint should solve the issue. Wouldn't this imply that said joint gets moved when performing leaning or mantling? IMHO following this approach it would me more worthwhile to overhaul the manling and leaning animations so that they represent these movements. We may have some skilled modelers able to do this. Short dated altering the scriptobject used by the lantern seems like the easier approach to me. The lantern still gets bound to the player, but its position and orientation relative to his origin gets recalculated each frame. |
|
|
You are correct. However, I think our animators (if there still are any working) can do stuff that is more worthwhile than animate a model the player never gets to see, nor has any effect on gameplay, with the exception of this new feature, which can be imnplemented a lot easier via a general dummy joint representing the camera position and orientation. This general camera joint could be utlized in scripts to have stuff appear in the player view etc., so it would have tons of possible usecases. Your proposed solution is exactly what I proposed in option b), but as noted above, the gamecode currently does not know about this lantern and I would like to keep it that way. Or are you saying that you'd be able to do that in a script without any game code support? If so, please show me a proof of concept. I'd be very interested to see how that works. |
|
|
Yeah, I was thinking about handling this via the scriptobject used by the lantern. All scriptfunctions to retrieve the required information and applying the neccessary adjustments are already present in the current code. I will try to create a poc tomorrow. |
|
|
So I've actually found an even easier way. There is a weapon entity called 'player1_weapon' that is used to bind the weapons to and that does move with leaning/meantling. I can easely attach the lantern light there. I'll attach the altered script. |
|
|
Awesome. Nice work! To complete this task, I suggest the following: - Remove all remains of the old attachment method from tdm_playerstools_lantern.def - Change the attachment position a little bit so that the produced shadows look more like before while not leaning. - Test against issue 3376, which also has a testmap. |
|
|
I've attached lanternfix.zip containing both the altered def as well as the script. Origin and rotation of the light are still read out by the script from the def, so mappers can change that easely in the def without having to fiddle with the script. I've also altered the positioning of the light a bit. You can alter it furthermore if you are unhappy by adjusting the origin setting in the definition of the lantern light. Testing against issue 3376 using the testmap provided there didn't show up any issues on my end, so this seems solved either. I might however only had luck so it would be good if someone could check against. |
|
|
I find these values recreate the original look and feel better: "origin" "10 12.5 -5" When testing, I noticed that bringing up the objectives screen actually alters the origin of the light. This is not so good. Can we do something about that? |
|
|
I will apply your suggested origin value. Regarding the issue with the objectives screen I will have to take a look what exactly is happening. If I can find out what is causing it I should be able to fix it (fingers crossed :) ) |
|
|
So I've tested it and the player_weapon entity I've attached the lantern to is lowered when the objectives screen is brought up. I guess this makes sense in some way. Personally I consider the movement of the light as minor and nothing that neccessarely requires "fixing", especially as it would either mean changing the behaviour of the weapon entity or some sort of hack to get around it. I would therefore suggest to get feedback from others to decide on whether we keep it like it is or do something about it. |
|
|
It happens also when you open the inventory and I think it looks really weird and unprofessional to keep it this way. I was trying to find references to player1_weapon, to see how it all works or if we can use something else, but I couldn't find any? Where did you find this magical entity? :-) |
|
|
I've found the entity by going third person and let TDM show the entities to me. pm_thirdperson 1 g_showEntityInfo 1 ;) So I've inspected the issue and I must admit, that fixing that is more troublesome then expected. The issue is as stated before, that under certain circumstances the player weapon and therefore the lantern attached to it gets lowered. The problem here is that the position of the weapon relative to the players viewing position also changes when the player ducks for example. This makes it complicated to keep it at a desireable position. Interestingly enough you didn't seem to notice the latter. The only clean solution that comes to my mind would be to add a new attachment position similar to the weapon one, that moves with leaning but does not perform the other unwanted movements. I still consider the issue minor and the behaviour neither weird nor unprofessional, however, and would really want to wait for feedback from others to see how urgent it would really be to fix that. I will move on to some other issues on my todo-list and come back to this later. |
 |
STiFU gave the go-ahead to merge this. |
|
|
It might make sense to also test the current solution against 0002079. |
 |
I have tried the fix. The lantern moves down due to many different events: looking objectives frobbing reading a readable picking a lock One might argue that player actually moves his hand in these cases... Leaning changes the position of the lantern (unless crouched). Leaning into the chest seems to work, but again if not crouched. Here are serious issues I had on Saint Lucia map: 1) Being on a ladder. If you face away, up or down, then the lantern disappears or produces weird shadows. 2) Being near the door, facing away from it --- light disappears. 3) In one location, lantern gets into low ceiling (as described in 0003376). Execute: setviewpos 50.73 2442.1 -302.5 51.6 -128.2 0.0 4) In another location, lantern light disappears when I'm standing near a wall. Execute: -2296.62 1096.75 18.25 38.2 -51.2 0.0 I did not test which of these issues appear with traditional lantern positioning. However, it is clear that this fix does not fix the problem reliably: it simply trades one cases for the other ones. I don't like the idea of merging it. |
|
|
It's no bugfix, but a feature implementation, though. We wanted to have the lantern move when the player leans, so you can e.g. easier see what's inside a chest, i.e., without crouch-climbing onto it. So, if problems 1-4 were already given with traditional latern positioning (which I strongly suspect), there is just the added benefit of this feature remaining. |
|
|
I'm not sure points 1 and 2 happen with current lantern. The problem is that you change the position of lantern globally, not only when leaning. Mappers could previously test and workaround some of the issues. By changing the position, you break their efforts. Moreover, the new position does not seem like being much better globally. |
|
|
The goal was to bring the lantern position as close as possible to the original position. I guess we failed at that. Maybe this could be resolved by some more value tweaking. @Obstler would you mind having another look and test the cases outlined by stgatilov? |
|
|
@stgatilov I have been reviewing this issue. Considering the many issues you reported above, I too think we should go a different direction with implementing the feature. A different attachment position is needed that meets the following criteria: -It must always be within the player collision box -It must move with the viewport (leaning, shouldering, mantling) |
- Anonymous
