Mirrored Maps - hsurdlog issues - 1x lighting and 1x cart rotation

  • If you're asking a question make sure to set the thread type to be a question!

Khuntza

L4: Comfortable Member
Dec 29, 2009
155
102
Hey guys.. Im finalising work on mirrored Goldrush and have two minor issues that I cant seem to solve. One lighting related and one to do with cart positioning..

First up lighting.. This prop is pissing me off.. It's set as prop_dynamic_overide and is removed at the end of completion of point 1. I have tried changing the receive shadows flag and I have also set an info_light as its lighting origin. I'm not sure why its still dark.

pl_hsurdlog_prop.jpg


2nd issue has to do with the cart roation on the third stage.. The cart starts off in its expected position.
pl_hsurdlog_cart_1.jpg


If it is moved forward then allowed to roll back to its starting position, like so
pl_hsurdlog_cart_3.jpg


As the cart gets back to its starting position it suddenly rotates 90 degreees sd it comes to a rest..
pl_hsurdlog_cart_4.jpg


From this piont, if it is pushed forward it re-orientates itself back to its expected position and everything is fine.

This is only occurring on the third stage and isnt an issue in stages 1 and 2. Any ideas on where I can look?

In the decompiled map, the cart setup is actually rotated 90 degess in the opposite direction to what Im seeing on this stage. I tried roatating the cart but it actually rotates the cart for the entiriy for the map.
pl_hsurdlog_cart_hammer.jpg

You can see it's actually facing the opposite direction of where it rotates back to, so I dont thing the actual prop orientation is the root cause here.

Any help or direction you can provide would be appreciated. These are litteraly the last two issues I'm working on before I can get a RC1 out. Thanks in advance!
 

ics

http://ics-base.net
aa
Jun 17, 2010
841
540
Where is the lighting origin, is it near the stairs? Like very near or far away? Try move it closer. Might not solve it though but worth a try.

On the path_track, do you have it set for "face this path tracks's angles"? Cart needs to always face right in the hammer editor, so it looks normal in the world itself.
 

Khuntza

L4: Comfortable Member
Dec 29, 2009
155
102
Thank you for the suggestions. Alas, I'm still no closer to resolving either issue..

The info_light is referenced in the stairs Lighting Origin. I also had tried having it closer to the prop, here is where it is now (kinda out in the open) and it's not made a difference..
pl_hsurdlog_stairs_hammer.JPG


For the tracks, the path_track is set to "face this path tracks's angles" already. I assume the cart follows the path_tracks and the positioning of the actual tracks are irrelevant, yeah? I've just moved the tracks and the two path_tracks a few units and Im recompiling now.
pl_hsurdlog_cart_hammer_path.jpg
 

DrSquishy

we've all had better times to die
aa
Feb 10, 2017
1,297
974
Thank you for the suggestions. Alas, I'm still no closer to resolving either issue..

The info_light is referenced in the stairs Lighting Origin. I also had tried having it closer to the prop, here is where it is now (kinda out in the open) and it's not made a difference..
Is it using vertex lighting? If so, it won't use the lighting origin
 

Khuntza

L4: Comfortable Member
Dec 29, 2009
155
102
I think part of the issue is that it's a prop_dynamic_override.. It doesnt have an option to disable vertex lighting.
 

Khuntza

L4: Comfortable Member
Dec 29, 2009
155
102
Ok.. So the cart roation issue is resolved. It was caused by a combination of output flags on the starting two path_track being combined on the second one along with the rotation of the very last path_track from stage 2. Sorted.

I could still do with some help on the lighting of those damn stairs though. Im seriously at the stage where I'm just going to make a lighter skin to mask the issue.
 

XEnderFaceX

F1 Fan
Aug 18, 2015
316
98
Is the Origin of the Stair Prop inside a Brush? If yes, then that might be causing the lighting bug
 

Khuntza

L4: Comfortable Member
Dec 29, 2009
155
102
Ok, what the actual fuck. I fixed the stair case as well.

It wasn't anything in hammer or the compile process but appears to be some kind of issue in the model itelf.

I decompiled the model and applied a renamed copy of the VTF I extracted from the game files as its texture. I then recompiled a custom duplicate of the model with the intention of then being able to then just adjust the birghtness of the texture to hide the problem.

I compiled with the new model and lighting seemed to work fine. I was just using the standard wood_floor001 VTF. So it looks like the games copy of the stair case was the problem. My custom one worked fine.

pl_hsurdlog_stairs_wtf.JPG


Net result is I'll just have to pack in a custom model and texture.

I'd be interested to hear any insights people who make custom models might have. It's a bit of a weird one.

Thanks to everone who put forward suggestions on how to these issues. Both are now resolved and pl_hsurdlog is basically ready to go.
 

Khuntza

L4: Comfortable Member
Dec 29, 2009
155
102
I had another thought about this. Probably the only difference in the prop now is the VMT in use. I'm using a super basic one I generated with VTFEdit. Something in the original VMT is probably the root cause of the darkness.

I couldn't locate the original VMT file within the VPK files.. has there been a change in where these are stored? I'd like to find it to compare..
 

DrSquishy

we've all had better times to die
aa
Feb 10, 2017
1,297
974
I had another thought about this. Probably the only difference in the prop now is the VMT in use. I'm using a super basic one I generated with VTFEdit. Something in the original VMT is probably the root cause of the darkness.

I couldn't locate the original VMT file within the VPK files.. has there been a change in where these are stored? I'd like to find it to compare..
It'd be in tf2_misc_dir - perhaps you're looking in tf2_textures_dir, where VTF files are found?
 

Khuntza

L4: Comfortable Member
Dec 29, 2009
155
102
It'd be in tf2_misc_dir - perhaps you're looking in tf2_textures_dir, where VTF files are found?

Derp, thanks. I was expecting the VTF and the VMT to be together in the materials VPK. My bad.

Looking at the original VMT, it uses the LightmapedGeneric shader. I used the VertexLitGeneric one. Ill just settle for packing the additional model and get on with it.
 

henke37

aa
Sep 23, 2011
2,075
515
Obviously you need to do prop lightmaps for that shader. And that's only for prop_static. And you need to tell vrad to compute model lightmaps.
 

Khuntza

L4: Comfortable Member
Dec 29, 2009
155
102
Yeah.. but it needs to be 'prop_dynamic_override' as its one of the props that gets removed at the end of round 1.. Theres no option to generate lightmaps.

Nowhere else in the map are lightmaps being generated for this prop either, even when its used as prop_static.
 

DrSquishy

we've all had better times to die
aa
Feb 10, 2017
1,297
974
Yeah.. but it needs to be 'prop_dynamic_override' as its one of the props that gets removed at the end of round 1.. Theres no option to generate lightmaps.

Nowhere else in the map are lightmaps being generated for this prop either, even when its used as prop_static.
Prop_dynamic and prop_dynamic_override can only use origin lighting. You will still want to use VertexLitGenetic over LightmappedGeneric as the former is intended for models while the latter brushes (I believe)
 

Khuntza

L4: Comfortable Member
Dec 29, 2009
155
102
That's my understanding now too. The original model uses a floor texture that used LightmappedGeneric.

I now have a version of those stairs that use VertexLitGeneric if anyone ever has a need for them :)
 
May 25, 2015
390
307
I might be wrong, but I believe info_lighting can only be used with prop_static, or at least it's intented to. Have you tried using another entity as the lighting origin? (The description of the Lighting Origin keyvalue in Hammer seems to imply that the correct entity to use is path_corner)