New lighting for old maps

Discussion in 'Mapping Questions & Discussion' started by chickeneater, Sep 9, 2013.

  1. chickeneater

    chickeneater L1: Registered

    Messages:
    3
    Positive Ratings:
    0
    So i've recently started my journey into 'customization' and boy has that cut into my actual TF2 playtime. I'm the no. 1 fan of pyrovision, though somewhat disappointed that i've only realised you could enable it on all maps just now. Ive also replaced sky_goldrush_1, sky_hydro_1 and sky_trainyard_01 with the frag-friendly sky_harvest_night_01. So yeah, pyrovision and a purple hazy skybox, what else could anyone ask for right ?

    That's where my question comes in, i believe the lighting is attributed to the .bsp files in teamfortress2/tf/maps/ and has nothing to do with the materials/skybox/ vmt's and vtf's.

    With 0 experience in hammer, I've tried going into properties of 'entities' > 'light_environment' of a decompiled map but my nerdgasm was cut short 2 minutes in because two out of the 4 Hammer windows just displays a purple and black square texture. I have no idea what i did or am doing in hammer right now. I hope you bear with my noobness, sorry here's TLDR

    1.) Is the Koth_Harvest_Event_01 map lighting different compared to say goldrush,badwater and degrootkeep lighting if you've only added vmt's and vtf's to your custom/yadayada/materials/skybox/ folder ? I see a dark tint on harvest event.

    2.) How do i go about getting that tint on goldrush/badwater and degrootkeep short of opening the maps in hammer and editing it ?

    Thanks and cheers
    Andrew
     
  2. Idolon

    aa Idolon the worst admin

    Messages:
    1,550
    Positive Ratings:
    4,444
    Lightmap data (every surface of every part of the level has a lightmap associated with it, which is what controls lighting in Source Engine) is compiled at the same time as the map, meaning it can't really be changed aside from:

    1) hacking into the lightmap lump of the bsp and mass editing it (good luck with that)

    2) decompiling, editing in hammer, recompiling

    Both of these will also cause a mismatch map error (Map differs from server's version), so I wouldn't recommend them. Your next best bet would be some sort of color correction, but I'm not 100% sure how to go about it. This might be a good spot to start researching.

    Good luck!
     
  3. Fr0Z3nR

    aa Fr0Z3nR Creator of blackholes & memes. Destroyer of forums

    Messages:
    6,391
    Positive Ratings:
    4,906
    Should be noted that decompiling and recompiling is far more annoying than it seems, since you will have to go through and redo the optimization. When a map is decompiled, the hint brushes and stuff get cut along the vis leaves, if I remember correctly. So that needs to be redone. Area portals might get messed up and then those will have to be redone. So it becomes a huge under-going if you plan to rebuild/recompile maps.

    Larger maps might also hit the new brush limit (See: Zinkenite).
     
  4. chickeneater

    chickeneater L1: Registered

    Messages:
    3
    Positive Ratings:
    0
    Do i get 'mismatch map error' on sv_pure 1 servers ? Think those are what i play on

    Edit: Froz3n : Yeah, i did decompile them from the teamfortress2/tf/maps/ stock ones, didn't know it'd be complicated

    Anyways, thanks for the feedback

    Edit: Reckon my best bet now is to tint the skybox a bit darker and look further up when i play, lol cheers
     
    Last edited: Sep 9, 2013
  5. henke37

    aa henke37

    Messages:
    1,914
    Positive Ratings:
    448
    The error happens even on sv_pure 0 servers. The engine enforces this in order to ensure synchronization capabilities. A different brush could drastically change the result of a player action. It's infeasible to attempt to find a rule for what changes are safe, so they are all considered sync unsafe.
     
  6. Pocket

    aa Pocket func_croc

    Messages:
    4,489
    Positive Ratings:
    2,219
    I suspect that if you just wanted to make a new version of an existing map that just changes the lighting, you could do it without resorting to decompiling or editing the lightmaps by hand. Compiling a map involves three steps, each performed by a different program: Creating a BSP file, calculating the visibility and adding that data to it, and adding the lighting. I do not know if VRAD gets its light-entity data from the BSP file itself or if it has to load up the VMF to get it, but I suppose in theory you could decompile the map, edit the light_environment, and then (with the original BSP file copied to the /mapsrc/ folder) run just VRAD by itself to make it burn new lighting into the already-compiled map.

    Somebody should try that and see what happens.