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

Discussion in 'Mapping Questions & Discussion' started by Khuntza, Jan 19, 2019.

  1. Khuntza

    aa Khuntza

    Messages:
    150
    Positive Ratings:
    76
    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.

    [​IMG]

    2nd issue has to do with the cart roation on the third stage.. The cart starts off in its expected position.
    [​IMG]

    If it is moved forward then allowed to roll back to its starting position, like so
    [​IMG]

    As the cart gets back to its starting position it suddenly rotates 90 degreees sd it comes to a rest..
    [​IMG]

    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.
    [​IMG]
    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!
     
  2. ics

    aa ics http://ics-base.net

    Messages:
    814
    Positive Ratings:
    513
    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.
     
    • Like Like x 2
  3. XEnderFaceX

    aa XEnderFaceX

    Messages:
    244
    Positive Ratings:
    72
    Dont you need to enter the name of the info_lighting into the Prop?
     
    • Like Like x 1
  4. Khuntza

    aa Khuntza

    Messages:
    150
    Positive Ratings:
    76
    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..
    [​IMG]

    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.
    [​IMG]
     
  5. DrSquishy

    aa DrSquishy ???

    Messages:
    1,211
    Positive Ratings:
    779
    Is it using vertex lighting? If so, it won't use the lighting origin
     
    • Like Like x 1
  6. Khuntza

    aa Khuntza

    Messages:
    150
    Positive Ratings:
    76
    I think part of the issue is that it's a prop_dynamic_override.. It doesnt have an option to disable vertex lighting.
     
  7. Khuntza

    aa Khuntza

    Messages:
    150
    Positive Ratings:
    76
    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.
     
  8. XEnderFaceX

    aa XEnderFaceX

    Messages:
    244
    Positive Ratings:
    72
    Is the Origin of the Stair Prop inside a Brush? If yes, then that might be causing the lighting bug
     
    • Like Like x 1
  9. Khuntza

    aa Khuntza

    Messages:
    150
    Positive Ratings:
    76
    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.

    [​IMG]

    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.
     
    • Like Like x 3
  10. Khuntza

    aa Khuntza

    Messages:
    150
    Positive Ratings:
    76
    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..
     
  11. DrSquishy

    aa DrSquishy ???

    Messages:
    1,211
    Positive Ratings:
    779
    It'd be in tf2_misc_dir - perhaps you're looking in tf2_textures_dir, where VTF files are found?
     
    • Thanks Thanks x 1
  12. Khuntza

    aa Khuntza

    Messages:
    150
    Positive Ratings:
    76
    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.
     
  13. henke37

    aa henke37

    Messages:
    2,042
    Positive Ratings:
    490
    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.
     
    • Like Like x 1
    • Agree Agree x 1
  14. Khuntza

    aa Khuntza

    Messages:
    150
    Positive Ratings:
    76
    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.
     
  15. DrSquishy

    aa DrSquishy ???

    Messages:
    1,211
    Positive Ratings:
    779
    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)
     
    • Like Like x 1
  16. Khuntza

    aa Khuntza

    Messages:
    150
    Positive Ratings:
    76
    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 :)
     
  17. Dr. Orange

    Dr. Orange L6: Sharp Member

    Messages:
    387
    Positive Ratings:
    292
    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)